Internet DRAFT - draft-wolff-radext-ext-attribute

draft-wolff-radext-ext-attribute







Network Working Group                                      B. Wolff, Ed.
Internet-Draft                                              Databus Inc.
Expires: August 30, 2006                                        G. Weber
                                                           Cisco Systems
                                                       February 26, 2006


                       Extended RADIUS Attributes
                draft-wolff-radext-ext-attribute-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The RADIUS protocol is being extended beyond the wildest imaginations
   of its original designers.  These extensions are pushing up against
   the existing limitations on the numbers, length, base types and
   grouping of RADIUS attributes.  This document specifies a method of
   relaxing those limitations.





Wolff & Weber            Expires August 30, 2006                [Page 1]

Internet-Draft         Extended RADIUS Attributes          February 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Extended-Space Attribute . . . . . . . . . . . . . . . . . . .  3
     2.1.  Purpose  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Attribute Format . . . . . . . . . . . . . . . . . . . . .  4
       2.2.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . .  4
       2.2.2.  Concatenation  . . . . . . . . . . . . . . . . . . . .  4
       2.2.3.  Alignment and Padding  . . . . . . . . . . . . . . . .  4
       2.2.4.  Additional Data Types  . . . . . . . . . . . . . . . .  5
     2.3.  M-bit  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.4.  P-bit  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.5.  Vendor-Specific Attributes . . . . . . . . . . . . . . . .  5
     2.6.  Interoperability and Proxy Considerations  . . . . . . . .  6
     2.7.  RADIUS Message Types . . . . . . . . . . . . . . . . . . .  6
   3.  Diameter Considerations  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Interworking with Diameter . . . . . . . . . . . . . . . .  6
     3.2.  No RADIUS-Only Attributes  . . . . . . . . . . . . . . . .  6
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  Table of Attributes  . . . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  8
   Appendix B.  Encoding Example  . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11






















Wolff & Weber            Expires August 30, 2006                [Page 2]

Internet-Draft         Extended RADIUS Attributes          February 2006


1.  Introduction

   The Remote Authentication Dial In User Service (RADIUS) protocol
   [RFC2865] is being extended beyond the wildest imaginations of its
   original designers.  These extensions are pushing up against the
   existing limitations on the numbers, length, base types and grouping
   of RADIUS attributes.  This document specifies a method of relaxing
   those limitations.  An Extended-Space attribute is defined for
   RADIUS.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Extended-Space Attribute

   This document defines a new RADIUS standard attribute, Extended-
   Space.

           0                   1                   2
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |     Type      |    Length     |     String...
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          +---------------------+------------------------------+
          | Field               | Description                  |
          +---------------------+------------------------------+
          | Type                | TBD                          |
          | Length              | >=3                          |
          | String              | Formatted as described below |
          +---------------------+------------------------------+

2.1.  Purpose

   RADIUS has, from any reasonable perspective, been a successful
   protocol.  However some limitations have become apparent:
   o  We are approaching the point where the limit of 256 possible
      attribute type numbers may be reached.
   o  In some cases the limit of 253 bytes for attribute value length is
      inadequate.
   o  The set of standard attribute value types is inadequate.
   o  The facility for attribute grouping (tags) is limited in the
      number of groups and allows no nesting.
   Extended-Space removes all of these limitations, as described below.



Wolff & Weber            Expires August 30, 2006                [Page 3]

Internet-Draft         Extended RADIUS Attributes          February 2006


2.2.  Attribute Format

   The format of the Value portion is a sequence of one or more
   Diameter-format attributes as specified in Section 4 of [RFC3588].

2.2.1.  Rationale

   The choice to encapsulate newly-defined attributes rather than change
   the basic RADIUS TLV attribute format is forced by the requirement
   for interoperability with existing RADIUS clients, proxies and
   servers.  An older implementation may not understand the contents of
   the new attribute, but it MUST be able at least to skip over it.

   The choice to use the Diameter attribute format is motivated by the
   expectation that interworking between RADIUS and Diameter will be
   increasingly common, and a conviction that defining facilities and
   services in RADIUS without also defining them in Diameter is unwise.
   It would be easy to find another representation (eg, BER
   [ISO.8825.1990] ) that might in some ways be superior to the Diameter
   format, or to invent yet another TLV format.  Such optimization at
   the expense of interworking is deemed an unprofitable trade.

