draft-ietf-radext-dtls-11.txt		draft-ietf-radext-dtls-12.txt
	Network Working Group Alan DeKok		Network Working Group Alan DeKok
	INTERNET-DRAFT FreeRADIUS		INTERNET-DRAFT FreeRADIUS
	Category: Experimental		Category: Experimental
	<draft-ietf-radext-dtls-11.txt>		<draft-ietf-radext-dtls-12.txt>
	Expires: October 28, 2015		Expires: November 8, 2014
	30 April 2014		8 May 2014
	DTLS as a Transport Layer for RADIUS		DTLS as a Transport Layer for RADIUS
	draft-ietf-radext-dtls-11		draft-ietf-radext-dtls-12
	Abstract		Abstract
	The RADIUS protocol defined in RFC 2865 has limited support for		The RADIUS protocol defined in RFC 2865 has limited support for
	authentication and encryption of RADIUS packets. The protocol		authentication and encryption of RADIUS packets. The protocol
	transports data in the clear, although some parts of the packets can		transports data in the clear, although some parts of the packets can
	have obfuscated content. Packets may be replayed verbatim by an		have obfuscated content. Packets may be replayed verbatim by an
	attacker, and client-server authentication is based on fixed shared		attacker, and client-server authentication is based on fixed shared
	secrets. This document specifies how the Datagram Transport Layer		secrets. This document specifies how the Datagram Transport Layer
	Security (DTLS) protocol may be used as a fix for these problems. It		Security (DTLS) protocol may be used as a fix for these problems. It
	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 October 15, 2014		This Internet-Draft will expire on November 8, 2014
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 3, line 36		skipping to change at page 3, line 36
	7. Diameter Considerations .................................. 17		7. Diameter Considerations .................................. 17
	8. IANA Considerations ...................................... 17		8. IANA Considerations ...................................... 17
	9. Implementation Status .................................... 18		9. Implementation Status .................................... 18
	9.1. Radsecproxy ......................................... 18		9.1. Radsecproxy ......................................... 18
	9.2. jradius ............................................. 18		9.2. jradius ............................................. 18
	10. Security Considerations ................................. 19		10. Security Considerations ................................. 19
	10.1. Crypto-Agility ..................................... 19		10.1. Crypto-Agility ..................................... 19
	10.2. Legacy RADIUS Security ............................. 20		10.2. Legacy RADIUS Security ............................. 20
	10.3. Resource Exhaustion ................................ 21		10.3. Resource Exhaustion ................................ 21
	10.4. Client-Server Authentication with DTLS ............. 21		10.4. Client-Server Authentication with DTLS ............. 21
	10.5. Network Address Translation ........................ 22		10.5. Network Address Translation ........................ 23
	10.6. Wildcard Clients ................................... 23		10.6. Wildcard Clients ................................... 23
	10.7. Session Closing .................................... 23		10.7. Session Closing .................................... 24
	10.8. Client Subsystems .................................. 24		10.8. Client Subsystems .................................. 24
	11. References .............................................. 24		11. References .............................................. 25
	11.1. Normative references ............................... 24		11.1. Normative references ............................... 25
	11.2. Informative references ............................. 25		11.2. Informative references ............................. 26
	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 5, line 24		skipping to change at page 5, line 24
	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.		further processing.
	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", "NOT
	and "OPTIONAL" in this document are to be interpreted as described in		RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
	[RFC2119].		interpreted as described in [RFC2119].
	1.3. Document Status		1.3. Document Status
	This document is an Experimental RFC.		This document is an Experimental RFC.
	It is one out of several approaches to address known cryptographic		It is one out of several approaches to address known cryptographic
	weaknesses of the RADIUS protocol, such as [RFC6614]. This		weaknesses of the RADIUS protocol, such as [RFC6614]. This
	specification does not fulfill all recommendations on a AAA transport		specification does not fulfill all recommendations on a AAA transport
	profile as per [RFC3539]; however unlike [RFC6614], it is based on		profile as per [RFC3539]; however unlike [RFC6614], it is based on
	UDP, does not have head-of-line blocking issues.		UDP, does not have head-of-line blocking issues.
	skipping to change at page 12, line 45		skipping to change at page 12, line 45
	session lifetimes, and other implementation-specific data.		session lifetimes, and other implementation-specific data.
	5.1.1. Session Opening and Closing		5.1.1. Session Opening and Closing
	Session tracking is subject to Denial of Service (DoS) attacks due to		Session tracking is subject to Denial of Service (DoS) attacks due to
	the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers		the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers
	SHOULD use the stateless cookie tracking technique described in		SHOULD use the stateless cookie tracking technique described in
	[RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a		[RFC6347] Section 4.2.1. DTLS sessions SHOULD NOT be tracked until a
	ClientHello packet has been received with an appropriate Cookie		ClientHello packet has been received with an appropriate Cookie
	value. Server implementation SHOULD have a way of tracking partially		value. Server implementation SHOULD have a way of tracking partially
	setup DTLS sessions. Servers SHOULD limit both the number and impact		setup DTLS sessions. Servers MUST limit both the number and impact
	on resources of partial sessions.		on resources of partial sessions.
	Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure		Sessions (both 4-tuple and entry) MUST be deleted when a TLS Closure
	Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246]		Alert ([RFC5246] Section 7.2.1) or a fatal TLS Error Alert ([RFC5246]
	Section 7.2.2) is received. When a session is deleted due to it		Section 7.2.2) is received. When a session is deleted due to it
	failing security requirements, the DTLS session MUST be closed, and		failing security requirements, the DTLS session MUST be closed, and
	any TLS session resumption parameters for that session MUST be		any TLS session resumption parameters for that session MUST be
	discarded, and all tracking information MUST be deleted.		discarded, and all tracking information MUST be deleted.
	Sessions MUST also be deleted when a RADIUS packet fails validation		Sessions MUST also be deleted when a RADIUS packet fails validation
	skipping to change at page 16, line 16		skipping to change at page 16, line 16
	support keys of at least 16 octets in length. Implementations SHOULD		support keys of at least 16 octets in length. Implementations SHOULD
	support key lengths of 32 octets, and SHOULD allow for longer keys.		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,		The key data MUST be capable of being any value (0 through 255,
	inclusive). Implementations MUST NOT limit themselves to using		inclusive). Implementations MUST NOT limit themselves to using
	textual keys. It is RECOMMENDED that the administration interface		textual keys. It is RECOMMENDED that the administration interface
	allows for the keys to be entered as humanly readable strings in hex		allows for the keys to be entered as humanly readable strings in hex
	format.		format.
	When creating keys, it is RECOMMENDED that keys be derived from a		When creating keys, it is RECOMMENDED that keys be derived from a
	cryptographically secure pseudo-random number generator (CSPRNG)		cryptographically secure pseudo-random number generator (CSPRNG)
	instead of allowing administrators to invent "secure" keys on theur		instead of administrators inventing keys on their own. If managing
	own. If managing keys is too complicated, a certificate-based TLS		keys is too complicated, a certificate-based TLS method SHOULD be
	method SHOULD be used instead.		used instead.
	6.1. Client Implementations		6.1. Client Implementations
	RADIUS/DTLS clients should use connected sockets where possible. Use		RADIUS/DTLS clients should use connected sockets where possible. Use
	of connected sockets means that the underlying kernel tracks the		of connected sockets means that the underlying kernel tracks the
	sessions, so that the client subsystem does not need to multiple		sessions, so that the client subsystem does not need to manage
	multiple sessions on one socket.		multiple sessions on one socket.
	RADIUS/DTLS clients should use a single source (IP + port) when		RADIUS/DTLS clients should use a single source (IP + port) when
	sending packets to a particular RADIUS/DTLS server. Doing so		sending packets to a particular RADIUS/DTLS server. Doing so
	minimizes the number of DTLS session setups. It also ensures that		minimizes the number of DTLS session setups. It also ensures that
	information about the home server state is discovered only once.		information about the home server state is discovered only once.
	In practice, this means that RADIUS/DTLS clients with multiple		In practice, this means that RADIUS/DTLS clients with multiple
	internal RADIUS sources should use a local proxy which arbitrates all		internal RADIUS sources should use a local proxy which arbitrates all
	RADIUS traffic between the client and all servers. The proxy should		RADIUS traffic between the client and all servers. The proxy should
	skipping to change at page 21, line 48		skipping to change at page 21, line 48
	relationships. The specification for dynamic discovery of RADIUS		relationships. The specification for dynamic discovery of RADIUS
	servers is under development, so we will not address that here.		servers is under development, so we will not address that here.
	Static configuration of client-server relationships for RADIUS/UDP		Static configuration of client-server relationships for RADIUS/UDP
	means that a client has a fixed IP address for a server, and a shared		means that a client has a fixed IP address for a server, and a shared
	secret used to authenticate traffic sent to that address. The server		secret used to authenticate traffic sent to that address. The server
	in turn has a fixed IP address for a client, and a shared secret used		in turn has a fixed IP address for a client, and a shared secret used
	to authenticate traffic from that address. This model needs to be		to authenticate traffic from that address. This model needs to be
	extended for RADIUS/DTLS.		extended for RADIUS/DTLS.
	When DTLS is used, the fixed IP address model can be relaxed. As		Instead of a shared secret, TLS credentials MUST be used by each
	discussed earlier in Section 2.2.1, client identities should be		party to authenticate the other. The issue of identity is more
	determined from TLS parameters. Any authentication credentials for		problematic. As with RADIUS/UDP, IP addresses may be used as a key
	that client are then determined solely from the client identity, and		to determine the authentication credentials which a client will
	not from an IP address. See [RFC6614] Section 2.4 for a discussion		present to a server, or which credentials a server will accept from a
	of how to match a certificate to a client identity.		client. This is the fixed IP address model of RADIUS/UDP, with the
			shared secret replaced by TLS credentials.
			There are, however, additional considerations with RADIUS/DTLS. When
			a client is configured with a host name for a server, the server may
			present to the client a certificate containing a host name. The
			client MUST then verify that the host names match. Any mismatch is a
			security violation, and the connection MUST be closed.
			A RADIUS/DTLS server MAY be configured with a "wildcard" IP address
			match for clients, instead of a unique fixed IP address for each
			client. In that case, clients MUST be individually configured with a
			unique certificate. When the server receives a connection from a
			client, it MUST determine client identity from the client
			certificate, and MUST authenticate (or not) the client based on that
			certificate. See [RFC6614] Section 2.4 for a discussion of how to
			match a certificate to a client identity.
	However, servers SHOULD use IP address filtering to minimize the		However, servers SHOULD use IP address filtering to minimize the
	possibility of attacks. That is, they SHOULD permit clients only		possibility of attacks. That is, they SHOULD permit clients only
	from a particular IP address range or ranges. They SHOULD silently		from a limited IP address range or ranges. They SHOULD silently
	discard all traffic from outside of those ranges.		discard all traffic from outside of those ranges.
	Since the client-server relationship is static, the authentication		Since the client-server relationship is static, the authentication
	credentials for that relationship should also be statically		credentials for that relationship must also be statically configured.
	configured. That is, a client connecting to a DTLS server SHOULD be		That is, a client connecting to a DTLS server SHOULD be pre-
	pre-configured with the servers credentials (e.g. PSK or		configured with the servers credentials (e.g. PSK or certificate).
	certificate). If the server fails to present the correct		If the server fails to present the correct credentials, the DTLS
	credentials, the DTLS session MUST be closed.		session MUST be closed. Each server SHOULD be preconfigured with
			sufficient information to authenticate connecting clients.
	The above requirement can be met by using a private Certificate		The above requirements can be met by using a private Certificate
	Authority (CA) for certificates used in RADIUS/DTLS environments. If		Authority (CA) for certificates used in RADIUS/DTLS environments. If
	a client were configured to use a public CA, then it could accept as		a client were configured to use a public CA, then it could accept as
	valid any server which has a certificate signed by that CA. While		valid any server which has a certificate signed by that CA. While
	the traffic would be secure from third-party observers, the server		the traffic would be secure from third-party observers, the server
	would, howrver, have unrestricted access to all of the RADIUS		would, howrver, have unrestricted access to all of the RADIUS
	traffic, including all user credentials and passwords.		traffic, including all user credentials and passwords.
	Therefore, clients SHOULD NOT be pre-configured with a list of known		Therefore, clients SHOULD NOT be pre-configured with a list of known
	public CAs by the vendor or manufacturer. Instead, the clients		public CAs by the vendor or manufacturer. Instead, the clients
	SHOULD start off with an empty CA list. The addition of a CA SHOULD		SHOULD start off with an empty CA list. The addition of a CA SHOULD
	skipping to change at page 22, line 41		skipping to change at page 23, line 10
	This scenario is the opposite of web browsers, where they are pre-		This scenario is the opposite of web browsers, where they are pre-
	configured with many known CAs. The goal there is security from		configured with many known CAs. The goal there is security from
	third-party observers, but also the ability to communicate with any		third-party observers, but also the ability to communicate with any
	unknown site which presents a signed certificate. In contrast, the		unknown site which presents a signed certificate. In contrast, the
	goal of RADIUS/DTLS is both security from third-party observers, and		goal of RADIUS/DTLS is both security from third-party observers, and
	the ability to communicate with only a small set of well-known		the ability to communicate with only a small set of well-known
	servers.		servers.
	This requirement does not prevent clients from using hostnames		This requirement does not prevent clients from using hostnames
	instead of IP addresses for locating a particular server. Instead,		instead of IP addresses for locating a particular server. Instead,
	it means that the credentials for that server should be		it means that the credentials for that server should be preconfigured
	preconfigured, and strongly tied to that hostname. This requirement		on the client, and associated with that hostname. This requirement
	does suggest that in the absence of a specification for dynamic		does suggest that in the absence of a specification for dynamic
	discovery, clients SHOULD use only those servers which have been		discovery, clients SHOULD use only those servers which have been
	manually configured by an administrator.		manually configured by an administrator.
	10.5. Network Address Translation		10.5. 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.
End of changes. 15 change blocks.
	33 lines changed or deleted		50 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/