draft-ietf-radext-radsec-10.txt		draft-ietf-radext-radsec-11.txt
	RADIUS Extensions Working Group S. Winter		RADIUS Extensions Working Group S. Winter
	Internet-Draft RESTENA		Internet-Draft RESTENA
	Intended status: Experimental M. McCauley		Intended status: Experimental M. McCauley
	Expires: July 12, 2012 OSC		Expires: July 30, 2012 OSC
	S. Venaas		S. Venaas
	UNINETT
	K. Wierenga		K. Wierenga
	Cisco		Cisco
	January 9, 2012		January 27, 2012
	TLS encryption for RADIUS		TLS encryption for RADIUS
	draft-ietf-radext-radsec-10		draft-ietf-radext-radsec-11
	Abstract		Abstract
	This document specifies security on the transport layer (TLS) for the		This document specifies security on the transport layer (TLS) for the
	RADIUS protocol when transmitted over TCP. This enables dynamic		RADIUS protocol when transmitted over TCP. This enables dynamic
	trust relationships between RADIUS servers.		trust relationships between RADIUS servers.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 37		skipping to change at page 1, line 36
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on July 12, 2012.		This Internet-Draft will expire on July 30, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 25		skipping to change at page 2, line 24
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
			1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4
	2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4		2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4
	2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4		2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
	2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4		2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4		2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6		2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6
	2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7		2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7
	3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8		3. Informative: Design Decisions . . . . . . . . . . . . . . . . 9
	3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8		3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 9
	3.2. Ciphersuites and Compression Negotiation Considerations . 9		3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 9
	3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10		3.3. Ciphersuites and Compression Negotiation Considerations . 10
			3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10
	4. Compatibility with other RADIUS transports . . . . . . . . . . 11		4. Compatibility with other RADIUS transports . . . . . . . . . . 11
	5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11		5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
			10.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16		Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16
	Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17		Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17
	Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18		Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18
	1. Introduction		1. Introduction
	The RADIUS protocol [RFC2865] is a widely deployed authentication and		The RADIUS protocol [RFC2865] is a widely deployed authentication and
	authorisation protocol. The supplementary RADIUS Accounting		authorisation protocol. The supplementary RADIUS Accounting
	specification [RFC2866] also provides accounting mechanisms, thus		specification [RFC2866] also provides accounting mechanisms, thus
	delivering a full AAA solution. However, RADIUS is experiencing		delivering a full AAA solution. However, RADIUS is experiencing
	skipping to change at page 3, line 40		skipping to change at page 3, line 40
	Because of the static trust establishment between RADIUS peers (IP		Because of the static trust establishment between RADIUS peers (IP
	address and shared secret) the only scalable way of creating a		address and shared secret) the only scalable way of creating a
	massive deployment of RADIUS-servers under control by different		massive deployment of RADIUS-servers under control by different
	administrative entities is to introduce some form of a proxy chain to		administrative entities is to introduce some form of a proxy chain to
	route the access requests to their home server. This creates a lot		route the access requests to their home server. This creates a lot
	of overhead in terms of possible points of failure, longer		of overhead in terms of possible points of failure, longer
	transmission times as well as middleboxes through which		transmission times as well as middleboxes through which
	authentication traffic flows. These middleboxes may learn privacy-		authentication traffic flows. These middleboxes may learn privacy-
	relevant data while forwarding requests. The new features in RADIUS		relevant data while forwarding requests. The new features in RADIUS
	over TLS obsolete the use of IP addresses and shared MD5 secrets to		over TLS obsolete the use of IP addresses and shared MD5 secrets to
	identify other peers and thus allow the dynamic establishment of		identify other peers and thus allow the use of more contemporary
	connections to peers that are not previously configured, and thus		trust models, e.g. checking a certificate by inspecting the issuer
	makes it possible to avoid aggregation-only RADIUS proxies and reduce		and other certificate properties.
	the number of middleboxes which can eavesdrop on traffic. One
	mechanism to discover RADIUS over TLS peers with DNS is specified in
	[I-D.ietf-radext-dynamic-discovery].
	1.1. Requirements Language		1.1. 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", "NOT		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
	RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be		RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
	interpreted as described in RFC 2119. [RFC2119]		interpreted as described in RFC 2119. [RFC2119]
	1.2. Terminology		1.2. Terminology
	skipping to change at page 4, line 18		skipping to change at page 4, line 17
	RADIUS/TLS node: a RADIUS over TLS client or server		RADIUS/TLS node: a RADIUS over TLS client or server
	RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new		RADIUS/TLS Client: a RADIUS over TLS instance which initiates a new
	connection.		connection.
	RADIUS/TLS Server: a RADIUS over TLS instance which listens on a		RADIUS/TLS Server: a RADIUS over TLS instance which listens on a
	RADIUS over TLS port and accepts new connections		RADIUS over TLS port and accepts new connections
	RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865]		RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865]
			1.3. Document Status
			This document is an Experimental RFC.
			It is one out of several approaches to address known cryptographic
			weaknesses of the RADIUS protocol (see also Section 4). The
			specification does not fulfill all recommendations on a AAA transport
			profile as per [RFC3539]; in particular, by being based on TCP as a
			transport layer, it does not prevent head-of-line blocking issues.
			It has yet to be decided whether this approach is to be chosen for
			standards track. One key aspect to judge whether the approach is
			usable at large scale is by observing the uptake, usability and
			operational behaviour of the protocol in large-scale, real-life
			deployments.
			An example for a world-wide roaming environment that uses RADIUS over
			TLS to secure communication is "eduroam", see [eduroam].
	2. Normative: Transport Layer Security for RADIUS/TCP		2. Normative: Transport Layer Security for RADIUS/TCP
	2.1. TCP port and packet types		2.1. TCP port and packet types
	The default destination port number for RADIUS over TLS is TCP/2083.		The default destination port number for RADIUS over TLS is TCP/2083.
	There are no separate ports for authentication, accounting and		There are no separate ports for authentication, accounting and
	dynamic authorisation changes. The source port is arbitrary. See		dynamic authorisation changes. The source port is arbitrary. See
	section Section 3.3 (4) and (5) for considerations regarding		section Section 3.4 for considerations regarding separation of
	separation of authentication, accounting and dynauth traffic.		authentication, accounting and dynauth traffic.
	2.2. TLS negotiation		2.2. TLS negotiation
	RADIUS/TLS has no notion of negotiating TLS in an established		RADIUS/TLS has no notion of negotiating TLS in an established
	connection. Servers and clients need to be preconfigured to use		connection. Servers and clients need to be preconfigured to use
	RADIUS/TLS for a given endpoint.		RADIUS/TLS for a given endpoint.
	2.3. Connection Setup		2.3. Connection Setup
	RADIUS/TLS nodes		RADIUS/TLS nodes
	1. establish TCP connections as per [I-D.ietf-radext-tcp-transport].		1. establish TCP connections as per [I-D.ietf-radext-tcp-transport].
	Failure to connect leads to continuous retries, with		Failure to connect leads to continuous retries, with
	exponentially growing intervals between every try. If multiple		exponentially growing intervals between every try. If multiple
	servers are defined, the node MAY attempt to establish a		servers are defined, the node MAY attempt to establish a
	connection to these other servers in parallel, in order to		connection to these other servers in parallel, in order to
	implement quick failover.		implement quick failover.
	2. after completing the TCP handshake, immediately negotiate TLS		2. after completing the TCP handshake, immediately negotiate TLS
	sessions. The following restrictions apply: according to		sessions according to [RFC5246] or its predecessor TLS 1.1. The
	[RFC5246] or its predecessor TLS 1.1. The following restrictions		following restrictions apply:
	apply:
	* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2		* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2
	[RFC5246] ]) is REQUIRED.		[RFC5246] ]) is REQUIRED.
	* Support for certificate-based mutual authentication is		* Support for certificate-based mutual authentication is
	REQUIRED.		REQUIRED.
	* Negotiation of mutual authentication is REQUIRED.		* Negotiation of mutual authentication is REQUIRED.
	* Negotiation of a ciphersuite providing for confidentiality as		* Negotiation of a ciphersuite providing for confidentiality as
	well as integrity protection is REQUIRED.		well as integrity protection is REQUIRED.
	* Support for and negotiation of compression is OPTIONAL.		* Support for and negotiation of compression is OPTIONAL.
	* Support for TLS-PSK mutual authentication [RFC4279] is		* Support for TLS-PSK mutual authentication [RFC4279] is
	OPTIONAL.		OPTIONAL.
	* RADIUS/TLS implementations MUST at a minimum support		* RADIUS/TLS implementations MUST at a minimum support
	negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD		negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD
	support TLS_RSA_WITH_RC4_128_SHA and		support TLS_RSA_WITH_RC4_128_SHA and
	TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ).		TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 (1) ).
	* In addition, RADIUS/TLS implementations MUST support		* In addition, RADIUS/TLS implementations MUST support
	negotiation of the mandatory-to-implement ciphersuites		negotiation of the mandatory-to-implement ciphersuites
	required by the versions of TLS that they support.		required by the versions of TLS that they support.
	* RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL		* RADIUS/TLS nodes MUST NOT negotiate ciphersuites with NULL
	encryption (e.g. [RFC4785]).		encryption (e.g. [RFC4785]).
	3. If TLS is used in an X.509 certificate based operation mode, the		3. If TLS is used in an X.509 certificate based operation mode, the
	following list of certificate validation options applies:		following list of certificate validation options applies:
	* Implementations MUST allow to configure a list of acceptable		* Implementations MUST allow to configure a list of acceptable
	Certification Authorities for incoming connections.		Certification Authorities for incoming connections.
	* Certificate validation MUST include the verification rules as		* Certificate validation MUST include the verification rules as
	per [RFC5280].		per [RFC5280].
	* Implementations SHOULD indicate their acceptable Certification		* Implementations SHOULD indicate their acceptable Certification
	Authorities as per section 7.4.4 (server side) and x.y.z		Authorities as per section 7.4.4 (server side) and x.y.z
	["Trusted CA Indication"] (client side) of [RFC5246] (see		["Trusted CA Indication"] (client side) of [RFC5246] (see
	Section 3.1)		Section 3.2)
	* Implementations SHOULD allow to configure a list of acceptable		* Implementations SHOULD allow to configure a list of acceptable
	certificates, identified via certificate fingerprint. When a		certificates, identified via certificate fingerprint. When a
	fingerprint configured, the fingerprint is prepended with an		fingerprint configured, the fingerprint is prepended with an
	ASCII label identifying the hash function followed by a colon.		ASCII label identifying the hash function followed by a colon.
	Implementations MUST support SHA-1 as the hash algorithm and		Implementations MUST support SHA-1 as the hash algorithm and
	use the ASCII label "sha-1" to identify the SHA-1 algorithm.		use the ASCII label "sha-1" to identify the SHA-1 algorithm.
	The length of a SHA-1 hash is 20 bytes and the length of the		The length of a SHA-1 hash is 20 bytes and the length of the
	corresponding fingerprint string is 65 characters. An example		corresponding fingerprint string is 65 characters. An example
	certificate fingerprint is: sha-		certificate fingerprint is: sha-
	skipping to change at page 6, line 19		skipping to change at page 6, line 37
	IP addresses can be contained in the Common Name (CN) or		IP addresses can be contained in the Common Name (CN) or
	subjectAltName entries. For verification, only one of these		subjectAltName entries. For verification, only one of these
	entries is to be considered. The following precedence		entries is to be considered. The following precedence
	applies: for DNS name validation, subjectAltName:DNS has		applies: for DNS name validation, subjectAltName:DNS has
	precedence over CN; for IP address validation, subjectAltName:		precedence over CN; for IP address validation, subjectAltName:
	iPAddr has precedence over CN.		iPAddr has precedence over CN.
	* Implementations SHOULD allow to configure a set of acceptable		* Implementations SHOULD allow to configure a set of acceptable
	values for subjectAltName:URI.		values for subjectAltName:URI.
	4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The		4. start exchanging RADIUS datagrams. Note Section 3.4 (1) ). The
	shared secret to compute the (obsolete) MD5 integrity checks and		shared secret to compute the (obsolete) MD5 integrity checks and
	attribute encryption MUST be "radsec" (see Section 3.3 (2) ).		attribute encryption MUST be "radsec" (see Section 3.4 (2) ).
	2.4. Connecting Client Identity		2.4. Connecting Client Identity
	In RADIUS/UDP, clients are uniquely identified by their IP address.		In RADIUS/UDP, clients are uniquely identified by their IP address.
	Since the shared secret is associated with the origin IP address, if		Since the shared secret is associated with the origin IP address, if
	more than one RADIUS client is associated with the same IP address,		more than one RADIUS client is associated with the same IP address,
	then those clients also must utilize the same shared secret, a		then those clients also must utilize the same shared secret, a
	practice which is inherently insecure as noted in [RFC5247].		practice which is inherently insecure as noted in [RFC5247].
	RADIUS/TLS supports multiple operation modes.		RADIUS/TLS supports multiple operation modes.
	skipping to change at page 7, line 36		skipping to change at page 8, line 4
	o Originating IP address		o Originating IP address
	o TLS Identifier		o TLS Identifier
	2.5. RADIUS Datagrams		2.5. RADIUS Datagrams
	Authentication, Accounting and Authorization packets are sent		Authentication, Accounting and Authorization packets are sent
	according to the following rules:		according to the following rules:
	RADIUS/TLS clients transmit the same packet types on the connection		RADIUS/TLS clients transmit the same packet types on the connection
	they initiated as a RADIUS/UDP client would (see Section 3.3 (3) and		they initiated as a RADIUS/UDP client would (see Section 3.4 (3) and
	(4) ). E.g. they send		(4) ). E.g. they send
	o Access-Request		o Access-Request
	o Accounting-Request		o Accounting-Request
	o Status-Server		o Status-Server
	o Disconnect-ACK		o Disconnect-ACK
	skipping to change at page 8, line 34		skipping to change at page 9, line 4
	o ...		o ...
	and they receive		and they receive
	o Access-Request		o Access-Request
	o Accounting-Request		o Accounting-Request
	o Status-Server		o Status-Server
	o Disconnect-ACK		o Disconnect-ACK
	o ...		o ...
	3. Informative: Design Decisions		3. Informative: Design Decisions
	This section explains the design decisions that led to the rules		This section explains the design decisions that led to the rules
	defined in the previous section.		defined in the previous section.
	3.1. X.509 Certificate Considerations		3.1. Implications of Dynamic Peer Discovery
			One mechanism to discover RADIUS over TLS peers dynamically via DNS
			is specified in [I-D.ietf-radext-dynamic-discovery]. While this
			mechanism is still under development and therefore is not a normative
			dependency of RADIUS/TLS, the use of dynamic discovery has potential
			future implications that are important to understand.
			Readers of this document who are considering the deployment of DNS-
			based dynamic discovery are thus encouraged to read
			[I-D.ietf-radext-dynamic-discovery] and follow its future
			development.
			3.2. X.509 Certificate Considerations
	(1) If a RADIUS/TLS client is in possession of multiple certificates		(1) If a RADIUS/TLS client is in possession of multiple certificates
	from different CAs (i.e. is part of multiple roaming consortia) and		from different CAs (i.e. is part of multiple roaming consortia) and
	dynamic discovery is used, the discovery mechanism possibly does not		dynamic discovery is used, the discovery mechanism possibly does not
	yield sufficient information to identify the consortium uniquely		yield sufficient information to identify the consortium uniquely
	(e.g. DNS discovery). Subsequently, the client may not know by		(e.g. DNS discovery). Subsequently, the client may not know by
	itself which client certificate to use for the TLS handshake. Then		itself which client certificate to use for the TLS handshake. Then
	it is necessary for the server to signal which consortium it belongs		it is necessary for the server to signal which consortium it belongs
	to, and which certificates it expects. If there is no risk of		to, and which certificates it expects. If there is no risk of
	confusing multiple roaming consortia, providing this information in		confusing multiple roaming consortia, providing this information in
	skipping to change at page 9, line 19		skipping to change at page 10, line 5
	(2) If a RADIUS/TLS server is in possession of multiple certificates		(2) If a RADIUS/TLS server is in possession of multiple certificates
	from different CAs (i.e. is part of multiple roaming consortia), it		from different CAs (i.e. is part of multiple roaming consortia), it
	will need to select one of its certificates to present to the RADIUS/		will need to select one of its certificates to present to the RADIUS/
	TLS client. If the client sends the Trusted CA Indication, this hint		TLS client. If the client sends the Trusted CA Indication, this hint
	can make the server select the appropriate certificate and prevent a		can make the server select the appropriate certificate and prevent a
	handshake failure. Omitting this indication makes it impossible to		handshake failure. Omitting this indication makes it impossible to
	deterministically select the right certificate in this case. If		deterministically select the right certificate in this case. If
	there is no risk of confusing multiple roaming consortia, providing		there is no risk of confusing multiple roaming consortia, providing
	this indication in the handshake is not crucial.		this indication in the handshake is not crucial.
	(3) If dynamic peer discovery as per		3.3. Ciphersuites and Compression Negotiation Considerations
	[I-D.ietf-radext-dynamic-discovery] is used, peer authentication
	alone is not sufficient; the peer must also be authorised to perform
	user authentications. In these cases, the trust fabric cannot depend
	on peer authentication methods like DNSSEC to identify RADIUS/TLS
	nodes. The nodes also need to be properly authorised. Typically,
	this can be achieved by adding appropriate authorisation fields into
	a X.509 certificate. Such fields include SRV authority [RFC4985],
	subjectAltNames, or a defined list of certificate fingerprints.
	Operators of a RADIUS/TLS infrastructure should define their own
	authorisation trust model and apply this model to the certificates.
	The checks enumerated in Section 2.3 provide sufficient flexibility
	for the implementation of authorisation trust models.
	3.2. Ciphersuites and Compression Negotiation Considerations
	Not all TLS ciphersuites in [RFC5246] are supported by available TLS		Not all TLS ciphersuites in [RFC5246] are supported by available TLS
	tool kits, and licenses may be required in some cases. The existing		tool kits, and licenses may be required in some cases. The existing
	implementations of RADIUS/TLS use OpenSSL as cryptographic backend,		implementations of RADIUS/TLS use OpenSSL as cryptographic backend,
	which supports all of the ciphersuites listed in the rules in the		which supports all of the ciphersuites listed in the rules in the
	normative section.		normative section.
	The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-		The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
	implement according to [RFC5246] and thus has to be supported by		implement according to [RFC5246] and thus has to be supported by
	RADIUS/TLS nodes.		RADIUS/TLS nodes.
	The two other ciphersuites in the normative section are widely		The two other ciphersuites in the normative section are widely
	implemented in TLS toolkits and are considered good practice to		implemented in TLS toolkits and are considered good practice to
	implement.		implement.
	3.3. RADIUS Datagram Considerations		3.4. RADIUS Datagram Considerations
	(1) After the TLS session is established, RADIUS packet payloads are		(1) After the TLS session is established, RADIUS packet payloads are
	exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet		exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet
	size can be determined by evaluating the size of the datagram that		size can be determined by evaluating the size of the datagram that
	arrived. Due to the stream nature of TCP and TLS, this does not hold		arrived. Due to the stream nature of TCP and TLS, this does not hold
	true for RADIUS/TLS packet exchange. Instead, packet boundaries of		true for RADIUS/TLS packet exchange. Instead, packet boundaries of
	RADIUS packets that arrive in the stream are calculated by evaluating		RADIUS packets that arrive in the stream are calculated by evaluating
	the packet's Length field. Special care needs to be taken on the		the packet's Length field. Special care needs to be taken on the
	packet sender side that the value of the Length field is indeed		packet sender side that the value of the Length field is indeed
	correct before sending it over the TLS tunnel, because incorrect		correct before sending it over the TLS tunnel, because incorrect
	skipping to change at page 10, line 47		skipping to change at page 11, line 14
	acceptable packet types for clients and servers mirror the packet		acceptable packet types for clients and servers mirror the packet
	flow behaviour from RADIUS/UDP.		flow behaviour from RADIUS/UDP.
	(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly		(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
	allocated UDP port to signal that a peer RADIUS server does not		allocated UDP port to signal that a peer RADIUS server does not
	support reception and processing of the packet types in [RFC5176].		support reception and processing of the packet types in [RFC5176].
	These packet types are listed as to be received in RADIUS/TLS		These packet types are listed as to be received in RADIUS/TLS
	implementations. Note well: it is not required for an implementation		implementations. Note well: it is not required for an implementation
	to actually process these packet types. It is sufficient that upon		to actually process these packet types. It is sufficient that upon
	receiving such a packet, an unconditional NAK is sent back to		receiving such a packet, an unconditional NAK is sent back to
	indicate that the action is not supported.		indicate that the action is not supported. The NAK SHOULD contain an
			attribute Error-Cause with the value 406 ("Unsupported Extension");
			see [RFC5176] for details.
	(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly		(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
	allocated UDP port to signal that a peer RADIUS server does not		allocated UDP port to signal that a peer RADIUS server does not
	support reception and processing of RADIUS Accounting packets. There		support reception and processing of RADIUS Accounting packets. There
	is no RADIUS datagram to signal an Accounting NAK. Clients may be		is no RADIUS datagram to signal an Accounting NAK. Clients may be
	misconfigured to send Accounting packets to a RADIUS/TLS server which		misconfigured to send Accounting packets to a RADIUS/TLS server which
	does not wish to process their Accounting packet. The server will		does not wish to process their Accounting packet. The server will
	need to silently drop the packet. The client will need to deduce		need to silently drop the packet. The client will need to deduce
	from the absence of replies that it is misconfigured; no negative		from the absence of replies that it is misconfigured; no negative
	ICMP response will reveal this.		ICMP response will reveal this.
	skipping to change at page 11, line 35		skipping to change at page 12, line 5
	transports, which is called a multi-stack implementation.		transports, which is called a multi-stack implementation.
	If a given IP device is able to receive RADIUS payloads on multiple		If a given IP device is able to receive RADIUS payloads on multiple
	transports, this may or may not be the same instance of software, and		transports, this may or may not be the same instance of software, and
	it may or may not serve the same purposes. It is not safe to assume		it may or may not serve the same purposes. It is not safe to assume
	that both ports are interchangeable. In particular, it can not be		that both ports are interchangeable. In particular, it can not be
	assumed that state is maintained for the packet payloads between the		assumed that state is maintained for the packet payloads between the
	transports. Two such instances MUST be considered separate RADIUS		transports. Two such instances MUST be considered separate RADIUS
	server entities.		server entities.
	As a consequence, the selection of transports to communicate from a
	client to a server is a manual administrative action. An automatic
	fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
	bidding attacks on the peer communication.
	5. Diameter Compatibility		5. Diameter Compatibility
	Since RADIUS/TLS is only a new transport profile for RADIUS,		Since RADIUS/TLS is only a new transport profile for RADIUS,
	compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP		compatibility of RADIUS/TLS - Diameter [RFC3588] vs. RADIUS/UDP
	[RFC2865] - Diameter [RFC3588] is identical. The considerations		[RFC2865] - Diameter [RFC3588] is identical. The considerations
	regarding payload size in [I-D.ietf-radext-tcp-transport] apply.		regarding payload size in [I-D.ietf-radext-tcp-transport] apply.
	6. Security Considerations		6. Security Considerations
	The computational resources to establish a TLS tunnel are		The computational resources to establish a TLS tunnel are
	significantly higher than simply sending mostly unencrypted UDP		significantly higher than simply sending mostly unencrypted UDP
	datagrams. Therefore, clients connecting to a RADIUS/TLS node will		datagrams. Therefore, clients connecting to a RADIUS/TLS node will
	more easily create high load conditions and a malicious client might		more easily create high load conditions and a malicious client might
	create a Denial-of-Service attack more easily.		create a Denial-of-Service attack more easily.
	In the case of dynamic peer discovery as per
	[I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
	able to accept connections from a large, not previously known, group
	of hosts, possibly the whole internet. In this case, the server's
	RADIUS/TLS port can not be protected from unauthorised connection
	attempts with measures on the network layer, i.e. access lists and
	firewalls. This opens more attack vectors for Distributed Denial of
	Service attacks, just like any other service that is supposed to
	serve arbitrary clients (like for example web servers).
	In the case of dynamic peer discovery as per
	[I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
	proof of authorisation for a connecting RADIUS/TLS nodes. Special
	care needs to be taken that certificates get verified properly
	according to the chosen trust model (particularly: consulting CRLs,
	checking critical extensions, checking subjectAltNames etc.) to
	prevent unauthorised connections.
	Some TLS ciphersuites only provide integrity validation of their		Some TLS ciphersuites only provide integrity validation of their
	payload, and provide no encryption. This specification forbids the		payload, and provide no encryption. This specification forbids the
	use of such ciphersuites. Since the RADIUS payload's shared secret		use of such ciphersuites. Since the RADIUS payload's shared secret
	is fixed to the well-known term "radsec" (see Section 2.3 (4) ) ,		is fixed to the well-known term "radsec" (see Section 2.3 (4) ) ,
	failure to comply with this requirement will expose the entire		failure to comply with this requirement will expose the entire
	datagram payload in plain text, including User-Password, to		datagram payload in plain text, including User-Password, to
	intermediate IP nodes.		intermediate IP nodes.
	If peer communication between two devices is configured for both		If peer communication between two devices is configured for both
	RADIUS/TLS and RADIUS/UDP, a failover from TLS security to classic		RADIUS/TLS transport (i.e TLS security on the transport layer, shared
	RADIUS security opens the way for a down-bidding attack if an		secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security
			with a secret manually configured by the administrator), and where
			the RADIUS/UDP transport is the failover option if the TLS session
			cannot be established, a down-bidding attack can occur if an
	adversary can maliciously close the TCP connection, or prevent it		adversary can maliciously close the TCP connection, or prevent it
	from being established. In this case, security of the packet payload		from being established. Situations where clients are configured in
	is reduced from the selected TLS cipher suite packet encryption to		such a way are likely to occur during a migration phase from RADIUS/
	the classic MD5 per-attribute encryption. Such an attack can be		UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker
	mitigated by delisting the RADIUS/UDP client from the server		can reduce the security of the packet payload from the selected TLS
	configuration after successfully migrating that client to RADIUS/TLS.		cipher suite packet encryption to the classic MD5 per-attribute
			encryption. The situation should be avoided by disabling the weaker
			RADIUS/UDP transport as soon as the new RADIUS/TLS transport is
			established and tested. Disabling can happen at either the RADIUS
			client or server side:
			o Client side: de-configure the failover setup, leaving RADIUS/TLS
			as the only communication option
			o Server side: de-configure the RADIUS/UDP client from the list of
			valid RADIUS clients
	The RADIUS/TLS transport provides authentication and encryption		The RADIUS/TLS transport provides authentication and encryption
	between RADIUS peers. In the presence of proxies, the intermediate		between RADIUS peers. In the presence of proxies, the intermediate
	proxies can still inspect the individual RADIUS packets, i.e. "end-		proxies can still inspect the individual RADIUS packets, i.e. "end-
	to-end" encryption is not provided. Where intermediate proxies are		to-end" encryption is not provided. Where intermediate proxies are
	untrusted, it is desirable to use other RADIUS mechanisms to prevent		untrusted, it is desirable to use other RADIUS mechanisms to prevent
	RADIUS packet payload from inspection by such proxies. One common		RADIUS packet payload from inspection by such proxies. One common
	method to protect passwords is the use of EAP methods which utilize		method to protect passwords is the use of EAP methods which utilize
	TLS.		TLS.
	7. IANA Considerations		7. IANA Considerations
	This document has no actions for IANA. The TCP port 2083 was already		No new RADIUS attributes or packet codes are defined. IANA is
	previously assigned by IANA for RadSec, an early implementation of		requested to update the already-assigned TCP port number 2083 in the
	RADIUS/TLS. No new RADIUS attributes or packet codes are defined.		following ways:
	8. Acknowledgements		o Reference: list the RFC number of this document as the reference
			o Assignment Notes: add the text "The TCP port 2083 was already
			previously assigned by IANA for "RadSec", an early implementation
			of RADIUS/TLS, prior to issuance of this RFC. This early
			implementation can be configured to be compatible to RADIUS/TLS as
			specified by the IETF. See RFC (RFC number of this document),
			Appendix A for details."
			8. Notes to the RFC Editor
			[I-D.ietf-radext-tcp-transport] is currently in the publication queue
			because it has a normative reference on this draft; it has no other
			blocking dependencies. The two drafts should be published as an RFC
			simultaneously, ideally with consequtive numbers. The references in
			this draft to [I-D.ietf-radext-tcp-transport] should be changed to
			references to the corresponding RFC prior to publication.
			This section, "Notes to the RFC Editor" should be deleted from the
			draft prior to publication.
			9. Acknowledgements
	RADIUS/TLS was first implemented as "RADSec" by Open Systems		RADIUS/TLS was first implemented as "RADSec" by Open Systems
	Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS		Consultants, Currumbin Waters, Australia, for their "Radiator" RADIUS
	server product (see [radsec-whitepaper]).		server product (see [radsec-whitepaper]).
	Funding and input for the development of this Internet Draft was		Funding and input for the development of this Internet Draft was
	provided by the European Commission co-funded project "GEANT2"		provided by the European Commission co-funded project "GEANT2"
	[geant2] and further feedback was provided by the TERENA Task Force		[geant2] and further feedback was provided by the TERENA Task Force
	Mobility [terena].		Mobility [terena].
	9. References		10. References
			10.1. Normative References
	9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use		[RFC2119] Bradner, S., "Key words for use
	in RFCs to Indicate Requirement		in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119,		Levels", BCP 14, RFC 2119,
	March 1997.		March 1997.
	[RFC2865] Rigney, C., Willens, S., Rubens,		[RFC2865] Rigney, C., Willens, S., Rubens,
	A., and W. Simpson, "Remote		A., and W. Simpson, "Remote
	Authentication Dial In User		Authentication Dial In User
	Service (RADIUS)", RFC 2865,		Service (RADIUS)", RFC 2865,
	skipping to change at page 13, line 52		skipping to change at page 14, line 32
	Transport Layer Security (TLS)",		Transport Layer Security (TLS)",
	RFC 4279, December 2005.		RFC 4279, December 2005.
	[RFC4785] Blumenthal, U. and P. Goel,		[RFC4785] Blumenthal, U. and P. Goel,
	"Pre-Shared Key (PSK)		"Pre-Shared Key (PSK)
	Ciphersuites with NULL		Ciphersuites with NULL
	Encryption for Transport Layer		Encryption for Transport Layer
	Security (TLS)", RFC 4785,		Security (TLS)", RFC 4785,
	January 2007.		January 2007.
	[RFC4985] Santesson, S., "Internet X.509
	Public Key Infrastructure
	Subject Alternative Name for
	Expression of Service Name",
	RFC 4985, August 2007.
	[RFC5280] Cooper, D., Santesson, S.,		[RFC5280] Cooper, D., Santesson, S.,
	Farrell, S., Boeyen, S.,		Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk,		Housley, R., and W. Polk,
	"Internet X.509 Public Key		"Internet X.509 Public Key
	Infrastructure Certificate and		Infrastructure Certificate and
	Certificate Revocation List		Certificate Revocation List
	(CRL) Profile", RFC 5280,		(CRL) Profile", RFC 5280,
	May 2008.		May 2008.
	[RFC5176] Chiba, M., Dommety, G., Eklund,		[RFC5176] Chiba, M., Dommety, G., Eklund,
	skipping to change at page 14, line 42		skipping to change at page 15, line 17
	Eronen, "Extensible		Eronen, "Extensible
	Authentication Protocol (EAP)		Authentication Protocol (EAP)
	Key Management Framework",		Key Management Framework",
	RFC 5247, August 2008.		RFC 5247, August 2008.
	[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr		[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr
	aft-ietf-radext-tcp-transport-09		aft-ietf-radext-tcp-transport-09
	(work in progress),		(work in progress),
	October 2010.		October 2010.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport		[I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport
	Layer for RADIUS",		Layer for RADIUS",
	draft-ietf-radext-dtls-01 (work		draft-ietf-radext-dtls-01 (work
	in progress), October 2010.		in progress), October 2010.
	[I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley,		[I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley,
	"NAI-based Dynamic Peer		"NAI-based Dynamic Peer
	Discovery for RADIUS/TLS and		Discovery for RADIUS/TLS and
	RADIUS/DTLS", draft-ietf-radext-		RADIUS/DTLS", draft-ietf-radext-
	dynamic-discovery-03 (work in		dynamic-discovery-03 (work in
	progress), July 2011.		progress), July 2011.
			[RFC3539] Aboba, B. and J. Wood,
			"Authentication, Authorization
			and Accounting (AAA) Transport
			Profile", RFC 3539, June 2003.
	[RFC3588] Calhoun, P., Loughney, J.,		[RFC3588] Calhoun, P., Loughney, J.,
	Guttman, E., Zorn, G., and J.		Guttman, E., Zorn, G., and J.
	Arkko, "Diameter Base Protocol",		Arkko, "Diameter Base Protocol",
	RFC 3588, September 2003.		RFC 3588, September 2003.
	[RFC4346] Dierks, T. and E. Rescorla, "The		[RFC4346] Dierks, T. and E. Rescorla, "The
	Transport Layer Security (TLS)		Transport Layer Security (TLS)
	Protocol Version 1.1", RFC 4346,		Protocol Version 1.1", RFC 4346,
	April 2006.		April 2006.
			[RFC6421] Nelson, D., "Crypto-Agility
			Requirements for Remote
			Authentication Dial-In User
			Service (RADIUS)", RFC 6421,
			November 2011.
	[radsec-whitepaper] Open System Consultants, "RadSec		[radsec-whitepaper] Open System Consultants, "RadSec
	- a secure, reliable RADIUS		- a secure, reliable RADIUS
	Protocol", May 2005, <http://		Protocol", May 2005, <http://
	www.open.com.au/radiator/		www.open.com.au/radiator/
	radsec-whitepaper.pdf>.		radsec-whitepaper.pdf>.
	[MD5-attacks] Black, J., Cochran, M., and T.		[MD5-attacks] Black, J., Cochran, M., and T.
	Highland, "A Study of the MD5		Highland, "A Study of the MD5
	Attacks: Insights and		Attacks: Insights and
	Improvements", October 2006, <ht		Improvements", October 2006, <ht
	skipping to change at page 16, line 23		skipping to change at page 17, line 8
	using the RadSec protocol.		using the RadSec protocol.
	The <ServerRADSEC> clause defines a RadSec server, and causes		The <ServerRADSEC> clause defines a RadSec server, and causes
	Radiator to listen on the configured port and address(es) for		Radiator to listen on the configured port and address(es) for
	connections from <Authby RADSEC> clients. When an <Authby RADSEC>		connections from <Authby RADSEC> clients. When an <Authby RADSEC>
	client connects to a <ServerRADSEC> server, the client sends RADIUS		client connects to a <ServerRADSEC> server, the client sends RADIUS
	requests through the stream to the server. The server then handles		requests through the stream to the server. The server then handles
	the request in the same way as if the request had been received from		the request in the same way as if the request had been received from
	a conventional UDP RADIUS client.		a conventional UDP RADIUS client.
	Radiator is compliant to version 2 of RadSec if the following options		Radiator is compliant to RADIUS/TLS if the following options are
	are used:		used:
	<AuthBy RADSEC>		<AuthBy RADSEC>
	* Protocol tcp		* Protocol tcp
	* UseTLS		* UseTLS
	* TLS_CertificateFile		* TLS_CertificateFile
	* Secret radsec		* Secret radsec
	skipping to change at page 18, line 11		skipping to change at page 18, line 46
	The proxy supports Status-Server messages. They are only sent to a		The proxy supports Status-Server messages. They are only sent to a
	server if enabled for that particular server. Status-Server requests		server if enabled for that particular server. Status-Server requests
	are always responded to.		are always responded to.
	This RadSec implementation has been successfully tested together with		This RadSec implementation has been successfully tested together with
	Radiator. It is a freely available open-source implementation. For		Radiator. It is a freely available open-source implementation. For
	source code and documentation, see [radsecproxy-impl].		source code and documentation, see [radsecproxy-impl].
	Appendix C. Assessment of Crypto-Agility Requirements		Appendix C. Assessment of Crypto-Agility Requirements
	The RADIUS Crypto-Agility Requirements (link to RFC once issued here)		The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous
	defines numerous classification criteria for protocols that strive to		classification criteria for protocols that strive to enhance the
	enhance the security of RADIUS. It contains mandatory (M) and		security of RADIUS. It contains mandatory (M) and recommended (R)
	recommended (R) criteria which crypto-agile protocols have to		criteria which crypto-agile protocols have to fulfill. The authors
	fulfill. The authors believe that the following assessment about the		believe that the following assessment about the crypto-agility
	crypto-agility properties of RADIUS/TLS are true.		properties of RADIUS/TLS are true.
	By virtue of operating on the transport layer with TLS, the		By virtue of operating on the transport layer with TLS, the
	cryptographically agile properties of TLS are inherited, and RADIUS/		cryptographically agile properties of TLS are inherited, and RADIUS/
	TLS subsequently meets the following points:		TLS subsequently meets the following points:
	(M) negotiation of cryptographic algorithms for integrity and auth		(M) negotiation of cryptographic algorithms for integrity and auth
	(M) negotiation of cryptographic algorithms for encryption		(M) negotiation of cryptographic algorithms for encryption
	(M) replay protection		(M) replay protection
	skipping to change at page 20, line 30		skipping to change at page 21, line 17
	9 Bulbul Place		9 Bulbul Place
	Currumbin Waters QLD 4223		Currumbin Waters QLD 4223
	AUSTRALIA		AUSTRALIA
	Phone: +61 7 5598 7474		Phone: +61 7 5598 7474
	Fax: +61 7 5598 7070		Fax: +61 7 5598 7070
	EMail: mikem@open.com.au		EMail: mikem@open.com.au
	URI: http://www.open.com.au.		URI: http://www.open.com.au.
	Stig Venaas		Stig Venaas
	UNINETT		cisco Systems
	Abels gate 5 - Teknobyen		Tasman Drive
	Trondheim 7465		San Jose, CA 95134
	NORWAY		USA
	Phone: +47 73 55 79 00		EMail: stig@cisco.com
	Fax: +47 73 55 79 01
	EMail: stig.venaas@uninett.no
	URI: http://www.uninett.no.
	Klaas Wierenga		Klaas Wierenga
	Cisco Systems International BV		Cisco Systems International BV
	Haarlerbergweg 13-19		Haarlerbergweg 13-19
	Amsterdam 1101 CH		Amsterdam 1101 CH
	The Netherlands		The Netherlands
	Phone: +31 (0)20 3571752		Phone: +31 (0)20 3571752
	Fax:		Fax:
	EMail: kwiereng@cisco.com		EMail: kwiereng@cisco.com
End of changes. 39 change blocks.
	111 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/