Subject: Review of draft-ietf-radext-design-03.txt

From: Bernard Aboba <[email-masked]>
Date: Tue, 1 Jul 2008 07:17:29 -0700 (PDT)

Section 1.1

Suggest chasnging:

"  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.

   See [RFC5080] Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute."

To:

"  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) require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model, as described in Section 3.3. Such changes should 
   not be undertaken outside the IETF and when handled within the IETF 
   require "IETF Consensus" for adoption, as noted in "IANA Considerations 
   for RADIUS" [RFC3575] Section 2.1."

Add Section 3.3: 

"  3.3 RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

     * The RADIUS protocol is stateless; 
     * Provisioning of services is not possible within an Access-Reject; 
     * Distinction between authorization checks and user authentication; 
     * Authentication and integrity protection of RADIUS packets; 
     * The RADIUS protocol is a Request/Response protocol; 

   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.  See "Common
   RADIUS Implementation Issues and Suggested Fixes" [RFC5080] 
   Section 2.1.1 for a more in-depth discussion of the use
   of the State Attribute.

   As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
   to deny access to the requested service.  As a result, RADIUS does
   not allow the provisioning of services within an Access-Reject. 
   As a result, documents which include provisioning of services
   within an Access-Reject are inherently incompatible with RADIUS
   and need to be redesigned.

   As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request
   may not contain user authentication attributes or a State
   Attribute linking the Access-Request to an earlier user
   authentication.  Such an Access-Request, known as an 
   authorization check, provides no assurance that it 
   corresponds to a live user.  RADIUS specifications
   defining attributes containing confidential information
   (such as Tunnel-Password) should be careful to prohibit
   such attributes from being returned in response to an
   authorization check.  Also, [RFC5080] Section 2.1.1 notes that 
   authentication mechanisms need to tie a sequence of 
   Access-Request/Access-Challenge packets together into one 
   authentication session.  The State Attribute is RECOMMENDED
   for this purpose. 

   While [RFC2865] did not require authentication and integrity
   protection of RADIUS Access-Request packets, subsequent
   authentication mechanism specifications such as RADIUS/EAP
   [RFC3579] and Digest Authentication [RFC5090] have mandated
   authentication and integrity protection for all
   RADIUS packets.  It is expected that specifications for new
   RADIUS authentication mechanisms will continue this practice.
   As noted in [RFC5080] Section 2.1.1, integrity protection 
   should also be extended to Access-Request packets performing
   authorization checks.

   The RADIUS protocol as defined in [RFC2865] is a request-response
   protocol spoken between RADIUS clients and servers.  A single 
   RADIUS Access-Request packet will solicit in response at most a single 
   Access-Accept, Access-Reject or Access-Challenge packet, sent to the IP 
   address of the RADIUS Client that sent the original Access-Request.  
   Similarly, a single Change-of-Authorization (CoA)-Request packet
   will solicit in response at most a single CoA-ACK or CoA-NAK packet,
   sent to the IP address of the Dynamic Authorization Client (DAC)
   that sent the original CoA-Request. A single Disconnect-Request packet
   will solicit in response at most a single Disconnect-ACK or 
   Disconnect-NAK packet, sent to the IP address of the Dynamic 
   Authorization Client (DAC) that sent the original CoA-Request."

NITs:

Section 1

"such an "Expert Review"" -> "such as an "Expert Review""

Section 1.1

"In order enable" -> "In order to enable"

Prior to the first recommendation, insert:

"Encouraging SDOs to request review of RADIUS attribute specifications by 
sending email to the AAA Doctors or equivalent mailing list;"

"Development of a program to encourage SDOs to make" -> "SDOs to make"

"proposed in this document;" -> "proposed in this document, with reviews
posted to the RADEXT WG or equivalent IETF mailing list;" 

Section 2.1.1

"most significant octet first" -> "in network byte order"

"this usage is NOT RECOMMENDED" -> "this usage is NOT 
RECOMMENDED."

Section 2.1.3

"complex structures" -> "complex structures;"
"well-known types" -> "well-known types;"

"implement a new attribute, as the" -> "implement a new attribute. The"

"to send a new attribute" -> "to send a new static attribute"
"dictionary and policy management" -> "dictionary" 

"required in the RADIUS server's" -> "required in the policy management 
code and in the RADIUS server's"

"error prone implmentations, and interoperability problems." ->
"error prone implementations, interoperability problems, and even
security vulnerabilities."

"most of the complex attributes" -> "most of the existing complex 
attributes"

Section 2.1.4

"does not originate from, or is checked" -> "originates from the user
and is not validated" 
"on an unauthenticated host." -> "on the user."

Section 2.1.5

"RADIUS also SHOULD NOT be extended to new commands via attributes." ->
"New attributes or new values of existing attributes SHOULD NOT be used 
to define new RADIUS commands." 

"Specifications SHOULD NOT" -> "Specifications also SHOULD NOT"

Section 3.1.1

"attribute ID" -> "attribute" 

Section 3.1.3

"via IETF process" -> "via the IETF process"
"SDO specificiations" -> "SDO specifications."

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 07 Jul 2008 14:32:52 +0200

Bernard Aboba wrote:
...

  I've just submitted -04, which incorporates this review.

  Alan DeKok.