draft-ietf-radext-dtls-09.txt		draft-ietf-radext-dtls-10.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-09.txt>		<draft-ietf-radext-dtls-10.txt>
	Expires: October 5, 2014		Expires: October 15, 2015
	5 February 2014		16 April 2014
	DTLS as a Transport Layer for RADIUS		DTLS as a Transport Layer for RADIUS
	draft-ietf-radext-dtls-09		draft-ietf-radext-dtls-10
	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 5, 2014		This Internet-Draft will expire on October 15, 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 26		skipping to change at page 3, line 26
	3.1. DTLS Port and Packet Types .......................... 10		3.1. DTLS Port and Packet Types .......................... 10
	3.2. Server Behavior ..................................... 10		3.2. Server Behavior ..................................... 10
	4. Client Behavior .......................................... 11		4. Client Behavior .......................................... 11
	5. Session Management ....................................... 11		5. Session Management ....................................... 11
	5.1. Server Session Management ........................... 12		5.1. Server Session Management ........................... 12
	5.1.1. Session Opening and Closing .................... 12		5.1.1. Session Opening and Closing .................... 12
	5.2. Client Session Management ........................... 14		5.2. Client Session Management ........................... 14
	6. Implementation Guidelines ................................ 15		6. Implementation Guidelines ................................ 15
	6.1. Client Implementations .............................. 16		6.1. Client Implementations .............................. 16
	6.2. Server Implementations .............................. 17		6.2. Server Implementations .............................. 17
	7. Implementation Experience ................................ 17		7. Diameter Considerations .................................. 17
	8. Diameter Considerations .................................. 18		8. IANA Considerations ...................................... 17
	9. IANA Considerations ...................................... 18		9. Implementation Status .................................... 18
	10. Security Considerations ................................. 18		9.1. Radsecproxy ......................................... 18
	10.1. Legacy RADIUS Security ............................. 19		9.2. jradius ............................................. 18
	10.2. Resource Exhaustion ................................ 20		10. Security Considerations ................................. 19
	10.3. Client-Server Authentication with DTLS ............. 20		10.1. Crypto-Agility ..................................... 19
	10.4. Network Address Translation ........................ 21		10.2. Legacy RADIUS Security ............................. 20
	10.5. Wildcard Clients ................................... 22		10.3. Resource Exhaustion ................................ 21
	10.6. Session Closing .................................... 22		10.4. Client-Server Authentication with DTLS ............. 21
	10.7. Client Subsystems .................................. 22		10.5. Network Address Translation ........................ 22
	11. References .............................................. 23		10.6. Wildcard Clients ................................... 23
	11.1. Normative references ............................... 23		10.7. Session Closing .................................... 23
	11.2. Informative references ............................. 24		10.8. Client Subsystems .................................. 23
			11. References .............................................. 24
			11.1. Normative references ............................... 24
			11.2. Informative references ............................. 25
	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 34		skipping to change at page 4, line 34
	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 User		Another benefit is that RADIUS over DTLS continues to be a User
	Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP		Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP
	is largely only to add TLS support. This allows implementations to		is largely only to add TLS support. This allows implementations to
	remain UDP based, without changing to a TCP architecture.		remain UDP based, without changing to a TCP architecture.
	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/UDP. The DTLS protocol does not add reliable
	in-order transport to RADIUS. DTLS also does not support		or 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. These		RADIUS the issues of order, reliability, and fragmentation. These
	issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS		issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS
	[RFC6614].		[RFC6614].
	1.1. Terminology		1.1. Terminology
	This document uses the following terms:		This document uses the following terms:
	skipping to change at page 12, line 7		skipping to change at page 12, line 7
	[RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests		[RFC5080] section 2.2.2 describes how duplicate RADIUS/UDP requests
	result in the retransmission of a previously cached RADIUS/UDP		result in the retransmission of a previously cached RADIUS/UDP
	response. Due to DTLS sequence window requirements, a server MUST		response. Due to DTLS sequence window requirements, a server MUST
	NOT retransmit a previously sent DTLS packet. Instead, it should		NOT retransmit a previously sent DTLS packet. Instead, it should
	cache the RADIUS response packet, and re-process it through DTLS to		cache the RADIUS response packet, and re-process it through DTLS to
	create a new RADIUS/DTLS packet, every time it is necessary to		create a new RADIUS/DTLS packet, every time it is necessary to
	retransmit a RADIUS response.		retransmit a RADIUS response.
	5.1. Server Session Management		5.1. Server Session Management
	A RADIUS/DTLS server MUST track ongoing DTLS client session based the		A RADIUS/DTLS server MUST track ongoing DTLS sessions for each based
	following 4-tuple:		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 4-tuple is independent of IP address version (IPv4 or		Note that this 4-tuple is independent of IP address version (IPv4 or
	IPv6).		IPv6).
	Each 4-tuple points to a unique session entry, which contains the		Each 4-tuple points to a unique session entry, which usually contain
	following information:		the following information:
	DTLS Data		DTLS Session
	An implementation-specific variable containing information about		Any information required to maintain and manage the DTLS session.
	the active DTLS session.
	Last Taffic		Last Taffic
	A variable containing a timestamp which indicates when this session		A variable containing a timestamp which indicates when this session
	last received valid traffic.		last received valid traffic. If "Last Traffic" is not used, this
			variable may not exist.
	Each entry may contain other information, such as idle timeouts,		DTLS Data
			An implementation-specific variable which may information about the
			active DTLS session. This variable may be empty or non existent.
			This data will typically contain information such as idle timeouts,
	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
	skipping to change at page 15, line 19		skipping to change at page 15, line 22
	When client fails to implement both DTLS heartbeats and watchdog		When client fails to implement both DTLS heartbeats and watchdog
	packets, it has no way of knowing that a DTLS session has been		packets, it has no way of knowing that a DTLS session has been
	closed. There is therefore the possibility that the server closes		closed. There is therefore the possibility that the server closes
	the session without the client knowing. When that happens, the		the session without the client knowing. When that happens, the
	client may later transmit packets in a session, and those packets		client may later transmit packets in a session, and those packets
	will be ignored by the server. The client is then forced to time out		will be ignored by the server. The client is then forced to time out
	those packets and then the session, leading to delays and network		those packets and then the session, leading to delays and network
	instabilities.		instabilities.
	For these reasons, it is RECOMMENDED that RADIUS/DTLS clients		For these reasons, it is RECOMMENDED that all DTLS sessions are
	implement DTLS heartbeats and/or watchdog packets for all DTLS		configured to use DTLS heartbeats and/or watchdog packets.
	sessions.
	DTLS sessions MUST also be deleted when a RADIUS packet fails		DTLS sessions MUST also be deleted when a RADIUS packet fails
	validation due to a packet being malformed, or when it has an invalid		validation due to a packet being malformed, or when it has an invalid
	Message-Authenticator, or invalid Response Authenticator. There are		Message-Authenticator, or invalid Response Authenticator. There are
	other cases when the specifications require that a packet received		other cases when the specifications require that a packet received
	via a DTLS session be "silently discarded". In those cases,		via a DTLS session be "silently discarded". In those cases,
	implementations MAY delete the underlying DTLS session.		implementations MAY delete the underlying DTLS session.
	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
	skipping to change at page 17, line 28		skipping to change at page 17, line 29
	individual subsystem on the client.		individual subsystem on the client.
	6.2. Server Implementations		6.2. Server Implementations
	RADIUS/DTLS servers should not use connected sockets to read DTLS		RADIUS/DTLS servers should not use connected sockets to read DTLS
	packets from a client. This recommendation is because a connected		packets from a client. This recommendation is because a connected
	UDP socket will accept packets only from one source IP address and		UDP socket will accept packets only from one source IP address and
	port. This limitation would prevent the server from accepting		port. This limitation would prevent the server from accepting
	packets from multiple clients on the same port.		packets from multiple clients on the same port.
	7. Implementation Experience		7. Diameter Considerations
	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.
	9. IANA Considerations		8. IANA Considerations
	No new RADIUS attributes or packet codes are defined. IANA is		No new RADIUS attributes or packet codes are defined. IANA is
	requested to update the already-assigned UDP port number 2083 in the		requested to update the "Service Name and Transport Protocol Port
	following ways:		Number Registry". The entry corresponding to port service name
			"radsec", port number "2083", and transport protocol "UDP" should be
			updated as follows:
	o Reference: list the RFC number of this document as the reference		o Assignee: change "Mike McCauley" to "IESG".
			o Contact: change ""Mike McCauley" to "IETF Chair"
			o Reference: Add this document as a reference
	o Assignment Notes: add the text "The UDP port 2083 was already		o Assignment Notes: add the text "The UDP port 2083 was already
	previously assigned by IANA for "RadSec", an early implementation		previously assigned by IANA for "RadSec", an early implementation
	of RADIUS/TLS, prior to issuance of this RFC."		of RADIUS/TLS, prior to issuance of this RFC."
			9. Implementation Status
			This section records the status of known implementations of
			RADIUS/DTLS at the time of posting of this Internet- Draft, and is
			based on a proposal described in [RFC6982].
			The description of implementations in this section is intended to
			assist the IETF in its decision processes in progressing drafts to
			RFCs.
			9.1. Radsecproxy
			Organization: Radsecproxy
			URL: https://software.uninett.no/radsecproxy/
			Maturity: Widely-used software based on early drafts of this
			document.
			The use of the DTLS functionality is not clear.
			Coverage: The bulk of this specification is implemented, based on
			earlier versions of this document. Exact revisions
			which were implemented are unknown.
			Licensing: Freely distributable with acknowledgement
			Implementation experience: No comments from implementors.
			9.2. jradius
			Organization: Coova
			URL: http://www.coova.org/JRadius/RadSec
			Maturity: Production software based on early drafts of this
			document.
			The use of the DTLS functionality is not clear.
			Coverage: The bulk of this specification is implemented, based on
			earlier versions of this document. Exact revisions
			which were implemented are unknown.
			Licensing: Freely distributable with requirement to
			redistribute source.
			Implementation experience: No comments from implementors.
	10. Security Considerations		10. Security Considerations
	The bulk of this specification is devoted to discussing security		The bulk of this 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
	skipping to change at page 19, line 18		skipping to change at page 19, line 45
	implementation error, all of the RADIUS traffic will be readable by		implementation error, all of the RADIUS traffic will be readable by
	an observer. Implementations therefore MUST NOT use null encryption		an observer. Implementations therefore MUST NOT use null encryption
	methods for RADIUS/DTLS.		methods for RADIUS/DTLS.
	For systems which perform protocol-based firewalling and/or		For systems which perform protocol-based firewalling and/or
	filtering, it is RECOMMENDED that they be configured to permit only		filtering, it is RECOMMENDED that they be configured to permit only
	DTLS over the RADIUS/DTLS port. Where deep packet inspection is		DTLS over the RADIUS/DTLS port. Where deep packet inspection is
	possible, there should be further restrictions to allow only RADIUS		possible, there should be further restrictions to allow only RADIUS
	packets inside of the DTLS session.		packets inside of the DTLS session.
	10.1. Legacy RADIUS Security		10.1. Crypto-Agility
	protocol. We suggest that RADIUS clients and servers implement		Section 4.2 of [RFC6421] makes a number of recommendations about
	either this specification, or [RFC6614]. New attacks on MD5 have		security properties of new RADIUS proposals. All of those
	appeared over the past few years, and there is a distinct possibility		recommendations are satisfied by using DTLS as the transport layer.
	that MD5 may be completely broken in the near future. Such a break
	would mean that RADIUS/UDP was completely insecure.		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 using DTLS key management.
			10.2. Legacy RADIUS Security
			We reiterate here the poor security of the legacy RADIUS protocol.
			We suggest that RADIUS clients and servers implement either this
			specification, or [RFC6614]. New attacks on MD5 have appeared over
			the past few years, and there is a distinct possibility that MD5 may
			be completely broken in the near future. Such a break would mean
			that RADIUS/UDP was completely insecure.
	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
	cannot overstate the disastrous consequences of a successful attack		cannot overstate the disastrous consequences of a successful attack
	on RADIUS.		on RADIUS.
	We also caution implementors (especially client implementors) about		We also caution implementors (especially client implementors) about
	using RADIUS/DTLS. It may be tempting to use the shared secret as		using RADIUS/DTLS. It may be tempting to use the shared secret as
	the basis for a TLS pre-shared key (PSK) method, and to leave the		the basis for a TLS pre-shared key (PSK) method, and to leave the
	skipping to change at page 19, line 49		skipping to change at page 20, line 51
	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.
	TLS-PSK methods are susceptible to dictionary attacks. Section 6,		TLS-PSK methods are susceptible to dictionary attacks. Section 6,
	above, recommends deriving TLS-PSK keys from a CSPRNG, which makes		above, recommends deriving TLS-PSK keys from a Cryptographically
			Secure Pseudo-Random Number Generator (CSPRNG), which makes
	dictionary attacks significantly more difficult. Servers SHOULD		dictionary attacks significantly more difficult. Servers SHOULD
	track failed client connections by TLS-PSK ID, and block TLS-PSK IDs		track failed client connections by TLS-PSK ID, and block TLS-PSK IDs
	which seem to be attempting brute-force searchs of the keyspace.		which seem to be attempting brute-force searchs of the keyspace.
	The historic RADIUS practice of using shared secrets (here, PSKs)		The historic RADIUS practice of using shared secrets (here, PSKs)
	that are minor variations of words is NOT RECOMMENDED, as it would		that are minor variations of words is NOT RECOMMENDED, as it would
	negate all of the security of DTLS.		negate all of the security of DTLS.
	10.2. Resource Exhaustion		10.3. 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 similar		which were not possible in RADIUS/UDP. These attacks are the similar
	to those described in [RFC6614] Section 6, for TCP.		to those described in [RFC6614] Section 6, for TCP.
	Session tracking as described in Section 5.1 can result in resource		Session tracking as described in Section 5.1 can result in resource
	exhaustion. Servers MUST therefore limit the absolute number of		exhaustion. Servers MUST therefore limit the absolute number of
	sessions that they track. When the total number of sessions tracked		sessions that they track. When the total number of sessions tracked
	is going to exceed the configured limit, servers MAY free up		is going to exceed the configured limit, servers MAY free up
	resources by closing the session which has been idle for the longest		resources by closing the session which has been idle for the longest
	time. Doing so may free up idle resources which then allow the		time. Doing so may free up idle resources which then allow the
	server to accept a new session.		server to accept a new session.
	Servers MUST limit the number of partially open DTLS sessions. These		Servers MUST limit the number of partially open DTLS sessions. These
	limits SHOULD be exposed to the administrator as configurable		limits SHOULD be exposed to the administrator as configurable
	settings.		settings.
	10.3. Client-Server Authentication with DTLS		10.4. Client-Server Authentication with DTLS
	We expect that the initial deployment of DTLS will be follow the		We expect that the initial deployment of DTLS will be follow the
	RADIUS/UDP model of statically configured client-server		RADIUS/UDP model of statically configured client-server
	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		When DTLS is used, the fixed IP address model can be relaxed. As
	discussed earlier in Section 2.2.1, client identies should be		discussed earlier in Section 2.2.1, client identities should be
	determined from TLS parameters. Any authentication credentials for		determined from TLS parameters. Any authentication credentials for
	that client are then determined solely from the client identity, and		that client are then determined solely from the client identity, and
	not from an IP address. See [RFC6614] Section 2.4 for a discussion		not from an IP address. See [RFC6614] Section 2.4 for a discussion
	of how to match a certificate to a client identity.		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 particular IP address range or ranges. They SHOULD silently
	discard all traffic from outside of those ranges.		discard all traffic from outside of those ranges.
	skipping to change at page 21, line 41		skipping to change at page 22, line 46
	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, and strongly tied to that hostname. This requirement		preconfigured, and strongly tied to 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.4. 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.
	In addition, port re-use on a NAT gateway means that packets from		In addition, port re-use on a NAT gateway means that packets from
	different clients may appear to come from the same source port on the		different clients may appear to come from the same source port on the
	NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from		NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from
	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, then the client would have an inconsistent		behavior is allowed, then the client would have an inconsistent
	security profile, allowing an attacker to choose the most insecure		security profile, allowing an attacker to choose the most insecure
	method.		method.
	As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT		As a result, RADIUS/UDP 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.
	10.5. Wildcard Clients		10.6. 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.
	The use of RADIUS/DTLS can allow for the safe usage of wildcards.		The use of RADIUS/DTLS can allow for the safe usage of wildcards.
	When RADIUS/DTLS is used with wildcards, clients MUST be uniquely		When RADIUS/DTLS is used with wildcards, clients MUST be uniquely
	identified using TLS parameters, and any certificate or PSK used MUST		identified using TLS parameters, and any certificate or PSK used MUST
	be unique to each client.		be unique to each client.
	10.6. Session Closing		10.7. Session Closing
	Section 5.1.1, above, requires that DTLS sessions be closed when the		Section 5.1.1, above, requires that DTLS sessions be closed when the
	transported RADIUS packets are malformed, or fail the authenticator		transported RADIUS packets are malformed, or fail the authenticator
	checks. The reason is that the session is expected to be used for		checks. The reason is that the session is expected to be used for
	transport of RADIUS packets only.		transport of RADIUS packets only.
	Any non-RADIUS traffic on that session means the other party is		Any non-RADIUS traffic on that session means the other party is
	misbehaving, and is a potential security risk. Similarly, any RADIUS		misbehaving, and is a potential security risk. Similarly, any RADIUS
	traffic failing authentication vector or Message-Authenticator		traffic failing authentication vector or Message-Authenticator
	validation means that two parties do not have a common shared secret,		validation means that two parties do not have a common shared secret,
	and the session is therefore unauthenticated and insecure.		and the session is therefore unauthenticated and insecure.
	We wish to avoid the situation where a third party can send well-		We wish to avoid the situation where a third party can send well-
	formed RADIUS packets which cause a DTLS session to close.		formed RADIUS packets which cause a DTLS session to close.
	Therefore, in other situations, the session SHOULD remain open in the		Therefore, in other situations, the session SHOULD remain open in the
	face of non-conformant packets.		face of non-conformant packets.
	10.7. Client Subsystems		10.8. Client Subsystems
	Many traditional clients treat RADIUS as subsystem-specific. That		Many traditional clients treat RADIUS as subsystem-specific. That
	is, each subsystem on the client has its own RADIUS implementation		is, each subsystem on the client has its own RADIUS implementation
	and configuration. These independent implementations work for simple		and configuration. These independent implementations work for simple
	systems, but break down for RADIUS when multiple servers, fail-over,		systems, but break down for RADIUS when multiple servers, fail-over,
	and load-balancing are required. They have even worse issues when		and load-balancing are required. They have even worse issues when
	DTLS is enabled.		DTLS is enabled.
	As noted in Section 6.1, above, clients SHOULD use a local proxy		As noted in Section 6.1, above, clients SHOULD use a local proxy
	which arbitrates all RADIUS traffic between the client and all		which arbitrates all RADIUS traffic between the client and all
	skipping to change at page 24, line 49		skipping to change at page 26, line 6
	[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]		[RFC6421]
	Nelson, D. (Ed), "Crypto-Agility Requirements for Remote		Nelson, D. (Ed), "Crypto-Agility Requirements for Remote
	Authentication Dial-In User Service (RADIUS)", RFC 6421, November		Authentication Dial-In User Service (RADIUS)", RFC 6421, November
	2011.		2011.
			[RFC6982]
			Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code:
			The Implementation Status Section", RFC 6982, July 2013.
	[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. 27 change blocks.
	80 lines changed or deleted		140 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/