--- 1/draft-ietf-radext-status-server-02.txt 2008-12-18 02:12:03.000000000 +0100 +++ 2/draft-ietf-radext-status-server-03.txt 2008-12-18 02:12:03.000000000 +0100 @@ -1,101 +1,100 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS -Category: Informational - -Expires: May 2, 2009 -2 November 2008 +Category: Proposed Standard + +Expires: June 16, 2009 +16 December 2008 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of 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 May 2, 2009. + This Internet-Draft will expire on June 16, 2009. Copyright Notice - Copyright (C) The IETF Trust (2008). + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. + + 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. 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. Table of Contents -1. Introduction ............................................. 3 - 1.1. Terminology ......................................... 3 - 1.2. Requirements Language ............................... 4 -2. Problem Statement ........................................ 5 - 2.1. Overloading Access-Request .......................... 5 - 2.1.1. Recommendation against Access-Request .......... 6 - 2.2. Overloading Accounting-Request ...................... 6 - 2.2.1. Recommendation against Accounting-Request ...... 7 - 2.3. Status-Server as a Solution ......................... 7 - 2.3.1. Status-Server to the RADIUS Authentication port 7 -2.3.2. ....................................................... 8 - 2.3.3. Status-Server to the RADIUS Change-of-Authorizat 8 -3. Packet Format ............................................ 8 - 3.1. Consistent definition for Status-Server ............. 10 +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.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 ................................. 13 - 4.3. Change of Authorization and Status-Server ........... 15 - 4.4. More Robust Fail-over with Status-Server ............ 16 - 4.5. Proxy Server handling of Status-Server .............. 16 - 4.6. Realm Routing ....................................... 17 - 4.7. Management Information Base (MIB) Considerations .... 19 - 4.7.1. Interaction with RADIUS Server MIBs ............ 19 - 4.7.2. Interaction with RADIUS Client MIBs ............ 19 -5. Additional considerations ................................ 20 - 5.1. Local site testing .................................. 20 + 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 ........................ 22 -6. Table of Attributes ...................................... 22 + 5.3. Other uses for Status-Server ........................ 21 +6. Table of Attributes ...................................... 21 7. Examples ................................................. 22 - 7.1. Minimal Query to Authentication Port ................ 23 + 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 ............................... 26 - 10.2. Informative references ............................. 26 -Intellectual Property Statement .............................. 27 -Disclaimer of Validity ....................................... 28 -Full Copyright Statement ..................................... 28 + 10.1. Normative references ............................... 25 + 10.2. Informative references ............................. 25 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.). @@ -112,21 +111,21 @@ retransmissions internally. Since RADIUS runs over the User Datagram Protocol (UDP) rather than Transport Control Protocol (TCP), the full watchdog mechanism is not applicable here. 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 lists additional considerations not covered in the other sections. The - remaining text contains a RADIUS table of attributes, and discussed + remaining text contains a RADIUS table of attributes, and discusses security considerations not covered elsewhere in the document. 1.1. 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. @@ -191,55 +190,55 @@ conversation is necessary. Another possibility is that the server responds with an Access- Reject, indicating that the user is not authorized to gain access to the network. As above, the server may also perform local site actions, such as warning an administrator of failed login attempts. The server may also delay the Access-Reject response, in the traditional manner of rate-limiting failed authentication attempts. This delay in response means that the querying administrator is unsure as to whether or not the server is down, is slow to respond, - or is intentionally delaying it's response to the query. + or is intentionally delaying its response to the query. In addition, using Access-Request queries may mean that the server may have local users configured whose sole reason for existence is to enable these query requests. Unless the server's policy is designed carefully, it may be possible for an attacker to use those credentials to gain unauthorized network access. We note that some NAS implementations currently use Access-Request packets as described above, with a fixed (and non configurable) user name and password. Implementation issues with that equipment means - that if a RADIUS server does not respond to those qeuries, it may be + that if a RADIUS server does not respond to those queries, it may be marked as unresponsive by the NAS. This marking may happen even if the server is actively responding to other Access-Requests from that same NAS. This behavior is confusing to administrators who then need to determine why an active server has been marked as "unresponsive". 2.1.1. Recommendation against Access-Request For the reasons outlined above, NAS implementors SHOULD NOT generate Access-Request packets solely to see if a server is alive. Similarly, site administrators SHOULD NOT configure test users whose sole reason for existence is to enable such queries via Access- Request packets. Note that it still may be useful to configure test users for the purpose of performing end-to-end or in-depth testing of a servers - policy. While this practice is wide-spread, we caution - administrators to use it with care. + policy. While this practice is widespread, we caution administrators + to use it with care. 2.2. Overloading Accounting-Request A similar solution for the problem of querying server status may be for a NAS to send specially formed Accounting-Request packets to a - RADIUS servers authentication port. The NAS can then look for a + RADIUS servers accounting port. The NAS can then look for a response, and use this information to determine if the server is active or unresponsive. As seen above with Access-Request, the server may then conclude that a real user has logged onto a NAS, and perform local site actions that are undesirable for a simple status query. Another consideration is that some attributes are mandatory to include in an Accounting-Request. This requirement forces the administrator to query an accounting server with fake values for @@ -250,108 +249,82 @@ 2.2.1. Recommendation against Accounting-Request For the reasons outlined above, NAS implementors SHOULD NOT generate Accounting-Request packets solely to see if a server is alive. Similarly, site administrators SHOULD NOT configure accounting policies whose sole reason for existence is to enable such queries via Accounting-Request packets. Note that it still may be useful to configure test users for the purpose of performing end-to-end or in-depth testing of a servers - policy. While this practice is wide-spread, we caution - administrators to use it with care. + policy. While this practice is widespread, we caution administrators + to use it with care. 2.3. Status-Server as a Solution A better solution to the above problems is to use the Status-Server packet code. The name of the code leads us to conclude that it was intended for packets that query the status of a server. Since the packet is otherwise undefined, it does not cause interoperability issues to create implementation-specific definitions for it. The - difficulty until now has been defining an inter-operable method of + difficulty until now has been defining an interoperable method of performing these queries. This document addresses that need. 2.3.1. Status-Server to the RADIUS Authentication port Status-Server SHOULD be used instead of Access-Request to query the - responsiveness of a server. In this use-case, the protocol exchange + responsiveness of a server. In this use case, the protocol exchange between client and server is similar to the usual exchange of Access- Request and Access-Accept, as shown below. NAS RADIUS server --- ------------- Status-Server/ Message-Authenticator -> <- Access-Accept/ Reply-Message The Status-Server packet MUST contain a Message-Authenticator attribute for security. The response (if any) to a Status-Server - packet sent to an authentication port MUST be an Access-Accept - packet. The list of attributes that are permitted in the Access- - Accept packet is given in the Table of Attributes in Section 6, - below. + packet sent to an authentication port SHOULD be an Access-Accept + packet. Other response packet codes are NOT RECOMMENDED. The list + of attributes that are permitted in the Access-Accept packet is given + in the Table of Attributes in Section 6, below. -2.3.2. +2.3.2. Status-Server to the RADIUS Accounting port - Status-Server may be used instead of Accounting-Request to query the - responsiveness of a server. In this use-case, the protocol exchange + Status-Server MAY be used instead of Accounting-Request to query the + responsiveness of a server. In this use case, the protocol exchange between client and server is similar to the usual exchange of Accounting-Request and Accounting-Response, as shown below. NAS RADIUS server --- ------------- Status-Server/ Message-Authenticator -> <- Accounting-Response The Status-Server packet MUST contain a Message-Authenticator attribute for security. The response (if any) to a Status-Server - packet sent to an accounting port MUST be an Accounting-Response - packet. The list of attributes that are permitted in the Accounting- - Response packet is given in the Table of Attributes in Section 6, - below. - -2.3.3. Status-Server to the RADIUS Change-of-Authorization port - - Status-Server may be pro-actively sent by a server to a NAS when the - server first boots. This use mirrors the Accounting-Request use of - the Acct-Status-Type attribute with value "Accounting On". This - packet can serve as an indication to the NAS that the server is - available for authentication and accounting requests. - - In this use-case, the protocol exchange between client and server is - similar to the usual exchange of CoA-Request and CoA-ACK, as shown - below. - - RADIUS Server NAS - ------------- --- - Status-Server/ - Message-Authenticator -> - <- CoA-ACK - - The Status-Server packet MUST contain a Message-Authenticator - attribute for security. The response (if any) to a Status-Server - packet sent to a Change-of-Authorization port MUST be a CoA-ACK - packet. The list of attributes that are permitted in the CoA-ACK - packet is given in the Table of Attributes in Section 6, below. + packet sent to an accounting port SHOULD be an Accounting-Response + packet. Other response packet codes are NOT RECOMMENDED. The list + of attributes that are permitted in the Accounting-Response packet is + given in the Table of Attributes in Section 6, below. 3. Packet Format - Status-Server packets re-use the RADIUS packet format, with the - fields and values for those fields as defined [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. + Status-Server packets reuse the RADIUS packet format, with the fields + and values for those fields as defined [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, @@ -374,125 +347,122 @@ 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 for calculating the Response - Authenticator of the Access-Accept, with the Status-Server Request - Authenticator taking the place of the Access-Request Request - Authenticator. + 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 for calculating the Response Authenticator of - the Accounting-Response, with the Status-Server Request Authenticator - taking the place of the Accounting-Request Request Authenticator. + 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 - NOTE send more than one response packet. + 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, one of NAS-IP- - Address or NAS-IPv6-Address, and Reply-Message. These attributes are - not necessary for the operation of Status-Server, but may be useful - information to a server that receives those packets. + 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. User authentication credentials such as User-Password, CHAP-Password, EAP-Message, etc. 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, etc. 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 7. -3.1. Consistent definition for Status-Server +3.1. Single definition for Status-Server When sent to a RADIUS accounting port, contents of the Status-Server packets are calculated as described above. That is, even though the packets are being sent to an accounting port, they are not created using the same method as for Accounting-Requests. This difference has a number of benefits. - Having one definition for Status-Server packets is simpler than + Having a single definition for Status-Server packets is simpler than having different definitions for different destination ports. In addition, if we were to define Status-Server as being similar to - Accounting-Request or CoA-Request, but containing no attributes, then - those packets could be trivially forged. + Accounting-Request but containing no attributes, then those packets + could be trivially forged. We therefore define Status-Server consistently, and vary the response packets depending on the port to which the request is sent. When sent to an authentication port, the response to a Status-Server query is an Access-Accept packet. When sent to an accounting port, the response to a Status-Server query is an Accounting-Response packet. - When sent to a change of authorization (CoA) port, the response to a - Status-Server query is an CoA-ACK packet 4. Implementation notes There are a number of considerations to take into account when 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, accounting, and coa + 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, or - a Change-Of-Authorization packet sent to a CoA 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, or a CoA-ACK packet sent from a - CoA port. + 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, accounting, and - coa packets. + 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. @@ -527,49 +497,48 @@ 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, Accounting-Response, - or CoA-ACK 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. + 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 Identifer 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 has determined that the Status-Server - packet has timed out, it may re-use that Identifier in another - packet. + 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), Accounting-Response (5), or CoA-ACK (44). 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. + 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. 4.2. Server Requirements @@ -606,27 +575,27 @@ 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 who is interested in obtaining additional information about the server. - The server MAY prioritize the handling Status-Server queries over the - handling of other requests, subject to the rate limiting described - above. + 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 to not respond to a Status-Server, depending on local site policy. For example, a server that is running but is - unable to perform it's normal activities MAY silently discard Status- + 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 are accepted only on "authentication" ports, (e.g. 1812/udp), and that Accounting-Request packets are 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 @@ -637,115 +606,73 @@ Accounting-Request packets on the same port, and 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, 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. -4.3. Change of Authorization and Status-Server - - The use of Status-Server with respect to Change of Authorization - requires some additional discussion. - - When a Dynamic Authorization Client ([RFC5176] Section 1.3) reboots, - it SHOULD send a Status-Server packet to a CoA port to IP addresses - that are configured as both Dynamic Authorization Servers and RADIUS - clients. Jitter SHOULD be used to avoid synchronization issues. If - there is no response to a packet, the periodic timer above SHOULD be - used to continue sending packets to that destination until a response - has been received. When a response is received, the Dynamic - Authorization Client MUST NOT send further Status-Server packets to - the CoA port of any Dynamic Authorization until it next reboots. - - When a Dynamic Authorization Server receives a Status-Server packet - to it's CoA port, it SHOULD respond with a CoA-ACK packet, as - described above. It MAY use this information to modify it's - authentication and/or accounting behavior, as described below. - - If the Status-Server packet came to a NAS CoA port from an IP address - which is also configured as an authentication and/or accounting - server. the NAS MAY decide to mark the RADIUS server as being - responsive. If the RADIUS server had previously been marked as - unresponsive, this change would enable the NAS to start packets to - start sending packets to that RADIUS server again. The NAS MAY - otherwise decide to receive multiple packets to it's CoA port before - marking the RADIUS server as responsive. This behavior is - implementation-defined, and SHOULD be configurable. - - Where possible, the Dynamic Authorization Client (usually a RADIUS - server) SHOULD originate the Status-Server packet from the port to - which the NAS would normally send Request packets. For example, a - packet sent from from a RADIUS server with source port 1812 to a NAS - with destination port 3799, would indicate to the NAS that the RADIUS - authentication server at that address is alive. - -4.4. More Robust Fail-over with Status-Server +4.3. More Robust Fail-over with Status-Server A common problem in RADIUS client implementations is the implementation of a robust fail-over mechanism between servers. A client may have multiple servers configured, with one server marked as primary and another marked as secondary. If the client determines that the primary is unresponsive, it can "fail over" to the secondary, and send requests to the secondary instead of to the primary. However, it is difficult in standard RADIUS for a client to know when it should start sending requests to the primary again. Sending test Access-Requests or Accounting-Requests to see if the server is alive has the issues outlined above in Section 2. Clients could alternately send real traffic to the primary, on the hope that it is responsive. If the server is still unresponsive, however, the result may be user login failures. The Status-Server solution is an ideal - one to solve this problem. + way to solve this problem. When a client fails over from one server to another because of a lack of responsiveness, it SHOULD send periodic Status-Server packets to the unresponsive server, using the timer (Tw) defined above. - Once three time periods have passed where Status-Server messages have + Once three time periods have passed where Status-Server packets have been sent and responded to, the server should be deemed responsive and RADIUS requests may sent to it again. This determination should be made separately for each server that the client has a relationship with. The same algorithm should be used for both authentication and accounting ports. The client MUST treat each destination (ip, port) combination as a unique server for the purposes of this determination. - The practice of sending Status-Server packets to CoA ports (where - applicable) can increase the information available in the network, - and further help to stabilize the network, and to lower response - times in the event of network changes. - The above behavior is modelled after [RFC3539] Section 3.4.1. We note that if a reliable transport is used for RADIUS, then the algorithms specified in [RFC3539] MUST be used in preference to the ones given here. -4.5. Proxy Server handling of Status-Server +4.4. Proxy Server handling of Status-Server Many RADIUS servers can act as proxy servers, and can forward requests to home servers. Such servers MUST NOT proxy Status-Server packets. The purpose of Status-Server as specified here is to permit the client to query the responsiveness of a server that it has a direct relationship with. 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 MAY act as clients sending Status-Server queries to other servers. However, those activities MUST be independent of one another. -4.6. Realm Routing +4.5. Realm Routing RADIUS servers are commonly used in an environment where Network Access Identifiers (NAIs) are used as routing identifiers [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, the mechanism outlined above may be inadequate. The schematic below demonstrates this scenario. @@ -771,24 +698,24 @@ is reachable from Proxy Server S, as it can then route all requests for Realm A to that Proxy Server. Without this knowledge, the client may route requests to Proxy Server P, where they may be discarded or rejected. To complicate matters, the behavior of Proxy Servers 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 Proxy Server being down, or the next - server along along the proxy chain is unreachable. + server along the proxy chain being unreachable. In the worst case, failures in routing for Realm A may affect users - Realm B. For example, if Proxy Server P can reach Realm B but not + of Realm B. For example, if Proxy Server P can reach Realm B but not Realm A, and Proxy Server S can reach Realm A but not Realm B, then active paths exist to handle all RADIUS requests. However, depending on the NAS and Proxy Server implementation choices, the NAS may not be able to determine which server requests may be sent to in order to maintain network stability. This problem cannot, unfortunately 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 @@ -815,77 +742,77 @@ A more realistic situation than the one outlined above is where each Proxy Server also has multiple choices of Home Servers for a realm, as outlined below. /-> Proxy Server P -----> Home Server P / \ / NAS X \ / \ \-> Proxy Server S -----> Home Server S - In this situation, if all participants impement Status-Server as + 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 home 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 home server. In many situations where three or more links are broken, then requests from the NAS may still reach a home 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. -4.7. Management Information Base (MIB) Considerations +4.6. Management Information Base (MIB) Considerations -4.7.1. Interaction with RADIUS Server MIBs +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 MIBs. - [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 - 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. + they can affect the [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 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 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] - MIBs, then it SHOULD also support vendor-specific MIBs containing - similar information as the standard MIBs, but which are instead + 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 MIBs for Status-Server is outside of the - scope of this document. + Any definition of the server MIB modules for Status-Server is outside + of the scope of this document. -4.7.2. Interaction with RADIUS Client MIBs +4.6.2. Interaction with RADIUS Client MIB modules 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] MIBs, then it SHOULD also support vendor-specific MIBs - containing similar information as those MIBs, but which are instead - dedicated solely to tracking Status-Server requests and responses. - Any definition of the client MIBs for Status-Server is outside of the - scope of this document. + [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 @@ -896,28 +823,28 @@ 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 it's dependencies, is + server infrastructure, including all of its dependencies, is functioning as expected. These queries are most useful in - deployments where an administrator has internal RADIUS server that + 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 used for these test users SHOULD be difficult to - guess by an attacker. An Access-Request packet for a test user + 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. @@ -956,54 +883,58 @@ 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 re-use that Identifier in another 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, implementors are warned that - such uses have not been analyzed for potential security issues or - network problems. + 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. 6. Table of Attributes - The following table provide a guide to which attributes may be found - in Status-Server packets, and in what quantity. No attributes other - than the ones listed below should be found in a Status-Server packet. + 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- CoA- - Server Accept Response ACK # Attribute + Status- Access- Accounting- + Server Accept Response # Attribute - 0-1 0 0 0 4 NAS-IP-Address - 0 0+ 0 0 18 Reply-Message - 0+ 0+ 0+ 0 26 Vendor-Specific - 0+ 0+ 0 0 31 Calling-Station-Id - 0-1 0 0 0 32 NAS-Identifier - 1 0-1 0-1 0-1 80 Message-Authenticator - 0-1 0 0 0 95 NAS-IPv6-Address + 0-1 0 0 4 NAS-IP-Address [Note 1] + 0 0+ 0 18 Reply-Message + 0+ 0+ 0+ 26 Vendor-Specific + 0-1 0 0 32 NAS-Identifier [Note 1] + 1 0-1 0-1 80 Message-Authenticator + 0-1 0 0 95 NAS-IPv6-Address [Note 1] + + [Note 1] A Status-Server SHOULD contain one of (NAS-IP-Address or + 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 @@ -1023,25 +954,24 @@ 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 + 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 @@ -1063,21 +993,21 @@ da de 26 36 78 58 1 Code = Status-Server (12) 1 ID = 179 2 Length = 38 16 Request Authenticator Attributes: 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858 - The Response Authenticator is a 16-octet MD5 checksum of the code + The Response Authenticator is a 16 octet MD5 checksum of the code (5), id (179), Length (20), the Request Authenticator from above, and the shared secret. 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 @@ -1150,109 +1080,56 @@ use of Status-Server as defined herein. 10. References 10.1. Normative references [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. -[RFC2866] - Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. - -[RFC3579] - Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In User - Service) Support For Extensible Authentication Protocol (EAP)", RFC - 3579, September 2003. - [RFC4282] Aboba, B., and Beadles, M. at al, "The Network Access Identifier", RFC 4282, December 2005. 10.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 + User Service) Support For Extensible Authentication Protocol + (EAP)", RFC 3579, September 2003. + [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. -[RFC5176] Chiba, M., Eklund, M., et al, "Dynamic Authorization - Extensions to Remote Authentication Dial In User Service - (RADIUS)", RFC 5176, January 2008. - 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 inter- - operability testing. + Consultants for making a Radiator server available for + interoperability testing. Authors' Addresses Alan DeKok The FreeRADIUS Server Project http://freeradius.org Email: aland@freeradius.org - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society.