draft-ietf-radext-radsec-09.txt		draft-ietf-radext-radsec-10.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: January 9, 2012 OSC		Expires: July 12, 2012 OSC
	S. Venaas		S. Venaas
	UNINETT		UNINETT
	K. Wierenga		K. Wierenga
	Cisco		Cisco
	July 8, 2011		January 9, 2012
	TLS encryption for RADIUS		TLS encryption for RADIUS
	draft-ietf-radext-radsec-09		draft-ietf-radext-radsec-10
	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 37
	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 January 9, 2012.		This Internet-Draft will expire on July 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 43		skipping to change at page 2, line 43
	3.2. Ciphersuites and Compression Negotiation Considerations . 9		3.2. Ciphersuites and Compression Negotiation Considerations . 9
	3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 10		3.3. 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 . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Implementation Overview: Radiator . . . . . . . . . . 15		Appendix A. Implementation Overview: Radiator . . . . . . . . . . 16
	Appendix B. Implementation Overview: radsecproxy . . . . . . . . 16		Appendix B. Implementation Overview: radsecproxy . . . . . . . . 17
	Appendix C. Assessment of Crypto-Agility Requirements . . . . . . 17		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
	several shortcomings, such as its dependency on the unreliable		several shortcomings, such as its dependency on the unreliable
	transport protocol UDP and the lack of security for large parts of		transport protocol UDP and the lack of security for large parts of
	its packet payload. RADIUS security is based on the MD5 algorithm,		its packet payload. RADIUS security is based on the MD5 algorithm,
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	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 dynamic establishment of
	connections to peers that are not previously configured, and thus		connections to peers that are not previously configured, and thus
	makes it possible to avoid aggregation-only RADIUS proxies and reduce		makes it possible to avoid aggregation-only RADIUS proxies and reduce
	the number of middleboxes which can eavesdrop on traffic. One		the number of middleboxes which can eavesdrop on traffic. One
	mechanism to discover RADIUS over TLS peers with DNS is specified in		mechanism to discover RADIUS over TLS peers with DNS is specified in
	[I-D.winter-dynamic-discovery].		[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 9, line 19		skipping to change at page 9, line 19
	(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 [I-D.winter-dynamic-discovery]		(3) If dynamic peer discovery as per
	is used, peer authentication alone is not sufficient; the peer must		[I-D.ietf-radext-dynamic-discovery] is used, peer authentication
	also be authorised to perform user authentications. In these cases,		alone is not sufficient; the peer must also be authorised to perform
	the trust fabric cannot depend on peer authentication methods like		user authentications. In these cases, the trust fabric cannot depend
	DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be		on peer authentication methods like DNSSEC to identify RADIUS/TLS
	properly authorised. Typically, this can be achieved by adding		nodes. The nodes also need to be properly authorised. Typically,
	appropriate authorisation fields into a X.509 certificate. Such		this can be achieved by adding appropriate authorisation fields into
	fields include SRV authority [RFC4985], subjectAltNames, or a defined		a X.509 certificate. Such fields include SRV authority [RFC4985],
	list of certificate fingerprints. Operators of a RADIUS/TLS		subjectAltNames, or a defined list of certificate fingerprints.
	infrastructure should define their own authorisation trust model and		Operators of a RADIUS/TLS infrastructure should define their own
	apply this model to the certificates. The checks enumerated in		authorisation trust model and apply this model to the certificates.
	Section 2.3 provide sufficient flexibility for the implementation of		The checks enumerated in Section 2.3 provide sufficient flexibility
	authorisation trust models.		for the implementation of authorisation trust models.
	3.2. Ciphersuites and Compression Negotiation Considerations		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-
	skipping to change at page 12, line 8		skipping to change at page 12, line 8
	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		In the case of dynamic peer discovery as per
	[I-D.winter-dynamic-discovery], a RADIUS/TLS node needs to be able to		[I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
	accept connections from a large, not previously known, group of		able to accept connections from a large, not previously known, group
	hosts, possibly the whole internet. In this case, the server's		of hosts, possibly the whole internet. In this case, the server's
	RADIUS/TLS port can not be protected from unauthorised connection		RADIUS/TLS port can not be protected from unauthorised connection
	attempts with measures on the network layer, i.e. access lists and		attempts with measures on the network layer, i.e. access lists and
	firewalls. This opens more attack vectors for Distributed Denial of		firewalls. This opens more attack vectors for Distributed Denial of
	Service attacks, just like any other service that is supposed to		Service attacks, just like any other service that is supposed to
	serve arbitrary clients (like for example web servers).		serve arbitrary clients (like for example web servers).
	In the case of dynamic peer discovery as per		In the case of dynamic peer discovery as per
	[I-D.winter-dynamic-discovery], X.509 certificates are the only proof		[I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
	of authorisation for a connecting RADIUS/TLS nodes. Special care		proof of authorisation for a connecting RADIUS/TLS nodes. Special
	needs to be taken that certificates get verified properly according		care needs to be taken that certificates get verified properly
	to the chosen trust model (particularly: consulting CRLs, checking		according to the chosen trust model (particularly: consulting CRLs,
	critical extensions, checking subjectAltNames etc.) to prevent		checking critical extensions, checking subjectAltNames etc.) to
	unauthorised connections.		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 and well-known, failure to comply with this requirement will		is fixed to the well-known term "radsec" (see Section 2.3 (4) ) ,
	expose the entire datagram payload in plain text, including User-		failure to comply with this requirement will expose the entire
	Password, to intermediate IP nodes.		datagram payload in plain text, including User-Password, to
			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 and RADIUS/UDP, a failover from TLS security to classic
	RADIUS security opens the way for a down-bidding attack if an		RADIUS security opens the way for a down-bidding attack 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. In this case, security of the packet payload
	is reduced from the selected TLS cipher suite packet encryption to		is reduced from the selected TLS cipher suite packet encryption to
	the classic MD5 per-attribute encryption. Such an attack can be		the classic MD5 per-attribute encryption. Such an attack can be
	mitigated by delisting the RADIUS/UDP client from the server		mitigated by delisting the RADIUS/UDP client from the server
	configuration after successfully migrating that client to RADIUS/TLS.		configuration after successfully migrating that client to RADIUS/TLS.
	skipping to change at page 13, line 26		skipping to change at page 13, line 26
	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		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in		[RFC2119] Bradner, S., "Key words for use
	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, A.,		[RFC2865] Rigney, C., Willens, S., Rubens,
	and W. Simpson, "Remote		A., and W. Simpson, "Remote
	Authentication Dial In User Service		Authentication Dial In User
	(RADIUS)", RFC 2865, June 2000.		Service (RADIUS)", RFC 2865,
			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, "Pre-		[RFC4279] Eronen, P. and H. Tschofenig,
	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-		[RFC4785] Blumenthal, U. and P. Goel,
	Shared Key (PSK) Ciphersuites with		"Pre-Shared Key (PSK)
	NULL Encryption for Transport Layer		Ciphersuites with NULL
	Security (TLS)", RFC 4785,		Encryption for Transport Layer
	January 2007.		Security (TLS)", RFC 4785,
			January 2007.
	[RFC4985] Santesson, S., "Internet X.509		[RFC4985] Santesson, S., "Internet X.509
	Public Key Infrastructure Subject		Public Key Infrastructure
	Alternative Name for Expression of		Subject Alternative Name for
	Service Name", RFC 4985,		Expression of Service Name",
	August 2007.		RFC 4985, August 2007.
	[RFC5280] Cooper, D., Santesson, S., Farrell,		[RFC5280] Cooper, D., Santesson, S.,
	S., Boeyen, S., Housley, R., and W.		Farrell, S., Boeyen, S.,
	Polk, "Internet X.509 Public Key		Housley, R., and W. Polk,
	Infrastructure Certificate and		"Internet X.509 Public Key
	Certificate Revocation List (CRL)		Infrastructure Certificate and
	Profile", RFC 5280, May 2008.		Certificate Revocation List
			(CRL) Profile", RFC 5280,
			May 2008.
	[RFC5176] Chiba, M., Dommety, G., Eklund, M.,		[RFC5176] Chiba, M., Dommety, G., Eklund,
	Mitton, D., and B. Aboba, "Dynamic		M., Mitton, D., and B. Aboba,
	Authorization Extensions to Remote		"Dynamic Authorization
	Authentication Dial In User Service		Extensions to Remote
	(RADIUS)", RFC 5176, January 2008.		Authentication Dial In User
			Service (RADIUS)", RFC 5176,
			January 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The		[RFC5246] Dierks, T. and E. Rescorla, "The
	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. Eronen,		[RFC5247] Aboba, B., Simon, D., and P.
	"Extensible Authentication Protocol		Eronen, "Extensible
	(EAP) Key Management Framework",		Authentication Protocol (EAP)
	RFC 5247, August 2008.		Key Management Framework",
			RFC 5247, August 2008.
	[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",		[I-D.ietf-radext-tcp-transport] DeKok, A., "RADIUS Over TCP", dr
	draft-ietf-radext-tcp-transport-09		aft-ietf-radext-tcp-transport-09
	(work in progress), October 2010.		(work in progress),
			October 2010.
	9.2. Informative References		9.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 in		draft-ietf-radext-dtls-01 (work
	progress), October 2010.		in progress), October 2010.
	[I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI-		[I-D.ietf-radext-dynamic-discovery] Winter, S. and M. McCauley,
	based Dynamic Peer Discovery for		"NAI-based Dynamic Peer
	RADIUS over TLS and DTLS",		Discovery for RADIUS/TLS and
	draft-winter-dynamic-discovery-00		RADIUS/DTLS", draft-ietf-radext-
	(work in progress), February 2009.		dynamic-discovery-03 (work in
			progress), July 2011.
	[RFC3588] Calhoun, P., Loughney, J., Guttman,		[RFC3588] Calhoun, P., Loughney, J.,
	E., Zorn, G., and J. Arkko,		Guttman, E., Zorn, G., and J.
	"Diameter Base Protocol", RFC 3588,		Arkko, "Diameter Base Protocol",
	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.
	[radsec-whitepaper] Open System Consultants, "RadSec - a		[radsec-whitepaper] Open System Consultants, "RadSec
	secure, reliable RADIUS Protocol",		- a secure, reliable RADIUS
	May 2005, <http://www.open.com.au/		Protocol", May 2005, <http://
	radiator/radsec-whitepaper.pdf>.		www.open.com.au/radiator/
			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 Improvements",		Attacks: Insights and
	October 2006, <http://		Improvements", October 2006, <ht
	www.springerlink.com/content/		tp://www.springerlink.com/
	40867l85727r7084/>.		content/40867l85727r7084/>.
	[radsecproxy-impl] Venaas, S., "radsecproxy Project		[radsecproxy-impl] Venaas, S., "radsecproxy Project
	Homepage", 2007, <http://		Homepage", 2007, <http://
	software.uninett.no/radsecproxy/>.		software.uninett.no/
			radsecproxy/>.
	[eduroam] Trans-European Research and		[eduroam] Trans-European Research and
	Education Networking Association,		Education Networking
	"eduroam Homepage", 2007,		Association, "eduroam Homepage",
	<http://www.eduroam.org/>.		2007, <http://www.eduroam.org/>.
	[geant2] Delivery of Advanced Network		[geant2] Delivery of Advanced Network
	Technology to Europe, "European		Technology to Europe, "European
	Commission Information Society and		Commission Information Society
	Media: GEANT2", 2008,		and Media: GEANT2", 2008,
	<http://www.geant2.net/>.		<http://www.geant2.net/>.
	[terena] TERENA, "Trans-European Research and		[terena] TERENA, "Trans-European Research
	Education Networking Association",		and Education Networking
	2008, <http://www.terena.org/>.		Association", 2008,
			<http://www.terena.org/>.
	Appendix A. Implementation Overview: Radiator		Appendix A. Implementation Overview: Radiator
	Radiator implements the RadSec protocol for proxying requests with		Radiator implements the RadSec protocol for proxying requests with
	the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator		the <Authby RADSEC> and <ServerRADSEC> clauses in the Radiator
	configuration file.		configuration file.
	The <AuthBy RADSEC> clause defines a RadSec client, and causes		The <AuthBy RADSEC> clause defines a RadSec client, and causes
	Radiator to send RADIUS requests to the configured RadSec server		Radiator to send RADIUS requests to the configured RadSec server
	using the RadSec protocol.		using the RadSec protocol.
End of changes. 32 change blocks.
	122 lines changed or deleted		135 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/