--- 1/draft-ietf-radext-status-server-08.txt 2010-05-18 18:12:59.000000000 +0200 +++ 2/draft-ietf-radext-status-server-09.txt 2010-05-18 18:12:59.000000000 +0200 @@ -1,22 +1,22 @@ Network Working Group Alan DeKok INTERNET-DRAFT FreeRADIUS Category: Informational Updates: 2866 - -Expires: November 4, 2010 -4 May 2010 + +Expires: November 18, 2010 +18 May 2010 Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol - draft-ietf-radext-status-server-08 + draft-ietf-radext-status-server-09 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. @@ -25,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 4, 2010. + This Internet-Draft will expire on November 18, 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 @@ -479,22 +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 use a watchdog timer such as defined in [RFC3539] - to determine when to send Status-Server packets. + The client SHOULD use a watchdog timer such as defined in 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 @@ -643,23 +643,24 @@ Status-Server packets to the original proxy, the RADIUS client can determine when it becomes responsive again. 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. - 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. + Clients SHOULD use a retransmission mechanism similar to that given + in 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. 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. @@ -1028,56 +1028,56 @@ 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. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. +[RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and + Accounting (AAA) Transport Profile", RFC 3539, June 2003. + [RFC4086] Eastlake, D., et al, "Randomness Requirements for Security", RFC 4086, June 2005. [RFC4282] Aboba, B., and Beadles, M. at al, "The Network Access Identifier", RFC 4282, December 2005. +[RFC5080] Nelson, D., DeKok, A, "Common Remote Authentication Dial In + User Service (RADIUS) Implementation Issues and Suggested + Fixes", RFC 5080, December 2007. + 9.2. Informative references [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, August 2006. -[RFC5080] Nelson, D., DeKok, A, "Common Remote Authentication Dial In - User Service (RADIUS) Implementation Issues and Suggested - Fixes", RFC 5080, December 2007. - Acknowledgments Parts of the text in Section 3 defining the Request and Response Authenticators were taken with minor edits from [RFC2865] Section 3. The author would like to thank Mike McCauley of Open Systems Consultants for making a Radiator server available for interoperability testing. Ignacio Goyret provided valuable feedback on the history and security