2.2.2.  Concatenation

   The concatenation of the values of all instances of Extended-Space in
   a RADIUS message is a logical Extended-Space attribute, which
   consists of a sequence of one or more Diameter-format attributes.
   There is no defined or expected relationship between the boundary of
   a particular Extended-Space attribute and any enclosed Diameter-
   format attribute.  There is no requirement that all instances of
   Extended-Space attribute except the last be of maximum length,
   although the generation of a myriad of tiny Extended-Space instances
   would reflect badly on the implementor.

   Note well that the existing length limit for a complete RADIUS
   message of 4096 bytes continues in effect.

2.2.3.  Alignment and Padding

   In Diameter itself, each attribute starts on a 4-byte boundary.  This
   convenience cannot be maintained in RADIUS, because the TL part of
   TLV is 2 bytes and there is no requirement that an attribute start on
   any particular boundary.  If an implementation needs assurance of
   4-byte alignment, it can copy the concatenated values of the
   Extended-Space instances to an aligned buffer.

   Padding as specified in section 4 of [RFC3588] MUST be included.  An
   implementor will naturally be tempted to omit the padding from the



Wolff & Weber            Expires August 30, 2006                [Page 4]

Internet-Draft         Extended RADIUS Attributes          February 2006


   last Extended-Space instance, especially when such padding would
   require the generation of an extra instance containing only padding.
   This temptation MUST be resisted, as a proxy might add another
   instance of its own to the end of a RADIUS message.  A RADIUS
   implementation that receives a message where the total length of the
   (logically or actually) concatenated value fields of the Extended-
   Space instances is not a multiple of 4 SHOULD treat this error as it
   would any other format-related error, such as a TLV length field of
   less than 2 (or 3, if an empty V is considered a format error).

2.2.4.  Additional Data Types

   Extended-Space is of type String.  The extended attribute(s) that it
   contains may use any of the data types defined for Diameter
   attributes.

2.2.4.1.  Grouping

   Extended attributes may be of data type Grouped.  In this case, as
   with Diameter attributes, the specification which defines them must
   include an ABNF specification [RFC4234] describing the contents of
   each such attribute.

2.3.  M-bit

   The Mandatory bit in the attribute header will be supported by
   implementations that support Extended-Space.  Unlike Diameter,
   however, proxies that are unaware of Extended-Space will not parse
   the internal contents of those attributes and thus cannot reject
   messages based on unknown mandatory attributes.

2.4.  P-bit

   Until use of the P-bit in the Diameter AVP header is defined, it
   SHOULD be treated as specified for the reserved bits in [RFC3588].

2.5.  Vendor-Specific Attributes

   The Diameter AVP header includes provision for a Vendor field,
   allowing vendor-specific attributes.  Vendors SHOULD use standard
   base types and formats in defining vendor-specific attributes, and
   standard group formats, so that if a vendor-specific attribute
   attains wide use it can be converted into a standard attribute simply
   by publishing a specification, assigning a number, setting V=0 and
   removing the vendor field.






Wolff & Weber            Expires August 30, 2006                [Page 5]

Internet-Draft         Extended RADIUS Attributes          February 2006


2.6.  Interoperability and Proxy Considerations

   Unless and until support for Extended-Space becomes universal, a
   RADIUS speaker wishing to use it must face the risk that the
   recipient, or a proxy, will not understand or support it and may
   react badly.  Some ways to minimize this risk:
   1.  Receiving an Extended-Space from a given source can be taken as
       strong evidence that it is safe to reply with one.
   2.  If RADIUS acquires a capability negotiation or indication
       mechanism, use of Extended-Space is an obvious subject.
   3.  Least desirable would be a per-partner or global configuration
       flag.
   The implication of the first item above is that a sender of Extended-
   Space MUST be prepared to accept one.  But there is a further
   implication for proxies, even extending to proxies that do not
   understand or support Extended-Space: a proxy MUST NOT react
   differently to Extended-Space in requests and responses.  That is, if
   a proxy silently discards RADIUS messages on the grounds that an
   unknown attribute has been found, or prunes the attribute from the
   messages, it MUST do so consistently on both requests and responses.
   This is in one sense a retroactive requirement, usually a very bad
   idea.  However it seems justified in that inconsistent proxy behavior
   is unreasonable even in the absence of an explicit requirement.

2.7.  RADIUS Message Types

   Extended-Space MAY be used in all RADIUS messages other than Access-
   Reject.  Extended-Space SHOULD NOT be used in Access-Reject unless
   the sender is confident that all proxies and the recipient will react
   well.


3.  Diameter Considerations

