draft-ietf-radext-status-server-08.txt   draft-ietf-radext-status-server-09.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Informational Category: Informational
Updates: 2866 Updates: 2866
<draft-ietf-radext-status-server-08.txt> <draft-ietf-radext-status-server-09.txt>
Expires: November 4, 2010 Expires: November 18, 2010
4 May 2010 18 May 2010
Use of Status-Server Packets in the Use of Status-Server Packets in the
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
draft-ietf-radext-status-server-08 draft-ietf-radext-status-server-09
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 12, line 22 skipping to change at page 12, line 22
4.1. Client Requirements 4.1. Client Requirements
Clients SHOULD permit administrators to globally enable or disable Clients SHOULD permit administrators to globally enable or disable
the generation of Status-Server packets. The default SHOULD be that the generation of Status-Server packets. The default SHOULD be that
it is disabled. As it is undesirable to send queries to servers 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 do not support Status-Server, clients SHOULD also have a per-server
configuration indicating whether or not to enable Status-Server for a configuration indicating whether or not to enable Status-Server for a
particular destination. The default SHOULD be that it is disabled. particular destination. The default SHOULD be that it is disabled.
The client SHOULD use a watchdog timer such as defined in [RFC3539] The client SHOULD use a watchdog timer such as defined in Section
to determine when to send Status-Server packets. 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 When Status-Server packets are sent from a client, they MUST NOT be
retransmitted. Instead, the Identity field MUST be changed every retransmitted. Instead, the Identity field MUST be changed every
time a packet is transmitted. The old packet should be discarded, time a packet is transmitted. The old packet should be discarded,
and a new Status-Server packet should be generated and sent, with new and a new Status-Server packet should be generated and sent, with new
Identity and Authenticator fields. Identity and Authenticator fields.
Clients MUST include the Message-Authenticator attribute in all Clients MUST include the Message-Authenticator attribute in all
Status-Server packets. Failure to do so would mean that the packets Status-Server packets. Failure to do so would mean that the packets
could be trivially spoofed, leading to potential denial of service could be trivially spoofed, leading to potential denial of service
skipping to change at page 15, line 41 skipping to change at page 15, line 41
Status-Server packets to the original proxy, the RADIUS client can Status-Server packets to the original proxy, the RADIUS client can
determine when it becomes responsive again. determine when it becomes responsive again.
Once the server has been deemed responsive, normal RADIUS requests Once the server has been deemed responsive, normal RADIUS requests
may sent to it again. This determination should be made separately may sent to it again. This determination should be made separately
for each server that the client has a relationship with. The same for each server that the client has a relationship with. The same
algorithm SHOULD be used for both authentication and accounting algorithm SHOULD be used for both authentication and accounting
ports. The client MUST treat each destination (IP, port) combination ports. The client MUST treat each destination (IP, port) combination
as a unique server for the purposes of this determination. as a unique server for the purposes of this determination.
Clients SHOULD use a watchdog timer mechanism similar to that given Clients SHOULD use a retransmission mechanism similar to that given
in [RFC3539] Section 3.4.1. If a reliable transport is used for in Section 2.2.1 of [RFC5080]. If a reliable transport is used for
RADIUS, then the algorithms specified in [RFC3539] MUST be used. RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST
be used.
4.4. 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 Many RADIUS servers can act as proxy servers, and can forward
requests to another RADIUS server. Such servers MUST NOT proxy requests to another RADIUS server. Such servers MUST NOT proxy
Status-Server packets. The purpose of Status-Server as specified Status-Server packets. The purpose of Status-Server as specified
here is to permit the client to query the responsiveness of a server here is to permit the client to query the responsiveness of a server
that it has a direct relationship with. Proxying Status-Server that it has a direct relationship with. Proxying Status-Server
queries would negate any usefulness that may be gained by queries would negate any usefulness that may be gained by
implementing support for them. implementing support for them.
skipping to change at page 23, line 46 skipping to change at page 23, line 46
Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April, Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, April,
1992 1992
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 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", [RFC4086] Eastlake, D., et al, "Randomness Requirements for Security",
RFC 4086, June 2005. RFC 4086, June 2005.
[RFC4282] Aboba, B., and Beadles, M. at al, "The Network Access [RFC4282] Aboba, B., and Beadles, M. at al, "The Network Access
Identifier", RFC 4282, December 2005. 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 9.2. Informative references
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [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 [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003. (EAP)", RFC 3579, September 2003.
[RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes [RFC4270] Hoffman, P, and Schneier, B, "Attacks on Cryptographic Hashes
in Internet Protocols", RFC 4270, November 2005. in Internet Protocols", RFC 4270, November 2005.
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC
4668, August 2006. 4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC
4669, August 2006. 4669, August 2006.
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670,
August 2006. August 2006.
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671,
August 2006. 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 Acknowledgments
Parts of the text in Section 3 defining the Request and Response Parts of the text in Section 3 defining the Request and Response
Authenticators were taken with minor edits from [RFC2865] Section 3. Authenticators were taken with minor edits from [RFC2865] Section 3.
The author would like to thank Mike McCauley of Open Systems The author would like to thank Mike McCauley of Open Systems
Consultants for making a Radiator server available for Consultants for making a Radiator server available for
interoperability testing. interoperability testing.
Ignacio Goyret provided valuable feedback on the history and security Ignacio Goyret provided valuable feedback on the history and security
 End of changes. 9 change blocks. 
17 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/