draft-ietf-radext-radsec-11.txt		draft-ietf-radext-radsec-12.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 30, 2012 OSC		Expires: August 17, 2012 OSC
	S. Venaas		S. Venaas
	K. Wierenga		K. Wierenga
	Cisco		Cisco
	January 27, 2012		February 14, 2012
	TLS encryption for RADIUS		Transport Layer Security (TLS) encryption for RADIUS
	draft-ietf-radext-radsec-11		draft-ietf-radext-radsec-12
	Abstract		Abstract
	This document specifies security on the transport layer (TLS) for the		This document specifies a transport profile for RADIUS using
	RADIUS protocol when transmitted over TCP. This enables dynamic		Transport Layer Security (TLS) over TCP as the transport protocol.
	trust relationships between RADIUS servers.		This enables dynamic 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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). 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 30, 2012.		This Internet-Draft will expire on August 17, 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 25
	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		1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4
	2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 4		2. Normative: Transport Layer Security for RADIUS/TCP . . . . . . 5
	2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4		2.1. TCP port and packet types . . . . . . . . . . . . . . . . 5
	2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4		2.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5		2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6		2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 7
	2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7		2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 8
	3. Informative: Design Decisions . . . . . . . . . . . . . . . . 9		3. Informative: Design Decisions . . . . . . . . . . . . . . . . 10
	3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 9		3.1. Implications of Dynamic Peer Discovery . . . . . . . . . . 10
	3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 9		3.2. X.509 Certificate Considerations . . . . . . . . . . . . . 10
	3.3. Ciphersuites and Compression Negotiation Considerations . 10		3.3. Ciphersuites and Compression Negotiation Considerations . 11
	3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10		3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . . 11
	4. Compatibility with other RADIUS transports . . . . . . . . . . 11		4. Compatibility with other RADIUS transports . . . . . . . . . . 12
	5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 12		5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 13		8. Notes to the RFC Editor . . . . . . . . . . . . . . . . . . . 15
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16		Appendix A. Implementation Overview: Radiator . . . . . . . . . . 18
	Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17		Appendix B. Implementation Overview: radsecproxy . . . . . . . . 19
	Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 18		Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 20
	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 Authentication, Authorization, and Accounting (AAA)
	several shortcomings, such as its dependency on the unreliable		solution. However, RADIUS is experiencing several shortcomings, such
	transport protocol UDP and the lack of security for large parts of		as its dependency on the unreliable transport protocol UDP and the
	its packet payload. RADIUS security is based on the MD5 algorithm,		lack of security for large parts of its packet payload. RADIUS
	which has been proven to be insecure.		security is based on the MD5 algorithm, which has been proven to be
			insecure.
	The main focus of RADIUS over TLS is to provide a means to secure the		The main focus of RADIUS over TLS is to provide a means to secure the
	communication between RADIUS/TCP peers on the transport layer. The		communication between RADIUS/TCP peers using TLS. The most important
	most important use of this specification lies in roaming environments		use of this specification lies in roaming environments where RADIUS
	where RADIUS packets need to be transferred through different		packets need to be transferred through different administrative
	administrative domains and untrusted, potentially hostile networks.		domains and untrusted, potentially hostile networks. An example for
	An example for a world-wide roaming environment that uses RADIUS over		a world-wide roaming environment that uses RADIUS over TLS to secure
	TLS to secure communication is "eduroam", see [eduroam].		communication is "eduroam", see [eduroam].
	There are multiple known attacks on the MD5 algorithm which is used		There are multiple known attacks on the MD5 algorithm which is used
	in RADIUS to provide integrity protection and a limited		in RADIUS to provide integrity protection and a limited
	confidentiality protection (see [MD5-attacks]). RADIUS over TLS		confidentiality protection (see [MD5-attacks]). RADIUS over TLS
	wraps the entire RADIUS packet payload into a TLS stream and thus		wraps the entire RADIUS packet payload into a TLS stream and thus
	mitigates the risk of attacks on MD5.		mitigates the risk of attacks on MD5.
	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
	skipping to change at page 4, line 27		skipping to change at page 4, line 27
	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 (see also Section 4). The		weaknesses of the RADIUS protocol (see also Section 4). The
	specification does not fulfill all recommendations on a AAA transport		specification does not fulfill all recommendations on a AAA transport
	profile as per [RFC3539]; in particular, by being based on TCP as a		profile as per [RFC3539]; in particular, by being based on TCP as a
	transport layer, it does not prevent head-of-line blocking issues.		transport layer, it does not prevent head-of-line blocking issues.
			If this specification is indeed selected for advancement to standards
			track, certificate verification options (section 2.3.2) need to be
			refined.
			Another experimental characteristic of this specification is the
			question of key management between RADIUS/TLS peers. RADIUS/UDP only
			allowed for manual key management, i.e. distribution of a shared
			secret between a client and a server. RADIUS/TLS allows manual
			distribution of long-term proofs of peer identity as well (by using
			TLS-PSK cipher suites, or identifying clients by a certificate
			fingerprint), but as a new feature enables use of X.509 certificates
			in a PKIX infrastructure. It remains to be seen if one of these
			methods prevail, or if both will find their place in real-life
			deployments. The authors can imagine pre-shared keys to be popular
			in small-scale deployments (SOHO or isolated enterprise deployments)
			where scalability is not an issue and the deployment of a CA is
			considered too much a hassle; but can also imagine large roaming
			consortia to make use of PKIX. Readers of this specification are
			encouraged to read the discussion of key management issus within
			[RFC6421] as well as [RFC4107].
	It has yet to be decided whether this approach is to be chosen for		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		standards track. One key aspect to judge whether the approach is
	usable at large scale is by observing the uptake, usability and		usable at large scale is by observing the uptake, usability and
	operational behaviour of the protocol in large-scale, real-life		operational behaviour of the protocol in large-scale, real-life
	deployments.		deployments.
	An example for a world-wide roaming environment that uses RADIUS over		An example for a world-wide roaming environment that uses RADIUS over
	TLS to secure communication is "eduroam", see [eduroam].		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.4 for considerations regarding separation of		section Section 3.4 for considerations regarding separation of
	authentication, accounting and dynauth traffic.		authentication, accounting and dynamic authorization 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
	skipping to change at page 5, line 21		skipping to change at page 5, line 40
	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 according to [RFC5246] or its predecessor TLS 1.1. The		sessions according to [RFC5246] or its predecessor TLS 1.1. The
	following restrictions apply:		following restrictions 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. To prevent known attacks on TLS
			versions prior to 1.1, implementations MUST NOT negotiate TLS
			versions prior to 1.1.
	* 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. Failure to comply
			with this requirement can lead to severe security problmes,
			like user passwords being recoverable by third parties. See
			Section 6 for details.
	* 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.3 (1) ).		TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.3 ).
	* 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		3. Peer authentication can be performed in any of the following
	encryption (e.g. [RFC4785]).		three operation models:
	3. If TLS is used in an X.509 certificate based operation mode, the		* TLS with X.509 certificates using PKIX trust models (this
	following list of certificate validation options applies:		model is mandatory to implement):
	* Implementations MUST allow to configure a list of acceptable		+ Implementations MUST allow to configure a list of trusted
	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
	per [RFC5280].		as per [RFC5280].
	* Implementations SHOULD indicate their acceptable Certification		+ Implementations SHOULD indicate their trusted Certification
	Authorities as per section 7.4.4 (server side) and x.y.z		Authorities (CAs). For TLS 1.2, this is done using
	["Trusted CA Indication"] (client side) of [RFC5246] (see		[RFC5246] section 7.4.4 "certificate authorities" (server
	Section 3.2)		side) and [RFC6066] Section 6 "Trusted CA Indication"
			(client side). See also Section 3.2.
	* Implementations SHOULD allow to configure a list of acceptable		+ Peer validation always includes a check on whether the
	certificates, identified via certificate fingerprint. When a		locally configured expected DNS name or IP address of the
	fingerprint configured, the fingerprint is prepended with an		server that is contacted matches its presented certificate.
	ASCII label identifying the hash function followed by a colon.		DNS names and IP addresses can be contained in the Common
	Implementations MUST support SHA-1 as the hash algorithm and		Name (CN) or subjectAltName entries. For verification,
	use the ASCII label "sha-1" to identify the SHA-1 algorithm.		only one of these entries is to be considered. The
	The length of a SHA-1 hash is 20 bytes and the length of the		following precedence applies: for DNS name validation,
	corresponding fingerprint string is 65 characters. An example		subjectAltName:DNS has precedence over CN; for IP address
	certificate fingerprint is: sha-		validation, subjectAltName:iPAddr has precedence over CN.
	1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D		Implementors of this specification are advised to read
			[RFC6125] Section 6 for more details on DNS name
			validation.
	* Peer validation always includes a check on whether the locally		+ Implementations MAY allow to configure a set of additional
	configured expected DNS name or IP address of the server that		properties of the certificate to check for a peer's
	is contacted matches its presented certificate. DNS names and		authorisation to communicate (e.g. a set of allowed values
	IP addresses can be contained in the Common Name (CN) or		in subjectAltName:URI or a set of allowed X509v3
	subjectAltName entries. For verification, only one of these		Certificate Policies)
	entries is to be considered. The following precedence
	applies: for DNS name validation, subjectAltName:DNS has
	precedence over CN; for IP address validation, subjectAltName:
	iPAddr has precedence over CN.
	* Implementations SHOULD allow to configure a set of acceptable		+ When the configured trust base changes (e.g. removal of a
	values for subjectAltName:URI.		CA from the list of trusted CAs; issuance of a new CRL for
			a given CA) implementations MAY re-negotiate the TLS
			session to re-assess the connecting peer's continued
			authorisation.
	4. start exchanging RADIUS datagrams. Note Section 3.4 (1) ). The		* TLS with X.509 certificates using certificate fingerprints
			(this model is optional to implement): Implementations SHOULD
			allow to configure a list of trusted certificates, identified
			via fingerprint of the DER encoded certificate octets.
			Implementations MUST support SHA-1 as the hash algorithm for
			the fingerprint. To prevent attacks based on hash collisions,
			support for a more contemporary hash function such as SHA-256
			is RECOMMENDED.
			* TLS using TLS-PSK (this model is optional to implement)
			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.4 (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.
	In TLS-PSK operation, a client is uniquely identified by its TLS		In TLS-PSK operation, a client is uniquely identified by its TLS
	identifier.		identifier.
	In TLS-X.509 mode using fingerprints, a client is uniquely identified		In TLS-X.509 mode using fingerprints, a client is uniquely identified
	by the fingerprint of the presented client certificate.		by the fingerprint of the presented client certificate.
	In TLS-X.509 with PKI infrastructure, a client is uniquely identified		In TLS-X.509 mode using PKIX trust models, a client is uniquely
	by the serial number of the tuple (presented client		identified by the tuple (serial number of presented client
	certificate;Issuer).		certificate;Issuer).
	Note well: having identified a connecting entity does not mean the		Note well: having identified a connecting entity does not mean the
	server necessarily wants to communicate with that client. E.g. if		server necessarily wants to communicate with that client. E.g. if
	the Issuer is not in a trusted set of Issuers, the server may decline		the Issuer is not in a trusted set of Issuers, the server may decline
	to perform RADIUS transactions with this client.		to perform RADIUS transactions with this client.
	There are numerous trust models in PKI environments, and it is beyond		There are numerous trust models in PKIX environments, and it is
	the scope of this document to define how a particular deployment		beyond the scope of this document to define how a particular
	determines whether a client is trustworthy. Implementations which		deployment determines whether a client is trustworthy.
	want to support a wide variety of trust models should expose as many		Implementations which want to support a wide variety of trust models
	details of the presented certificate to the administrator as possible		should expose as many details of the presented certificate to the
	so that the trust model can be implemented by the administrator. As		administrator as possible so that the trust model can be implemented
	a suggestion, at least the following parameters of the X.509 client		by the administrator. As a suggestion, at least the following
	certificate should be exposed:		parameters of the X.509 client certificate should be exposed:
	o Originating IP address		o Originating IP address
	o Certificate Fingerprint		o Certificate Fingerprint
	o Issuer		o Issuer
	o Subject		o Subject
	o all X509v3 Extended Key Usage		o all X509v3 Extended Key Usage
	skipping to change at page 9, line 4		skipping to change at page 9, line 44
	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 ...
			Due to the use of one single TCP port for all packet types, it is
			required for a RADIUS/TLS server to signal to a connecting peer which
			types of packets are supported on a server. See also section
			Section 3.4 for a discussion of signaling.
			o When receiving an unwanted packet of type 'CoA-Request' or
			'Disconnect-Request', it needs to be replied to with a 'CoA-NAK'
			or 'Disconnect-NAK' respectively. The NAK SHOULD contain an
			attribute Error-Cause with the value 406 ("Unsupported
			Extension"); see [RFC5176] for details.
			o When receiving an unwanted packet of type 'Accounting-Request',
			the RADIUS/TLS server SHOULD reply with an Accounting-Response
			containing an Error-Cause attribute with value 406 "Unsupported
			Extension" as defined in [RFC5176]. A RADIUS/TLS accounting
			client receiving such an Accounting-Response SHOULD log the error
			and stop sending Accounting-Request packets.
	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. Implications of Dynamic Peer Discovery		3.1. Implications of Dynamic Peer Discovery
	One mechanism to discover RADIUS over TLS peers dynamically via DNS		One mechanism to discover RADIUS over TLS peers dynamically via DNS
	is specified in [I-D.ietf-radext-dynamic-discovery]. While this		is specified in [I-D.ietf-radext-dynamic-discovery]. While this
	mechanism is still under development and therefore is not a normative		mechanism is still under development and therefore is not a normative
	skipping to change at page 10, line 14		skipping to change at page 11, line 21
	3.3. Ciphersuites and Compression Negotiation Considerations		3.3. 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 [RFC4346] 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.4. 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
	skipping to change at page 11, line 12		skipping to change at page 12, line 20
	of a server which receives requests, processes them and sends the		of a server which receives requests, processes them and sends the
	appropriate replies is to be preserved. The normative rules about		appropriate replies is to be preserved. The normative rules about
	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 only required to send
	receiving such a packet, an unconditional NAK is sent back to		the NAK as defined above.
	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. To prevent a
	need to silently drop the packet. The client will need to deduce		regression of detectability of this situation, the Accounting-
	from the absence of replies that it is misconfigured; no negative		Response + Error-Cause sgnaling was introduced.
	ICMP response will reveal this.
	4. Compatibility with other RADIUS transports		4. Compatibility with other RADIUS transports
	Ongoing work in the IETF defines multiple alternative transports to		Ongoing work in the IETF defines multiple alternative transports to
	the classic UDP transport model as defined in [RFC2865], namely		the classic UDP transport model as defined in [RFC2865], namely
	RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over DTLS		RADIUS over TCP [I-D.ietf-radext-tcp-transport], RADIUS over Datagram
	[I-D.ietf-radext-dtls] and this present document on RADIUS over TLS.		Transport Layer Security (DTLS) [I-D.ietf-radext-dtls] and this
			present document on RADIUS over TLS.
	RADIUS/TLS does not specify any inherent backwards compatibility to		RADIUS/TLS does not specify any inherent backwards compatibility to
	RADIUS/UDP or cross compatibility to the other transports, i.e. an		RADIUS/UDP or cross compatibility to the other transports, i.e. an
	implementation which implements RADIUS/TLS only will not be able to		implementation which implements RADIUS/TLS only will not be able to
	receive or send RADIUS packet payloads over other transports. An		receive or send RADIUS packet payloads over other transports. An
	implementation wishing to be backward or cross compatible (i.e.		implementation wishing to be backward or cross compatible (i.e.
	wishes to serve clients using other transports than RADIUS/TLS) will		wishes to serve clients using other transports than RADIUS/TLS) will
	need to implement these other transports along with the RADIUS/TLS		need to implement these other transports along with the RADIUS/TLS
	transport and be prepared to send and receive on all implemented		transport and be prepared to send and receive on all implemented
	transports, which is called a multi-stack implementation.		transports, which is called a multi-stack implementation.
	skipping to change at page 12, line 28		skipping to change at page 13, line 32
	create a Denial-of-Service attack more easily.		create a Denial-of-Service attack more easily.
	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		By virtue of being based on TCP, there are several generic attack
	RADIUS/TLS transport (i.e TLS security on the transport layer, shared		vectors to slow down or prevent the TCP connection from being
			established; see [RFC4953] for details. If a TCP connection is not
			up when a packet is to be processed, it gets re-established, so such
			attacks in general lead only to a minor performance degradation (the
			time it takes to re-establish the connection). There is one notable
			exception where an attacker might create a bidding-down attack
			though: If peer communication between two devices is configured for
			both RADIUS/TLS (i.e TLS security over TCP as a transport, shared
	secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security		secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security
	with a secret manually configured by the administrator), and where		with a secret manually configured by the administrator), and where
	the RADIUS/UDP transport is the failover option if the TLS session		the RADIUS/UDP transport is the failover option if the TLS session
	cannot be established, a down-bidding attack can occur if an		cannot be established, a bidding-down 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. Situations where clients are configured in		from being established. Situations where clients are configured in
	such a way are likely to occur during a migration phase from RADIUS/		such a way are likely to occur during a migration phase from RADIUS/
	UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker		UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker
	can reduce the security of the packet payload from the selected TLS		can reduce the security of the packet payload from the selected TLS
	cipher suite packet encryption to the classic MD5 per-attribute		cipher suite packet encryption to the classic MD5 per-attribute
	encryption. The situation should be avoided by disabling the weaker		encryption. The situation should be avoided by disabling the weaker
	RADIUS/UDP transport as soon as the new RADIUS/TLS transport is		RADIUS/UDP transport as soon as the new RADIUS/TLS connection is
	established and tested. Disabling can happen at either the RADIUS		established and tested. Disabling can happen at either the RADIUS
	client or server side:		client or server side:
	o Client side: de-configure the failover setup, leaving RADIUS/TLS		o Client side: de-configure the failover setup, leaving RADIUS/TLS
	as the only communication option		as the only communication option
	o Server side: de-configure the RADIUS/UDP client from the list of		o Server side: de-configure the RADIUS/UDP client from the list of
	valid RADIUS clients		valid RADIUS clients
	The RADIUS/TLS transport provides authentication and encryption		RADIUS/TLS provides authentication and encryption between RADIUS
	between RADIUS peers. In the presence of proxies, the intermediate		peers. In the presence of proxies, the intermediate proxies can
	proxies can still inspect the individual RADIUS packets, i.e. "end-		still inspect the individual RADIUS packets, i.e. "end-to-end"
	to-end" encryption is not provided. Where intermediate proxies are		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 the Extensible
	TLS.		Authentication Protocol (EAP) and EAP methods which utilize TLS.
			When using certificate fingerprints to identify RADIUS/TLS peers, any
			two certificates which produce the same hash value (i.e. which have a
			hash collision) will be considered the same client. It is therefore
			important to make sure that the hash function used is
			cryptographically uncompromised so that an attacker is very unlikely
			to be able to produce a hash collision with a certificate of his
			choice. While this specification mandates support for SHA-1, a later
			revision will likely demand support for more contemporary hash
			functions because as of issuance of this document there are already
			attacks on SHA-1.
	7. IANA Considerations		7. 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 TCP port number 2083 in the		requested to update the already-assigned TCP port number 2083 in the
	following ways:		following ways:
	o Reference: list the RFC number of this document as the reference		o Reference: list the RFC number of this document as the reference
	o Assignment Notes: add the text "The TCP port 2083 was already		o Assignment Notes: add the text "The TCP port 2083 was already
	skipping to change at page 14, line 25		skipping to change at page 15, line 51
	June 2000.		June 2000.
	[RFC2866] Rigney, C., "RADIUS Accounting",		[RFC2866] Rigney, C., "RADIUS Accounting",
	RFC 2866, June 2000.		RFC 2866, June 2000.
	[RFC4279] Eronen, P. and H. Tschofenig,		[RFC4279] Eronen, P. and H. Tschofenig,
	"Pre-Shared Key Ciphersuites for		"Pre-Shared Key Ciphersuites for
	Transport Layer Security (TLS)",		Transport Layer Security (TLS)",
	RFC 4279, December 2005.		RFC 4279, December 2005.
	[RFC4785] Blumenthal, U. and P. Goel,
	"Pre-Shared Key (PSK)
	Ciphersuites with NULL
	Encryption for Transport Layer
	Security (TLS)", RFC 4785,
	January 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 15, line 12		skipping to change at page 16, line 30
	Transport Layer Security (TLS)		Transport Layer Security (TLS)
	Protocol Version 1.2", RFC 5246,		Protocol Version 1.2", RFC 5246,
	August 2008.		August 2008.
	[RFC5247] Aboba, B., Simon, D., and P.		[RFC5247] Aboba, B., Simon, D., and P.
	Eronen, "Extensible		Eronen, "Extensible
	Authentication Protocol (EAP)		Authentication Protocol (EAP)
	Key Management Framework",		Key Management Framework",
	RFC 5247, August 2008.		RFC 5247, August 2008.
			[RFC6066] Eastlake, D., "Transport Layer
			Security (TLS) Extensions:
			Extension Definitions",
			RFC 6066, January 2011.
	[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.
	10.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
	skipping to change at page 15, line 41		skipping to change at page 17, line 16
	[RFC3539] Aboba, B. and J. Wood,		[RFC3539] Aboba, B. and J. Wood,
	"Authentication, Authorization		"Authentication, Authorization
	and Accounting (AAA) Transport		and Accounting (AAA) Transport
	Profile", RFC 3539, June 2003.		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.
			[RFC4107] Bellovin, S. and R. Housley,
			"Guidelines for Cryptographic
			Key Management", BCP 107,
			RFC 4107, June 2005.
	[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.
			[RFC4953] Touch, J., "Defending TCP
			Against Spoofing Attacks",
			RFC 4953, July 2007.
			[RFC6125] Saint-Andre, P. and J. Hodges,
			"Representation and Verification
			of Domain-Based Application
			Service Identity within Internet
			Public Key Infrastructure Using
			X.509 (PKIX) Certificates in the
			Context of Transport Layer
			Security (TLS)", RFC 6125,
			March 2011.
	[RFC6421] Nelson, D., "Crypto-Agility		[RFC6421] Nelson, D., "Crypto-Agility
	Requirements for Remote		Requirements for Remote
	Authentication Dial-In User		Authentication Dial-In User
	Service (RADIUS)", RFC 6421,		Service (RADIUS)", RFC 6421,
	November 2011.		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/
	skipping to change at page 19, line 5		skipping to change at page 20, line 46
	Appendix C. Assessment of Crypto-Agility Requirements		Appendix C. Assessment of Crypto-Agility Requirements
	The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous		The RADIUS Crypto-Agility Requirements [RFC6421] defines numerous
	classification criteria for protocols that strive to enhance the		classification criteria for protocols that strive to enhance the
	security of RADIUS. It contains mandatory (M) and recommended (R)		security of RADIUS. It contains mandatory (M) and recommended (R)
	criteria which crypto-agile protocols have to fulfill. The authors		criteria which crypto-agile protocols have to fulfill. The authors
	believe that the following assessment about the crypto-agility		believe that the following assessment about the 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 being a transport profile using TLS over TCP as a
	cryptographically agile properties of TLS are inherited, and RADIUS/		transport protocol, the cryptographically agile properties of TLS are
	TLS subsequently meets the following points:		inherited, and RADIUS/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
	(M) define mandatory-to-implement cryptographic algorithms		(M) define mandatory-to-implement cryptographic algorithms
	(M) generate fresh session keys for use between client and server		(M) generate fresh session keys for use between client and server
	(R) support for Perfect Forward Secrecy in session keys		(R) support for Perfect Forward Secrecy in session keys
End of changes. 42 change blocks.
	122 lines changed or deleted		212 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/