draft-ietf-radext-radsec-04.txt		draft-ietf-radext-radsec-05.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: September 7, 2009 OSC		Expires: January 14, 2010 OSC
	S. Venaas		S. Venaas
	UNINETT		UNINETT
	K. Wierenga		K. Wierenga
	Cisco		Cisco
	March 06, 2009		July 13, 2009
	TLS encryption for RADIUS over TCP (RadSec)		TLS encryption for RADIUS over TCP (RadSec)
	draft-ietf-radext-radsec-04		draft-ietf-radext-radsec-05
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 1, line 47		skipping to change at page 1, line 47
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 7, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Normative: Transport Layer Security for RADIUS over TCP . . . 4		2. Normative: Transport Layer Security for RADIUS over TCP . . . 4
	2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4		2.1. TCP port and packet types . . . . . . . . . . . . . . . . 4
	2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4		2.2. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
	2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5		2.3. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 5
	3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7		3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7
	3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7		3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7
	3.2. Ciphersuites and Compression Negotiation Considerations . 8		3.2. Ciphersuites and Compression Negotiation Considerations . 8
	3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8		3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8
	4. Compatibility with other RADIUS transports . . . . . . . . . . 9		4. Compatibility with other RADIUS transports . . . . . . . . . . 9
	5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 10		5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13		Appendix A. Implementation Overview: Radiator . . . . . . . . . . 13
	Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14		Appendix B. Implementation Overview: radsecproxy . . . . . . . . 14
	1. Introduction		1. Introduction
	skipping to change at page 4, line 39		skipping to change at page 4, line 39
	TLS 1.1. The following restrictions apply:		TLS 1.1. The following restrictions apply:
	* The authentication MUST be mutual, i.e. both the RadSec server		* The authentication MUST be mutual, i.e. both the RadSec server
	and the RadSec client authenticate each other.		and the RadSec client authenticate each other.
	* The client MUST NOT negotiate cipher suites which only provide		* The client MUST NOT negotiate cipher suites which only provide
	integrity protection.		integrity protection.
	* The TLS session MAY use mutual PSKs for connection setup.		* The TLS session MAY use mutual PSKs for connection setup.
	* RADSEC implementations MUST support he mandatory to implement		* Negotiation of compression for the TLS session is OPTIONAL.
	cipher suites specified in TLS. For purposes of compatibility
			* RADSEC implementations MUST support the mandatory to implement
			cipher suites specified in TLS (i.e.
			TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility
	with some current deployments implementations SHOULD support		with some current deployments implementations SHOULD support
	TLS_RSA_WITH_RC4_128_SHA as well (see Section 3.2 (1) ).		TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
			well (see Section 3.2 (1) ).
	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]. If service names as per [RFC4985] are present		per [RFC5280]. If service names as per [RFC4985] are present
	in the certificate and dynamic discovery utilizing SRVs in DNS		in the certificate and dynamic discovery utilizing SRVs in DNS
	is used (see [I-D.winter-dynamic-discovery]), the SRV entry		is used (see [I-D.winter-dynamic-discovery]) and the TLS
	SHOULD be validated.		implementation supports evaluation of the extensions in
			[RFC4985], the SRV entry MUST be validated.
	* 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 (1) )		Section 3.1)
	* 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-
	1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D		1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
	* Peer validation always includes a check on whether the DNS		* Peer validation always includes a check on whether the locally
	name or the IP address of the server that is contacted matches		configured expected DNS name or IP address of the server that
	its certificate. DNS names and IP addresses can be contained		is contacted matches its presented certificate. DNS names and
	in the Common Name (CN) or subjectAltName entries. For		IP addresses can be contained in the Common Name (CN) or
	verification, only one these entries is to be considered. The		subjectAltName entries. For verification, only one these
	following precedence applies: for DNS name validation,		entries is to be considered. The following precedence
	subjectAltName:DNS has precedence over CN; for IP address		applies: for DNS name validation, subjectAltName:DNS has
	validation, subjectAltName:iPAddr has precedence over CN.		precedence over CN; for IP address validation, subjectAltName:
			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.3 (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.3 (2) ).
	2.3. RADIUS Datagrams		2.3. RADIUS Datagrams
	skipping to change at page 7, line 36		skipping to change at page 7, line 40
	(2) If a RadSec server is in possession of multiple certificates from		(2) If a RadSec server is in possession of multiple certificates from
	different CAs (i.e. is part of multiple roaming consortia), it will		different CAs (i.e. is part of multiple roaming consortia), it will
	need to select one of its certificates to present to the RadSec		need to select one of its certificates to present to the RadSec
	client. If the client sends the Trusted CA Indication, this hint can		client. If the client sends the Trusted CA Indication, this hint can
	make the server select the appropriate certificate and prevent a		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.
	(4) If dynamic peer discovery as per [I-D.winter-dynamic-discovery]		(3) If dynamic peer discovery as per [I-D.winter-dynamic-discovery]
	is used, peer authentication alone is not sufficient; the peer must		is used, peer authentication alone is not sufficient; the peer must
	also be authorised to perform user authentications. In these cases,		also be authorised to perform user authentications. In these cases,
	the trust fabric cannot depend on peer authentication methods like		the trust fabric cannot depend on peer authentication methods like
	DNSSEC to identify RadSec nodes. The RadSec nodes also need to be		DNSSEC to identify RadSec nodes. The RadSec nodes also need to be
	properly authorised. Typically, this can be achieved by adding		properly authorised. Typically, this can be achieved by adding
	appropriate authorisation fields into a X.509 certificate. Such		appropriate authorisation fields into a X.509 certificate. Such
	fields include SRV authority (x.y.z... reference), subjectAltName:		fields include SRV authority (x.y.z... reference), subjectAltName:
	URI, or a defined list of certificate fingerprints. Operators of a		URI, or a defined list of certificate fingerprints. Operators of a
	RadSec infrastructure should define their own authorisation trust		RadSec infrastructure should define their own authorisation trust
	model and apply this model to the certificates. The checks		model and apply this model to the certificates. The checks
	enumerated in Section 2.2 provide sufficient flexibility for the		enumerated in Section 2.2 provide sufficient flexibility for the
	implementation of authorisation trust models.		implementation of authorisation trust models.
	3.2. Ciphersuites and Compression Negotiation Considerations		3.2. Ciphersuites and Compression Negotiation Considerations
	RadSec implementations need not necessarily support all TLS		Not all TLS ciphersuites in [RFC5246] are supported by available TLS
	ciphersuites listed in [RFC5246]. Not all TLS ciphersuites		tool kits, and licenses may be required in some cases. The existing
	are supported by available TLS tool kits and licenses may be required		implementations of RadSec use OpenSSL as cryptographic backend, which
	in some cases. The existing implementations of RadSec use OpenSSL as		supports all of the ciphersuites listed in the rules in the normative
	cryptographic backend, which supports all of the ciphersuites listed		section.
	in the rules in the 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
	RadSec nodes.		RadSec nodes.
	The two other ciphersuites in the normative section		The two other ciphersuites in the normative section are widely
	(TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are		implemented in TLS toolkits and are considered good practice to
	widely implemented in TLS toolkits and are considered good practice		implement.
	to implement.
	TLS also supports compression. Compression is an optional
	feature. During the RadSec conversation the client and server may
	negotiate compression, but must continue the conversation even if the
	other peer rejects compression.
	3.3. RADIUS Datagram Considerations		3.3. 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 plain RADIUS, the packet		exchanged over the encrypted TLS tunnel. In plain RADIUS, 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 RadSec packet exchange. Instead, packet boundaries of		true for RadSec 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
	skipping to change at page 12, line 34		skipping to change at page 12, line 29
	draft-dekok-radext-tcp-transport-01		draft-dekok-radext-tcp-transport-01
	(work in progress), November 2008.		(work in progress), November 2008.
	9.2. Informative References		9.2. Informative References
	[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport		[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport
	Layer for RADIUS",		Layer for RADIUS",
	draft-dekok-radext-dtls-00 (work in		draft-dekok-radext-dtls-00 (work in
	progress), February 2007.		progress), February 2007.
	[I-D.winter-dynamic-discovery] Winter, S. and M. McCauley, "NAI-		[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery
	based Dynamic Peer Discovery for		for RADIUS over TLD and DTLS",
	RADIUS over TLS and DTLS",
	draft-winter-dynamic-discovery-00		draft-winter-dynamic-discovery-00
	(work in progress), February 2009.		(work in progress), February 2009.
	[RFC3588] Calhoun, P., Loughney, J., Guttman,		[RFC3588] Calhoun, P., Loughney, J., Guttman,
	E., Zorn, G., and J. Arkko,		E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588,		"Diameter Base Protocol", RFC 3588,
	September 2003.		September 2003.
	[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>.
	[radiator-manual] Open System Consultants, "Radiator
	Radius Server - Installation and
	Reference Manual", 2006, <http://
	www.open.com.au/radiator/ref.html>.
	[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 Association,
	"eduroam Homepage", 2007,		"eduroam Homepage", 2007,
	<http://www.eduroam.org/>.		<http://www.eduroam.org/>.
	[geant2] Delivery of Advanced Network		[geant2] Delivery of Advanced Network
	skipping to change at page 14, line 42		skipping to change at page 14, line 32
	that supports any number and combination of clients and servers,		that supports any number and combination of clients and servers,
	supporting RADIUS over UDP and RadSec. The main idea is that it can		supporting RADIUS over UDP and RadSec. The main idea is that it can
	be used on the same host as a non-RadSec client or server to ensure		be used on the same host as a non-RadSec client or server to ensure
	RadSec is used on the wire, however as a generic proxy it can be used		RadSec is used on the wire, however as a generic proxy it can be used
	in other circumstances as well.		in other circumstances as well.
	The configuration file consists of client and server clauses, where		The configuration file consists of client and server clauses, where
	there is one such clause for each client or server. In such a clause		there is one such clause for each client or server. In such a clause
	one specifies either "type tls" or "type udp" for RadSec or UDP		one specifies either "type tls" or "type udp" for RadSec or UDP
	transport. For RadSec the default shared secret "mysecret" (without		transport. For RadSec the default shared secret "mysecret" (without
	quotes), the same as Radiator, is used. A secret may be specified by		quotes), the same as Radiator, is used. For compliance with this
	putting say "secret somesharedsecret" inside a client or server		document, this setting needs to be configured for the shared secret
	clause.		"radsec". A secret may be specified by putting say "secret
			somesharedsecret" inside a client or server clause.
	In order to use TLS for clients and/or servers, one must also specify		In order to use TLS for clients and/or servers, one must also specify
	where to locate CA certificates, as well as certificate and key for		where to locate CA certificates, as well as certificate and key for
	the client or server. This is done in a TLS clause. There may be		the client or server. This is done in a TLS clause. There may be
	one or several TLS clauses. A client or server clause may reference		one or several TLS clauses. A client or server clause may reference
	a particular TLS clause, or just use a default one. One use for		a particular TLS clause, or just use a default one. One use for
	multiple TLS clauses may be to present one certificate to clients and		multiple TLS clauses may be to present one certificate to clients and
	another to servers.		another to servers.
	If any RadSec (TLS) clients are configured, the proxy will at startup		If any RadSec (TLS) clients are configured, the proxy will at startup
End of changes. 16 change blocks.
	46 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/