draft-ietf-radext-radsec-02.txt		draft-ietf-radext-radsec-03.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: April 27, 2009 OSC		Expires: August 15, 2009 OSC
	S. Venaas		S. Venaas
	UNINETT		UNINETT
	K. Wierenga		K. Wierenga
	Cisco		Cisco
	October 24, 2008		February 11, 2009
	TLS encryption for RADIUS over TCP (RadSec)		TLS encryption for RADIUS over TCP (RadSec)
	draft-ietf-radext-radsec-02		draft-ietf-radext-radsec-03
	Status of This Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 April 27, 2009.		This Internet-Draft will expire on August 15, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document.
	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 [RFC2865] when transmitted over TCP		RADIUS protocol [RFC2865] when transmitted over TCP
	[I-D.dekok-radext-tcp-transport]. This enables dynamic trust		[I-D.dekok-radext-tcp-transport]. This enables dynamic trust
	relationships between RADIUS servers.		relationships between RADIUS servers.
	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
	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 . . . . . . . . . . . . . . . . 6		3. Informative: Design Decisions . . . . . . . . . . . . . . . . 7
	3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 6		3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 7
	3.2. Ciphersuites and Compression Negotiation Considerations . 8		3.2. Ciphersuites and Compression Negotiation Considerations . 7
	3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8		3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 8
	4. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9		4. Compatibility with other RADIUS transports . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 12		9.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Appendix B. Implementation Overview: Radiator . . . . . . . . . . 13		Appendix A. DNS NAPTR Peer Discovery . . . . . . . . . . . . . . 13
	Appendix C. Implementation Overview: radsecproxy . . . . . . . . 14		Appendix B. Implementation Overview: Radiator . . . . . . . . . . 14
			Appendix C. Implementation Overview: radsecproxy . . . . . . . . 15
	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 4, line 35		skipping to change at page 4, line 35
	RadSec nodes		RadSec nodes
	1. establish TCP connections as per [I-D.dekok-radext-tcp-transport]		1. establish TCP connections as per [I-D.dekok-radext-tcp-transport]
	2. negotiate TLS sessions according to [RFC5246] or its predecessor		2. negotiate TLS sessions according to [RFC5246] or its predecessor
	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.
	* When using X.509 certificates, RadSec servers SHOULD indicate
	their acceptable Certification Authorities as per section
	7.4.4 of [RFC5246] (see Section 3.1 (1) )
	* When using X.509 certificates, the TLS Extension "Trusted CA
	Indication" from [RFC5246] or its TLS 1.1 predecessor SHOULD
	be used to indicate trusted CAs for the client (see
	Section 3.1 (2) )
	* When using X.509 certificates, certificate validation is
	performed as per [RFC5280] or its predecessor. The client MAY
	perform additional checks to accomodate for different trust
	models.
	* 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 cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be		* The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
	supported.		supported.
	* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and		* The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
	TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2		TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
	(1) )		(1) )
	3. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The		3. If TLS is used in an X.509 certificate based operation mode, the
			following list of certificate validation options applies:
			* Implementations MUST allow to configure a list of acceptable
			Certification Authorities for incoming connections.
			* Certificate validation MUST include the verification rules as
			per [RFC5280]. If an SRV entry is present in the certificate
			and dynamic discovery based on DNS is used, the SRV entry
			SHOULD be validated. refence x.y.z here.
			* Implementations SHOULD indicate their acceptable Certification
			Authorities as per section 7.4.4 (server side) and x.y.z
			["Trusted CA Indication"] (client side) of [RFC5246] (see
			Section 3.1 (1) )
			* Implementations SHOULD allow to configure a list of acceptable
			certificates, identified via certificate fingerprint.
			* Peer validation always includes a check on whether the DNS
			name or the IP address of the server that is contacted matches
			its certificate. DNS names and IP addresses can be contained
			in the Common Name (CN) or subjectAltName entries. For
			verification, only one these 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
			values for subjectAltName:URI.
			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
	Authentication, Accounting and Authorization packets are sent		Authentication, Accounting and Authorization packets are sent
	according to the following rules:		according to the following rules:
	RadSec clients handle the following packet types from [RFC2865],		RadSec clients handle the following packet types from [RFC2865],
	[RFC2866], [RFC5176] on the connection they initiated (see		[RFC2866], [RFC5176] on the connection they initiated (see
	skipping to change at page 6, line 44		skipping to change at page 7, line 18
	defined in the previous section.		defined in the previous section.
	3.1. X.509 Certificate Considerations		3.1. X.509 Certificate Considerations
	(1) If a RadSec client is in possession of multiple certificates from		(1) If a RadSec client is in possession of multiple certificates from
	different CAs (i.e. is part of multiple roaming consortia) and		different CAs (i.e. is part of multiple roaming consortia) and
	dynamic discovery is used, the discovery mechanism possibly does not		dynamic discovery is used, the discovery mechanism possibly does not
	yield sufficient information to identify the consortium uniquely		yield sufficient information to identify the consortium uniquely
	(e.g. DNS discovery). Subsequently, the client may not know by		(e.g. DNS discovery). Subsequently, the client may not know by
	itself which client certificate to use for the TLS handshake. Then		itself which client certificate to use for the TLS handshake. Then
	it is necessary to for the server to signal which consortium it		it is necessary for the server to signal which consortium it belongs
	belongs to, and which certificates it expects. If there is no risk		to, and which certificates it expects. If there is no risk of
	of confusing multiple roaming consortia, providing this information		confusing multiple roaming consortia, providing this information in
	in the handshake is not crucial.		the handshake is not crucial.
	(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.
	(3) When using X.509 certificate validation, peer validation always		(4) If dynamic peer discovery as per [I-D.winter-dynamic-discovery]
	includes a check on whether the DNS name or the IP address of the		is used, peer authentication alone is not sufficient; the peer must
	server that is contacted matches its certificate. When a RadSec peer		also be authorised to perform user authentications. In these cases,
	establishes a new connection (acts as a client) to another peer, the		the trust fabric cannot depend on peer authentication methods like
	following rules of precedence are used during validation:		DNSSEC to identify RadSec nodes. The RadSec nodes also need to be
			properly authorised. Typically, this can be achieved by adding
	o If the client expects a certain fully qualified domain name (FQDN)		appropriate authorisation fields into a X.509 certificate. Such
	and the presented certificate contains both at least one instance		fields include SRV authority (x.y.z... reference), subjectAltName:
	of the subjectAltName field with type dNSName and a Common Name,		URI, or a defined list of certificate fingerprints. Operators of a
	then the certificate is considered a match if any one of those		RadSec infrastructure should define their own authorisation trust
	subjectAltName fields matches the expected FQDN. The Common Name		model and apply this model to the certificates. The checks
	field is not evaluated in this case.		enumerated in Section 2.2 provide sufficient flexibility for the
			implementation of authorisation trust models.
	o If the client expects a certain fully qualified domain name (FQDN)
	and the presented certificate does not contain any subjectAltName
	field with type dNSName, then the certificate is considered a
	match if the Common Name field matches the expected FQDN.
	o If the client expects a certain IP address and the presented
	certificate contains both at least one instance of the
	subjectAltName field with type iPAddr and a Common Name, then the
	certificate is considered a match if any one of those
	subjectAltName fields matches the expected IP address. The Common
	Name field is not evaluated in this case.
	o If the client expects a certain IP address and the presented
	certificate does not contain any subjectAltName field with type
	iPAddr, then the certificate is considered a match if the Common
	Name field matches the expected IP address.
	(4) If dynamic peer resolution is used, the above verification steps
	may not be sufficient to ensure that a connecting peer is authorised
	to perform user authentications. In these cases, the trust fabric
	cannot depend on peer authentication methods like DNSSEC to identify
	RadSec nodes. The RadSec nodes also need to be properly authorised.
	Operators of a RadSec infrastructure should define their own
	authorisation trust model and apply this model to the certificates
	after they have passed the standard validity checks above. Current
	RadSec implementations offer varying degrees of versatility for
	defining criteria which certificates to accept.
	3.2. Ciphersuites and Compression Negotiation Considerations		3.2. Ciphersuites and Compression Negotiation Considerations
	RadSec implementations need not necessarily support all TLS		RadSec implementations need not necessarily support all TLS
	ciphersuites listed in [RFC5246]. Not all TLS ciphersuites		ciphersuites listed in [RFC5246]. Not all TLS ciphersuites
	are supported by available TLS tool kits and licenses may be required		are supported by available TLS tool kits and licenses may be required
	in some cases. The existing implementations of RadSec use OpenSSL as		in some cases. The existing implementations of RadSec use OpenSSL as
	cryptographic backend, which supports all of the ciphersuites listed		cryptographic backend, which supports all of the ciphersuites listed
	in the rules in the normative section.		in the rules in the normative section.
	The TLS cphersuite 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
	(TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are		(TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA) are
	widely implemented in TLS toolkits and are considered good practice		widely implemented in TLS toolkits and are considered good practice
	to implement.		to implement.
	TLS also supports compression. Compression is an optional		TLS also supports compression. Compression is an optional
	feature. During the RadSec conversation the client and server may		feature. During the RadSec conversation the client and server may
	skipping to change at page 9, line 22		skipping to change at page 9, line 16
	(4) RADIUS [RFC2865] used negative ICMP responses to a newly		(4) RADIUS [RFC2865] used 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 RadSec		These packet types are listed as to be received in RadSec
	implementations. Note well: it is not required for an implementation		implementations. Note well: it is not required for an implementation
	to actually process these packet types. It is sufficient that upon		to actually process these packet types. It is sufficient that upon
	receiving such a packet, an unconditional NAK is sent back to		receiving such a packet, an unconditional NAK is sent back to
	indicate that the action is not supported.		indicate that the action is not supported.
	4. Diameter Compatibility		4. Compatibility with other RADIUS transports
			Ongoing work in the IETF defines multiple alternative transports to
			the classic UDP transport model as defined in [RFC2865], namely
			RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS
			[I-D.dekok-radext-dtls] and the present document on RadSec.
			RadSec does not specify any inherent backwards compatibility to
			classic RADIUS or cross compatibility to the other transports, i.e.
			an implementation which implements RadSec only will not be able to
			receive or send RADIUS packet payloads over other transports. An
			implementation wishing to be backward or cross compatible (i.e.
			wishes to serve clients using other transports than RadSec) will need
			to implement the other transports and RadSec transport and be
			prepared to send and receive on all implemented transports, which is
			called a multi-stack implementation.
			If a given IP device is able to receive RADIUS payloads on multiple
			transports, this may or may not be the same instance of software, and
			it may or may not serve the same purposes. It is not safe to assume
			that both ports are interchangeable. In particular, it can not be
			assumed that state is maintained for the packet payloads between the
			transports. Two such instances MUST be considered separate RADIUS
			server entities.
			As a consequence, the selection of transports to communicate from a
			client to a server is a manual administrative action. An automatic
			fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to
			down-bidding attacks on the peer communication.
			5. Diameter Compatibility
	Since RadSec is only a new transport profile for RADIUS,		Since RadSec is only a new transport profile for RADIUS,
	compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] -		compatibility of RadSec - Diameter [RFC3588] vs. RADIUS [RFC2865] -
	Diameter [RFC3588] is identical. The considerations regarding		Diameter [RFC3588] is identical. The considerations regarding
	payload size in [I-D.dekok-radext-tcp-transport] apply.		payload size in [I-D.dekok-radext-tcp-transport] apply.
	5. 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 RadSec node will more		datagrams. Therefore, clients connecting to a RadSec node will more
	easily create high load conditions and a malicious client might		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, a RadSec node needs to be able		In the case of dynamic peer discovery as per
	to accept connections from a large, not previously known, group of		[I-D.winter-dynamic-discovery], a RadSec node needs to be able to
			accept connections from a large, not previously known, group of
	hosts, possibly the whole internet. In this case, the server's		hosts, possibly the whole internet. In this case, the server's
	RadSec port can not be protected from unauthorised connection		RadSec 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, X.509 certificates are the		In the case of dynamic peer discovery as per
	only proof of authorisation for a connecting RadSec nodes. Special		[I-D.winter-dynamic-discovery], X.509 certificates are the only proof
	care needs to be taken that certificates get verified properly		of authorisation for a connecting RadSec nodes. Special care needs
	according to the chosen trust model (particularly: consulting CRL		to be taken that certificates get verified properly according to the
	lists, checking critical extensions, checking subjectAltNames etc.)		chosen trust model (particularly: consulting CRLs, checking critical
	to prevent unauthorised connections.		extensions, checking subjectAltNames etc.) to prevent unauthorised
			connections.
	Some TLS ciphersuites only provide integrity validation of their		Some TLS ciphersuites only provide integrity validation of their
	payload, and provide no encryption. This specification forbids the		payload, and provide no encryption. This specification forbids the
	use of such ciphersuites. Since the RADIUS payload's shared secret		use of such ciphersuites. Since the RADIUS payload's shared secret
	is fixed and well-known, failure to comply with this requirement will		is fixed and well-known, failure to comply with this requirement will
	expose the entire datagram payload in plain text, including User-		expose the entire datagram payload in plain text, including User-
	Password, to intermediate IP nodes.		Password, to intermediate IP nodes.
	6. IANA Considerations		If peer communication between two devices is configured for both
			RadSec and classic RADIUS, a failover from RadSec to classic RADIUS
			opens the way for a down-bidding attack if an adversary can
			maliciously close the TCP connection, or prevent it from being
			established. In this case, security of the packet payload is reduced
			from the selected TLS cipher suite packet encryption to the classic
			MD5 per-attribute encryption.
			7. IANA Considerations
	This document has no actions for IANA. The TCP port 2083 was already		This document has no actions for IANA. The TCP port 2083 was already
	previously assigned by IANA for RadSec. No new RADIUS attributes or		previously assigned by IANA for RadSec. No new RADIUS attributes or
	packet codes are defined.		packet codes are defined.
	7. Acknowledgements		8. Acknowledgements
	RadSec version 1 was first implemented by Open Systems Consultants,		RadSec version 1 was first implemented by Open Systems Consultants,
	Currumbin Waters, Australia, for their "Radiator" RADIUS server		Currumbin Waters, Australia, for their "Radiator" RADIUS server
	product (see [radsec-whitepaper]).		product (see [radsec-whitepaper]).
	Funding and input for the development of this Internet Draft was		Funding and input for the development of this Internet Draft was
	provided by the European Commission co-funded project "GEANT2"		provided by the European Commission co-funded project "GEANT2"
	[geant2] and further feedback was provided by the TERENA Task Force		[geant2] and further feedback was provided by the TERENA Task Force
	Mobility [terena].		Mobility [terena].
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in		[RFC2119] Bradner, S., "Key words for use in
	RFCs to Indicate Requirement		RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119,		Levels", BCP 14, RFC 2119,
	March 1997.		March 1997.
	[RFC2865] Rigney, C., Willens, S., Rubens,		[RFC2865] Rigney, C., Willens, S., Rubens,
	A., and W. Simpson, "Remote		A., and W. Simpson, "Remote
	Authentication Dial In User Service		Authentication Dial In User Service
	(RADIUS)", RFC 2865, June 2000.		(RADIUS)", RFC 2865, June 2000.
	skipping to change at page 11, line 17		skipping to change at page 11, line 52
	Authorization Extensions to Remote		Authorization Extensions to Remote
	Authentication Dial In User Service		Authentication Dial In User Service
	(RADIUS)", RFC 5176, January 2008.		(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.
	[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",		[I-D.dekok-radext-tcp-transport] DeKok, A., "RADIUS Over TCP",
	draft-dekok-radext-tcp-transport-00		draft-dekok-radext-tcp-transport-01
	(work in progress), July 2008.		(work in progress), November 2008.
	8.2. Informative References		9.2. Informative References
			[I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport
			Layer for RADIUS",
			draft-dekok-radext-dtls-00 (work in
			progress), February 2007.
			[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery
			for RADIUS over TLD and DTLS",
			draft-winter-dynamic-discovery-00
			(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/
	skipping to change at page 12, line 25		skipping to change at page 13, line 21
	describes an algorithm to retrieve the RadSec route information from		describes an algorithm to retrieve the RadSec route information from
	the global DNS using NAPTR and SRV records. The input of the		the global DNS using NAPTR and SRV records. The input of the
	algorithm is the realm part of the user name.		algorithm is the realm part of the user name.
	The following algorithm is used to discover a target server from a		The following algorithm is used to discover a target server from a
	Realm using DNS:		Realm using DNS:
	1. Look for NAPTR records for the Realm. If found, continue at step		1. Look for NAPTR records for the Realm. If found, continue at step
	2, otherwise continue at step 4.		2, otherwise continue at step 4.
	2. For each NAPTR found record, examine the Service field and use		2. For each NAPTR record found, examine the Service field and use
	that to determine the transport protocol and TLS requirements for		that to determine the transport protocol and TLS requirements for
	the server. The Service field starts with 'AAA' for insecure and		the server. The Service field starts with 'AAA' for insecure and
	'AAAS' for TLS secured. The Service field contains '+RADSECS'		'AAAS' for TLS secured. The Service field contains '+RADSECS'
	for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS'		for RadSec over SCTP, '+RADSECT' for RadSec over TCP or '+RADIUS'
	for RADIUS protocol over UDP. The most common Service field you		for RADIUS protocol over UDP. The most common Service field you
	will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP.		will see will be 'AAAS+RADSECT' for TLS secured RadSec over TCP.
	3.		3.
	A. If the NAPTR has the 'S' flag, look for SRV records for the		A. If the NAPTR has the 'S' flag, look for SRV records for the
	skipping to change at page 13, line 20		skipping to change at page 14, line 18
	example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" ""		example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" ""
	_radsec._tcp.example.com.		_radsec._tcp.example.com.
	_radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com.		_radsec._tcp.example.com. IN SRV 0 10 2083 radsec.example.com.
	radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704		radsec.example.com. IN AAAA 2001:0DB8::202:44ff:fe0a:f704
	Then the target selected would be a RadSec server on port 2083 at		Then the target selected would be a RadSec server on port 2083 at
	IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be		IPv6 address 2001:0DB8::202:44ff:fe0a:f704. The connection would be
	made over TCP/IP, and TLS encryption would be used. This complete		made over TCP/IP, and TLS encryption would be used. This complete
	specification of the realm is the most flexible and is recommended.		specification of the realm is the most flexible one and is
			recommended.
	Appendix B. Implementation Overview: Radiator		Appendix B. 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.
	The <ServerRADSEC> clause defines a RadSec server, and causes		The <ServerRADSEC> clause defines a RadSec server, and causes
	Radiator to listen on the configured port and address(es) for		Radiator to listen on the configured port and address(es) for
	connections from <Authby RADSEC> clients. When an <Authby RADSEC>		connections from <Authby RADSEC> clients. When an <Authby RADSEC>
	client connects to a <ServerRADSEC> server, the client sends RADIUS		client connects to a <ServerRADSEC> server, the client sends RADIUS
	requests through the stream to the server. The server then services		requests through the stream to the server. The server then handles
	the request in the same was as if the request had been received from		the request in the same way as if the request had been received from
	a conventional UDP RADIUS client.		a conventional UDP RADIUS client.
	Radiator is compliant to version 2 of RadSec if the following options		Radiator is compliant to version 2 of RadSec if the following options
	are used:		are used:
	<AuthBy RADSEC>		<AuthBy RADSEC>
	* Protocol tcp		* Protocol tcp
	* UseTLS		* UseTLS
	* TLS_CertificateFile		* TLS_CertificateFile
	* Secret radsec
			* Secret radsec
	<ServerRADSEC>		<ServerRADSEC>
	* Protocol tcp		* Protocol tcp
	* UseTLS		* UseTLS
	* TLS_RequireClientCert		* TLS_RequireClientCert
	* Secret radsec		* Secret radsec
	skipping to change at page 17, line 4		skipping to change at line 768
	Klaas Wierenga		Klaas Wierenga
	Cisco Systems International BV		Cisco Systems International BV
	Haarlerbergweg 13-19		Haarlerbergweg 13-19
	Amsterdam 1101 CH		Amsterdam 1101 CH
	The Netherlands		The Netherlands
	Phone: +31 (0)20 3571752		Phone: +31 (0)20 3571752
	Fax:		Fax:
	EMail: kwiereng@cisco.com		EMail: kwiereng@cisco.com
	URI: http://www.cisco.com.		URI: http://www.cisco.com.
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgement
	This document was produced using xml2rfc v1.33 (of
	http://xml.resource.org/) from a source in RFC-2629 XML format.
End of changes. 29 change blocks.
	103 lines changed or deleted		157 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/