Subject: Comment on draft-ietf-radext-design-04.txt, Appendix A

From: Bernard Aboba <[email-masked]>
Date: Sun, 13 Jul 2008 14:36:09 -0700 (PDT)

There are a few cases where the text in Appendix A is not backed by 
discussion in the rest of the document, and vice versa.  

A.4

      * Extending the RADIUS packet length limitation past 4096 octets.
        A multi-packet sequence of Access-Request / Access-Challenge
        SHOULD be used instead.  If that is not possible, then a method
        other than RADIUS SHOULD be used to transport the data.

[BA] Generally, the Design Guidelines in Appendix A are supported by text 
elsewhere in the document.  This one has no corresponding discussion, and 
it seems to me that there are enough issues so  that adding a section for 
such a discussion could be beneficial.  For example:

* Discussion of the length restriction.  As far as I can tell, the length 
restriction is mentioned only in RFC 2865 Section 3.  However, there 
is no normative language or even discussion on how receivers behave 
on encountering larger packets.  Based on this, one thing we can say is 
that a sender cannot by default assume that a receiver will be able to 
handle a RADIUS packet longer than 4096 octets.  So my suggestion 
would be to rephrase the first sentence to state that attribute designers 
SHOULD NOT assume that receivers can handle packets larger than 4096 
octets.  In the discussion section, you can then talk about potential 
alternatives for designers. 

* Support for Access-Challenge.  In looking back at the WG discussion on 
attribute length, the most frequently discussed cases where large 
attributes (and hence large packets) might be required are filter rules 
(e.g. NAS-Filter-Rule).  Unfortunately, Section 3 of RFC 4849 does not 
permit this attribute to be placed in an Access-Challenge.  There are 
quite a few other attributes that also do not permit this usage (although 
most are not large enough to be an issue).   Even if this were to be 
fixed, using a multi-packet sequence would imply that RADIUS attributes in 
a subsequent packet would be concatenated to those in a new packet, as 
opposed to replacing them.  So it seems to me that the attribute would 
need to be specially designed for fragmentation across multi-packet 
sequences.  I don't think we can see that even the Extended Attributes are 
designed for such a use. 

Also, as we discussed in the RADIUS location work, not all NASes are going 
to be "Challenge capable" for a access mechanism.  Does this imply wider 
use of the Challenge-Capable Attribute than what is implied in the RADIUS 
location draft? 

Given all of this, it is not clear to me that the suggestion in the rest 
of the paragraph will be workable in all situations.  

My suggestion is to change A.4 to the following:

A.4. Changes to the RADIUS Protocol

   Does the attribute specification change the RADIUS operational model?
   If so, then another mmethod of achieving the design objectives SHOULD 
   be used.  Potential problems include: 

      * Defining new commands in RADIUS using attributes.  
        The addition of new commands to RADIUS should be handled 
        via allocation of a new command Code, not by use of an attribute.  
        This includes new commands created by overloading attributes such 
        as the Service-Type attribute to define new values that modify
        the functionality of Access-Request packets.
      * Using RADIUS as a transport protocol for data unrelated to
        authentication, authorization or accounting.  Using RADIUS
        to transport authentication methods such as EAP is explicitly
        permited, even if those methods require the transport of 
        relatively large amounts of data.  Transport of opaque
        data relating to AAA is also permitted, as discussed in
        Section 2.1.3.  However, if the specification does not
        relate to AAA, then RADIUS SHOULD NOT be used.  
      * Assuming support for packet lengths greater than 4096 octets.
        Attribute designers cannot assume that RADIUS implementations 
        can successfully handle packets larger than 4096 octets.  
        If a specification could lead to a RADIUS packet larger than
        4096 octets, then alternatives described in Section 3.3 
        SHOULD be considered. 
      * Stateless operation.  The RADIUS protocol is stateless, and 
        documents which require stateful protocol behavior without use of  
        the State Attribute need to be redesigned. 
      * Provisioning of service in an Access-Reject.  This is not 
        permitted.  If limited access needs to be provided, then an
        Access-Accept with appropriate authorizations can be used instead.
      * Lack of user authentication or authorization restrictions.  
        In an authorization check, where there is no demonstration of a 
        live user, confidential data cannot be returned.  Where there 
        is a link to a previous user authentication, the State attribute 
        needs to be present. 
      * Lack of per-packet integrity and authentication. 
        It is expected that documents will support per-packet
        integrity and authentication. 
      * Modification of RADIUS packet sequences.  In RADIUS,
        each request is encapsulated in its own packet, and
        elicits a single response, sent to the requester.  Since
        changes to this paradigm are likely to require major modifications
        to RADIUS client and server implementations, they SHOULD be
        avoided if possible. 

