Re: Review of RADIUS Design Guidelines document

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Here is my review of the RADIUS Design Guidelines document:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt
...
> I am not sure that these paragraphs provide a sufficiently comprehensive
> description of what would constitute a change to the RADIUS operational
> model.  For example, "Design Considerations for Protocol Extensions"
> (http://www.watersprings.org/pub/id/draft-carpenter-extension-recs-02.txt)
> provides a definition of a "major extension" in Section 3.3 that seems
> considerably broader than the considerations provided in the above
> paragraphs.  My suggestion would be to expand this section to explicitly
> list some of the basic assumptions of the RADIUS protocol. 

  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.  Other points
are:

 - RADIUS is a transport protocol for authentication credentials,
authorization information, and accounting data for user sessions
 - authorization is possible only after a session has been successfully
authenticated
 - the protocol is "hop by hop", and not "end to end"
 - all data transported by RADIUS is visible to all intermediate nodes
 - 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

  Suggestions for more?

> 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/>