draft-ietf-radext-dtls-02.txt		draft-ietf-radext-dtls-03.txt
	Network Working Group Alan DeKok		Network Working Group Alan DeKok
	INTERNET-DRAFT FreeRADIUS		INTERNET-DRAFT FreeRADIUS
	Category: Informational		Category: Experimental
	<draft-ietf-radext-dtls-02.txt>		<draft-ietf-radext-dtls-03.txt>
	Expires: May 16, 2013		Expires: July 28, 2013
	16 July 2012		28 January 2013
	DTLS as a Transport Layer for RADIUS		DTLS as a Transport Layer for RADIUS
	draft-ietf-radext-dtls-02		draft-ietf-radext-dtls-03
	Abstract		Abstract
	The RADIUS protocol [RFC2865] has limited support for authentication		The RADIUS protocol [RFC2865] has limited support for authentication
	and encryption of RADIUS packets. The protocol transports data "in		and encryption of RADIUS packets. The protocol transports data "in
	the clear", although some parts of the packets can have "obfuscated"		the clear", although some parts of the packets can have "obfuscated"
	content. Packets may be replayed verbatim by an attacker, and		content. Packets may be replayed verbatim by an attacker, and
	client-server authentication is based on fixed shared secrets. This		client-server authentication is based on fixed shared secrets. This
	document specifies how the Datagram Transport Layer Security (DTLS)		document specifies how the Datagram Transport Layer Security (DTLS)
	protocol may be used as a fix for these problems. It also describes		protocol may be used as a fix for these problems. It also describes
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	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 May 16, 2013		This Internet-Draft will expire on July 28, 2013
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 15		skipping to change at page 3, line 15
	Table of Contents		Table of Contents
	1. Introduction ............................................. 4		1. Introduction ............................................. 4
	1.1. Terminology ......................................... 4		1.1. Terminology ......................................... 4
	1.2. Requirements Language ............................... 5		1.2. Requirements Language ............................... 5
	2. Building on Existing Foundations ......................... 6		2. Building on Existing Foundations ......................... 6
	2.1. Changes to RADIUS ................................... 6		2.1. Changes to RADIUS ................................... 6
	2.2. Similarities with RADIUS/TLS ........................ 7		2.2. Similarities with RADIUS/TLS ........................ 7
	2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7		2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS ......... 7
	2.2.2. Reinforcement of RADIUS/TLS .................... 8		2.2.2. Reinforcement of RADIUS/TLS .................... 8
	3. Reception of Packets ..................................... 8		3. Transition Path .......................................... 8
	4. Connection Management .................................... 9		3.1. Server Transition to DTLS ........................... 8
	4.1. Server Connection Management ........................ 9		4. Client Transition ........................................ 9
	4.1.1. Table Management ............................... 10		5. Connection Management .................................... 10
	4.1.2. Protocol Disambiguation ........................ 11		5.1. Server Connection Management ........................ 10
	4.1.3. Processing Algorithm ........................... 12		5.1.1. Session Management ............................. 11
	4.2. Client Connection Management ........................ 13		5.1.2. Protocol Disambiguation ........................ 12
	5. Diameter Considerations .................................. 14		5.1.3. Processing Algorithm ........................... 13
	6. IANA Considerations ...................................... 14		5.2. Client Connection Management ........................ 15
	7. Security Considerations .................................. 14		6. Implementation Guidelines ................................ 16
	7.1. Legacy RADIUS Security .............................. 14		6.1. Client Implementations .............................. 16
	7.2. Resource Exhaustion ................................. 15		6.2. Server Implementations .............................. 17
	7.3. Network Address Translation ......................... 16		7. Implementation Experience ................................ 17
	7.4. Wildcard Clients .................................... 16		8. Diameter Considerations .................................. 17
	8. References ............................................... 16		9. IANA Considerations ...................................... 18
	8.1. Normative references ................................ 16		10. Security Considerations ................................. 18
	8.2. Informative references .............................. 17		10.1. Legacy RADIUS Security ............................. 18
			10.2. Resource Exhaustion ................................ 19
			10.3. Network Address Translation ........................ 19
			10.4. Wildcard Clients ................................... 20
			10.5. Session Closing .................................... 20
			10.6. Clients Subsystems ................................. 21
			11. References .............................................. 21
			11.1. Normative references ............................... 21
			11.2. Informative references ............................. 22
	1. Introduction		1. Introduction
	The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176],		The RADIUS protocol as described in [RFC2865], [RFC2866], [RFC5176],
	and others has traditionally used methods based on MD5 [RFC1321] for		and others has traditionally used methods based on MD5 [RFC1321] for
	per-packet authentication and integrity checks. However, the MD5		per-packet authentication and integrity checks. However, the MD5
	algorithm has known weaknesses such as [MD5Attack] and [MD5Break].		algorithm has known weaknesses such as [MD5Attack] and [MD5Break].
	As a result, some specifications such as [RFC5176] have recommended		As a result, some specifications such as [RFC5176] have recommended
	using IPSec to secure RADIUS traffic.		using IPSec to secure RADIUS traffic.
	skipping to change at page 4, line 28		skipping to change at page 4, line 28
	requirement that the RADIUS traffic be encrypted and/or authenticated		requirement that the RADIUS traffic be encrypted and/or authenticated
	is implicit in the network configuration, and is not enforced by the		is implicit in the network configuration, and is not enforced by the
	RADIUS application.		RADIUS application.
	This specification takes a different approach. We define a method		This specification takes a different approach. We define a method
	for using DTLS [RFC6347] as a RADIUS transport protocol. This		for using DTLS [RFC6347] as a RADIUS transport protocol. This
	approach has the benefit that the RADIUS application can directly		approach has the benefit that the RADIUS application can directly
	monitor and control the security policies associated with the traffic		monitor and control the security policies associated with the traffic
	that it processes.		that it processes.
	Another benefit is that RADIUS over DTLS continues to be a UDP-based		Another benefit is that RADIUS over DTLS continues to be a User
	protocol. This continuity ensures that existing network-layer		Datagram Protocol (UDP) based protocol. This continuity ensures that
	infrastructure (firewall rules, etc.) does not need to be changed		existing network-layer infrastructure (firewall rules, etc.) does not
	when RADIUS clients and servers are upgraded to support RADIUS over		need to be changed when RADIUS clients and servers are upgraded to
	DTLS.		support RADIUS over DTLS.
	This specification does not, however, solve all of the problems		This specification does not, however, solve all of the problems
	associated with RADIUS. The DTLS protocol does not add reliable or		associated with RADIUS. The DTLS protocol does not add reliable or
	in-order transport to RADIUS. DTLS also does not support		in-order transport to RADIUS. DTLS also does not support
	fragmentation of application-layer messages, or of the DTLS messages		fragmentation of application-layer messages, or of the DTLS messages
	themselves. This specification therefore shares with traditional		themselves. This specification therefore shares with traditional
	RADIUS the issues of order, reliability, and fragmentation.		RADIUS the issues of order, reliability, and fragmentation.
	1.1. Terminology		1.1. Terminology
	skipping to change at page 5, line 18		skipping to change at page 5, line 18
	implement RADIUS/DTLS.		implement RADIUS/DTLS.
	RADIUS/UDP		RADIUS/UDP
	RADIUS over UDP, as defined in [RFC2865].		RADIUS over UDP, as defined in [RFC2865].
	RADIUS/TLS		RADIUS/TLS
	RADIUS over TLS, as defined in [RFC6614].		RADIUS over TLS, as defined in [RFC6614].
	silently discard		silently discard
	This means that the implementation discards the packet without		This means that the implementation discards the packet without
	further processing. See Section X.Y for additional requirements on		further processing.
	packets being silently discarded.
	1.2. Requirements Language		1.2. Requirements Language
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. The key words "MUST", "MUST NOT", "REQUIRED",		of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" in this document are to be interpreted as described in		and "OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	2. Building on Existing Foundations		2. Building on Existing Foundations
	skipping to change at page 6, line 33		skipping to change at page 6, line 33
	* Maximum packet length		* Maximum packet length
	* Attribute format		* Attribute format
	* Vendor-Specific Attribute (VSA) format		* Vendor-Specific Attribute (VSA) format
	* Permitted data types		* Permitted data types
	* Calculations of dynamic attributes such as CHAP-Challenge,		* Calculations of dynamic attributes such as CHAP-Challenge,
	or Message-Authenticator.		or Message-Authenticator.
	* Calculation of "obfuscated" attributes such as User-Password		* Calculation of "obfuscated" attributes such as User-Password
	and Tunnel-Password.		and Tunnel-Password.
	* UDP port numbering and relationship between code and port		* UDP port numbering and relationship between code and port
	In short, the application creates a RADIUS packet as usual, and then		In short, the application creates a RADIUS packet via the usual
	instead of sending it over a UDP socket, sends the packet to a DTLS		methods, and then instead of sending it over a UDP socket, sends the
	layer for encapsulation. DTLS then acts as a transport layer for		packet to a DTLS layer for encapsulation. DTLS then acts as a
	RADIUS, hence the names "RADIUS/UDP" and "RADIUS/DTLS".		transport layer for RADIUS, hence the names "RADIUS/UDP" and
			"RADIUS/DTLS".
	The requirement that RADIUS remain largely unchanged ensures the		The requirement that RADIUS remain largely unchanged ensures the
	simplest possible implementation and widest interoperability of this		simplest possible implementation and widest interoperability of this
	specification.		specification.
	We note that the DTLS encapsulation of RADIUS means that the minimum		We note that the DTLS encapsulation of RADIUS means that the minimum
	and maximum UDP packet sizes increase by the DTLS overhead.		and maximum UDP packet sizes increase by the DTLS overhead.
	Implementations should be aware of this, and take it into account		Implementations should be aware of this, and take it into account
	when allocating buffers to read and write RADIUS/DTLS packets.		when allocating buffers to read and write RADIUS/DTLS packets.
	skipping to change at page 7, line 13		skipping to change at page 7, line 14
	length.		length.
	(2) The shared secret secret used to compute the MD5 integrity		(2) The shared secret secret used to compute the MD5 integrity
	checks and the attribute encryption MUST be "radius/dtls".		checks and the attribute encryption MUST be "radius/dtls".
	All other aspects of RADIUS are unchanged.		All other aspects of RADIUS are unchanged.
	2.2. Similarities with RADIUS/TLS		2.2. Similarities with RADIUS/TLS
	While this specification can be thought of as RADIUS/TLS over UDP		While this specification can be thought of as RADIUS/TLS over UDP
	instead of TCP, there are some differences between the two methods.		instead of the Transmission Control Protocol (TCP), there are some
	The bulk of [RFC6614] applies to this specification, so we do not		differences between the two methods. The bulk of [RFC6614] applies
	repeat it here.		to this specification, so we do not repeat it here.
	This section explains the differences between RADIUS/TLS and		This section explains the differences between RADIUS/TLS and
	RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as		RADIUS/DTLS, as semantic "patches" to [RFC6614]. The changes are as
	follows:		follows:
	* We replace references to "TCP" with "UDP"		* We replace references to "TCP" with "UDP"
	* We replace references to "RADIUS/TLS" with "RADIUS/DTLS"		* We replace references to "RADIUS/TLS" with "RADIUS/DTLS"
	* We replace references to "TLS" with "DTLS"		* We replace references to "TLS" with "DTLS"
	Those changes are sufficient to cover the majority of the differences		Those changes are sufficient to cover the majority of the differences
	between the two specifications. The next section reviews some more		between the two specifications. The next section reviews some more
	detailed changes from [RFC6614], giving additional commentary only		detailed changes from [RFC6614], giving additional commentary only
	where necessary.		where necessary.
	2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS		2.2.1. Changes from RADIUS/TLS to RADIUS/DTLS
			This section describes where this specification is similar to
			[RFC6614], and where it differs.
	Section 2.1 does not apply to RADIUS/DTLS. The relationship between		Section 2.1 does not apply to RADIUS/DTLS. The relationship between
	RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from		RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from
	RADIUS/UDP.		RADIUS/UDP.
	Section 2.2 applies also to RADIUS/DTLS, except for the		Section 2.2 applies to RADIUS/DTLS. Servers and clients need to be
			preconfigured to use RADIUS/DTLS for a given endpoint.
			Most of Section 2.3 applies also to RADIUS/DTLS. Item (1) should be
			interpreted as applying to DTLS session initiation, instead of TCP
			connection establishment. Item (2) applies, except for the
	recommendation that implementations "SHOULD" support		recommendation that implementations "SHOULD" support
	TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical		TLS_RSA_WITH_RC4_128_SHA. This recommendation is a historical
	artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS.		artifact of RADIUS/TLS, and does not apply to RADIUS/DTLS. Item (3)
			applies to RADIUS/DTLS. Item (4) applies, except that the fixed
			shared secret is "radius/dtls", as described above.
	Section 2.3 does not apply to RADIUS/DTLS.		Section 2.4 does not apply to RADIUS/DTLS.
	Section 2.4 does not apply to RADIUS/DTLS. The relationship between		Section 2.5 does not apply to RADIUS/DTLS. The relationship between
	RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from		RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged from
	RADIUS/UDP.		RADIUS/UDP.
	Section 3.3 item (1) does not apply to RADIUS/DTLS. Each RADIUS		Sections 3.1, 3.2, and 3.3 apply to RADIUS/DTLS.
			Section 3.4 item (1) does not apply to RADIUS/DTLS. Each RADIUS
	packet is encapsulated in one DTLS packet, and there is no "stream"		packet is encapsulated in one DTLS packet, and there is no "stream"
	of RADIUS packets inside of a TLS session. Implementors MUST enforce		of RADIUS packets inside of a TLS session. Implementors MUST enforce
	the requirements of [RFC2865] Section 3 for the RADIUS Length field,		the requirements of [RFC2865] Section 3 for the RADIUS Length field,
	using the length of the decrypted DTLS data for the checks. This		using the length of the decrypted DTLS data for the checks. This
	check replaces the RADIUS method of using the length field from the		check replaces the RADIUS method of using the length field from the
	UDP packet.		UDP packet.
	Section 3.3 item (3) does not apply to RADIUS/TDLS. The relationship		Section 3.4 item (3) does not apply to RADIUS/DTLS. The relationship
	between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged		between RADIUS packet codes and UDP ports in RADIUS/DTLS is unchanged
	from RADIUS.		from RADIUS.
	Section 3.3 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS		Section 3.4 item (4) does not apply to RADIUS/DTLS. As RADIUS/DTLS
	still uses UDP for a transport, the use of negative ICMP responses is		still uses UDP for a transport, the use of negative ICMP responses is
	unchanged from RADIUS.		unchanged from RADIUS.
			Section 4 does not apply to RADIUS/DTLS. Protocol compatibility
			considerations are defined in this document.
	2.2.2. Reinforcement of RADIUS/TLS		2.2.2. Reinforcement of RADIUS/TLS
	We re-iterate that much of [RFC6614] applies to this document.		We re-iterate that much of [RFC6614] applies to this document.
	Specifically, Section 4 and Section 6 of that document are applicable		Specifically, Section 4 and Section 6 of that document are applicable
	in their entirety to RADIUS/DTLS.		in their entirety to RADIUS/DTLS.
	3. Reception of Packets		3. Transition Path
	As this specification permits implementations to to accept both		Transitioning to DTLS is a process which needs to be done carefully.
			A poorly handled transition is complex for administrators, and
			potentially subject to security downgrade attacks. This section
			describes how clients and servers should transition to DTLS.
			3.1. Server Transition to DTLS
			As this specification permits server implementations to accept both
	RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a		RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a
	method to disambiguate packets between the two protocols. This		method to disambiguate packets between the two protocols. This
	method is applicable only to RADIUS/DTLS servers. RADIUS/DTLS		method is applicable only to RADIUS/DTLS servers.
	clients SHOULD use connected sockets, as discussed in Section X.Y,
	below.
	RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for		RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for
	each client that indicates if it requires a client to use		each client that indicates if it requires a client to use
	RADIUS/DTLS. The interpretation of this flag is as follows. If the		RADIUS/DTLS. The interpretation of this flag is as follows. If the
	flag is "true" then the client supports RADIUS/DTLS, and all packets		flag is "true" then the client supports RADIUS/DTLS, and all packets
	from that client MUST be processed as RADIUS/DTLS. If the flag is		from that client MUST be processed as RADIUS/DTLS. If the flag is
	"false", then the client supports RADIUS/UDP, but may still support		"false", then the client supports RADIUS/UDP, but may still support
	RADIUS/DTLS. Packets from the client need to be examined to see if		RADIUS/DTLS. Packets from the client need to be examined to see if
	they are RADIUS/UDP or RADIUS/DTLS.		they are RADIUS/UDP or RADIUS/DTLS.
	The "DTLS Required" flag MUST be exposed to administrators of the		The "DTLS Required" flag MUST be exposed to administrators of the
	server. As clients are upgraded, administrators can then manually		server. As clients are upgraded, administrators can then manually
	mark them as using RADIUS/DTLS.		mark them as using RADIUS/DTLS. The default value for the flag
			SHOULD be "false".
			It is RECOMMENDED that the default value for the "DTLS Required" flag
			be set to "true" when this specification has acheived wide-spread
			adoption.
	Once a RADIUS/DTLS server has established a DTLS session with a		Once a RADIUS/DTLS server has established a DTLS session with a
	client that previously had the flag set to "false", the server MUST		client that previously had the flag set to "false", the server MUST
	set the "DTLS Required" flag to "true". This change requires all		set the "DTLS Required" flag to "true". This change requires all
	subsequent traffic from that client to use DTLS, and prevents		subsequent traffic from that client to use DTLS, and prevents
	bidding-down attacks. The server SHOULD also notify the		bidding-down attacks. The server SHOULD also notify the
	administrator that it has successfully established the first DTLS		administrator that it has successfully established the first DTLS
	session with that client.		session with that client.
	Note that this last requirement on servers can impose significant		Note that this last requirement on servers can impose significant
	changes for clients. Clients can no longer have multiple independent		changes for clients. These changes are discussed in the next
	RADIUS implementations or processes that originate RADIUS/UDP and		section.
	RADIUS/DTLS packets. Instead, they need to use only one transport
	layer, either UDP or DTLS.
	It is therefore RECOMMENDED that RADIUS/DTLS clients use a local		4. Client Transition
	proxy which arbitrates all traffic between the client and any
	servers. The proxy SHOULD accept traffic only from the authorized
	subsystems on the client machine, and SHOULD proxy that traffic to
	one or more known servers.
	4. Connection Management		As this specification permits client implementations to to send both
			RADIUS/UDP and RADIUS/DTLS packets from the same address, we require
			guidelines for when to use one or the other. This method is
			applicable only to RADIUS/DTLS clients.
			RADIUS/DTLS clients MUST maintain a boolean "DTLS Required" flag for
			each server that indicates if that server requires it to use
			RADIUS/DTLS. The interpretation of this flag is as follows. If the
			flag is "true" then the server supports RADIUS/DTLS, and all packets
			sent to that server MUST be RADIUS/DTLS. If the flag is "false",
			then the server supports RADIUS/UDP, but may still support
			RADIUS/DTLS. Packets sent to that server MUST be RADIUS/UDP.
			The "DTLS Required" flag MUST be exposed to administrators of the
			client. As servers are upgraded, administrators can then manually
			mark them as using RADIUS/DTLS. The default value for the flag
			SHOULD be "false".
			It is RECOMMENDED that the default value for the "DTLS Required" flag
			be set to "true" when this specification has acheived wide-spread
			adoption.
			RADIUS/DTLS clients SHOULD NOT probe servers to see if they support
			DTLS transport. Doing so would cause servers to immediately require
			that all new packets from the client use DTLS. This requirement may
			be difficult for a client to satisfy. Instead, clients SHOULD use
			DTLS as a transport layer only when administratively configured.
			The requirements of this specification mean that RADIUS/DTLS clients
			can no longer have multiple independent RADIUS implementations, or
			processes that originate RADIUS/UDP and RADIUS/DTLS packets.
			Instead, clients MUST use only one transport layer to communicate
			with a specific server. It is RECOMMENDED that clients use a local
			proxy as described in Section 6.1, above.
			5. Connection Management
	Where [RFC6614] can rely on the TCP state machine to perform		Where [RFC6614] can rely on the TCP state machine to perform
	connection tracking, this specification cannot. As a result,		connection tracking, this specification cannot. As a result,
	implementations of this specification will need to perform connection		implementations of this specification may need to perform connection
	management of the DTLS session in the application layer.		management of the DTLS session in the application layer. This
			section describes logically how this tracking is done.
			Implementations may choose to use the method described here, or
			another, equivalent method.
	4.1. Server Connection Management		5.1. Server Connection Management
	A RADIUS/DTLS server MUST maintain a table that tracks ongoing client		A RADIUS/DTLS server MUST track ongoing client connections based on a
	connections based on a key composed of the following 4-tuple:		key composed of the following 4-tuple:
	* source IP address		* source IP address
	* source port		* source port
	* destination IP address		* destination IP address
	* destination port		* destination port
	Note that this table is independent of IP address version (IPv4 or		Note that this key is independent of IP address version (IPv4 or
	IPv6).		IPv6).
	Each table entry contains the following information:		Each entry associated with a key contains the following information:
	Protocol Type		Protocol Type
	A flag which is either "RADIUS/UDP" for old-style RADIUS traffic,		A flag which is either "RADIUS/UDP" for old-style RADIUS traffic,
	or "RADIUS/DTLS" for RADIUS/DTLS connections.		or "RADIUS/DTLS" for RADIUS/DTLS connections.
	DTLS Data		DTLS Data
	An implementation-specific variable containing information about		An implementation-specific variable containing information about
	the active DTLS connection. For non-DTLS connections, this		the active DTLS connection. For non-DTLS connections, this
	variable MUST be empty.		variable MUST be empty.
	Last Packet		Last Packet
	A variable containing a timestamp which indicates when the last		A variable containing a timestamp which indicates when the last
	valid packet was received for this connection. Packets which are		valid packet was received for this connection. Packets which are
	"silently discarded" MUST NOT update this variable.		"silently discarded" MUST NOT update this variable.
	Each entry may contain other information, such as idle timeouts,		Each entry may contain other information, such as idle timeouts,
	connection lifetimes, and other implementation-specific data.		connection lifetimes, and other implementation-specific data.
	RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS		5.1.1. Session Management
	packets from a client. This recommendation is because a connected
	UDP socket will accept packets only from one source IP address and
	port. This limitation would prevent the server from accepting
	packets from multiple clients on the same port.
	4.1.1. Table Management
	This tracking table is subject to Denial of Service (DoS) attacks due		Session tracking is subject to Denial of Service (DoS) attacks due to
	to the ability of an attacker to forge UDP traffic. RADIUS/DTLS		the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers
	servers SHOULD use the stateless cookie tracking technique described		SHOULD use the stateless cookie tracking technique described in
	in [RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be added to the		[RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a
	tracking table until a ClientHello packet has been received with an		ClientHello packet has been received with an appropriate Cookie
	appropriate Cookie value. The requirement to accept RADIUS/UDP and		value. The requirement to accept RADIUS/UDP and RADIUS/DTLS on the
	RADIUS/DTLS on the same port makes this recommendation difficult to		same port makes this recommendation difficult to implement in
	implement in practice. Server implementation SHOULD therefore have a		practice. Server implementation SHOULD therefore have a way of
	way of tracking partially setup DTLS connections. Servers SHOULD		tracking partially setup DTLS connections. Servers SHOULD limit both
	limit both the number and impact on resources of partial connections.		the number and impact on resources of partial connections.
	Entries in the tracking table MUST deleted when a TLS Closure Alert		Sessions (both key and entry) MUST deleted when a TLS Closure Alert
	([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section		([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section
	7.2.2) is received. Where the specifications require that a packet		7.2.2) is received. When a session is deleted due to failed
	received via a DTLS session be "silently discarded", the entry in the		security, the DTLS session MUST be closed, and any TLS session
	tracking table corresponding to that DTLS session MUST also be		resumption parameters for that session MUST be discarded, and all
	deleted, the DTLS session MUST be closed, and any TLS session		tracking information MUST be deleted.
	resumption parameters for that session MUST be discarded. The
	implementation MAY provide the capability of logging the error,		Sessions MUST also be deleted when a RADIUS packet fails validation
	including the contents of the silently discarded packet, and SHOULD		due to a packet being malformed, or when it has an invalid Message-
	record the event in a statistics counter.		Authenticator, or invalid Request Authenticator. There are other
			cases when the specifications require that a packet received via a
			DTLS session be "silently discarded". In those cases,
			implementations MAY delete the underlying session as described above.
			There are few reasons to communicate with a NAS which is not
			implementing RADIUS.
			Once a DTLS session is established, a RADIUS/DTLS server SHOULD use
			DTLS Heartbeats [RFC6520] to determine connectivity between the two
			servers. A server may also use watchdog packets from the client to
			determine that the connection is still active.
	As UDP does not guarantee delivery of messages, RADIUS/DTLS servers		As UDP does not guarantee delivery of messages, RADIUS/DTLS servers
	MUST also maintain a "Last Packet" timestamp per DTLS session. The		MUST also maintain a "Last Packet" timestamp per DTLS session. The
	timestamp SHOULD be updated on reception of a valid DTLS packet. The		timestamp SHOULD be updated on reception of a valid RADIUS/DTLS
	timestamp MUST NOT be updated in other situations. When a session		packet. The timestamp MUST NOT be updated in other situations. When
	has not received a packet for a period of time, it is labelled		a session has not received a packet for a period of time, it is
	"idle". The server SHOULD delete idle DTLS session from the tracking		labelled "idle". The server SHOULD delete idle DTLS sessions after
	table after an "idle timeout". The server MAY cache the TLS session		an "idle timeout". The server MAY cache the TLS session parameters,
	parameters, in order to provide for fast session resumption.		in order to provide for fast session resumption.
	This session "idle timeout" SHOULD be exposed to the administrator as		This session "idle timeout" SHOULD be exposed to the administrator as
	a configurable setting. It SHOULD NOT be set to less than 60		a configurable setting. It SHOULD NOT be set to less than 60
	seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes).		seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes).
	The minimum value useful value for this timer is determined by the		The minimum value useful value for this timer is determined by the
	application-layer watchdog mechanism defined in the following		application-layer watchdog mechanism defined in the following
	section.		section.
	RADIUS/DTLS servers SHOULD also keep track of the total number of		RADIUS/DTLS servers SHOULD also monitor the total number of sessions
	sessions in the tracking table. They SHOULD stop the creating of new		they are tracking. They SHOULD stop the creating of new sessions
	sessions when a large number are already being tracked. This		when a large number are already being tracked. This "maximum
	"maximum sessions" number SHOULD be exposed to administrators as a		sessions" number SHOULD be exposed to administrators as a
	configurable setting.		configurable setting.
	4.1.2. Protocol Disambiguation		RADIUS/DTLS servers SHOULD implement session resumption, preferably
			stateless session resumption as given in [RFC5077]. This practice
			lowers the time and effort required to start a DTLS session with a
			client, and increases network responsiveness.
			5.1.2. Protocol Disambiguation
	When the "DTLS Required" flag for a client is set to "false", the		When the "DTLS Required" flag for a client is set to "false", the
	client may, or may not be sending DTLS packets. For existing		client may, or may not be sending DTLS packets. For existing
	connections, protocol disambiguation is simple, the "Protocol Type"		connections, protocol disambiguation is simple, the "Protocol Type"
	field in the tracking table entry is examined. New connections must		field in the session tracking entry is examined. New connections
	still be disambiguated.		must still be disambiguated.
	In order to provide a robust upgrade path, the RADIUS/DTLS server		In order to provide a robust upgrade path, the RADIUS/DTLS server
	MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS.		MUST examine the packet to see if it is RADIUS/UDP or RADIUS/DTLS.
	This examination method is defined here.		This examination method is defined here.
	We justify the examination methods by analysing the packet formats		We justify the examination methods by analysing the packet formats
	for the two protocols. We assume that the server has a buffer in		for the two protocols. We assume that the server has a buffer in
	which it has received a UDP packet matching no entry on the		which it has received a UDP packet matching no entry based on the
	conneciton tracking table. It must then analyse this buffer to		4-tuple key defined above. It must then analyse this buffer to
	determine which protocol is used to process the packet.		determine which protocol is used to process the packet.
	The DTLS record format ([RFC6347] Section 4.1) is shown below, in		The DTLS record format ([RFC6347] Section 4.1) is shown below, in
	pseudo-code:		pseudo-code:
	struct {		struct {
	uint8 type;		uint8 type;
	uint16 version;		uint16 version;
	uint16 epoch;		uint16 epoch;
	uint48 sequence_number;		uint48 sequence_number;
	skipping to change at page 12, line 21		skipping to change at page 13, line 41
	Resource-Free-Response. That code is intended to be a response from		Resource-Free-Response. That code is intended to be a response from
	a server to a client, and will therefore never be sent by a client to		a server to a client, and will therefore never be sent by a client to
	a server.		a server.
	As a result, protocol disambiguation for new connections to a server		As a result, protocol disambiguation for new connections to a server
	is straightforward. Only the first octet of the packet needs to be		is straightforward. Only the first octet of the packet needs to be
	examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet		examined to disambiguate RADIUS/DTLS from RADIUS/UDP. If that octet
	has value 22, then the packet is likely to be RADIUS/DTLS.		has value 22, then the packet is likely to be RADIUS/DTLS.
	Otherwise, the packet is likely to be RADIUS/UDP.		Otherwise, the packet is likely to be RADIUS/UDP.
	4.1.3. Processing Algorithm		5.1.3. Processing Algorithm
	When a RADIUS/DTLS server recieves a packet, it uses the following		When a RADIUS/DTLS server recieves a packet, it uses the following
	algorithm to process that packet. As with RADIUS/UDP, packets from		algorithm to process that packet. As with RADIUS/UDP, packets from
	unknown clients MUST be silently discarded.		unknown clients MUST be silently discarded.
	The "DTLS Required" flag for that client is examined. If it is set		The "DTLS Required" flag for that client is examined. If it is set
	to "true", then the packet MUST be processed as RADIUS/DTLS.		to "true", then the packet MUST be processed as RADIUS/DTLS.
	If the "DTLS Required" flag is set to "false", the connection		If the "DTLS Required" flag is set to "false", the session is looked
	tracking table is examined. Packets matching an existing entry MUST		up using the 4-tuple key defined above. Packets matching an existing
	be processed as defined by the "Protocol Type" field of that entry.		entry MUST be processed as defined by the "Protocol Type" field of
			that entry.
	If the "DTLS Required" flag is set to "false" and no entry exists in		If the "DTLS Required" flag is set to "false" and no matching entry
	the connection tracking table, then the first octet of the packet is		has been found, then the first octet of the packet is examined. If
	examined. If it has value 22, then the packet MUST be processed as		it has value 22, then the packet MUST be processed as RADIUS/DTLS.
	RADIUS/DTLS. Otherwise, the packet MUST be processed as RADIUS/UDP.		Otherwise, the packet MUST be processed as RADIUS/UDP.
	In all cases, the packet MUST be checked for correctness. For		In all cases, the packet MUST be checked for correctness. For
	RADIUS/UDP, any packets which are silently discarded MUST NOT affect		RADIUS/UDP, any packets which are silently discarded MUST NOT affect
	the state of any variable in the session tracking table. For		the state of any variable in session tracking entry. For
	RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST		RADIUS/DTLS, any packets which are discarded by the DTLS layer MUST
	NOT affect the state of any variable in the session tracking table.		NOT affect the state of any variable in the session tracking entry.
	For RADIUS/DTLS, any RADIUS packets which are subsequently silently		For RADIUS/DTLS, any RADIUS packets which are subsequently silently
	discarded MUST result in the removal of the associated entry from the		discarded MUST result in the removal of the associated entry and key.
	connection tracking table.
	When the packet matches an existing entry in the connection table,		When the packet matches an existing key, and is accepted for
	and is accepted for processing by the server, the "Last Packet"		processing by the server, the "Last Packet" timestamp is updated in
	timestamp is updated. Where the packet does not match any entry in		that entry. Where the packet does not match an existing key, a new
	the connection table, a new connection is created using the 4-tuple		entry is created for that key. The "Protocol Type" flag for that
	key defined above. The "Protocol Type" flag for that connection is		entry is set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by
	set to "RADIUS/DTLS", or "RADIUS/UDP", as determined by examining the		examining the first octet of the packet.
	first octet of the packet.
	When a server has the clients "DTLS Required" flag set to "false", it		When a server has the clients "DTLS Required" flag set to "false", it
	MUST set the flag to "true" after establishing a DTLS session with		MUST set the flag to "true" after establishing a DTLS session with
	that client. It MUST NOT set the flag to "true" until a DTLS session		that client. It MUST NOT set the flag to "true" until a DTLS session
	has been fully established. Doing so would mean that attackers could		has been fully established. Doing so would mean that attackers could
	perform a DoS attack by sending forged DTLS ClientHello packets to a		perform a DoS attack by sending forged DTLS ClientHello packets to a
	server.		server.
	4.2. Client Connection Management		Since UDP is stateless, the potential exists for the client to
			initiate a new DTLS session using a particular 4-tuple, before the
			server has closed the old session. For security reasons, the server
			must keep the old session active until it has received secure
			notification from the client that the session is closed. Or, when
			the server has decided for itself that the session is closed. Taking
			any other action would permit unauthenticated clients to perform a
			DoS attack, by closing active DTLS session.
	Clients SHOULD use "connected" UDP sockets for RADIUS/DTLS traffic.		As a result, servers MUST ignore any attempts to re-use an existing
	A connected socket will then rely on the operating system to perform		4-tuple from an active session. This requirement can likely be
	connection tracking. Clients SHOULD NOT use "unconnected" sockets		reached by simply processing the packet through the existing session,
	for RADIUS/DTLS traffic. Using unconnected sockets would require the		as with any other packet received via that 4-tuple. Non-compliant,
	client to implement a connection tracking table, which is complex and		or unexpected packets will be ignored by the SSL layer.
	unnecessary.
	Once a DTLS session is established, a RADIUS/DTLS client SHOULD use		The above requirement is mitigated by the suggestion in Section 6.1,
			below, that the client use a local proxy for all RADIUS traffic.
			That proxy can then track the ports which it uses, and ensure that
			re-use of 4-tuples is avoided. The exact process by which this
			tracking is done is outside of the scope of this document.
			5.2. Client Connection Management
			Clients SHOULD use Path MTU (PMTU) discovery [RFC6520] to determine
			the PMTU between the client and server, prior to sending any RADIUS
			traffic. Once a DTLS session is established, a RADIUS/DTLS client
			SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity
			between the two servers. Alternatively, RADIUS/DTLS clients may use
	the application-layer watchdog algorithm defined in [RFC3539] to		the application-layer watchdog algorithm defined in [RFC3539] to
	determine server responsiveness. The Status-Server packet defined in		determine server responsiveness. The Status-Server packet defined in
	[RFC5997] MUST be used as the "watchdog packet" in the watchdog		[RFC5997] SHOULD be used as the "watchdog packet" in any application-
	algorithm.		layer watchdog algorithm.
	RADIUS/DTLS clients SHOULD pro-actively close sessions when they have		RADIUS/DTLS clients SHOULD pro-actively close sessions when they have
	been idle for a period of time. Clients SHOULD close a session when		been idle for a period of time. Clients SHOULD close a session when
	no traffic other than watchdog packets and (possibly) watchdog		the DTLS Heartbeat algorithm indicates that the session is no longer
	responses have been sent for three watchdog timeouts. This behavior		active. Clients SHOULD close a session when no traffic other than
	ensures that clients do not waste resources on the server by causing		watchdog packets and (possibly) watchdog responses have been sent for
	it to track idle sessions.		three watchdog timeouts. This behavior ensures that clients do not
			waste resources on the server by causing it to track idle sessions.
			DTLS sessions MUST also be deleted when a RADIUS packet fails
			validation due to a packet being malformed, or when it has an invalid
			Message-Authenticator, or invalid Response Authenticator. There are
			other cases when the specifications require that a packet received
			via a DTLS session be "silently discarded". In those cases,
			implementations MAY delete the underlying DTLS session.
	RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS		RADIUS/DTLS clients MUST NOT send both RADIUS/UDP and RADIUS/DTLS
	packets over the same key of (source IP, source port, destination IP,		packets over the same key of (source IP, source port, destination IP,
	destination port) as defined in Section 4.1, above . Doing so would		destination port) as defined in Section 4.1, above . Doing so would
	make it impossible to correctly process either kind of packet.		make it impossible to correctly process either kind of packet.
	RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS		RADIUS/DTLS clients SHOULD NOT send both RADIUS/UDP and RADIUS/DTLS
	packets to different servers from the same source socket. This		packets to different servers from the same source socket. This
	practice causes increased complexity in the client application, and		practice causes increased complexity in the client application, and
	increases the potential for security breaches due to implementation		increases the potential for security breaches due to implementation
	issues.		issues.
	RADIUS/DTLS clients SHOULD use TLS session resumption. This practice		RADIUS/DTLS clients SHOULD implement session resumption, preferably
			stateless session resumption as given in [RFC5077]. This practice
	lowers the time and effort required to start a DTLS session with a		lowers the time and effort required to start a DTLS session with a
	server, and increases network responsiveness.		server, and increases network responsiveness.
	5. Diameter Considerations		6. Implementation Guidelines
			The text above describes the protocol. In this section, we give
			additional implementation guidelines. These guidelines are not part
			of the protocol, but may help implementors create simple, secure, and
			inter-operable implementations.
			Where a TLS pre-shared key (PSK) method is used, implementations MUST
			support keys of at least 16 octets in length. Implementations SHOULD
			support key lengths of 32 octets, and SHOULD allow for longer keys.
			The key data MUST be capable of being any value (0 through 255,
			inclusive). Implementations MUST NOT limit themselves to using
			textual keys. It is RECOMMENDED that the administration interface
			allos for the keys to be entered as hex strings.
			It is RECOMMENDED that keys be derived from a cryptographically
			secure pseudo-random number generator (CSPRNG). If managing keys is
			too complicated, a certificate-based TLS method SHOULD be used
			instead.
			6.1. Client Implementations
			RADIUS/DTLS clients SHOULD use connected sockets where possible. Use
			of connected sockets means that the underlying kernel tracks the
			sessions, so that the client subsystem does not need to. It is a
			good idea to leverage existing functionality.
			RADIUS/DTLS clients SHOULD use a local proxy which arbitrates all
			RADIUS traffic between the client and all servers. The proxy SHOULD
			accept traffic only from the authorized subsystems on the client
			machine, and SHOULD proxy that traffic to known servers. Each
			authorized subsystem SHOULD include an attribute which uniquely
			identifies that subsystem to the proxy, so that the proxy can apply
			origin-specific proxy rules and security policies. We suggest using
			NAS-Identifier for this purpose.
			Each client subsystem can include a subsystem-specific NAS-Identifier
			in each request. The format of this attribute is implementation-
			specific. The proxy SHOULD verify that the request originated from
			the local system, ideally via a loopback address. The proxy MUST
			then re-write any subsystem-specific NAS-Identifier to a NAS-
			Identifier which identifies the client as a whole. Or, remove NAS-
			Identifier entirely and replace it with NAS-IP-Address or NAS-
			IPv6-Address.
			In traditional RADIUS, the cost to set up a new "session" between a
			client and server was minimal. The client subsystem could simply
			open a port, send a packet, wait for the response, and the close the
			port. With RADIUS/DTLS, the connection setup is significantly more
			expensive. In addition, there may be a requirement to use DTLS in
			order to communicate with a server, so that traditional RADIUS would
			be ignored by that server. The knowledge of what protocol to use is
			best managed by a dedicated RADIUS subsystem, rather than by each
			individual subsystem on the client.
			6.2. Server Implementations
			RADIUS/DTLS servers SHOULD NOT use connected sockets to read DTLS
			packets from a client. This recommendation is because a connected
			UDP socket will accept packets only from one source IP address and
			port. This limitation would prevent the server from accepting
			packets from multiple clients on the same port.
			7. Implementation Experience
			Two implementations of RADIUS/DTLS exist, Radsecproxy, and jradius
			(http://www.coova.org/JRadius). Some experimental tests have been
			performed, but there are at this time no production implementations
			using RADIUS/DTLS.
			Section 4.2 of [RFC6421] makes a number of recommendations about
			security properties of new RADIUS proposals. All of those
			recommendations are satisfied by using DTLS as the transport layer.
			Section 4.3 of [RFC6421] makes a number of recommendations about
			backwards compatibility with RADIUS. Section 3, above, addresses
			these concerns in detail.
			Section 4.4 of [RFC6421] recommends that change control be ceded to
			the IETF, and that interoperability is possible. Both requirements
			are satisfied.
			Section 4.5 of [RFC6421] requires that the new security methods apply
			to all packet types. This requirement is satisfied by allowing DTLS
			to be used for all RADIUS traffic. In addition, Section 3, above,
			addresses concerns about documenting the transition from legacy
			RADIUS to crypto-agile RADIUS.
			Section 4.6 of [RFC6421] requires automated key management. This
			requirement is satisfied by leveraging DTLS.
			8. Diameter Considerations
	This specification defines a transport layer for RADIUS. It makes no		This specification defines a transport layer for RADIUS. It makes no
	other changes to the RADIUS protocol. As a result, there are no		other changes to the RADIUS protocol. As a result, there are no
	Diameter considerations.		Diameter considerations.
	6. IANA Considerations		9. IANA Considerations
	This specification does not create any new registries, nor does it		This specification does not create any new registries, nor does it
	require assignment of any protocol parameters.		require assignment of any protocol parameters.
	7. Security Considerations		10. Security Considerations
	This entire specification is devoted to discussing security		This entire specification is devoted to discussing security
	considerations related to RADIUS. However, we discuss a few		considerations related to RADIUS. However, we discuss a few
	additional issues here.		additional issues here.
	This specification relies on the existing DTLS, RADIUS/UDP, and		This specification relies on the existing DTLS, RADIUS/UDP, and
	RADIUS/TLS specifications. As a result, all security considerations		RADIUS/TLS specifications. As a result, all security considerations
	for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the		for DTLS apply to the DTLS portion of RADIUS/DTLS. Similarly, the
	TLS and RADIUS security issues discussed in [RFC6614] also apply to		TLS and RADIUS security issues discussed in [RFC6614] also apply to
	this specification. All of the security considerations for RADIUS		this specification. All of the security considerations for RADIUS
	skipping to change at page 14, line 46		skipping to change at page 18, line 40
	The only new portion of the specification that could have security		The only new portion of the specification that could have security
	implications is a servers ability to accept both RADIUS and DTLS		implications is a servers ability to accept both RADIUS and DTLS
	packets on the same port. The filter that disambiguates the two		packets on the same port. The filter that disambiguates the two
	protocols is simple, and is just a check for the value of one octet.		protocols is simple, and is just a check for the value of one octet.
	We do not expect this check to have any security issues.		We do not expect this check to have any security issues.
	We also note that nothing prevents malicious clients from sending		We also note that nothing prevents malicious clients from sending
	DTLS packets to existing RADIUS implementations, or RADIUS packets to		DTLS packets to existing RADIUS implementations, or RADIUS packets to
	existing DTLS implementations. There should therefore be no issue		existing DTLS implementations. There should therefore be no issue
	with clients sending RADIUS/DTLS packets to legacy servers that do		with clients sending RADIUS/DTLS packets to legacy servers that do
	not support the protocol. These packets will be silently ignored,		not support the protocol. These packets will be silently discarded,
	and will not change the security profile of the server.		and will not change the security profile of the server.
	7.1. Legacy RADIUS Security		10.1. Legacy RADIUS Security
	We reiterate here the poor security of the legacy RADIUS protocol.		We reiterate here the poor security of the legacy RADIUS protocol.
	It is RECOMMENDED that all RADIUS clients and servers implement this		It is RECOMMENDED that all RADIUS clients and servers implement this
	specification. New attacks on MD5 have appeared over the past few		specification. New attacks on MD5 have appeared over the past few
	years, and there is a distinct possibility that MD5 may be completely		years, and there is a distinct possibility that MD5 may be completely
	broken in the near future.		broken in the near future.
	The existence of fast and cheap attacks on MD5 could result in a loss		The existence of fast and cheap attacks on MD5 could result in a loss
	of all network security which depends on RADIUS. Attackers could		of all network security which depends on RADIUS. Attackers could
	obtain user passwords, and possibly gain complete network access. We		obtain user passwords, and possibly gain complete network access. We
	skipping to change at page 15, line 30		skipping to change at page 19, line 24
	shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of		shared secret between RADIUS/UDP and RADIUS/DTLS would negate all of
	the benefits found by using DTLS.		the benefits found by using DTLS.
	RADIUS/DTLS client implementors MUST expose a configuration that		RADIUS/DTLS client implementors MUST expose a configuration that
	allows the administrator to choose the cipher suite. Where		allows the administrator to choose the cipher suite. Where
	certificates are used, RADIUS/DTLS client implementors MUST expose a		certificates are used, RADIUS/DTLS client implementors MUST expose a
	configuration which allows an administrator to configure all		configuration which allows an administrator to configure all
	certificates necessary for certificate-based authentication. These		certificates necessary for certificate-based authentication. These
	certificates include client, server, and root certificates.		certificates include client, server, and root certificates.
	When using PSK methods, RADIUS/DTLS servers MUST support keys (i.e.		TLS-PSK methods are susceptible to dictionary attacks. Section 6,
	shared secrets) that are at least 32 characters in length. These		above, recommends deriving TLS-PSK keys from a CSPRNG, which makes
	keys SHOULD be able to contain arbitrary binary data. RADIUS/DTLS		dictionary attacks significantly more difficult. Servers SHOULD
	server administrators MUST use strong shared secrets for those PSK		track failed client connections by TLS-PSK ID, and block TLS-PSK IDs
	methods. We RECOMMEND using keys derived from a cryptographically		which seem to be attempting brute-force searchs of the keyspace.
	secure pseudo-random number generator (CSPRNG). For example, a
	reasonable key may be 32 characters of a SHA-256 hash of at least 64
	octetss of data taken from a CSPRNG. If this method seems too
	complicated, a certificate-based TLS method SHOULD be used instead.
	The previous RADIUS practice of using shared secrets that are minor		The previous RADIUS practice of using shared secrets that are minor
	variations of words is NOT RECOMMENDED, as it would negate nearly all		variations of words is NOT RECOMMENDED, as it would negate all of the
	of the security of DTLS.		security of DTLS.
	7.2. Resource Exhaustion		10.2. Resource Exhaustion
	The use of DTLS allows DoS attacks, and resource exhaustion attacks		The use of DTLS allows DoS attacks, and resource exhaustion attacks
	which were not possible in RADIUS/UDP. These attacks are the same as		which were not possible in RADIUS/UDP. These attacks are the similar
	described in [RFC6614] Section X.Y.		to those described in [RFC6614] Section 6, for TCP.
	Use of the connection tracking table defined in Section X.Y can		Session tracking as described in Section 5.1 can result in resource
	result in resource exhaustion. Servers MUST therefore limit the		exhaustion. Servers MUST therefore limit the absolute number of
	absolute number of entries in the table. Servers MUST limit the		sessions that they track. Servers MUST limit the number of partially
	number of partially open DTLS sessions. These limits SHOULD be		open DTLS sessions. These limits SHOULD be exposed to the
	exposed to the administrator as configurable settings.		administrator as configurable settings.
	7.3. Network Address Translation		10.3. Network Address Translation
	Network Address Translation (NAT) is fundamentally incompatible with		Network Address Translation (NAT) is fundamentally incompatible with
	RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the		RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the
	shared secret for the client, and NAT hides many clients behind one		shared secret for the client, and NAT hides many clients behind one
	source IP address.		source IP address.
	The migration flag described above in Section 3 is also tracked per		The migration flag described above in Section 3 is also tracked per
	source IP address. Using a NAT in front of many RADIUS clients		source IP address. Using a NAT in front of many RADIUS clients
	negates the function of the flag, making it impossible to migrate		negates the function of the flag, making it impossible to migrate
	multiple clients in a secure fashion.		multiple clients in a secure fashion.
	skipping to change at page 16, line 33		skipping to change at page 20, line 23
	a client IP/port combination, followed by the reception of a		a client IP/port combination, followed by the reception of a
	RADIUS/UDP packet from that same client IP/port combination. If this		RADIUS/UDP packet from that same client IP/port combination. If this
	behavior is allowed, it would permit a downgrade attack to occur, and		behavior is allowed, it would permit a downgrade attack to occur, and
	would negate all of the security added by RADIUS/DTLS.		would negate all of the security added by RADIUS/DTLS.
	As a result, RADIUS clients SHOULD NOT be located behind a NAT		As a result, RADIUS clients SHOULD NOT be located behind a NAT
	gateway. If clients are located behind a NAT gateway, then a secure		gateway. If clients are located behind a NAT gateway, then a secure
	transport such as DTLS MUST be used. As discussed below, a method		transport such as DTLS MUST be used. As discussed below, a method
	for uniquely identifying each client MUST be used.		for uniquely identifying each client MUST be used.
	7.4. Wildcard Clients		10.4. Wildcard Clients
	Some RADIUS server implementations allow for "wildcard" clients.		Some RADIUS server implementations allow for "wildcard" clients.
	That is, clients with an IPv4 netmask of other than 32, or an IPv6		That is, clients with an IPv4 netmask of other than 32, or an IPv6
	netmask of other than 128. That practice is NOT RECOMMENDED for		netmask of other than 128. That practice is NOT RECOMMENDED for
	RADIUS/UDP, as it means multiple clients use the same shared secret.		RADIUS/UDP, as it means multiple clients use the same shared secret.
	When a client is a "wildcard", then RADIUS/DTLS MUST be used.		When a client is a "wildcard", then RADIUS/DTLS MUST be used.
	Clients MUST be uniquely identified, and any certificate or PSK used		Clients MUST be uniquely identified, and any certificate or PSK used
	MUST be unique to each client.		MUST be unique to each client.
	8. References		10.5. Session Closing
	8.1. Normative references		Section 5.1.1 above requires that DTLS sessions be closed when the
			transported RADIUS packets are malformed, or fail various
			authenticator checks. This requirement is due to security
			considerations.
			When an implementation has a DTLS connection, it is expected that the
			connection be used to transport RADIUS. Any non-RADIUS traffic on
			that connection means the other party is misbehaving, and a potential
			security risk. Similarly, any RADIUS traffic failing validation
			means that two parties do not share the same security parameters, and
			the session is therefore a security risk.
			We wish to avoid the situation where a third party can send well-
			formed RADIUS packets which cause a DTLS connection to close.
			Therefore, in other situations, the session may remain open in the
			face of non-conformant packets.
			10.6. Clients Subsystems
			Many traditional clients treat RADIUS as subsystem-specific. That
			is, each subsystem on the client has its own RADIUS implementation
			and configuration. These independent implementations work for simple
			systems, but break down for RADIUS when multiple servers, fail-over,
			and load-balancing are required. They have even worse issues when
			DTLS is enabled.
			As noted in Section 6.1, above, clients SHOULD use a local proxy
			which arbitrates all RADIUS traffic between the client and all
			servers. This proxy will encapsulate all knowledge about servers,
			including security policies, fail-over, and load-balancing. All
			client subsystems SHOULD communicate with this local proxy, ideally
			over a loopback address. The requirements on using strong shared
			secrets still apply.
			The benefit of this configuration is that there is one place in the
			client which arbitrates all RADIUS traffic. Subsystems which do not
			implement DTLS can remain unaware of DTLS. DTLS connections opened
			by the proxy can remain open for long periods of time, even when
			client subsystems are restarted. The proxy can do RADIUS/UDP to some
			servers, and RADIUS/DTLS to others.
			Delegation of responsibilities and separation of tasks are important
			security principles. By moving all RADIUS/DTLS knowledge to a DTLS-
			aware proxy, security analysis becomes simpler, and enforcement of
			correct security becomes easier.
			11. References
			11.1. Normative references
	[RFC2865]		[RFC2865]
	Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote		Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
	Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.		Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
	[RFC3539]		[RFC3539]
	Aboba, B. et al., "Authentication, Authorization and Accounting		Aboba, B. et al., "Authentication, Authorization and Accounting
	(AAA) Transport Profile", RFC 3539, June 2003.		(AAA) Transport Profile", RFC 3539, June 2003.
			[RFC5077]
			Salowey, J, et al., "Transport Layer Security (TLS) Session
			Resumption without Server-Side State", RFC 5077, January 2008
	[RFC5246]		[RFC5246]
	Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)		Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
	Protocol Version 1.2", RFC 5246, August 2008.		Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5997]		[RFC5997]
	DeKok, A., "Use of Status-Server Packets in the Remote		DeKok, A., "Use of Status-Server Packets in the Remote
	Authentication Dial In User Service (RADIUS) Protocol", RFC 5997,		Authentication Dial In User Service (RADIUS) Protocol", RFC 5997,
	August 2010.		August 2010.
	[RFC6347]		[RFC6347]
	Rescorla E., and Modadugu, N., "Datagram Transport Layer Security",		Rescorla E., and Modadugu, N., "Datagram Transport Layer Security",
	RFC 6347, April 2006.		RFC 6347, April 2006.
			[RFC6520]
			Seggelmann, R., et al.,"Transport Layer Security (TLS) and Datagram
			Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520,
			February 2012.
	[RFC6614]		[RFC6614]
	Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC		Winter. S, et. al., "TLS encryption for RADIUS over TCP", RFFC
	6614, May 2012		6614, May 2012
	8.2. Informative references		11.2. Informative references
	[RFC1321]		[RFC1321]
	Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC		Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC
	1321, April 1992.		1321, April 1992.
	[RFC2119]		[RFC2119]
	Bradner, S., "Key words for use in RFCs to Indicate Requirement		Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March, 1997.		Levels", RFC 2119, March, 1997.
	[RFC2866]		[RFC2866]
	Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.		Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
	[RFC5176]		[RFC5176]
	Chiba, M. et al., "Dynamic Authorization Extensions to Remote		Chiba, M. et al., "Dynamic Authorization Extensions to Remote
	Authentication Dial In User Service (RADIUS)", RFC 5176, January		Authentication Dial In User Service (RADIUS)", RFC 5176, January
	2008.		2008.
			[RFC6421]
			Nelson, D. (Ed), "Crypto-Agility Requirements for Remote
			Authentication Dial-In User Service (RADIUS)", RFC 6421, November
			2011.
	[MD5Attack]		[MD5Attack]
	Dobbertin, H., "The Status of MD5 After a Recent Attack",		Dobbertin, H., "The Status of MD5 After a Recent Attack",
	CryptoBytes Vol.2 No.2, Summer 1996.		CryptoBytes Vol.2 No.2, Summer 1996.
	[MD5Break]		[MD5Break]
	Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash		Wang, Xiaoyun and Yu, Hongbo, "How to Break MD5 and Other Hash
	Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005.		Functions", EUROCRYPT. ISBN 3-540-25910-4, 2005.
	Acknowledgments		Acknowledgments
End of changes. 70 change blocks.
	172 lines changed or deleted		421 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/