For further details, see Section 3.3. 

Also, change Section 3.3 to the following:

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; 
      * RADIUS is a Client/Server protocol;
      * Packet length restriction. 

   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.

   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.
   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.  A similar need exists when 
   dynamic authorization is used in as noted in [RFC5176] Section 3.3. 
   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 certain RADIUS packets.  [RFC5080] Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
   including Access-Request packets performing authorization checks.  It
   is expected that specifications for new RADIUS authentication
   mechanisms will continue this practice.

   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 and port of the RADIUS Client that originated the Access-
   Request.  Similarly, a single Change-of-Authorization (CoA)-Request
   packet [RFC5176] will solicit in response at most a single CoA-ACK or
   CoA-NAK packet, sent to the IP address and port of the Dynamic
   Authorization Client (DAC) that originated the 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 and
   port of the Dynamic Authorization Client (DAC) that originated the
   CoA-Request.  Changes to this model are likely to require major
   revisions to existing implementations and so this is NOT RECOMMENDED.

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process 
   RADIUS packets larger than 4096 octets.  If a situation is envisaged
   where it may be necessary to carry authentication, authorization or
   accounting data in a packet larger than 4096 octets, then one of 
   the following approaches is RECOMMENDED: 

     1. Utilization of a sequence of packets.  In the case of RADIUS
        accounting, this would include a sequence of Accounting-Request
        packets.  This is non-trivial since RADIUS accounting clients 
        would need to be modified to split the attribute stream across 
        multiple Accounting-Requests, and billing servers would need to be 
        modified to re-assemble and interpret the attribute stream. 
        For RADIUS authentication, a sequence of Access-Request/
        Access-Challenge packets would be used; for this to be feasible,
        attribute designers need to enable inclusion of
        attributes that can consume considerable space within 
        Access-Challenge packets.  To maintain compatibility with 
        existing NASes,  either the use of Access-Challenge 
        packets needs to be permissible (as with RADIUS/EAP, defined in 
        [RFC3579]), or support for receipt of an Access-Challenge needs to 
        be indicated by the NAS (as in RADIUS Location [RADIUSLOC]). Also, 
        the specification needs to clearly describe how attribute 
        splitting is signalled and how attributes included within
        the sequence are to be interpretted, without requiring
        stateful operation.  Unfortunately, previous specifications
        have not always exhibited the required foresight.  For example, 
        even though very large filter rules are conceivable, the NAS-Filter-Rule
        Attribute defined in [RFC4849] is not permitted in an 
        Access-Challenge packet, nor is a mechanism specified to
        allow a set of NAS-Filter-Rule attributes to be split across
        an Access-Request/Access-Challenge sequence. 

     2. Utilization of names rather than values.  Where an attribute
        relates to a policy that could conceivably be pre-provisioned
        on the NAS, then the name of the pre-provisioned policy can be 
        transmitted in an attribute, rather than the policy itself, 
        which could be quite large.  An example of this is the Filter-Id 
        Attribute defined in [RFC2865] Section 5.11, which enables a set 
        of pre-provisioned filter rules to be referenced by name. 

     3. Utilization of Packetization Layer Path MTU Discovery
        techniques, as specified in [RFC4821].  As a last resort, where
        the above techniques cannot be made to work, it may be possible
        to apply the techniques described in [RFC4821] to discovery of
        of the maximum supported RADIUS packet size on the path between
        a RADIUS client and a home server.  While such an approach 
        can avoid the complexity of utilization of a sequence of 
        packets, dynamic discovery is likely to be time consuming
        and cannot be guaranteed to work with existing RADIUS 
        implementations.  As a result, this technique is not 
        generally applicable. 

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