Internet DRAFT - draft-lior-radext-end-to-end-caps

draft-lior-radext-end-to-end-caps







Network Working Group                                            A. Lior
Internet-Draft                                       Bridgewater Systems
Expires: January 18, 2006                                     F. Adrangi
                                                                   Intel
                                                           July 17, 2005


 End-to-End Capabilities Support for Remote Authentication Dial In User
                            Service (RADIUS)
                  draft-lior-radext-end-to-end-caps-01

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 January 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a new RADIUS attribute, End-to-End-Capability
   which can be used by a NAS to indicate its RADIUS capabilities to the
   RADIUS server and also allows the RADIUS server to request certain
   capabilities from the NAS.





Lior & Adrangi          Expires January 18, 2006                [Page 1]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  Motivation . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   End-to-End-Capability Attribute  . . . . . . . . . . . . . .   4
   3.   Attribute Table  . . . . . . . . . . . . . . . . . . . . . .   7
   4.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.   Diameter Compatibility . . . . . . . . . . . . . . . . . . .   7
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   8
   7.   Security considerations  . . . . . . . . . . . . . . . . . .   8
   8.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1  Bi-directional capability exchange . . . . . . . . . . . .   8
     8.2  How to handle SDO capability extensions  . . . . . . . . .   9
   9.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1   Normative references . . . . . . . . . . . . . . . . . .   9
     10.2   Informative references . . . . . . . . . . . . . . . . .  10
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  11
        Intellectual Property and Copyright Statements . . . . . . .  12































Lior & Adrangi          Expires January 18, 2006                [Page 2]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


1.  Introduction

1.1  Motivation

   There is a need for a RADIUS server to discover capabilities of a NAS
   that has initiated a connection to it.  The  RADIUS server may
   require that the NAS supports a particular RADIUS application.  For
   example, if the user being authenticated and authorized is a prepaid
   user, then the  RADIUS needs to be assured that the NAS supports
   prepaid capabilities as defined in [I-D.lior-radius-prepaid-
   extensions].  Similarly, the  network may need to know whether or not
   the NAS supports RADIUS Dymanic Authorization Extensions as defined
   in [RFC3576].  Whether or not a NAS supports a particular capability
   could impact if the user is allowed on the network; or which
   attributes are delivered and perhaps the value of those attributes;
   and whether or not, and how the  network interacts with the NAS
   midsession.

   In some cases, the NAS itself may also need to communicate that it
   requires that the  RADIUS server deliver a particular capability.
   For example, the NAS may require that the  server deliver the
   Chargeable User Identity attribute as defined in [I-D.ietf-radext-
   chargeable-user-id].

   Similarly, the RADIUS server may require that the NAS enable certain
   feature that the RADIUS server requires for the session.  For
   example, the  network may require that the NAS deliver location
   information as defined by [I-D.ietf-geopriv-radius-lo] before it can
   authenticate the session.

   This document defines an attribute appropriately called End-to-End-
   Capability attribute that allows:
   o  The NAS to specify which capabilities it supports.
   o  The NAS to specify which capabilities that are required to be
      delivered by the RADIUS server.
   o  The RADIUS server to express the capabilities desired from the
      NAS.
   o  The RADIUS server to express the capabilities that the RADIUS
      server requires from the NAS.

   The End-to-End-Capability attribute defined in this document is
   different then the capability exchange defined in Base Diameter
   [RFC3588].  The purpose of the Diameter based capability exchange is
   support routing of Diameter messages.  Whereas, the functionality
   defined by this document is designed to ensure whether we can send an
   attribute or command or expect a behavior relating to this specific
   user's session.




Lior & Adrangi          Expires January 18, 2006                [Page 3]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


1.2  Terminology

   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 [RFC2119].

