On Sep 26, 2023, at 8:00 AM, [email protected] wrote: > > Hi RADEXT, > > FWIW, the document specifies the following new RADIUS attribute: > https://boucadair.github.io/policy-based-network-acl/draft-ietf-opsawg-ucl-acl.html#name-user-access-control-group-i > > 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://www.rfc-editor.org/rfc/rfc8044#section-2.1.3 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://datatracker.ietf.org/doc/html/draft-dekok-radext-deprecating-radius-03#section-7.3 Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
