Hi Alan, Thank you for the review and comments.
We prepared a PR to address these at: https://github.com/boucadair/policy-based-network-acl/pull/18/files Please note that for this one: > It may be good to give an example packet, but that may also be too > restrictive. What should be discussed is what format is used by the > credentials. i.e. User-Password or CHAP-Password. Given other > discussions and research in RADEXT, it would be good to suggest here > that User-Password is strongly preferred to the alternatives. I think that it is better to refer to a RADEXT doc (e.g., Section 7.3 of draft-dekok-radext-deprecating-radius) rather than duplicating the reco in the doc. Cheers, Med > -----Message d'origine----- > De : radext <[email protected]> De la part de Alan DeKok > Envoyé : mardi 26 septembre 2023 14:37 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]> > Cc : [email protected]; opsawg <[email protected]>; draft-ma-opsawg-ucl- > [email protected] > Objet : Re: [radext] draft-ietf-opsawg-ucl-acl: User Access Control > Group ID RADIUS Attribute > > On Sep 26, 2023, at 8:00 AM, [email protected] wrote: > > > > Hi RADEXT, > > > > FWIW, the document specifies the following new RADIUS attribute: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbouc > adair.github.io%2Fpolicy-based-network-acl%2Fdraft-ietf-opsawg-ucl- > acl.html%23name-user-access-control-group- > i&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C305c160d37f64930767b > 08dbbe8d6976%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638313286796 > 267255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TnIp9ejIAK5V6F%2BAvk > Y8c%2BeZ93Ph9hQwahIv%2FqgobRc%3D&reserved=0 > > > > Your review of that part of the spec is appreciated. > > My $0.02 as someone jumping on these kinds of things. Mostly nits. > > > The value fields of the Attribute are encoded in clear and not > encrypted as, for example, Tunnel- Password Attribute [RFC2868]. > > This text isn't necessary and can be omitted. > > > The User-Access-Group-ID Attribute MAY appear in a RADIUS > Accounting- Request packet. > > What is the interpretation of the attribute there? > > i.e. in Access-Request, it's a hint / request. In Accounting- > Request, it means... ? > > I think the requirement here is that if the User-Access-Group-ID > attribute appears in an Accounting-Request packets, it MUST have the > same value as given in the Access-Accept. > > That is, the value in Accounting-Request is an acknowledgment by the > NAS that it has received the attribute in the Access-Request, and is > enforcing that policy. > > > The User-Access-Group-ID Attribute is structured as follows: > > I would suggest following the attribute definition format suggested > in 8044: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > rfc-editor.org%2Frfc%2Frfc8044%23section- > 2.1.3&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C305c160d37f64930 > 767b08dbbe8d6976%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63831328 > 6796267255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k1J421hRuReCJAlY > ZCrMCWZYa%2BsixIs0eC86%2BHdWNLw%3D&reserved=0 > > It's only a minor change from what is there now. Add a "data type" > field, and remove the "extended type" field. > > > The User-Access-Group-ID Attribute is associated with the following > identifier: 241.TBA1. > > This text isn't necessary and can be omitted. Just leave a "TBD" in > the Type field as recommended by 8044. > > > The following table provides a guide as what type of RADIUS packets > that may contain User-Access-Group-ID Attribute, and in what quantity. > > It's not necessary to list the attribute number here. Just omit > that column. Identifying the attribute by name is enough > > I'll also note that this table allows for multiple copies of the > attribute to exist (i.e. "0+"). The rest of the text in the section > doesn't mention that more than one attribute are allowed. The text > should be updated to explain what that means. > > Perhaps something like "If more than one copy of the User-Access- > Group-ID attribute appears in an Access-Accept packet, it means that > the user is a member of all of those groups." > > I haven't taken a detailed look at the rest of the document, but > this text in Section 4.1 jumped out at me: > > > Step 3: The authentication request is then relayed to the AAA server > using a protocol such as RADIUS [RFC2865]. It is assumed that the AAA > server has been appropriately configured to store user credentials, > e.g., user name, password, group information and other user > attributes. > > It may be good to give an example packet, but that may also be too > restrictive. What should be discussed is what format is used by the > credentials. i.e. User-Password or CHAP-Password. Given other > discussions and research in RADEXT, it would be good to suggest here > that User-Password is strongly preferred to the alternatives. > > For anyone interested in the underlying reasons, there is a long > discussion of this topic in > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dekok-radext-deprecating-radius- > 03%23section- > 7.3&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C305c160d37f6493076 > 7b08dbbe8d6976%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383132867 > 96423481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tfHtb%2B3GhRWe%2Fx > n1zYDyNAGYsc3olh8S%2FJRzI6M9xBQ%3D&reserved=0 > > Alan DeKok. > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