2.  End-to-End-Capability Attribute

   The End-to-End-Capability attribute MAY be included in the Access-
   Request, Access-Challenge, Access-Accept and Change of Authorization
   packets.

   A NAS that supports RADIUS features beyond those defined in [RFC2865]
   SHOULD include the End-to-End-Capability attribute to advertize the
   capabilities that it supports.

   A NAS that requires certain capabilities from the RADIUS server
   SHOULD include the End-to-End-Capability attribute indicating which
   capabilities MUST be delivered by the RADIUS server.  If the
   requested capabilities are not delivered, the NAS MAY reject the
   subsequent replies from the RADIUS server.  The specific behavior
   will depend on the associated capability and will be defined in the
   associated RFCs.

   A RADIUS server MAY include an End-To-End-Capability attribute in an
   Access-Accept, Challenge message or COA packets to indicate which
   capabilites it desires from the NAS.  If the NAS recognizes the End-
   to-End-Capability attribute, then the NAS MAY honor the RADIUS
   server's request.

   Using the End-to-End-Capability attribute, the RADIUS server MAY
   specifiy which capabilities that it requires from the NAS.  A NAS
   that recognizes the End-to-End-Capability attribute and that supports
   the requested feature SHOULD deliver the requested capabilites to the
   RADIUS server.  If the capabilities are not delivered to the RADIUS
   server, the RADIUS server MAY reject the session.  If the session has
   already been established the RADIUS server may send a Disconnect
   Message to terminate the session.  The exact behavior of the RADIUS
   server is dependant on the actual capability being requested.

   A summary of the End-to-End-Capability attribute is given below.


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




Lior & Adrangi          Expires January 18, 2006                [Page 4]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


   Type: TBD for End-to-End-Capability.
   Length: >= 3
   String:
      The string consists of a sequence of capabilities with each
      capability encoded as a bit-pair.  Bit-pair '1' corresponds to
      Capability 1.  Bit-pair '2' corresponds to Capability 2, etc.
      The sequence is octet aligned.  The sequence will grow as
      capabilities are added.  A NAS or a RADIUS server MAY only report
      the first N octets of the sequence.  In this case the reciever
      SHALL interpret that the capabilities represented by the missing
      octets are not supported by the sender.
      The bit-pair are used to indicated the following:

      00: NOT-SUPPORTED

         Indicates that capability is not supported or not desired.

      10: SUPPORTED

         Implies that the capability is supported or desired.

      11: REQUIRED

         Implies that the capbility is supported and is required for the
         session.  When sent by the NAS to the RADIUS server, if the
         RADIUS server does not deliver the capability, the NAS MAY
         reject the session.  When sent by the RADIUS server to the NAS,
         the RADIUS server MAY reject the session if the capabilities
         are not delivered for the session.

   The following end-to-end capabilities identities are assigned by this
   document.  Additional capability Ids may be assigned later.  See the
   IANA section.


















Lior & Adrangi          Expires January 18, 2006                [Page 5]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


   +--------+----------------------------------------------------------+
   |  Cap.  | Capability                                               |
   |   Id   |                                                          |
   +--------+----------------------------------------------------------+
   |    0   | (RESERVED) MUST be set to '00'.                          |
   |    1   | (NASREQ) Support for basic authentication and            |
   |        | authorization services as per [RFC2865]. The NAS MAY     |
   |        | indicate SUPPORTED only.                                 |
   |    2   | (Accounting) Support for accounting as defined by        |
   |        | [RFC2866] and [RFC2869].  The NAS MAY indicate SUPPORTED |
   |        | only.                                                    |
   |    3   | (TUNNELS) Supports RADIUS Attributes for Tunnel Protocol |
   |        | Support as defined by [RFC2868]. The NAS MAY indicated   |
   |        | SUPPORTED and REQUIRED.                                  |
   |    4   | (DM) Support Disconnect Message as defined by [RFC3576]. |
   |        | The NAS MAY indicate SUPPORTED only.                     |
   |    5   | (COA) Support Change of Authorization as defined by      |
   |        | [RFC3576].  The NAS MAY indicate SUPPORTED only.         |
   |    6   | (CUI) Support Chargeable User Identity as defined by     |
   |        | [I-D.ietf-radext-chargeable-user-id].  The NAS MAY       |
   |        | indicate SUPPORTED and REQUIRED.                         |
   |    7   | (L2 Filter) Support Layer-2 filtering as defined by      |
   |        | [I-D.congdon-radext-ieee802].  The NAS MAY indicate      |
   |        | SUPPORTED only.                                          |
   |    8   | (L3 Filter) Support Layer-3 filtering as defined by      |
   |        | [I-D.congdon-radext-ieee802].  The NAS MAY indicate      |
   |        | SUPPORTED only.                                          |
   |    9   | (L3 Redirect) Support Layer-3 redirects as defined by    |
   |        | [I-D.congdon-radext-ieee802].  The NAS MAY indicate      |
   |        | SUPPORTED only.                                          |
   |   10   | (L4 Redirect) Support Layer-4 redirects as defined by    |
   |        | [I-D.congdon-radext-ieee802].  The NAS MAY indicate      |
   |        | SUPPORTED only.                                          |
   |   11   | (PREPAID VOLUME) Support Volume-based prepaid as defined |
   |        | by [I-D.lior-radius-prepaid-extensions].  The NAS MAY    |
   |        | indicate SUPPORTED only.                                 |
   |   12   | (PREPAID TIME) Support Time-based prepaid as defined by  |
   |        | [I-D.lior-radius-prepaid-extensions].  The NAS MAY       |
   |        | indicate SUPPORTED only.                                 |
   |   13   | (PREPAID POOL) Support prepaid pools as defined by       |
   |        | [I-D.lior-radius-prepaid-extensions].  The NAS MAY       |
   |        | indicate SUPPORTED only.                                 |
   |   14   | (PREPAID RATING) Support rating groups pas defined by    |
   |        | [I-D.lior-radius-prepaid-extensions].  The NAS MAY       |
   |        | indicate SUPPORTED only.                                 |






