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/