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]