Internet Engineering Task Force (IETF) A. DeKok Request for Comments: 5997 FreeRADIUS Updates: 2866 August 2010 Category: Informational ISSN: 2070-1721 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
AbstractThis document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5997. 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. 1. Introduction ....................................................3 1.1. Applicability ..............................................3 1.2. Terminology ................................................4 1.3. Requirements Language ......................................4 2. Overview ........................................................4 2.1. Why Access-Request is Inappropriate ........................6 2.1.1. Recommendation against Access-Request ...............7 2.2. Why Accounting-Request is Inappropriate ....................7 2.2.1. Recommendation against Accounting-Request ...........7 3. Packet Format ...................................................8 3.1. Single Definition for Status-Server .......................10 4. Implementation Notes ...........................................10 4.1. Client Requirements .......................................11 4.2. Server Requirements .......................................12 4.3. Failover with Status-Server ...............................14 4.4. Proxy Server Handling of Status-Server ....................14 4.5. Limitations of Status-Server ..............................15 4.6. Management Information Base (MIB) Considerations ..........17 4.6.1. Interaction with RADIUS Server MIB Modules .........17 4.6.2. Interaction with RADIUS Client MIB Modules .........17 5. Table of Attributes ............................................18 6. Examples .......................................................19 6.1. Minimal Query to Authentication Port ......................19 6.2. Minimal Query to Accounting Port ..........................20 6.3. Verbose Query and Response ................................21 7. Security Considerations ........................................21 8. References .....................................................23 8.1. Normative References ......................................23 8.2. Informative References ....................................23 Acknowledgments ...................................................24
RFC2865], Section 3, details of the operation and potential uses of the Code were not provided. As with the core RADIUS protocol, the Status-Server extension is stateless, and queries do not otherwise affect the normal operation of a server, nor do they result in any side effects, other than perhaps incrementing an internal packet counter. Most of the implementations of this extension have utilized it alongside implementations of RADIUS as defined in [RFC2865], so that this document focuses solely on the use of this extension with UDP transport. The rest of this document is laid out as follows. Section 2 contains the problem statement, and explanations as to why some possible solutions can have unwanted side effects. Section 3 defines the Status-Server packet format. Section 4 contains client and server requirements, along with some implementation notes. Section 5 contains a RADIUS table of attributes. The remaining text discusses security considerations not covered elsewhere in the document. RFC3579]). This enables an unauthorized client to spoof Status-Server packets, potentially leading to incorrect Access-Accepts. In order to remedy this problem, this specification requires the use of the Message- Authenticator attribute to provide per-packet authentication and integrity protection. With existing implementations of this protocol, the potential exists for Status-Server requests to be in conflict with Access-Request or Accounting-Request packets using the same Identifier. This specification recommends techniques to avoid this problem.
These limitations are discussed in more detail below. RFC2119].
response is NOT RECOMMENDED. An Access-Reject response MAY be used. The list of attributes that are permitted in Status-Server packets, and in Access-Accept or Accounting-Response packets responding to Status-Server packets, is provided in Section 5. Section 6 provides several examples. Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the client is provided with an indication of the status of that server only, since no RADIUS proxies are on the path between the RADIUS client and server. As servers respond to a Status-Server packet without examining the User-Name attribute, the response to a Status-Server packet cannot be used to infer any information about the reachability of specific realms. The "hop-by-hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of the first element on the path between the client and a server. Since the Status-Server packet is non-forwardable, the lack of a response may only be due to packet loss or the failure of the server at the destination IP address, and not due to faults in downstream links, proxies, or servers. It therefore provides an unambiguous indication of the status of a server. This information may be useful in situations in which the RADIUS client does not receive a response to an Access-Request. A client may have multiple proxies configured, with one proxy marked as primary and another marked as secondary. If the client does not receive a response to a request sent to the primary proxy, it can "failover" to the secondary, and send requests to the secondary proxy instead. However, it is possible that the lack of a response to requests sent to the primary proxy was due not to a failure within the primary, but to alternative causes such as a failed link along the path to the destination server or the failure of the destination server itself. In such a situation, it may be useful for the client to be able to distinguish between failure causes so that it does not trigger failover inappropriately. For example, if the primary proxy is down, then a quick failover to the secondary proxy would be prudent; whereas, if a downstream failure is the cause, then the value of failover to a secondary proxy will depend on whether packets forwarded by the secondary will utilize independent links, intermediaries, or destination servers.
The Status-Server packet is not a "Keep-Alive" as discussed in [RFC2865], Section 2.6. "Keep-Alives" are Access-Request packets sent to determine whether a downstream server is responsive. These packets are typically sent only when a server is suspected to be down, and they are no longer sent as soon as the server is available again.
RFC2865], Section 3. We do not include all of the text or diagrams of that section here, but instead explain the differences required to implement Status-Server. The Authenticator field of Status-Server packets MUST be generated using the same method as that used for the Request Authenticator field of Access-Request packets, as given below. The role of the Identifier field is the same for Status-Server as for other packets. However, as Status-Server is taking the role of Access-Request or Accounting-Request packets, there is the potential for Status-Server requests to be in conflict with Access-Request or Accounting-Request packets with the same Identifier. In Section 4.2 below, we describe a method for avoiding these problems. This method MUST be used to avoid conflicts between Status-Server and other packet types. Request Authenticator In Status-Server packets, the Authenticator value is a 16-octet random number called the Request Authenticator. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. See [RFC4086] for suggestions as to how random numbers may be generated. The Request Authenticator value in a Status-Server packet SHOULD also be unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Status-Server request from a client. Similarly, the Response Authenticator field of an Access-Accept packet sent in response to Status-Server queries MUST be generated using the same method as used for calculating the Response Authenticator of the Access-Accept sent in response to an Access- Request, with the Status-Server Request Authenticator taking the place of the Access-Request Request Authenticator.
The Response Authenticator field of an Accounting-Response packet sent in response to Status-Server queries MUST be generated using the same method as used for calculating the Response Authenticator of the Accounting-Response sent in response to an Accounting-Request, with the Status-Server Request Authenticator taking the place of the Accounting-Request Request Authenticator. Note that when a server responds to a Status-Server request, it MUST NOT send more than one Response packet. Response Authenticator The value of the Authenticator field in Access-Accept or Accounting-Response packets is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of: the RADIUS packet, beginning with the Code field, including the Identifier, the Length, the Request Authenticator field from the Status-Server packet, and the response Attributes (if any), followed by the shared secret. That is, ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + denotes concatenation. In addition to the above requirements, all Status-Server packets MUST include a Message-Authenticator attribute. Failure to do so would mean that the packets could be trivially spoofed. Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-Address or NAS-IPv6-Address. These attributes are not necessary for the operation of Status-Server, but may be useful information to a server that receives those packets. Other attributes SHOULD NOT be included in a Status-Server packet, and MUST be ignored if they are included. User authentication credentials such as User-Name, User-Password, CHAP-Password, EAP-Message MUST NOT appear in a Status-Server packet sent to a RADIUS authentication port. User or NAS accounting attributes such as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT appear in a Status-Server packet sent to a RADIUS accounting port. The Access-Accept MAY contain a Reply-Message or Message- Authenticator attribute. It SHOULD NOT contain other attributes. The Accounting-Response packets sent in response to a Status-Server query SHOULD NOT contain any attributes. As the intent is to
implement a simple query instead of user authentication or accounting, there is little reason to include other attributes in either the query or the corresponding response. Examples of Status-Server packet flows are given below in Section 6.
We also refer to "client" as the originator of the Status-Server packet, and "server" as the receiver of that packet and the originator of the Response packet. Using generic terms to describe the Status-Server conversations is simpler than duplicating the text for authentication and accounting packets. Section 2.2.1 of [RFC5080], to determine when to send Status-Server packets. When Status-Server packets are sent from a client, they MUST NOT be retransmitted. Instead, the Identity field MUST be changed every time a packet is transmitted. The old packet should be discarded, and a new Status-Server packet should be generated and sent, with new Identity and Authenticator fields. Clients MUST include the Message-Authenticator attribute in all Status-Server packets. Failure to do so would mean that the packets could be trivially spoofed, leading to potential denial-of-service (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server packet, except as outlined below in Section 5. As the intent of the packet is a simple status query, there is little reason for any additional attributes to appear in Status-Server packets. The client MAY increment packet counters as a result of sending a Status-Server request or of receiving a Response packet. The client MUST NOT perform any other action that is normally performed when it receives a Response packet, such as permitting a user to have login access to a port. Clients MAY send Status-Server requests to the RADIUS destination ports from the same source port used to send normal Request packets. Other clients MAY choose to send Status-Server requests from a unique source port that is not used to send Request packets. The above suggestion for a unique source port for Status-Server packets aids in matching responses to requests. Since the response to a Status-Server packet is an Access-Accept or Accounting-Response
packet, those responses are indistinguishable from other packets sent in response to a Request packet. Therefore, the best way to distinguish them from other traffic is to have a unique port. A client MAY send a Status-Server packet from a source port also used to send Request packets. In that case, the Identifier field MUST be unique across all outstanding Request packets for that source port, independent of the value of the RADIUS Code field for those outstanding requests. Once the client has either received a response to the Status-Server packet or determined that the Status-Server packet has timed out, it may reuse that Identifier in another packet. Robust implementations SHOULD accept any Response packet as a valid response to a Status-Server packet, subject to the validation requirements defined above for the Response Authenticator. The Code field of the packet matters less than the fact that a valid, signed response has been received. That is, prior to accepting the response as valid, the client should check that the Response packet Code field is either Access-Accept (2) or Accounting-Response (5). If the Code does not match any of these values, the packet MUST be silently discarded. The client MUST then validate the Response Authenticator via the algorithm given above in Section 3. If the Response Authenticator is not valid, the packet MUST be silently discarded. If the Response Authenticator is valid, then the packet MUST be deemed to be a valid response from the server. If the client instead discarded the response because the packet Code did not match what it expected, then it could erroneously discard valid responses from a server, and mark that server as unresponsive. This behavior would affect the stability of a RADIUS network, as responsive servers would erroneously be marked as unresponsive. We therefore recommend that clients should be liberal in what they accept as responses to Status-Server queries.
We note that [RFC2865], Section 3, defines a number of RADIUS Codes, but does not make statements about which Codes are valid for port 1812. In contrast, [RFC2866], Section 3, specifies that only RADIUS Accounting packets are to be sent to port 1813. This specification is compatible with [RFC2865], as it uses a known Code for packets to port 1812. This specification is not compatible with [RFC2866], as it adds a new Code (Status-Server) that is valid for port 1812. However, as the category of [RFC2866] is Informational, this conflict is acceptable. Servers SHOULD silently discard Status-Server packets if they determine that a client is sending too many Status-Server requests in a particular time period. The method used by a server to make this determination is implementation specific and out of scope for this specification. If a server supports Status-Server packets, and is configured to respond to them, and receives a packet from a known client, it MUST validate the Message-Authenticator attribute as defined in [RFC3579], Section 3.2. Packets failing that validation MUST be silently discarded. Servers SHOULD NOT otherwise discard Status-Server packets if they have recently sent the client a Response packet. The query may have originated from an administrator who does not have access to the Response packet stream or one who is interested in obtaining additional information about the server. The server MAY prioritize the handling of Status-Server packets over the handling of other requests, subject to the rate limiting described above. The server MAY decide not to respond to a Status-Server, depending on local-site policy. For example, a server that is running but is unable to perform its normal activities MAY silently discard Status- Server packets. This situation can happen, for example, when a server requires access to a database for normal operation, but the connection to that database is down. Or, it may happen when the accepted load on the server is lower than the offered load. Some server implementations require that Access-Request packets be accepted only on "authentication" ports (e.g., 1812/udp), and that Accounting-Request packets be accepted only on "accounting" ports (e.g., 1813/udp). Those implementations SHOULD reply to Status- Server packets sent to an "authentication" port with an Access-Accept packet and SHOULD reply to Status-Server packets sent to an "accounting" port with an Accounting-Response packet.
Some server implementations accept both Access-Request and Accounting-Request packets on the same port, and they do not distinguish between "authentication only" ports and "accounting only" ports. Those implementations SHOULD reply to Status-Server packets with an Access-Accept packet. The server MAY increment packet counters as a result of receiving a Status-Server packet or sending a Response packet. The server SHOULD NOT perform any other action that is normally performed when it receives a Request packet, other than sending a Response packet. Section 2.2.1 of [RFC5080]. If a reliable transport is used for RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST be used.
with which it has a direct relationship. Proxying Status-Server queries would negate any usefulness that may be gained by implementing support for them. Proxy servers MAY be configured to respond to Status-Server queries from clients, and they MAY act as clients sending Status-Server queries to other servers. However, those activities MUST be independent of one another. RFC4282]. In this practice, the User-Name attribute is decorated with realm- routing information, commonly in the format of "user@realm". Since a particular RADIUS server may act as a proxy for more than one realm, we need to explain how the behavior defined above in Section 4.3 affects realm routing. The schematic below demonstrates this scenario. /-> RADIUS Proxy P -----> RADIUS Server for Realm A / \ / NAS X \ / \ \-> RADIUS Proxy S -----> RADIUS Server for Realm B That is, the NAS has relationships with two RADIUS Proxies, P and S. Each RADIUS proxy has relationships with RADIUS servers for both Realm A and Realm B. In this scenario, the RADIUS proxies can determine if one or both of the RADIUS servers are dead or unreachable. The NAS can determine if one or both of the RADIUS proxies are dead or unreachable. There is an additional case to consider, however. If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but RADIUS Proxy S can reach that RADIUS server, then the NAS cannot discover this information using the Status-Server queries as outlined above. It would therefore be useful for the NAS to know that Realm A is reachable from RADIUS Proxy S, as it can then route all requests for Realm A to that RADIUS proxy. Without this knowledge, the client may route requests to RADIUS Proxy P, where they may be discarded or rejected. To complicate matters, the behavior of RADIUS Proxies P and S in this situation is not well defined. Some implementations simply fail to respond to the request, and other implementations respond with an
Access-Reject. If the implementation fails to respond, then the NAS cannot distinguish between the RADIUS proxy being down and the next server along the proxy chain being unreachable. In the worst case, failures in routing for Realm A may affect users of Realm B. For example, if RADIUS Proxy P can reach Realm B but not Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then active paths exist to handle all RADIUS requests. However, depending on the NAS and RADIUS proxy implementation choices, the NAS may not be able to determine to which server requests may be sent in order to maintain network stability. Unfortunately, this problem cannot be solved by using Status-Server requests. A robust solution would involve either a RADIUS routing table for the NAI realms or a RADIUS "destination unreachable" response to authentication requests. Either solution would not fit into the traditional RADIUS model, and both are therefore outside of the scope of this specification. The problem is discussed here in order to define how best to use Status-Server in this situation, rather than to define a new solution. When a server has responded recently to a request from a client, that client MUST mark the server as "responsive". In the above case, a RADIUS proxy may be responding to requests destined for Realm A, but not responding to requests destined for Realm B. The client therefore considers the server to be responsive, as it is receiving responses from the server. The client will then continue to send requests to the RADIUS proxy for destination Realm B, even though the RADIUS proxy cannot route the requests to that destination. This failure is a known limitation of RADIUS, and can be partially addressed through the use of failover in the RADIUS proxies. A more realistic situation than the one outlined above is one in which each RADIUS proxy also has multiple choices of RADIUS servers for a realm, as outlined below. /-> RADIUS Proxy P -----> RADIUS Server P / \ / NAS X \ / \ \-> RADIUS Proxy S -----> RADIUS Server S
In this situation, if all participants implement Status-Server as defined herein, any one link may be broken, and all requests from the NAS will still reach a RADIUS server. If two links are broken at different places (i.e., not both links from the NAS), then all requests from the NAS will still reach a RADIUS server. In many situations where three or more links are broken, requests from the NAS may still reach a RADIUS server. It is RECOMMENDED, therefore, that implementations desiring the most benefit from Status-Server also implement server failover. The combination of these two practices will maximize network reliability and stability. RFC4669] and [RFC4671] RADIUS server MIB modules. [RFC4669] defines a counter named radiusAuthServTotalUnknownTypes that counts "The number of RADIUS packets of unknown type that were received". [RFC4671] defines a similar counter named radiusAccServTotalUnknownTypes. Implementations not supporting Status-Server or implementations that are configured not to respond to Status-Server packets MUST use these counters to track received Status-Server packets. If, however, Status-Server is supported and the server is configured to respond as described above, then the counters defined in [RFC4669] and [RFC4671] MUST NOT be used to track Status-Server requests or responses to those requests. That is, when a server fully implements Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST be unaffected by the transmission or reception of packets relating to Status-Server. If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB modules, then it SHOULD also support vendor-specific MIB extensions dedicated solely to tracking Status-Server requests and responses. Any definition of the server MIB modules for Status-Server is outside of the scope of this document. RFC4668] or [RFC4670] counters upon reception of Response packets to Status- Server queries. That is, when a server fully implements Status-
Server, the counters defined in [RFC4668] and [RFC4670] MUST be unaffected by the transmission or reception of packets relating to Status-Server. If an implementation supports Status-Server and the [RFC4668] or [RFC4670] MIB modules, then it SHOULD also support vendor-specific MIB extensions dedicated solely to tracking Status-Server requests and responses. Any definition of the client MIB modules for Status- Server is outside of the scope of this document.
We reiterate that Status-Server packets MUST contain a Message- Authenticator attribute. Early implementations supporting Status- Server did not enforce this requirement, and were vulnerable to the following attacks: * Servers not checking the Message-Authenticator attribute could respond to Status-Server packets from an attacker, potentially enabling a reflected DoS attack onto a real client. * Servers not checking the Message-Authenticator attribute could be subject to a race condition, where an attacker could see an Access-Request packet from a valid client and synthesize a Status-Server packet containing the same Request Authenticator. If the attacker won the race against the valid client, the server could respond with an Access-Accept and potentially authorize unwanted service. The last attack is similar to a related attack when Access-Request packets contain a CHAP-Password but no Message-Authenticator. We re-iterate the suggestion of [RFC5080], Section 2.2.2, which proposes that all clients send a Message-Authenticator in every Access-Request packet, and that all servers have a configuration setting to require (or not) that a Message-Authenticator attribute be used in every Access-Request packet. Failure to include a Message-Authenticator attribute in a Status- Server packet means that any RADIUS client or server may be vulnerable to the attacks outlined above. For this reason, implementations of this specification that fail to require use of the Message-Authenticator attribute are NOT RECOMMENDED. Where this document differs from [RFC2865] is that it defines a new request/response method in RADIUS: the Status-Server request. As this use is based on previously described and implemented standards, we know of no additional security considerations that arise from the use of Status-Server as defined herein. Attacks on cryptographic hashes are well known [RFC4270] and getting better with time. RADIUS uses the MD5 hash [RFC1321] for packet authentication and attribute obfuscation. There are ongoing efforts in the IETF to analyze and address these issues for the RADIUS protocol.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [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. [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006. [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006. [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006. 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. http://freeradius.org EMail: firstname.lastname@example.org