--- 1/draft-ietf-radext-status-server-07.txt 2010-05-04 14:12:14.000000000 +0200 +++ 2/draft-ietf-radext-status-server-08.txt 2010-05-04 14:12:14.000000000 +0200 @@ -1,21 +1,22 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Informational - -Expires: November 27, 2010 -26 April 2010 +Updates: 2866 + +Expires: November 4, 2010 +4 May 2010 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol - draft-ietf-radext-status-server-07 + draft-ietf-radext-status-server-08 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -24,21 +25,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 27, 2010. + This Internet-Draft will expire on November 4, 2010. 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 @@ -78,29 +79,29 @@ 2.1. Why Access-Request is inappropriate ................. 7 2.1.1. Recommendation against Access-Request .......... 8 2.2. Why Accounting-Request is inappropriate ............. 8 2.2.1. Recommendation against Accounting-Request ...... 8 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. Fail-over with Status-Server ........................ 15 - 4.4. Proxy Server handling of Status-Server .............. 16 + 4.4. Proxy Server handling of Status-Server .............. 15 4.5. Limitations of Status-Server ........................ 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 + 4.6.2. Interaction with RADIUS Client MIB modules ..... 18 5. Table of Attributes ...................................... 19 -6. Examples ................................................. 20 +6. Examples ................................................. 19 6.1. Minimal Query to Authentication Port ................ 20 - 6.2. Minimal Query to Accounting Port .................... 21 + 6.2. Minimal Query to Accounting Port .................... 20 6.3. Verbose Query and Response .......................... 21 7. IANA Considerations ...................................... 22 8. Security Considerations .................................. 22 9. References ............................................... 23 9.1. Normative references ................................ 23 9.2. Informative references .............................. 24 1. Introduction This document specifies a deployed extension to the Remote @@ -175,43 +176,43 @@ In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Overview Status-Server packets are sent by a RADIUS client to a RADIUS server - in order to test the status of that server. A Message-Authenticator - attribute MUST be included so as to provide per-packet authentication - and integrity protection. A single Status-Server packet MUST be - included within a UDP datagram. RADIUS proxies MUST NOT forward - Status-Server packets. + in order to test the status of that server. The destination of a + Status-Server packet is set to the IP address and port of the server + that is being tested. A single Status-Server packet MUST be included + within a UDP datagram. A Message-Authenticator attribute MUST be + included so as to provide per-packet authentication and integrity + protection. - Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy - or server, the destination of a Status-Server packet is set to the IP - address of the server which is being tested. As a result, 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. Since 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. + RADIUS proxies or servers MUST NOT forward Status-Server packets. A + RADIUS server or proxy implementing this specification SHOULD respond + to a Status-Server packet with an Access-Accept (authentication port) + or Accounting-Response (accounting port). An Access-Challenge + response is NOT RECOMMENDED. An Access-Reject response MAY be used. + The list of attributes that are permitted in Status-Server and + Access-Accept packets responding to Status-Server packets are + provided in the Section 6. - A RADIUS server or proxy implementing this specification SHOULD - respond to a Status-Server packet with an Access-Accept - (authentication port) or Accounting-Message (accounting port). An - Access-Challenge response is NOT RECOMMENDED. An Access-Reject - response MAY be used. The list of attributes that are permitted in - Status-Server and Access-Accept packets responding to Status-Server - packets are provided in the Section 6. + 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, lack of a response may only be due to packet loss or the failure of the server in the destination IP address, not due to faults in downstream links, proxies or servers. It therefore provides an unambiguous indication of the status of a server. @@ -478,30 +479,22 @@ 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. - The client SHOULD also have a configurable global timer (Tw) that is - used when sending periodic Status-Server queries during server fail- - over. The default value SHOULD be 30 seconds, and the value MUST NOT - be permitted to be set below 6 seconds. If a response has not been - received within the timeout period, the Status-Server packet is - deemed to have received no corresponding Response packet, and MUST be - discarded. - - Clients SHOULD use a jitter of +/- 2 seconds when sending periodic - Status-Server packets, in order to avoid synchronization. + The client SHOULD use a watchdog timer such as defined in [RFC3539] + 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 @@ -632,46 +625,41 @@ perform any other action that is normally performed when it receives a Request packet, other than sending a Response packet. 4.3. Fail-over with Status-Server A client may wish to failover from one proxy to another in the event that it does not receive a response to an Access-Request or Accounting-Request. In order to determine whether the lack of response is due to a problem with the proxy or a downstream server, the client can send periodic Status-Server packets to a proxy after - lack of a response. The inter-packet period is Tw, as described in - Section 4.1. + lack of a response. These packets will help the client determine if the failure was due to an issue on the path between the client and proxy or the proxy itself, or whether the issue is occurring downstream. If no response is received to Status-Server packets, the RADIUS client can initiate failover to another proxy. By continuing to send - Status-Server packets to the original proxy at an interval of Tw, the - RADIUS client can determine when the original proxy becomes - responsive again. + Status-Server packets to the original proxy, the RADIUS client can + determine when it becomes responsive again. - 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. + Once the server has been deemed responsive, normal 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 above behavior is modeled 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. + Clients SHOULD use a watchdog timer mechanism similar to that given + in [RFC3539] Section 3.4.1. If a reliable transport is used for + RADIUS, then the algorithms specified in [RFC3539] MUST be used. 4.4. Proxy Server handling of Status-Server Many RADIUS servers can act as proxy servers, and can forward requests to another RADIUS server. 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. @@ -1019,20 +1007,26 @@ vulnerable to the attacks outlined above. For this reason, implementations of this specification which 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. + 9. References 9.1. Normative references [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", RFC 2119, March, 1997. @@ -1051,20 +1045,23 @@ [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. +[RFC4270] Hoffman, P, and Schneier, B, "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,