Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Proposed Standard Updates: 2885 Expires: October 24, 2016 24 April 2017 Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator. draft-dekok-radext-request-authenticator-00.txt Abstract RADIUS contains a one-octet Identifier field which is used to correlate requests and replies. This field limits the number of outstanding requests to 256. Experience shows that this limitation is problematic for high load systems. This document proposes to use the Request Authenticator field as an additional unique identifier. The replies can then be correlated to requests by copying the Request Authenticator from the request to a new attribute in the response, called the Original-Request-Authenticator. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 November 18, 2010. DeKok, Alan Standards Track [Page 1] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 Copyright Notice Copyright (c) 2010 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 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. DeKok, Alan Standards Track [Page 2] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 Table of Contents 9.1. ...................................................... 3 1. Introduction ............................................. 4 1.1. Outline of the document ............................. 4 1.2. Terminology ......................................... 4 1.3. Requirements Language ............................... 5 2. Overview ................................................. 6 3. Signaling via Status-Server .............................. 7 3.1. Static Configuration ................................ 8 4. Original-Request-Authenticator Attribute ................. 8 5. Transport Considerations ................................. 9 5.1. UDP ................................................. 10 5.2. TCP ................................................. 10 5.3. Dynamic Discovery ................................... 11 6. Implementation Considerations ............................ 12 6.1. Client Considerations ............................... 12 6.2. Server Considerations ............................... 12 7. IANA Considerations ...................................... 12 8. Security Considerations .................................. 12 9. Normative References ..................................... 13 9.1. ......................................................... 13 DeKok, Alan Standards Track [Page 3] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 1. Introduction The Remote Authentication Dial In User Service (RADIUS) protocol contains an Identifier field, defined in RFC 2865 Section 5 as: The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. The small size of the field allows for only 256 outstanding requests. If a client requires more than 256 packets to be outstanding to the RADIUS server, it must open a new source port. This limitation has been adequate for low-load RADIUS systems. But it is a problem in practice for high-load systems. Opening new sockets can be expensive for resource limited clients, and is generally unnecessary in other UDP protocols. For very high load systems, it would be good to allow RADIUS clients to "fill the pipe" with data. The problem is that RADIUS packets tend to be small, and RADIUS over UDP can reach the packet per second limit of the underlying network, which is usually much lower than the rated bandwidth of the link. We could use RADIUS over TCP [RFC6614], and rely on the network stack to use all available link bandwidth. However, the one-octet limit for the Identifier field means that a RADIUS client may only send 20K of data (in the low end), before that connection is "full", and the client must use another one. 1.1. Outline of the document The document gives a high level overview of proposal. It then describes how the functionality is signaled in a Status-Server [RFC5997] It then defines the Original-Request-Authenticator attribute. It then describes how this change to RADIUS affects each type of packet (ordered by Code). Finally, it describes how the change affects transports such as UDP, TCP, and TLS. 1.2. Terminology This document uses the following terms: Network Access Server (NAS) The device providing access to the network. Also known as the Authenticator (in IEEE 802.1X terminology) or RADIUS client. DeKok, Alan Standards Track [Page 4] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 RADIUS Proxy In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client. 1.3. Requirements Language In this document, several words are used to signify the requirements of the specification. 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]. DeKok, Alan Standards Track [Page 5] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 2. Overview We propose to use the Request Authenticator field as an additional unique identifier. Subject to certain limitations outlined below, the Request Authenticator can be broadly treated as being temporally and globally unique. This uniqueness is what allows it to be used as a packet identifier. Further, clients are already required to store the Request Authenticator for all packets, as it is used to verify the Response Authenticator in the response packet. When a client receives a response, it uses the network information (src/dst IP/port), along with the Code and Identifier field, to find the original request. For example, [RFC2865] Section 4.2 has the following text for Access-Accept responses: On reception of an Access-Accept, the Identifier field is matched with a pending Access-Request. The Response Authenticator field MUST contain the correct response for the pending Access-Request. Invalid packets are silently discarded. Each response packet definition has similar text. The client is currently unable to use the Request Authenticator as an identifier, because that field is not available when it receives the response. The solution defined herein is that the response contains an attribute, Original-Request-Authenticator. Clients can then use this attribute as an additional identifier, to correlate responses with requests. The Identifier field is still used, but is no longer the sole key used to correlate requests and responses. Since the Request Authenticator field is sixteen octets in size, this process allows a nearly unlimited number of requests to be outstanding on any connection. More correctly, it allows up to XXX requests and replies to be "live" over one connection. Even allowing for limitations on Request Authenticator uniques as described below, this should be more than sufficient for all practical purposes. The final piece of the solution is negotiation. Clients must be aware that servers support this behavior before sending more than 256 requests on one connection. Servers must be aware that they need to copy the Request Authenticator field from the request packet to the contents of the Original-Request-Authenticator attribute in the response packet. As with other specifications (refs...), we use DeKok, Alan Standards Track [Page 6] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 Status-Server for negotiation. 3. Signaling via Status-Server When a client supports this functionality, it sends a Status-Server packet to the server, containing an Original-Request-Authenticator attribute. See Section X, below, for the definition of the Original- Request-Authenticator attribute. The contents of the Original-Request-Authenticator attribute MUST be zero. The Original-Request-Authenticator attribute MUST NOT appear in any request packet other than Status-Server. A server which supports this functionality SHOULD signal that capability to the client by sending a response packet which contains an Original-Request-Authenticator attribute. That attribute MUST contain a copy of the Request Authenticator from the original Status- Server packet. When a client sends an Original-Request-Authenticator attribute in a Status-Server and does not receive that attribute in the response, the client MUST NOT use the Request Authenticator as an identifier field. The client MUST then behave as a normal RADIUS client. If a server does not support this functionality, it MUST NOT place an Original-Request-Authenticator attribute in the response packet. As the default behavior of existing RADIUS servers is to not place this attribute in the response to a Status-Server, negotiation will downgrade automatically to using standard RADIUS. As the response to a Status-Server can use one of many RADIUS Codes, we use a generic "response" name above. See following sections for how to handle specific types of responses. Even if a client and server negotiate the use of Original-Request- Authenticator, the client can, with no loss of functionality, simply fall back to the previous RADIUS behavior. For example, if the server misbehaves and sends either no Original-Request-Authenticator attribute, or an invalid one, the client falls back to allowing only 256 packets outstanding at one time. There is no need for the client to signal the server that it is behaving this way. Similarly, if a client and server negotiate the use of Original- Request-Authenticator, the server can, with no loss of functionality, simply fall back to the previous RADIUS behavior. For example, if the server decides to not honor previous negotiation of the Original- Request-Authenticator attribute, it simply stops sending that attribute in response packets. The client then sees that the DeKok, Alan Standards Track [Page 7] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 responses have no Original-Request-Authenticator attribute, and falls back to using standard RADIUS. There is a time frame during this fall back process during which the client and server may disagree on the capability of the other party. The main side effect of this disagreement is a transient increase in packet loss. This effect will quickly correct itself. That packet loss is minimal, and should not cause problems in practice. The possibility of such packet loss should be used instead by implementors as incentive to ensure that they do not create invalid Original-Request-Authenticator attributes. Implementing the specification correctly will prevent this packet loss from occuring. The negotiation outlined here ensures that RADIUS clients and servers supporting this functionality are entirely backwards compatible with existing RADIUS clients and servers. 3.1. Static Configuration As an alternative to using Status-Server, clients and servers MAY be administratively configured with a flag which indicates that the other party supports this functionality. Such a flag can be used where the parties are known to each other. Such a flag is not appropriate for dynamic peer discovery [RFC7585], as there are no provisions for encoding the flag in the DNS queries or responses. When a client is administratively configured to know that a server supports this functionality, it SHOULD NOT do negotiation via Status- Server. If a client is administratively configured to believe that a server supports the Original-Request-Authenticator attribute, but the response packets do not contain an Original-Request-Authenticator attribute, the client MUST update its configuration to mark the server as not supporting this functionality. This process allows for relatively simple downgrade negotiation in the event of misconfiguration on either the client or the server. 4. Original-Request-Authenticator Attribute We define a new attribute, called Original-Request-Authenticator. It is intended to be used in response packets, where it contains an exact copy of the Request Authenticator field from the original request that elicited the response. As per the suggestions of [RFC8044], we describe the attribute using DeKok, Alan Standards Track [Page 8] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 a data type defined therein, and without the use of ASCII art. Type TBD - IANA allocation from the "extended" type space Length 19 - TBD double-check this after IANA allocation Data Type octets Value MUST be 16 octets in length. For Status-Server packets, the contents of the Value field MUST be zero. For response packets, the contents of the Value field MUST be a copy of the Request Authenticator from the original packet that elicited the response. The Original-Request-Authenticator attribute can be used in a Status- Server packet. The Original-Request-Authenticator attribute can be used in a response packet. For example, it can be used in an Access-Accept, Accounting-Response, CoA-ACK, etc. The Original-Request-Authenticator attribute MUST NOT be used in any request packet. For example, it cannot be used in an Access-Request, Accounting-Request, or CoA-Request packet. Where permitted, the Original-Request-Authenticator attribute MUST exist either zero or one times in a packet. There MUST NOT be multiple occurances of the attribute in a packet. Where the format and/or contents of the Original-Request- Authenticator attribute does not meet these criteria, it MUST be treated as an "invalid attribute" as per [RFC6929], Section 2.8. That is, when an invalid Original-Request-Authenticator attribute is seen by either a client or server, their behavior is to behave as if the attribute did not exist, and therefore the parties should fall back to using standard RADIUS. 5. Transport Considerations This section describes transport considerations for this specification. DeKok, Alan Standards Track [Page 9] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 The considerations for DTLS are largely the same as for UDP. The considerations for TLS are largely the same as for TCP. We therefore do not have different sections herein for the TLS-enabled portion of the protocols. 5.1. UDP RADIUS over UDP is defined in [RFC2866]. RADIUS over DTLS is defined in [RFC7360]. When negotiated by both peers, this proposal changes the number of requests which can be outstanding over a UDP connection. Where clients are sending RADIUS packets over UDP, they SHOULD include the Original-Request-Authenticator attribute in all Status- Server messages to a server, even if the functionality has been previously negotiatied. While the client can generally assume that a continual flow of packets means that the server has not been changed, this assumption is not true when the server is unresponsive, and the client decides it needs to send Status-Server packets. Similarly, the server cannot assume that it is respond to the same client on every packet. However, once Original-Request-Authenticator has been negotiasted, the server can safely include that attribute in all response packets to that client. If the client changes to not supporting the attribute, the attribute will be ignored by the client, and the behavior falls back to standard RADIUS. Where clients are sending RADIUS packets over DTLS, there is an underlying TLS session context. The client can therefore assume that all packets for one TLS session are for the same server, with the same capabilities. The server can make the same assumption. Where clients start a new connection to a RADIUS over DTLS server, they SHOULD negotiate this functionality again, unless the behavior has been statically configured.. There is no guarantee that the new connection goes to the same server. 5.2. TCP RADIUS over TCP is defined in [RFC6614]. RADIUS over TLS is defined in [RFC6614]. When negotiated by both peers, this proposal changes the number of requests which can be outstanding over a TCP connection. Where clients start a new connection to a RADIUS over DTLS server, they SHOULD negotiate this functionality again, unless the behavior DeKok, Alan Standards Track [Page 10] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 has been statically configured.. There is no guarantee that the new connection goes to the same server. Status-Server packets are also used by the application-layer watchdog, described in [RFC6614] Section 2.6. Where clients have previously negotiated Original-Request-Authenticator for a connection, they MUST continue to send that attribute in all Status- Server packets over that connection. There are other consideratiosn with the use of Status-Server. Due to the limitations of the Id field, [RFC6613] Section 2.6.5 suggests: Implementations SHOULD reserve ID zero (0) on each TCP connection for Status-Server packets. This value was picked arbitrarily, as there is no reason to choose any one value over another for this use. This restriction can now be relaxed when both client and server have negotiated the use of the Original-Request-Authenticator attribute. Or, with no loss of generality, implementations can continue to use a fixed Id field for Status-Server application watchdog messages. We also note that the next paragraph of [RFC6614] Section 2.6.5. says: Implementors may be tempted to extend RADIUS to permit more than 256 outstanding packets on one connection. However, doing so is a violation of a fundamental part of the protocol and MUST NOT be done. Making that extension here is outside of the scope of this specification. This specification extends RADIUS in a standard way, making that recommendation redundant. 5.3. Dynamic Discovery The dynamic discovery of RADIUS servers is defined in [RFC7585]. This specification is compatible with [RFC7585], with the exception of the statically configured flag described in Section X, above. As the server is dynamically discovered, it is impossible to have a static flag describing the server capabilities. The other considerations for dynamic discovery are the same as for RADIUS over TLS. DeKok, Alan Standards Track [Page 11] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 6. Implementation Considerations This section describes implementation considerations for clients and servers. 6.1. Client Considerations Clients SHOULD have an configuration flag which lets administators statically configure this behavior for a server. Clients MUST otherwise negotiate this functionality before using it. If this functionality has been negotiated, clients MUST use the Request Authenticator as an part of the key used to uniquely identify request packets. 6.2. Server Considerations Servers SHOULD have an configuration flag which lets administators statically configure this behavior for a client. ServersMUST otherwise negotiate this functionality before using it. If this functionality has been negotiated, clients MUST use the Request Authenticator as an part of the key used to uniquely identify request packets. 7. IANA Considerations This specification allocates one attribute in the RADIUS Attribute Type registry, as follows. Name Original-Request-Authenticator Type TBD - allocate from the "extended" space Data Type octets 8. Security Considerations This proposal does not change the underlying RADIUS security model, which is poor. The contents of the Original-Request-Authenticator attribute are the Request Authenticator, which is already public information for UDP or TCP transports. DeKok, Alan Standards Track [Page 12] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 The use of Original-Request-Authenticator is defined in such a way that all systems fall back gracefully to using standard RADIUS. As such, there are no interoperability issues between this specification and existing RADIUS implementations. There are few, if any, security considerations related to implementations. Clients already must track the Request Authenticator, so matching it in a response packet is minimal extra work. Servers must also track and cache duplicate packets, as per [RFC5080] Section 2.2.2, so using the Request Authenticator as an additional identifier is minimal extra work. The use (or not) of Original-Request-Authenticator has no other security considerations, as it is used solely as an identifier to match requests and responses. It has no other meaning or use. 9. Normative References 9.1. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 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. [RFC5080] Nelson, D., DeKok, A, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC6929] DeKok, A. and Lior, A., "Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, January 2017. Informative references [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", RFC 5997, August 2017. DeKok, Alan Standards Track [Page 13] INTERNET-DRAFT Identifying RADIUS packets. 24 April 2017 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. [RFC6614] Winter, S., et al, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012. [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS", RFC 7360, September 2014. [RFC7585] Winter, S., and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 7585, October 2015 Acknowledgments Parts of the text in Section 3 defining the Request and Response Authenticators were taken with minor edits from [RFC2865] Section 3. The author would like to thank Mike McCauley of Open Systems Consultants for making a Radiator server available for interoperability testing. Ignacio Goyret provided valuable feedback on the history and security of the Status-Server packet. Author's Address Alan DeKok The FreeRADIUS Server Project http://freeradius.org Email: aland@freeradius.org DeKok, Alan Standards Track [Page 14]