3.1.  Interworking with Diameter

   Extended-Space, with its encapsulated Diameter-format attributes,
   should require minimal intelligence from a translating gateway.  The
   gateway MUST remove the encapsulation when translating from RADIUS to
   Diameter.  One open question is the Diameter requirement that new
   mandatory attributes require a new application id.  That would seem
   to require that the gateway derive the Diameter application id based
   on what it finds in the encapsulated attributes.

3.2.  No RADIUS-Only Attributes

   The mandate that there be no applications in RADIUS that cannot be
   handled in Diameter implies that any new RADIUS attributes also be



Wolff & Weber            Expires August 30, 2006                [Page 6]

Internet-Draft         Extended RADIUS Attributes          February 2006


   defined in Diameter.  This requirement applies to the attributes that
   Extended-Space encapsulates.  It would seem pointless for Extended-
   Space itself to be carried in Diameter, but a translating gateway not
   yet aware of Extended-Space might do so blindly.


4.  IANA Considerations

   All RADIUS attributes in the range 1-255 are automatically included
   in the Diameter attribute space.  With Extended-Space, RADIUS
   attributes can now be assigned numbers greater than 255.  Since any
   new RADIUS functionality must also be supportable in Diameter, a
   Diameter attribute number must be allocated for each new RADIUS
   attribute number.  It would appear sensible, and certainly make the
   job of a translating gateway easier, if the numbers were the same.

   While anything RADIUS can do Diameter must be able to do, the
   converse is not true.  There are already Diameter attributes that are
   specific to Diameter and make no sense in RADIUS.  It has been
   suggested that the Diameter attribute number space be partitioned,
   with a range defined for RADIUS attributes.  The advantage would be
   that a RADIUS implementation receiving an attribute outside the range
   could issue a more informative error report than simply "unknown
   attribute".  One can also think of such a partitioning as defining a
   range for Diameter-only attribute numbers.  The question of what
   relative sizes for the partitions are appropriate remains open.  Also
   open is what to do about the existing Diameter attributes, some of
   which may well be desirable for use in RADIUS.  Further, it is not
   clear that whether a particular attribute will always be Diameter-
   only can in all cases be known with confidence when the attribute is
   first defined.

   The requirements of [RFC3575] remain in effect for attribute numbers
   1-255.  Requirements for attribute numbers above 255 are stated in
   section 11.1.1 of [RFC3588].


5.  Security Considerations

   No new security implications for Extended-Space handling.











Wolff & Weber            Expires August 30, 2006                [Page 7]

Internet-Draft         Extended RADIUS Attributes          February 2006


6.  Table of Attributes

   +---------+--------+--------+-----------+---------+-----+-----------+
   | Request | Accept | Reject | Challenge | Accting |  #  | Name      |
   +---------+--------+--------+-----------+---------+-----+-----------+
   |    0+   |   0+   |   0*   |     0+    |   0+*   | TBD | Extended- |
   |         |        |        |           |         |     | Space     |
   +---------+--------+--------+-----------+---------+-----+-----------+

    * In Accounting-Ack, rare, and only for vendor-specific attributes.
           In Access-Reject, Extended-Space SHOULD NOT be used.


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
              Authentication Dial In User Service)", RFC 3575,
              July 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

7.2.  Informative References

   [ISO.8825.1990]
              International Organization for Standardization,
              "Information Processing Systems - Open Systems
              Interconnection - Specification of Basic Encoding Rules
              for Abstract Syntax Notation One (ASN.1)", ISO Standard
              8825, December 1990.


Appendix A.  Acknowledgments

   Many of the issues discussed in this document are a distillation of
   email threads on the RADEXT WG list which is archived here:



Wolff & Weber            Expires August 30, 2006                [Page 8]

Internet-Draft         Extended RADIUS Attributes          February 2006


   http://ops.ietf.org/lists/radiusext/

   Informal discussions with Alan DeKok, Dave Nelson and Emile van
   Bergen aided immensely in formulating and refining the ideas in this
   document.  The idea to use the Diameter AVP header was Alan's.


Appendix B.  Encoding Example

   TBD









































Wolff & Weber            Expires August 30, 2006                [Page 9]

Internet-Draft         Extended RADIUS Attributes          February 2006


Authors' Addresses

   Barney Wolff (editor)
   Databus Inc.
   15 Victor Drive
   Irvington, NY  10533-1919
   US

   Email: barney@databus.com


   Greg Weber
   Cisco Systems
   10850 Murdock Road
   Knoxville, TN  37932
   US

   Email: gdweber@cisco.com

































Wolff & Weber            Expires August 30, 2006               [Page 10]

Internet-Draft         Extended RADIUS Attributes          February 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Wolff & Weber            Expires August 30, 2006               [Page 11]