draft-ietf-radext-radsec-06.txt		draft-ietf-radext-radsec-07.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 6, 2010 OSC		Expires: January 13, 2011 OSC
	S. Venaas		S. Venaas
	UNINETT		UNINETT
	K. Wierenga		K. Wierenga
	Cisco		Cisco
	March 05, 2010		July 12, 2010
	TLS encryption for RADIUS		TLS encryption for RADIUS
	draft-ietf-radext-radsec-06		draft-ietf-radext-radsec-07
	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 to IETF 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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 6, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 34		skipping to change at page 2, line 27
	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
	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. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Connecting Client Identity . . . . . . . . . . . . . . . . 6		2.3. Connection Setup . . . . . . . . . . . . . . . . . . . . . 4
	2.4. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7		2.4. Connecting Client Identity . . . . . . . . . . . . . . . . 6
			2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . . 7
	3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8		3. Informative: Design Decisions . . . . . . . . . . . . . . . . 8
	3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8		3.1. X.509 Certificate Considerations . . . . . . . . . . . . . 8
	3.2. Ciphersuites and Compression Negotiation Considerations . 9		3.2. Ciphersuites and Compression Negotiation Considerations . 9
	3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9		3.3. RADIUS Datagram Considerations . . . . . . . . . . . . . . 9
	4. Compatibility with other RADIUS transports . . . . . . . . . . 10		4. Compatibility with other RADIUS transports . . . . . . . . . . 10
	5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11		5. Diameter Compatibility . . . . . . . . . . . . . . . . . . . . 11
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 26		skipping to change at page 3, line 26
	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 on the transport layer. The
	most important use of this specification lies in roaming environments		most important use of this specification lies in roaming environments
	where RADIUS packets need to be transferred through different		where RADIUS packets need to be transferred through different
	administrative domains and untrusted, potentially hostile networks.		administrative domains and untrusted, potentially hostile networks.
	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].
	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. RADIUS over TLS wraps the entire RADIUS		confidentiality protection (see [MD5-attacks]). RADIUS over TLS
	packet payload into a TLS stream and thus mitigates the risk of		wraps the entire RADIUS packet payload into a TLS stream and thus
	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
	administrative entities is to introduce some form of a proxy chain to		administrative entities is to introduce some form of a proxy chain to
	route the access requests to their home server. This creates a lot		route the access requests to their home server. This creates a lot
	of overhead in terms of possible points of failure, longer		of overhead in terms of possible points of failure, longer
	transmission times as well as middleboxes through which		transmission times as well as middleboxes through which
	authentication traffic flows. These middleboxes may learn privacy-		authentication traffic flows. These middleboxes may learn privacy-
	relevant data while forwarding requests. The new features in RADIUS		relevant data while forwarding requests. The new features in RADIUS
	over TLS obsolete the use of IP addresses and shared MD5 secrets to		over TLS obsolete the use of IP addresses and shared MD5 secrets to
	identify other peers and thus allow the dynamic establishment of		identify other peers and thus allow the 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 intermediate aggregation proxies. One		makes it possible to avoid aggregation-only RADIUS proxies and reduce
			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.winter-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", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" in this document are to be interpreted as described in		and "OPTIONAL" in this document are to be interpreted as described in
	RFC 2119. [RFC2119]		RFC 2119. [RFC2119]
	skipping to change at page 4, line 25		skipping to change at page 4, line 26
	RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865]		RADIUS/UDP: classic RADIUS transport over UDP as defined in [RFC2865]
	2. Normative: Transport Layer Security for RADIUS over TCP		2. Normative: Transport Layer Security for RADIUS over 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.		dynamic authorisation changes. The source port is arbitrary.
	2.2. Connection Setup		2.2. TLS negotiation
			RADIUS has no notion of negotiating TLS in an established connection.
			Servers and clients need to be preconfigured to use RADIUS/TLS for a
			given endpoint.
			2.3. Connection Setup
	RADIUS/TLS nodes		RADIUS/TLS 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. immediately negotiate TLS sessions. The following restrictions
	TLS 1.1. The following restrictions apply:		apply: according to [RFC5246] or its predecessor TLS 1.1. The
			following restrictions apply:
	* The authentication MUST be mutual, i.e. both the RADIUS/TLS		* Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2
	server and the RADIUS/TLS client authenticate each other.		[RFC5246]]) is REQUIRED.
	* The client MUST NOT negotiate cipher suites which only provide		* Support for certificate-based mutual authentication is
	integrity protection.		REQUIRED.
	* The TLS session MAY use mutual PSKs for connection setup.		* Negotiation of mutual authentication is REQUIRED.
	* Negotiation of compression for the TLS session is OPTIONAL.		* Negotiation of a ciphersuite providing for confidentiality as
			well as integrity protection is REQUIRED.
	* RADIUS/TLS implementations MUST support the mandatory to		* Support for and negotiation of compression is OPTIONAL.
	implement cipher suites specified in TLS (i.e.
	TLS_RSA_WITH_3DES_EDE_CBC_SHA). For purposes of compatibility		* Support for TLS-PSK mutual authentication [RFC4279] is
	with some current deployments implementations SHOULD support		OPTIONAL.
	TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
	well (see Section 3.2 (1) ).		* RADIUS/TLS implementations MUST at a minimum support
			negotiation of the TLS_RSA_WITH_3DES_EDE_CBC_SHA), and SHOULD
			support TLS_RSA_WITH_RC4_128_SHA and
			TLS_RSA_WITH_AES_128_CBC_SHA as well (see Section 3.2 (1) ).
			* In addition, RADIUS/TLS implementations MUST support
			negotiation of the mandatory-to-implement ciphersuites
			required by the versions of TLS that they support.
	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], using information from trusted sources only		per [RFC5280].
	(e.g. locally configured names). If service names as per
	[RFC4985] are present in the certificate and dynamic discovery
	utilizing SRVs in DNS is used (see
	[I-D.winter-dynamic-discovery]) and the TLS implementation
	supports evaluation of the extensions in [RFC4985], the SRV
	entry MUST be validated. In cases where no DNS SRV resolution
	took place to arrive at the TLS peer, subjectAltName:SRV
	entries can be ignored.
	* Implementations SHOULD indicate their acceptable Certification		* Implementations SHOULD indicate their acceptable Certification
	Authorities as per section 7.4.4 (server side) and x.y.z		Authorities as per section 7.4.4 (server side) and x.y.z
	["Trusted CA Indication"] (client side) of [RFC5246] (see		["Trusted CA Indication"] (client side) of [RFC5246] (see
	Section 3.1)		Section 3.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.
	skipping to change at page 6, line 9		skipping to change at page 6, line 12
	precedence over CN; for IP address validation, subjectAltName:		precedence over CN; for IP address validation, subjectAltName:
	iPAddr has precedence over CN.		iPAddr has precedence over CN.
	* Implementations SHOULD allow to configure a set of acceptable		* Implementations SHOULD allow to configure a set of acceptable
	values for subjectAltName:URI.		values for subjectAltName:URI.
	4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The		4. start exchanging RADIUS datagrams. Note Section 3.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. 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.
	This does not permit to determine whether the connecting entity is a		The IP address alone does not permit the server to determine whether
	NAS or a different server which proxies a request. When NAT is used		the connecting entity is a NAS or a different server which proxies a
	on the path to the server, it also does not permit to determine		request. When NAT is used on the path to the server, it also does
	whether there is more than one entity connecting from the same IP		not permit to determine whether there is more than one entity
	address.		connecting from the same IP address.
	RADIUS/TLS makes it possible to preserve this traditional RADIUS		RADIUS/TLS makes it possible to preserve this traditional RADIUS
	semantics by identifying a connecting client by the IP address which		semantics by identifying a connecting client by the IP address which
	initiated the TLS connection. In addition, it permits a much more		initiated the TLS connection. In addition, it permits a much more
	fine-grained identification. The parameters of the TLS connection		fine-grained identification. The parameters of the TLS connection
	can be attributed to the RADIUS packets inside the TLS connection.		can be attributed to the RADIUS packets inside the TLS connection.
	An implementation of RADIUS/TLS should expose as many details of the		An implementation of RADIUS/TLS should expose as many details of the
	TLS connection which belongs to an incoming RADIUS packet as possible		TLS connection which belongs to an incoming RADIUS packet as possible
	to the application layer to allow the administrator to define the		to the application layer to allow the administrator to define the
	identification criteria which are applicable to his desired		identification criteria which are applicable to his desired
	skipping to change at page 6, line 48		skipping to change at page 7, line 4
	o all X509v3 Extended Key Usage		o all X509v3 Extended Key Usage
	o all X509v3 Subject Alternative Name		o all X509v3 Subject Alternative Name
	o all X509v3 Certificate Policies		o all X509v3 Certificate Policies
	In TLS-PSK operation, at least the following parameters of the TLS		In TLS-PSK operation, at least the following parameters of the TLS
	connection should be exposed:		connection should be exposed:
	o Originating IP address		o Originating IP address
	o TLS Identifier		o TLS Identifier
	2.4. RADIUS Datagrams		2.5. RADIUS Datagrams
	Authentication, Accounting and Authorization packets are sent		Authentication, Accounting and Authorization packets are sent
	according to the following rules:		according to the following rules:
	RADIUS/TLS clients handle the following packet types from [RFC2865],		RADIUS/TLS clients handle the following packet types from [RFC2865],
	[RFC2866], [RFC5176] on the connection they initiated (see		[RFC2866], [RFC5176] on the connection they initiated (see
	Section 3.3 (3) and (4) ):		Section 3.3 (3) and (4) ):
	o send Access-Request		o send Access-Request
	skipping to change at page 9, line 11		skipping to change at page 9, line 13
	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 RADIUS/TLS nodes. The nodes also need to be		DNSSEC to identify RADIUS/TLS nodes. The 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 [RFC4985], subjectAltNames, or a defined		fields include SRV authority [RFC4985], subjectAltNames, or a defined
	list of certificate fingerprints. Operators of a RADIUS/TLS		list of certificate fingerprints. Operators of a RADIUS/TLS
	infrastructure should define their own authorisation trust model and		infrastructure should define their own authorisation trust model and
	apply this model to the certificates. The checks enumerated in		apply this model to the certificates. The checks enumerated in
	Section 2.2 provide sufficient flexibility for the implementation of		Section 2.3 provide sufficient flexibility for the implementation of
	authorisation trust models.		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.
	skipping to change at page 9, line 42		skipping to change at page 9, line 44
	(1) After the TLS session is established, RADIUS packet payloads are		(1) After the TLS session is established, RADIUS packet payloads are
	exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet		exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the packet
	size can be determined by evaluating the size of the datagram that		size can be determined by evaluating the size of the datagram that
	arrived. Due to the stream nature of TCP and TLS, this does not hold		arrived. Due to the stream nature of TCP and TLS, this does not hold
	true for RADIUS/TLS packet exchange. Instead, packet boundaries of		true for RADIUS/TLS packet exchange. Instead, packet boundaries of
	RADIUS packets that arrive in the stream are calculated by evaluating		RADIUS packets that arrive in the stream are calculated by evaluating
	the packet's Length field. Special care needs to be taken on the		the packet's Length field. Special care needs to be taken on the
	packet sender side that the value of the Length field is indeed		packet sender side that the value of the Length field is indeed
	correct before sending it over the TLS tunnel, because incorrect		correct before sending it over the TLS tunnel, because incorrect
	packet lengths can no longer be detected by a differing datagram		packet lengths can no longer be detected by a differing datagram
	boundary.		boundary. See section 2.6.4 of [I-D.dekok-radext-tcp-transport] for
			more details.
	(2) Within RADIUS [RFC2865], a shared secret is used for hiding		(2) Within RADIUS [RFC2865], a shared secret is used for hiding
	of attributes such as User-Password, as well as in computation of		of attributes such as User-Password, as well as in computation of
	the Response Authenticator. In RADIUS accounting [RFC2866], the		the Response Authenticator. In RADIUS accounting [RFC2866], the
	shared secret is used in computation of both the Request		shared secret is used in computation of both the Request
	Authenticator and the Response Authenticator. Since TLS provides		Authenticator and the Response Authenticator. Since TLS provides
	integrity protection and encryption sufficient to substitute for		integrity protection and encryption sufficient to substitute for
	RADIUS application-layer security, it is not necessary to configure a		RADIUS application-layer security, it is not necessary to configure a
	RADIUS shared secret. The use of a fixed string for the obsolete		RADIUS shared secret. The use of a fixed string for the obsolete
	shared secret eliminates possible node misconfigurations.		shared secret eliminates possible node misconfigurations.
	skipping to change at page 12, line 5		skipping to change at page 12, line 7
	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.
	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.		the classic MD5 per-attribute encryption. Such an attack can be
			mitigated by delisting the RADIUS/UDP client from the server
			configuration after successfully migrating that client to RADIUS/TLS.
	The RADIUS/TLS transport provides authentication and encryption		The RADIUS/TLS transport provides authentication and encryption
	between RADIUS peers. In the presence of proxies, the intermediate		between RADIUS peers. In the presence of proxies, the intermediate
	proxies can still inspect the individual RADIUS packets, i.e. "end-		proxies can still inspect the individual RADIUS packets, i.e. "end-
	to-end" encryption is not provided. Where intermediate proxies are		to-end" encryption is not provided. Where intermediate proxies are
	untrusted, it is desirable to use other RADIUS mechanisms to prevent		untrusted, it is desirable to use other RADIUS mechanisms to prevent
	RADIUS packet payload from inspection by such proxies. One common		RADIUS packet payload from inspection by such proxies. One common
	method to protect passwords is the use of EAP methods which utilize		method to protect passwords is the use of EAP methods which utilize
	TLS.		TLS.
	skipping to change at page 12, line 50		skipping to change at page 13, line 6
	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.
	[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-
			Shared Key Ciphersuites for
			Transport Layer Security (TLS)",
			RFC 4279, December 2005.
			[RFC4346] Dierks, T. and E. Rescorla, "The
			Transport Layer Security (TLS)
			Protocol Version 1.1", RFC 4346,
			April 2006.
	[RFC4985] Santesson, S., "Internet X.509		[RFC4985] Santesson, S., "Internet X.509
	Public Key Infrastructure Subject		Public Key Infrastructure Subject
	Alternative Name for Expression of		Alternative Name for Expression of
	Service Name", RFC 4985,		Service Name", RFC 4985,
	August 2007.		August 2007.
	[RFC5280] Cooper, D., Santesson, S., Farrell,		[RFC5280] Cooper, D., Santesson, S., Farrell,
	S., Boeyen, S., Housley, R., and W.		S., Boeyen, S., Housley, R., and W.
	Polk, "Internet X.509 Public Key		Polk, "Internet X.509 Public Key
	Infrastructure Certificate and		Infrastructure Certificate and
	skipping to change at page 13, line 26		skipping to change at page 13, line 40
	Mitton, D., and B. Aboba, "Dynamic		Mitton, D., and B. Aboba, "Dynamic
	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
	draft-dekok-radext-tcp-transport-01		-ietf-dekok-radext-tcp-transport-08
	(work in progress), November 2008.		(work in progress), July 2010.
	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-01 (work in		draft-dekok-radext-dtls-02 (work in
	progress), June 2009.		progress), March 2010.
	[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery		[I-D.winter-dynamic-discovery] Winter, S., "Dynamic Peer Discovery
	for RADIUS over TLD and DTLS",		for RADIUS over TLD 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>.
			[MD5-attacks] Black, J., Cochran, M., and T.
			Highland, "A Study of the MD5
			Attacks: Insights and
			Improvements", October 2006, <http:
			//www.springerlink.com/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 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
End of changes. 28 change blocks.
	61 lines changed or deleted		83 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/