|
> Hmm... I'm trying to come up with something that the WG could agree > with, but which isn't banal to the point of being meaningless. > > The comments about the State attribute are a good start. [BA] Yes, because they relate to fundamental assumptions of the protocol design. > Other points are: > > - RADIUS is a transport protocol for authentication credentials, > authorization information, and accounting data for user sessions [BA] Is this implying a requirement for a user session to be in progress at a NAS that originates a request? Or is it a statement relating to the kinds of purposes for which attributes can be used? > - authorization is possible only after a session has been successfully > authenticated [BA] Is this a statement about what messages authorizations can be included within (e.g. Access-Reject or Access-Challenge messages)? > - the protocol is "hop by hop", and not "end to end" [BA] There are protocol elements (e.g. NAS-Identifier, NAS-IP-Address, NAS-IPv6-Address) that refer to the original NAS. However, other fields (Message-Authenticator, Proxy-State, Authenticator field) are recalculated by intermediate nodes. How should specifications think about these distinctions? > - all data transported by RADIUS is visible to all intermediate nodes [BA] Is this a design principle, or just a statement of how things currently work? > - authentication servers do not have to be co-located with accounting > servers > - no action may be taken on Access-Reject other than disconnecting the > user session that was attempting authentication > - no information may be sent in an Accounting-Response > - Any PDU may not reach it's intended destination. Implementations > should be robust in the event of lost, missing, or incomplete information [BA] These seem reasonable. > > Suggestions for more? [BA] It might be worth saying that RADIUS attribute specifications do not define services, they describe how services that have already been defined should be provisioned. > > > Given the concern about SHA-1 collisions, is it worth recommending > > against use of this algorithm in new attributes? > > Yes. > > > I also something might be worth saying about the use of RADIUS without > > user authentication. > > This can be mentioned as part of the set of assumptions. > > > Section 1 > > > > Suggest changing: ... To: ... > > Looks good to me. > > > > Section 5 > > > > Suggest changing ... To: ... > > Looks good to me. > > Alan DeKok. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> |