Capability Negotiation in RADIUS

Remote Authentication Dial In User Service (RADIUS) and 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 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.

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.

This document defines following new RADIUS packet type to enable capability negotiation between RADIUS client and server.

This document defines following new RADIUS attributes to enable capability negotiation between RADIUS client and server.

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.

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 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 or one of the NAS-IP-Address/NAS-IPv6-Address for the porpose of RADIUS server to identify client.

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.

Following example figure shows the sequence of message exchanges which happens between RADIUS Client and RADIUS Server to negotiate a capabilities.

| | | | 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']]>

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 , in accordance with BCP 26 . 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:

This document defines the following attributes:

Additionally, IANA is requested to create the following new registries listed in the subsections below.

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

This document defines new RADIUS message types and new Attribute types, but otherwise makes no changes to the security of the RADIUS protocol.