Internet DRAFT - draft-halwasia-radext-capability-negotiation
draft-halwasia-radext-capability-negotiation
Network Working Group A. DeKok
Internet-Draft FreeRADIUS
Intended status: Standards Track G. Halwasia
Expires: April 11, 2013 S. Danda
M. Kumar
Cisco Systems
October 8, 2012
Capability Negotiation in RADIUS
draft-halwasia-radext-capability-negotiation-01
Abstract
This document describes procedure and mechanism to exchange and
negotiate capabilities between RADIUS client and RADIUS server.
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].
RADIUS-specific terminology is borrowed from [RFC2865] and [RFC2866].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 11, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
DeKok, et al. Expires April 11, 2013 [Page 1]
Internet-Draft Capability Negotiation in RADIUS October 2012
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Solution Description . . . . . . . . . . . . . . . . . . . 3
2. RADIUS Packets . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Capability-Request RADIUS Packet . . . . . . . . . . . . . 3
2.2. Capability-Response RADIUS Packet . . . . . . . . . . . . 4
3. RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Capability-Add Attribute . . . . . . . . . . . . . . . . . 6
3.2. Capability-Withdraw Attribute . . . . . . . . . . . . . . 6
3.3. Capability-Ack Attribute . . . . . . . . . . . . . . . . . 7
4. RADIUS Capability-Id . . . . . . . . . . . . . . . . . . . . . 8
5. RADIUS Client Behavior . . . . . . . . . . . . . . . . . . . . 8
6. RADIUS Server Behavior . . . . . . . . . . . . . . . . . . . . 9
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. New Registry: Capability-Identifier . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
DeKok, et al. Expires April 11, 2013 [Page 2]
Internet-Draft Capability Negotiation in RADIUS October 2012
1. Introduction
Remote Authentication Dial In User Service (RADIUS) [RFC2865] and
[RFC2866] is widely used protocol for Authentication, Authorization
and Accounting. There are quite a lot of extensions which are being
done on RADIUS protocol and considering that RADIUS is being deployed
quite extensively, it would be nice if RADIUS Client and Server can
negotiate the capability to support those extensions. This
specification recommends and envision each proposed capability to be
as precise and narrowly defined as possible and having said that we
envision fairly large number of capabilities rather than few broadly
defined ones. For example [I-D.ietf-radext-radius-extensions]
proposes extended attributes space along with few other extensions
and it would be nice if RADIUS Client and Server can signal and
negotiate support for 'extended attributes'. This document describes
procedure and mechanism to exchange and negotiate capabilities
between RADIUS client and RADIUS server.
1.1. Solution Description
This specification proposes to define two new RADIUS packet types to
negotiate capabilities between RADIUS client and RADIUS server as
defined in section 2. It also proposes to define 3 new attributes to
be carried inside new RADIUS packet types. New RADIUS packets to
negotiate capability has been chosen as it has minimal impact on the
RADIUS security model and existing implementations. Following
sections describes the new RADIUS packet types and attributes and
describes their usage in negotiating capabilities. As per this
specification Capability-Request RADIUS packets MUST NOT be proxied.
2. RADIUS Packets
This document defines following new RADIUS packet type to enable
capability negotiation between RADIUS client and server.
2.1. Capability-Request RADIUS Packet
DeKok, et al. Expires April 11, 2013 [Page 3]
Internet-Draft Capability Negotiation in RADIUS October 2012
Capability-Request RADIUS Packets are sent to a RADIUS server to
convey the capabilities RADIUS client intends to add and withdraw.
A summary of the Capability-Request packet format is shown below.
The fields are transmitted from left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
TBA1 - Capability-Request.
Identifier
The Identifier field MUST be changed whenever the content of the
Attributes field changes, and whenever a valid reply has been
received for a previous request. For retransmissions, the
Identifier MUST remain unchanged.
Request Authenticator
The Request Authenticator value MUST be changed each time a new
Identifier is used. It is calculated the same way as calculated
for Access-Request RADIUS Packet as described in section 3 of
RFC2865.
Attributes
The Attribute field is variable in length, and contains the list
of Attributes that are required.
2.2. Capability-Response RADIUS Packet
DeKok, et al. Expires April 11, 2013 [Page 4]
Internet-Draft Capability Negotiation in RADIUS October 2012
Capability-Withdraw RADIUS Packets are sent to a RADIUS client in
response to Capability-Request packet from RADIUS client.
A summary of the Capability-Withdraw packet format is shown below.
The fields are transmitted from left to right.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
TBA2 - Capability-Response.
Identifier
The Identifier field is a copy of the Identifier field of the
Capability-Request which caused this Capability-Response.
Response Authenticator
The Response Authenticator value is calculated from the
Capability-Request value. It is calculated the same way
as calculated for Access-Accept RADIUS Packet similar to
as described in section 3 of RFC2865.
Attributes
The Attribute field is variable in length, and contains the list
of Attributes that are required.
3. RADIUS Attributes
This document defines following new RADIUS attributes to enable
capability negotiation between RADIUS client and server.
DeKok, et al. Expires April 11, 2013 [Page 5]
Internet-Draft Capability Negotiation in RADIUS October 2012
3.1. Capability-Add Attribute
This attribute indicates the capability which the client wants to add.
The format of the Capability-Add Attribute is:
0 1 2 3
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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA3 - Capability-Add
Length
6
Value
Enumerated Data Type in 4-Octet unsigned integer defined in
[RFC6158]. This field contains the capability-id as specified
in section 4 of this document.
3.2. Capability-Withdraw Attribute
DeKok, et al. Expires April 11, 2013 [Page 6]
Internet-Draft Capability Negotiation in RADIUS October 2012
This attribute indicates the capability which the client wants to
withdraw.
The format of the Capability-Withdraw Attribute is:
0 1 2 3
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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA4 - Capability-Withdraw
Length
6
Value
Enumerated Data Type in 4-Octet unsigned integer defined in
[RFC6158]. This field contains the capability-id as specified
in section 4 of this document.
3.3. Capability-Ack Attribute
DeKok, et al. Expires April 11, 2013 [Page 7]
Internet-Draft Capability Negotiation in RADIUS October 2012
This attribute indicates the capability which the server wants to
Acknowledge.
The format of the Capability-Ack Attribute is:
0 1 2 3
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 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBA5 - Capability-Ack
Length
6
Value
Enumerated Data Type in 4-Octet unsigned integer defined in
[RFC6158]. This field contains the capability-id as specified
in section 4 of this document.
4. RADIUS Capability-Id
Value field of Capability-Add and Capability-Withdraw attributes
defined above contains the Capability-Id of the capability RADIUS
client wants to negotiate with RADIUS server. This document does not
define any new capability and it's associated Capability-Id. Any
specification which wants to use this mechanism of capability
negotiation MUST define a new capability. Each new capability MUST
be registered with IANA to get a capability-id from capability-id
registry.
5. RADIUS Client Behavior
RADIUS Client willing to negotiate capabilities SHOULD send
Capability-Request RADIUS Packet (defined in section 2) towards the
RADIUS Server. RADIUS Client MUST include Capability-Add Attribute
in Capability-Request RADIUS Packet for the capability client wants
to add/negotiate. Client can also include Capability-Withdraw
Attribute in the RADIUS packet in case it wants to withdraw the
DeKok, et al. Expires April 11, 2013 [Page 8]
Internet-Draft Capability Negotiation in RADIUS October 2012
capability it has negotiated earlier. Client MUST NOT add the
Capability-Withdraw Attribute in the Capability-Request RADIUS Packet
in case it has not negotiated the corresponding attribute earlier.
Client can include multiple Capability-Add and/or Capability-Withdraw
Attributes in the same Capability-Request RADIUS Packet. RADIUS
client MUST add atleast one Capability-Add and/or Capability-Withdraw
Attribute in Capability-Request RADIUS Packet. Client MUST NOT
include the Capability-Add and Capability-Withdraw Attribute for the
same capability in the same Capability-Request RADIUS Packet.
Apart from including Capability-Add and/or Capability-Withdraw
Attributes in the Capability-Request RADIUS Packet, Client can
include NAS-Identifier [RFC2865] or one of the NAS-IP-
Address[RFC2865]/NAS-IPv6-Address [RFC3162] for the porpose of RADIUS
server to identify client.
6. RADIUS Server Behavior
RADIUS Server implementing this specification MUST respond back with
Capability-Response RADIUS Packet after receiving a valid Capability-
Request RADIUS Packet from the RADIUS Client. As specified in
section 5, Client will advertise it's capabilities by including
Capability-Add and/or Capability-Withdraw Attributes in the same
Capability-Request RADIUS Packet. RADIUS Server will find out the
common set of agreed upon capabilities based upon the intersection in
between capabilities received from client and it's own capabilities.
RADIUS Server MUST include a Capability-Ack Attribute for each of the
agreed upon capabilities in the Capability-Response RADIUS Packet.
RADIUS Server MUST NOT include Capability-Ack attributes for all
those capabilities which is does not want to support/share with
RADIUS Client. If the RADIUS Server does not support any of the
capabilities specified in Capability-Request RADIUS Packet, it SHOULD
send back a empty Capability-Response RADIUS Packet without including
any Capability-Ack attribute.
RADIUS Server implementation which does not support capability
negotiation specified in this specification MUST silently discard
Capability-Request RADIUS Packet received from RADIUS Client.
7. Example
Following example figure shows the sequence of message exchanges
which happens between RADIUS Client and RADIUS Server to negotiate a
capabilities.
DeKok, et al. Expires April 11, 2013 [Page 9]
Internet-Draft Capability Negotiation in RADIUS October 2012
+-+-+-+-+-+ +-+-+-+-+-+
| CLIENT | | SERVER |
+-+-+-+-+-+ +-+-+-+-+-+
| |
| Capability-Request(Capability-Add(X),Capability-Add(Y), |
| NAS-IP-Address) |
|-------------------------------------------------------->|
| |
| Capability-Response(Capability-Ack(Y)) |
|<--------------------------------------------------------|
Figure 1: Capability Negotiation between Client and Server
Capability X = 'Understands 64-Bit Integers'
Capability Y = 'Supports Larger than 4K RADIUS packets'
8. IANA Considerations
The authors request that Packet Type, Attribute Types and Attribute
Values defined in this document be registered by by the Internet
Assigned Numbers Authority (IANA) from the RADIUS namespaces as
described in the "IANA Considerations" section of RFC 3575 [RFC3575],
in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes
and registries created by this document IANA is requested to place
them at http://www.iana.org/assignments/radius-types.
This document defines the following RADIUS messages:
- Capability-Request
- Capability-Response
This document defines the following attributes:
- Capability-Add
- Capability-Withdraw
- Capability-Ack
Additionally, IANA is requested to create the following new
registries listed in the subsections below.
8.1. New Registry: Capability-Identifier
This document also defines an Capabality-Identifier registry (used in
the value field of Capability-Add, Capability-Withdraw and
Capability-Ack Attributes). IANA is requested to just allocate space
DeKok, et al. Expires April 11, 2013 [Page 10]
Internet-Draft Capability Negotiation in RADIUS October 2012
for this registry and this document does not request IANA to allocate
any value from this registry.
Requests to IANA for a new value for a Capability Identifier will be
approved by Expert Review. A designated expert will be appointed by
the IESG.
9. Security Considerations
This document defines new RADIUS message types and new Attribute
types, but otherwise makes no changes to the security of the RADIUS
protocol.
10. Acknowledgements
11. References
11.1. Normative References
[I-D.ietf-radext-radius-extensions]
DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions",
draft-ietf-radext-radius-extensions-06 (work in progress),
June 2012.
[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.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines",
BCP 158, RFC 6158, March 2011.
DeKok, et al. Expires April 11, 2013 [Page 11]
Internet-Draft Capability Negotiation in RADIUS October 2012
11.2. Informative References
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
Authors' Addresses
Alan DeKok
FreeRADIUS
Phone:
Email: aland@deployingradius.com
Gaurav Halwasia
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone: +91 80 4429 2703
Email: ghalwasi@cisco.com
Satyanarayana Danda
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone: +91 80 4429 2684
Email: sdanda@cisco.com
Manoj Kumar
Cisco Systems
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Phone: +91 80 4429 2635
Email: magoyal@cisco.com
DeKok, et al. Expires April 11, 2013 [Page 12]
