Subject: Review of RADIUS Design Guidelines document

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Jan 2008 17:16:46 -0800

Here is my review of the RADIUS Design Guidelines document:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

Section 1.1 states:

"   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes that can be used to, in
   effect, provide new RADIUS commands (such as Service-Type) are out of
   scope.  Since protocol changes require greater expertise and deeper
   review, such changes should not be undertaken outside the IETF and
   when handled within the IETF require "IETF Consensus" for adoption,
   as noted in [RFC3575] Section 2.1.

   As with protocol changes, this document does not provide guidance to
   document authors seeking to change the RADIUS operational model.
   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned."

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.  

Section 5

Given the concern about SHA-1 collisions, is it worth recommending against use of this algorithm in new attributes? 

I also something might be worth saying about the use of RADIUS without user authentication. 

Other comments:

Section 1

Suggest changing:

"   This document provides guidelines for the design of RADIUS attributes
   both within the IETF as well as within other Standards Development
   Organizations (SDOs).  By articulating RADIUS design guidelines, it
   is hoped that this document will encourage the development and
   publication of high quality RADIUS attribute specifications.  The
   advice in this document will not be helpful unless it is put to use.

   As with "Guidelines for Authors and Reviewers of MIB Documents"
   [RFC4181], it is expected that this document will enable authors to
   check their document against the guidelines prior to requesting a
   review (such an "Expert Review" described in [RFC3575]).  Similarly,
   it is hoped that this document will be of use to reviewers (such as
   WG participants or the AAA Doctors) in improving the consistency of
   reviews.
"

To:

"   This document provides guidelines for the design of RADIUS attributes
   both within the IETF as well as within other Standards Development
   Organizations (SDOs).  By articulating RADIUS design guidelines, it
   is hoped that this document will encourage the development and
   publication of high quality RADIUS attribute specifications.  

   However, the advice in this document will not be helpful unless 
   it is put to use.  As with "Guidelines for Authors and Reviewers 
   of MIB Documents [RFC4181], it is expected that this document will 
   be used by authors to check their document against the guidelines 
   prior to requesting review (such an "Expert Review" described 
   in [RFC3575]).  Similarly, it is expected that this document will 
   used by reviewers (such as WG participants or the AAA Doctors),
   resulting in an improvement in the consistency of reviews."

Section 5

Suggest changing

"The MD5 algorithm
   has recently become a focus of scrutiny and concern in security
   circles, and as a result, the use of this technique in new attributes
   is NOT RECOMMENDED."

To:

   "The MD5 and SHA-1 algorithms
   have recently become a focus of scrutiny and concern in security
   circles, and as a result, the use of these algorithms in new attributes
   is NOT RECOMMENDED."

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jan 2008 17:49:53 +0100

> 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

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