Subject: RE: Review of RADIUS Design Guidelines document

From: Bernard Aboba <[email-masked]>
Date: Sun, 10 Feb 2008 12:45:46 -0800

>   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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>