Lior & Adrangi          Expires January 18, 2006                [Page 6]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


   |   15   | (PREPAID MULTI-SERVICE) Support for prepaid of           |
   |        | multi-services as defined by                             |
   |        | [I-D.lior-radius-prepaid-extensions].  The NAS MAY       |
   |        | indicate SUPPORTED only.                                 |
   |   16   | (CIVIC_LOCATION) Support for civic location as defined   |
   |        | by [I-D.ietf-geopriv-radius-lo].  The NAS MAY indicate   |
   |        | SUPPORTED only.                                          |
   |   17   | (GEO_LOCATION) Support for geospatial location as        |
   |        | defined by [I-D.ietf-geopriv-radius-lo]. The NAS MAY     |
   |        | indicate SUPPORTED only.                                 |
   +--------+----------------------------------------------------------+


3.  Attribute Table

   The following table provides a guide to which attribute(s) may be
   found in which kinds of packets, and in what quantity.

   Request Accept Reject Challenge Accounting    COA    #    Attribute
                                      Request
     0-1     0-1    0       0-1        0         0-1   TBD   End-to-End-Capability



4.  Example

   A RADIUS server may receive an End-to-End-Capability with the
   following value expressed in binary:
             '0010100010100000'

   The first bit-pair is set to zero as required by this document.  The
   next bit-pair is set to '10' indicating that NASREQ capability is
   SUPPORTED.  The next bit-pair is '10' indicating that the NAS
   supports Accounting.  The next bit-pair is set to '00' indicating
   that the NAS does not support the TUNNELING capability.  The next two
   bit-pair are set to '10' indicating that this NAS support both the
   Disconnect Message and Change of Authorization Messages as defined by
   [RFC3576].

   Note the rest of the bits up to a the octet boundary are set to '0'
   indicating the no other capabilities are supported.  Capabilities in
   Octets that follow this are not supported.

5.  Diameter Compatibility

   This attribute functions in an equivalent manner in both RADIUS and
   Diameter.  In Diameter, the base protocol layer may fill in the
   attribute values automatically based on its knowledge of applications



Lior & Adrangi          Expires January 18, 2006                [Page 7]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


   running on top of it.

6.  IANA Considerations

   This document uses the RADIUS [RFC2865] namespace, see
   "http://www.iana.org/assignments/radius-types".  This document
   instructs IANA to assign a new RADIUS attribute number for the End-
   to-End-Capability attribute.

         End-to-End-Capability                TBA

   Allocation of a new Error-Cause(101) value of "Unsupported
   Capability".

   Finally IANA should create a new name space, Capabilities Ids. The
   initial values in this name space include those listed in Section 2.
   New values in the 0-128 range can be allocated through IETF
   Consensus.  Other values (upto 2023 i.e. 253 bytes times 8 bits) can
   be allocated on a First-Come First Served basis with Specification
   Required.

