--- 1/draft-ietf-radext-status-server-03.txt 2009-03-02 23:12:10.000000000 +0100 +++ 2/draft-ietf-radext-status-server-04.txt 2009-03-02 23:12:10.000000000 +0100 @@ -1,51 +1,60 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS -Category: Proposed Standard - -Expires: June 16, 2009 -16 December 2008 - +Category: Informational + +Expires: September 1, 2009 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. 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. + 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 June 16, 2009. + This Internet-Draft will expire on September 1, 2009. Copyright Notice - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. - Copyright (c) 2008 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. + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract RFC 2865 defines a Status-Server code for use in RADIUS, but labels it as "Experimental" without further discussion. This document describes a practical use for the Status-Server packet code, which is to let clients query the status of a RADIUS server. These queries, and responses (if any) enable the client to make more informed decisions. The result is a more stable, and more robust RADIUS architecture. @@ -54,47 +63,43 @@ 1. Introduction ............................................. 4 1.1. Terminology ......................................... 4 1.2. Requirements Language ............................... 5 2. Problem Statement ........................................ 6 2.1. Overloading Access-Request .......................... 6 2.1.1. Recommendation against Access-Request .......... 7 2.2. Overloading Accounting-Request ...................... 7 2.2.1. Recommendation against Accounting-Request ...... 8 2.3. Status-Server as a Solution ......................... 8 - 2.3.1. Status-Server to the RADIUS Authentication port. 8 + 2.3.1. Status-Server to the RADIUS Authentication port 8 2.3.2. Status-Server to the RADIUS Accounting port .... 9 3. Packet Format ............................................ 9 3.1. Single definition for Status-Server ................. 11 4. Implementation notes ..................................... 11 4.1. Client Requirements ................................. 12 4.2. Server Requirements ................................. 14 4.3. More Robust Fail-over with Status-Server ............ 15 4.4. Proxy Server handling of Status-Server .............. 16 4.5. Realm Routing ....................................... 16 4.6. Management Information Base (MIB) Considerations .... 18 4.6.1. Interaction with RADIUS Server MIB modules ..... 18 4.6.2. Interaction with RADIUS Client MIB modules ..... 19 -5. Additional considerations ................................ 19 - 5.1. Local site testing .................................. 19 - 5.2. RADIUS over reliable transports ..................... 21 - 5.3. Other uses for Status-Server ........................ 21 -6. Table of Attributes ...................................... 21 -7. Examples ................................................. 22 - 7.1. Minimal Query to Authentication Port ................ 22 - 7.2. Minimal Query to Accounting Port .................... 23 - 7.3. Verbose Query and Response .......................... 24 -8. IANA Considerations ...................................... 25 -9. Security Considerations .................................. 25 -10. References .............................................. 25 - 10.1. Normative references ............................... 25 - 10.2. Informative references ............................. 25 +5. Table of Attributes ...................................... 19 +6. Examples ................................................. 20 + 6.1. Minimal Query to Authentication Port ................ 20 + 6.2. Minimal Query to Accounting Port .................... 21 + 6.3. Verbose Query and Response .......................... 22 +7. IANA Considerations ...................................... 22 +8. Security Considerations .................................. 23 +9. References ............................................... 23 + 9.1. Normative references ................................ 23 + 9.2. Informative references .............................. 23 1. Introduction The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and created a number of standards surrounding the protocol. It also defined experimental commands within the protocol, without elaborating further on the potential uses of those commands. One of the commands so defined was Status-Server ([RFC2865] Section 3.). @@ -434,34 +439,34 @@ implementing support for Status-Server. This section describes implementation details and requirements for RADIUS clients and servers that support Status-Server. The following text applies to the authentication and accounting ports. We use the generic terms below to simplify the discussion: * Request packet An Access-Request packet sent to an authentication port, or - an Accounting-Request packet sent to an accounting port + an Accounting-Request packet sent to an accounting port. * Response packet An Access-Accept, Access-Challenge, or Access-Reject packet sent from an authentication port, or an Accounting-Response packet sent from an accounting port. 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 + simpler than duplicating the text for authentication and accounting packets. 4.1. Client Requirements Clients SHOULD permit administrators to globally enable or disable the generation of Status-Server packets. The default SHOULD be that it is disabled. As it is undesirable to send queries to servers that do not support Status-Server, clients SHOULD also have a per-server configuration indicating whether or not to enable Status-Server for a particular destination. The default SHOULD be that it is disabled. @@ -762,21 +767,21 @@ combination of these two practices will maximize network reliability and stability. 4.6. Management Information Base (MIB) Considerations 4.6.1. Interaction with RADIUS Server MIB modules Since Status-Server packets are sent to the defined RADIUS ports, they can affect the [RFC4669] and [RFC4671] RADIUS server MIB modules. [RFC4669] defines a counter named - radiusAuthServTotalUnknownTypes, that counts "The number of RADIUS + radiusAuthServTotalUnknownTypes that counts "The number of RADIUS packets of unknown type that were received". [RFC4671] defines a similar counter named radiusAcctServTotalUnknownTypes. Implementations not supporting Status-Server, or implementations that are configured to not 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 @@ -794,128 +799,25 @@ Clients implementing Status-Server MUST NOT increment [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 containing similar information as those MIB modules, - but which are instead dedicated solely to tracking Status-Server - requests and responses. Any definition of the client MIB module - extensions for Status-Server is outside of the scope of this - document. - -5. Additional considerations - - There are additional topics related to the use of Status-Server that - may be covered. As those topics do not fit well into the preceding - sections, they are covered herein. - -5.1. Local site testing - - There is at least one situation where using Access-Request or - Accounting-Request packets may be useful, despite the recommendations - above in Section 2.1.1 and Section 2.2.1. That situation is local - site testing, where the RADIUS client, server, and user store are - under the control of a single administrator or administrative entity. - In that situation, administrators MAY configure a well-known "test" - user to enable local site testing. - - The advantage to creating such a local user is that it is now - possible for the administrator to send a RADIUS request that performs - end-to-end testing of the RADIUS server. As above with Status- - Server, this testing includes RADIUS server responsiveness. It may - also include querying databases of user authentication credentials, - or storing accounting data to a billing database. The information - obtained from performing those queries is that the entire RADIUS - server infrastructure, including all of its dependencies, is - functioning as expected. These queries are most useful in - deployments where an administrator has internal RADIUS servers that - proxy to other internal RADIUS servers, such as for load balancing or - fail over. - - If used, the names utilized for these test users SHOULD be difficult - to guess by an attacker. An Access-Request packet for a test user - otherwise should be treated as follows, depending on its origin: - - o Packets from localhost (127.0.0.1 or ::1): RADIUS servers - SHOULD treat the request according to local site policy. - - o Packets from NASes that normally originate Access-Request - packets (i.e. not proxy servers): RADIUS servers SHOULD respond - with an Access-Reject packet, as the use of Status-Server is - preferred. - - o Packets from other machines controlled by the administrator: - RADIUS servers SHOULD treat the request according to local site - policy. - - o Packets originating from machines not controlled by the - administrator: RADIUS servers MUST respond with an Access-Reject - packet. - - If a RADIUS server is configured to support test users for - Accounting-Request packets, it MAY respond with an Accounting- - Response packet, independent of the origin of the request. However, - any subsequent analysis of the accounting data such as billing or - usage MUST NOT include the data for the test user. - - If these recommendations are implemented, then it may be possible in - some situations to safely query a RADIUS server for responsiveness - using Access-Request or Accounting-Request packets. However, this - behavior is still NOT RECOMMENDED. - -5.2. RADIUS over reliable transports - - Although RADIUS has been assigned two TCP ports (1812/tcp and - 1813/tcp) in addition to the commonly used UDP ports, there has been - as yet no specification for using TCP as a reliable transport for - RADIUS. If such a specification were to be created, then the - transport issues discussed in [RFC3539] would apply. - - Further, when RADIUS is run over reliable transports, the watchdog - algorithm described in [RFC3539] Section 3.4 MUST be used rather than - the algorithm described above. For the reasons outlined above in - Section 2, Status-Server packets SHOULD be used as the watchdog - request, in preference to Access-Request or Accounting-Request - packets. - - Clients sending Status-Server over reliable transport MUST ensure - that the Identifier field is unique for all requests on a particular - connection, independent of the packet code. That is, if a Status- - Server with a particular value in the Identifier field is sent to a - server, the client MUST NOT simultaneously send an Access-Request or - Accounting-Request packet with that same Identifier value, on that - connection. Once the client has either received a response to the - Status-Server packet, or has determined that the Status-Server packet - has timed out, it may reuse that Identifier in another packet. - -5.3. Other uses for Status-Server - - While other uses of Status-Server are possible, uses beyond those - specified here are beyond the scope of this document. It may be - tempting to increase the utility of Status-Server by having the - responses carry additional information, but implementors are warned - that such uses have not been analyzed for potential security issues - or network problems. - - Specifically, it may seem useful to leverage a combination of Status- - Server and CoA ports in order to send realm routing information - "upstream" from the home servers to the proxy servers, and finally to - the NAS. This use of Status-Server is NOT RECOMMENDED, as there has - been insufficient analysis and deployment experience to know if it is - useful, or even if it makes the network less reliable. + MIB extensions dedicated solely to tracking Status-Server requests + and responses. Any definition of the client MIB module extensions + for Status-Server is outside of the scope of this document. -6. Table of Attributes +5. Table of Attributes The following table provides a guide to which attributes may be found in Status-Server packets, and in what quantity. Attributes other than the ones listed below SHOULD NOT be found in a Status-Server packet. Status- Access- Accounting- Server Accept Response # Attribute 0-1 0 0 4 NAS-IP-Address [Note 1] @@ -929,29 +830,29 @@ NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address). The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet. -7. Examples +6. Examples A few examples are presented to illustrate the flow of packets to both the authentication and accounting ports. These examples are not intended to be exhaustive, many others are possible. Hexadecimal dumps of the example packets are given in network byte order, using the shared secret "xyzzy5461". -7.1. Minimal Query to Authentication Port +6.1. Minimal Query to Authentication Port The NAS sends a Status-Server UDP packet with minimal content to a RADIUS server on port 1812. The Request Authenticator is a 16 octet random number generated by the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client. 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 @@ -954,39 +855,39 @@ that the request came from a known client. 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 82 20 97 c8 4f a3 1 Code = Status-Server (12) 1 ID = 218 2 Length = 38 16 Request Authenticator + Attributes: 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 The Response Authenticator is a 16 octet MD5 checksum of the code (2), id (218), Length (20), the Request Authenticator from above, and the shared secret. 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 b5 41 1d 66 - 1 Code = Access-Accept (2) 1 ID = 218 2 Length = 20 16 Request Authenticator Attributes: None. -7.2. Minimal Query to Accounting Port +6.2. Minimal Query to Accounting Port The NAS sends a Status-Server UDP packet with minimal content to a RADIUS server on port 1813. The Request Authenticator is a 16 octet random number generated by the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client. 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f @@ -1007,21 +908,21 @@ 02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 48 60 66 9c 1 Code = Accounting-Response (5) 1 ID = 179 2 Length = 20 16 Request Authenticator Attributes: None. -7.3. Verbose Query and Response +6.3. Verbose Query and Response The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS server on port 1812. The Request Authenticator is a 16 octet random number generated by the NAS. 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 @@ -1047,58 +948,58 @@ 38 3a 34 30 1 Code = Access-Accept (2) 1 ID = 71 2 Length = 52 16 Request Authenticator Attributes: 32 Reply-Message (18) -8. IANA Considerations +7. IANA Considerations This specification does not create any new registries, nor does it require assignment of any protocol parameters. -9. Security Considerations +8. Security Considerations This document defines the Status-Server packet as being similar in treatment to the Access-Request packet, and is therefore subject to the same security considerations as described in [RFC2865], Section 8. Status-Server packets also use the Message-Authenticator attribute, and are therefore subject to the same security considerations as [RFC3579], Section 4. We reiterate that Status-Server packets MUST contain a Message- Authenticator attribute. Early implementations supporting Status- Server did not enforce this requirement, and may have been vulnerable to DoS attacks as a result. 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. -10. References +9. References -10.1. Normative references +9.1. Normative references [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC4282] Aboba, B., and Beadles, M. at al, "The Network Access Identifier", RFC 4282, December 2005. -10.2. Informative references +9.2. Informative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and Accounting (AAA) Transport Profile", RFC 3539, June 2003. [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In