7.  Security considerations

   The RADIUS proxies MUST NOT modify the End-to-End-Capability
   attribute.  However, there is no way to detect or prevent this.

   If the NAS includes End-to-End-Capability attribute in an Access-
   Request packet, a man in the middle may remove attribute or change
   the value of the attribute.  This could result in a denial of service
   by causing the NAS to reject the session.  This attack could also
   cause the RADIUS server to deliver infomration that is not rquired by
   the NAS but could be useful to that attacker.  To prevent this
   attack, the NAS SHOULD include Message-Authenticator(80) in the
   Access-Request packets that contain a End-to-End-Capability
   attribute.

8.  Open Issues

8.1  Bi-directional capability exchange

   Glen Zorn asked the question, why should the capability exchange
   should only come from the client?  He is right!

   Using logoff as an example to illustrate why it makes sense.
   Supposing the NAS reports that it supports LOGOFF capability.  It
   would be nice for the Server to be able to tell the NAS that it wants
   to receive the LOGOFF message as decribed in the logoof document.
   The server could do this during Access-Accept or even mid-session



Lior & Adrangi          Expires January 18, 2006                [Page 8]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


   using CoA.

   By allowing the Server to send the capability attribute back in an
   Access-Accept the server can signal what it supports and what it
   REQUIRES.

   The [I-D.ietf-geopriv-radius-lo] also includes requirment for bi-
   directional exchange.

   ADDED IN VERSION 01

   Comments?

8.2  How to handle SDO capability extensions

   How will capabilities be extended?  When SDOs develop RADIUS
   application or deployments they often introduced their own capability
   attributes.  While it would be nice to have everyone develop all
   their work in the IETF.  This is not always practicle.

   We propose the following: Recommend to SDOs that if they want their
   own capability attribute that they should create their own VSA that
   matches the format of the End-to-End-Capability.

   The capability attribute would then be carried in the RADIUS packets
   as a VSA along side the RADIUS one.

   If they want to have an application that interoperates outside the
   scope of the SDOs, then they will have to allocate the capabilty
   attribute after they publish the RFC at the IETF.

9.  Acknowledgements

   We would like to acknowledge the helpfull comments received from
   Bernard Aboba, David Nelson, Barney Wolf, Paul Congdon, and Jari
   Arkko.

10.  References

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




Lior & Adrangi          Expires January 18, 2006                [Page 9]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


   [RFC2869]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS
              Extensions", RFC 2869, June 2000.

10.2  Informative references

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
              M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
              Support", RFC 2868, June 2000.

   [RFC3576]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 3576,
              July 2003.

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

   [I-D.lior-radius-prepaid-extensions]
              Lior, A., "PrePaid Extensions to Remote Authentication
              Dial-In User Service (RADIUS)",
              draft-lior-radius-prepaid-extensions-08 (work in
              progress), July 2005.

   [I-D.ietf-radext-chargeable-user-id]
              Adrangi, F., "Chargeable User Identity",
              draft-ietf-radext-chargeable-user-id-05 (work in
              progress), May 2005.

   [I-D.ietf-geopriv-radius-lo]
              Tschofenig, H., "Carrying Location Objects in RADIUS",
              draft-ietf-geopriv-radius-lo-04 (work in progress),
              July 2005.

   [I-D.congdon-radext-ieee802]
              Congdon, P., "RADIUS Extensions for IEEE 802",
              draft-congdon-radext-ieee802-03 (work in progress),
              February 2005.












Lior & Adrangi          Expires January 18, 2006               [Page 10]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


Authors' Addresses

   Avi Lior
   Bridgewater Systems Corporation
   303 Terry Fox Drive
   Ottawa, Ontario  K2K 3J1
   Canada

   Phone: +1 613-591-6655
   Email: avi@bridgewatersystems.com


   Farid Adrangi
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR  97124
   USA

   Phone: +1 503-712-1791
   Email: farid.adrangi@intel.com































Lior & Adrangi          Expires January 18, 2006               [Page 11]

Internet-Draft     E2E Capabilities Support for RADIUS         July 2005


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 (2005).  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.




Lior & Adrangi          Expires January 18, 2006               [Page 12]