draft-ietf-radext-dynamic-discovery-11.txt		draft-ietf-radext-dynamic-discovery-12.txt
	RADIUS Extensions Working Group S. Winter		RADIUS Extensions Working Group S. Winter
	Internet-Draft RESTENA		Internet-Draft RESTENA
	Intended status: Experimental M. McCauley		Intended status: Experimental M. McCauley
	Expires: September 4, 2014 OSC		Expires: April 30, 2015 OSC
	March 03, 2014		October 27, 2014
	NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS		NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS
	draft-ietf-radext-dynamic-discovery-11		draft-ietf-radext-dynamic-discovery-12
	Abstract		Abstract
	This document specifies a means to find authoritative RADIUS servers		This document specifies a means to find authoritative RADIUS servers
	for a given realm. It is used in conjunction with either RADIUS/TLS		for a given realm. It is used in conjunction with either RADIUS/TLS
	and RADIUS/DTLS.		and RADIUS/DTLS.
	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 33		skipping to change at page 1, line 33
	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 September 4, 2014.		This Internet-Draft will expire on April 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 12		skipping to change at page 2, line 12
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4		1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 4		2.1. DNS Resource Record definition . . . . . . . . . . . . . 4
	2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 5		2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9		2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9
	2.2. Definition of the X.509 certificate property		2.2. Definition of the X.509 certificate property
	SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11		SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11
	3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12		3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12
	3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12		3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12
	3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13		3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13
	3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14		3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14
	3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14		3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14
	skipping to change at page 2, line 49		skipping to change at page 2, line 49
	RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP,		RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP,
	RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers		RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers
	(clients, servers).		(clients, servers).
	Where more than one administrative entity collaborates for RADIUS		Where more than one administrative entity collaborates for RADIUS
	authentication of their respective customers (a "roaming		authentication of their respective customers (a "roaming
	consortium"), the Network Access Identifier (NAI)		consortium"), the Network Access Identifier (NAI)
	[I-D.ietf-radext-nai] is the suggested way of differentiating users		[I-D.ietf-radext-nai] is the suggested way of differentiating users
	between those entities; the part of a username to the right of the @		between those entities; the part of a username to the right of the @
	delimiter in a NAI is called the user's "realm". Where many realms		delimiter in an NAI is called the user's "realm". Where many realms
	and RADIUS forwarding servers are in use, the number of realms to be		and RADIUS forwarding servers are in use, the number of realms to be
	forwarded and the corresponding number of servers to configure may be		forwarded and the corresponding number of servers to configure may be
	significant. Where new realms with new servers are added or details		significant. Where new realms with new servers are added or details
	of existing servers change on a regular basis, maintaining a single		of existing servers change on a regular basis, maintaining a single
	monolithic configuration file for all these details may prove too		monolithic configuration file for all these details may prove too
	cumbersome to be useful.		cumbersome to be useful.
	Furthermore, in cases where a roaming consortium consists of		Furthermore, in cases where a roaming consortium consists of
	independently working branches (e.g. departments, national		independently working branches (e.g. departments, national
	subsidiaries), each with their own forwarding servers, and who add or		subsidiaries), each with their own forwarding servers, and who add or
	skipping to change at page 4, line 30		skipping to change at page 4, line 30
	The document provides a discovery mechanism for RADIUS which is very		The document provides a discovery mechanism for RADIUS which is very
	similar to the approach that is taken with the Diameter protocol		similar to the approach that is taken with the Diameter protocol
	[RFC6733]. As such, the basic approach (using NAPTR records in DNS		[RFC6733]. As such, the basic approach (using NAPTR records in DNS
	domains which match NAI realms) is not of very experimental nature.		domains which match NAI realms) is not of very experimental nature.
	However, the document offers a few choice points and extensions which		However, the document offers a few choice points and extensions which
	go beyond the provisions for Diameter. The list of major additions/		go beyond the provisions for Diameter. The list of major additions/
	deviations is		deviations is
	o a fallback mechanism using SRV records, should no matching NAPTR
	records be found (not defined for Diameter)
	o Provisions for determining the authority of a server to act for		o Provisions for determining the authority of a server to act for
	users of a realm (declared out of scope for Diameter)		users of a realm (declared out of scope for Diameter)
	o much more in-depth guidance on DNS regarding timeouts, failure		o much more in-depth guidance on DNS regarding timeouts, failure
	conditions, alteration of TTLs (not considered for Diameter)		conditions, alteration of Time-To-Live (TTL) information than the
			Diameter counterpart
	o a partially correct routing error detection (not considered for		o a partially correct routing error detection during DNS lookups
	Diameter)
	2. Definitions		2. Definitions
	2.1. DNS RR definition		2.1. DNS Resource Record definition
	DNS definitions of RADIUS/TLS servers can be either S-NAPTR records		DNS definitions of RADIUS/TLS servers can be either S-NAPTR records
	(see [RFC3958]) or SRV records. When both are defined, the		(see [RFC3958]) or SRV records. When both are defined, the
	resolution algorithm prefers S-NAPTR results (see Section 3.4 below).		resolution algorithm prefers S-NAPTR results (see Section 3.4 below).
	2.1.1. S-NAPTR		2.1.1. S-NAPTR
	2.1.1.1. Registration of Application Service and Protocol Tags		2.1.1.1. Registration of Application Service and Protocol Tags
	This specification defines three S-NAPTR service tags:		This specification defines three S-NAPTR service tags:
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| Service Tag | Use |		| Service Tag | Use |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| aaa+auth | RADIUS Authentication, i.e. traffic as |		| aaa+auth | RADIUS Authentication, i.e. traffic as |
	| | defined in [RFC2865] |		| | defined in [RFC2865] |
	| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |		| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
	skipping to change at page 5, line 22		skipping to change at page 5, line 19
	| Service Tag | Use |		| Service Tag | Use |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| aaa+auth | RADIUS Authentication, i.e. traffic as |		| aaa+auth | RADIUS Authentication, i.e. traffic as |
	| | defined in [RFC2865] |		| | defined in [RFC2865] |
	| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |		| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
	| aaa+acct | RADIUS Accounting, i.e. traffic as |		| aaa+acct | RADIUS Accounting, i.e. traffic as |
	| | defined in [RFC2866] |		| | defined in [RFC2866] |
	| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |		| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
	| aaa+dynauth | RADIUS Dynamic Authorisation, i.e. |		| aaa+dynauth | RADIUS Dynamic Authorisation, i.e. |
	| | traffic as defined in [RFC5176] |		| | traffic as defined in [RFC5176] |
	+--------------- --+-----------------------------------------+		+-----------------+-----------------------------------------+
	Figure 1: List of Service Tags		Figure 1: List of Service Tags
	This specification defines two S-NAPTR protocol tags:		This specification defines two S-NAPTR protocol tags:
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| Protocol Tag | Use |		| Protocol Tag | Use |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| radius.tls | RADIUS transported over TLS as defined |		| radius.tls.tcp | RADIUS transported over TLS as defined |
	| | in [RFC6614] |		| | in [RFC6614] |
	| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |		| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
	| radius.dtls | RADIUS transported over DTLS as defined |		| radius.dtls.udp | RADIUS transported over DTLS as defined |
	| | in [I-D.ietf-radext-dtls] |		| | in [RFC7360] |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	Figure 2: List of Protocol Tags		Figure 2: List of Protocol Tags
	Note well:		Note well:
	The S-NAPTR service and protocols are unrelated to the IANA		The S-NAPTR service and protocols are unrelated to the IANA
	Service Name and Transport Protocol Number registry		Service Name and Transport Protocol Number registry
	The delimiter '.' in the protocol tags is only a separator for		The delimiter '.' in the protocol tags is only a separator for
	skipping to change at page 6, line 18		skipping to change at page 6, line 14
	2.1.1.2. Definition of Conditions for Retry/Failure		2.1.1.2. Definition of Conditions for Retry/Failure
	RADIUS is a time-critical protocol; RADIUS clients which do not		RADIUS is a time-critical protocol; RADIUS clients which do not
	receive an answer after a configurable, but short, amount of time,		receive an answer after a configurable, but short, amount of time,
	will consider the request failed. Due to this, there is little		will consider the request failed. Due to this, there is little
	leeway for extensive retries.		leeway for extensive retries.
	As a general rule, only error conditions which generate an immediate		As a general rule, only error conditions which generate an immediate
	response from the other end are eligible for a retry of a discovered		response from the other end are eligible for a retry of a discovered
	target. Any error condition involving time-outs, or the absence of a		target. Any error condition involving timeouts, or the absence of a
	reply for more than one second during the connection setup phase is		reply for more than one second during the connection setup phase is
	to be considered a failure; the next target in the set of discovered		to be considered a failure; the next target in the set of discovered
	NAPTR targets is to be tried.		NAPTR targets is to be tried.
	Note that [RFC3958] already defines that a failure to identify the		Note that [RFC3958] already defines that a failure to identify the
	server as being authoritative for the realm is always considered a		server as being authoritative for the realm is always considered a
	failure; so even if a discovered target returns a wrong credential		failure; so even if a discovered target returns a wrong credential
	instantly, it is not eligible for retry.		instantly, it is not eligible for retry.
	Furthermore, the contacted RADIUS/TLS server verifies during		Furthermore, the contacted RADIUS/TLS server verifies during
	skipping to change at page 6, line 49		skipping to change at page 6, line 45
	that target (as identified by IP address and port number) SHOULD be		that target (as identified by IP address and port number) SHOULD be
	ignored from the result set of any subsequent executions of the		ignored from the result set of any subsequent executions of the
	discovery algorithm at least until the target's Effective TTL has		discovery algorithm at least until the target's Effective TTL has
	expired or until the entity which executes the algorithm changes its		expired or until the entity which executes the algorithm changes its
	TLS context to either send a new client certificate or expect a		TLS context to either send a new client certificate or expect a
	different server certificate.		different server certificate.
	2.1.1.3. Server Identification and Handshake		2.1.1.3. Server Identification and Handshake
	After the algorithm in this document has been executed, a RADIUS/TLS		After the algorithm in this document has been executed, a RADIUS/TLS
	session as per [RFC6614] is established. Since the dynamic discover		session as per [RFC6614] is established. Since the dynamic discovery
	algorithm does not have provisions to establish confidential keying		algorithm does not have provisions to establish confidential keying
	material between the RADIUS/TLS client (i.e. the server which		material between the RADIUS/TLS client (i.e. the server which
	executes the discovery algorithm) and the RADIUS/TLS server which was		executes the discovery algorithm) and the RADIUS/TLS server which was
	discovered, TLS-PKS ciphersuites cannot be used for in the subsequent		discovered, TLS-PKS ciphersuites cannot be used for in the subsequent
	TLS handshake. Only TLS ciphersuites using X.509 certificates can be		TLS handshake. Only TLS ciphersuites using X.509 certificates can be
	used with this algorithm.		used with this algorithm.
	There are numerous ways to define which certificates are acceptable		There are numerous ways to define which certificates are acceptable
	for use in this context. This document defines one mandatory-to-		for use in this context. This document defines one mandatory-to-
	implement mechanism which allows to verify whether the contacted host		implement mechanism which allows to verify whether the contacted host
	is authoritative for a NAI realm or not. It also gives one example		is authoritative for an NAI realm or not. It also gives one example
	of another mechanism which is currently in wide-spread deployment,		of another mechanism which is currently in wide-spread deployment,
	and one possible approach based on DNSSEC which is yet unimplemented.		and one possible approach based on DNSSEC which is yet unimplemented.
	2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm		2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm
	Verification of authority to provide AAA services over RADIUS/TLS is		Verification of authority to provide AAA services over RADIUS/TLS is
	a two-step process.		a two-step process.
	Step 1 is the verification of certificate wellformedness and validity		Step 1 is the verification of certificate wellformedness and validity
	as per [RFC5280] and whether it was issued from a root certificate		as per [RFC5280] and whether it was issued from a root certificate
	skipping to change at page 8, line 33		skipping to change at page 8, line 29
	Where DNSSEC is used, the results of the algorithm can be trusted;		Where DNSSEC is used, the results of the algorithm can be trusted;
	i.e. the entity which executes the algorithm can be certain that the		i.e. the entity which executes the algorithm can be certain that the
	realm that triggered the discovery is actually served by the server		realm that triggered the discovery is actually served by the server
	that was discovered via DNS. However, this does not guarantee that		that was discovered via DNS. However, this does not guarantee that
	the server is also authorized (i.e. a recognised member of the		the server is also authorized (i.e. a recognised member of the
	roaming consortium).		roaming consortium).
	The authorization can be sketched using DNSSEC+DANE as follows: if		The authorization can be sketched using DNSSEC+DANE as follows: if
	DANE/TLSA records of all authorized servers are put into a DNSSEC		DANE/TLSA records of all authorized servers are put into a DNSSEC
	zone with a common, consortium-specific branch of the DNS tree, then		zone with a common, consortium-specific branch of the DNS tree, then
	the entity executing the algorithm can retrieve TLSA RRs for the		the entity executing the algorithm can retrieve TLSA Resource Records
	label "realm.commonroot" and verify that the presented server		(TLSA RR) for the label "realm.commonroot" and verify that the
	certificate during the RADIUS/TLS handshake matches the information		presented server certificate during the RADIUS/TLS handshake matches
	in the TLSA record.		the information in the TLSA record.
	Example:		Example:
	Realm = "example.com"		Realm = "example.com"
	Common Branch = "idp.roaming-consortium.example.		Common Branch = "idp.roaming-consortium.example.
	label for TLSA query = "example.com.idp.roaming-		label for TLSA query = "example.com.idp.roaming-
	consortium.example.		consortium.example.
	skipping to change at page 9, line 26		skipping to change at page 9, line 26
	This specification defines two SRV prefixes (i.e. two values for the		This specification defines two SRV prefixes (i.e. two values for the
	"_service._proto" part of an SRV RR as per [RFC2782]):		"_service._proto" part of an SRV RR as per [RFC2782]):
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| SRV Label | Use |		| SRV Label | Use |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| _radiustls._tcp | RADIUS transported over TLS as defined |		| _radiustls._tcp | RADIUS transported over TLS as defined |
	| | in [RFC6614] |		| | in [RFC6614] |
	| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |		| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
	| _radiustls._udp | RADIUS transported over DTLS as defined |		| _radiustls._udp | RADIUS transported over DTLS as defined |
	| | in [I-D.ietf-radext-dtls] |		| | in [RFC7360] |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	Figure 3: List of SRV Labels		Figure 3: List of SRV Labels
	Just like NAPTR records, the lookup and subsequent follow-up of SRV		Just like NAPTR records, the lookup and subsequent follow-up of SRV
	records may yield more than one server to contact in a prioritised		records may yield more than one server to contact in a prioritised
	list. [RFC2782] does not specify rules regarding "Definition of		list. [RFC2782] does not specify rules regarding "Definition of
	Conditions for Retry/Failure", nor "Server Identification and		Conditions for Retry/Failure", nor "Server Identification and
	Handshake". This specification defines that the rules for these two		Handshake". This specification defines that the rules for these two
	topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be		topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be
	skipping to change at page 10, line 13		skipping to change at page 10, line 13
	associated to DNS names or special-purpose consortia where a globally		associated to DNS names or special-purpose consortia where a globally
	valid discovery is not a use case. Such other labels require a		valid discovery is not a use case. Such other labels require a
	consortium-wide agreement about the transformation from realm name to		consortium-wide agreement about the transformation from realm name to
	lookup label, and/or which service tag to use.		lookup label, and/or which service tag to use.
	Examples:		Examples:
	a. A general-purpose RADIUS server for realm example.com might have		a. A general-purpose RADIUS server for realm example.com might have
	DNS entries as follows:		DNS entries as follows:
	example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" ""		example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" ""
	_radiustls._tcp.foobar.example.com.		_radiustls._tcp.foobar.example.com.
	_radiustls._tcp.foobar.example.com. IN SRV 0 10 2083		_radiustls._tcp.foobar.example.com. IN SRV 0 10 2083
	radsec.example.com.		radsec.example.com.
	b. The consortium "foo" provides roaming services for its members		b. The consortium "foo" provides roaming services for its members
	only. The realms used are of the form enterprise-name.example.		only. The realms used are of the form enterprise-name.example.
	The consortium operates a special purpose DNS server for the		The consortium operates a special purpose DNS server for the
	(private) TLD "example" which all RADIUS servers use to resolve		(private) TLD "example" which all RADIUS servers use to resolve
	realm names. "Company, Inc." is part of the consortium. On the		realm names. "Company, Inc." is part of the consortium. On the
	consortium's DNS server, realm company.example might have the		consortium's DNS server, realm company.example might have the
	following DNS entries:		following DNS entries:
	company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" ""		company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp"
	roamserv.company.example		"" roamserv.company.example
	c. The eduroam consortium uses realms based on DNS, but provides its		c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses
	services to a closed community only. However, a AAA domain		realms based on DNS, but provides its services to a closed
	participating in eduroam may also want to expose AAA services to		community only. However, a AAA domain participating in eduroam
	other, general-purpose, applications (on the same or other RADIUS		may also want to expose AAA services to other, general-purpose,
	servers). Due to that, the eduroam consortium uses the service		applications (on the same or other RADIUS servers). Due to that,
	tag "x-eduroam" for authentication purposes and eduroam RADIUS		the eduroam consortium uses the service tag "x-eduroam" for
	servers use this tag to look up other eduroam servers. An		authentication purposes and eduroam RADIUS servers use this tag
	eduroam participant example.org which also provides general-		to look up other eduroam servers. An eduroam participant
	purpose AAA on a different server uses the general "aaa+auth"		example.org which also provides general-purpose AAA on a
	tag:		different server uses the general "aaa+auth" tag:
	example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" ""		example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" ""
	_radiustls._tcp.eduroam.example.org.		_radiustls._tcp.eduroam.example.org.
	example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" ""		example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" ""
	_radiustls._tcp.aaa.example.org		_radiustls._tcp.aaa.example.org
	_radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa-		_radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa-
	eduroam.example.org.		eduroam.example.org.
	_radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa-		_radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa-
	default.example.org.		default.example.org.
	2.2. Definition of the X.509 certificate property		2.2. Definition of the X.509 certificate property
	SubjectAltName:otherName:NAIRealm		SubjectAltName:otherName:NAIRealm
	This specification retrieves IP addresses and port numbers from the		This specification retrieves IP addresses and port numbers from the
	Domain Name System which are subsequently used to authenticate users		Domain Name System which are subsequently used to authenticate users
	via the RADIUS/TLS protocol. Since the Domain Name System is not		via the RADIUS/TLS protocol. Since the Domain Name System is not
	necessarily trustworthy (e.g. if DNSSEC is not deployed for the		necessarily trustworthy (e.g. if DNSSEC is not deployed for the
	queried domain name), it is important to verify that the server which		queried domain name), it is important to verify that the server which
	was contacted is authorized to service requests for the user which		was contacted is authorized to service requests for the user which
	triggered the discovery process.		triggered the discovery process.
	The input to the algorithm is a NAI realm as specified in		The input to the algorithm is an NAI realm as specified in
	Section 3.4.1. As a consequence, the X.509 certificate of the server		Section 3.4.1. As a consequence, the X.509 certificate of the server
	which is ultimately contacted for user authentication needs to be		which is ultimately contacted for user authentication needs to be
	able to express that it is authorized to handle requests for that		able to express that it is authorized to handle requests for that
	realm.		realm.
	Current subjectAltName fields do not semantically allow to express an		Current subjectAltName fields do not semantically allow to express an
	NAI realm; the field subjectAltName:dNSName is syntactically a good		NAI realm; the field subjectAltName:dNSName is syntactically a good
	match but would inappropriately conflate DNS names and NAI realm		match but would inappropriately conflate DNS names and NAI realm
	names. Thus, this specification defines a new subjectAltName field		names. Thus, this specification defines a new subjectAltName field
	to hold either a single NAI realm name or a wildcard name matching a		to hold either a single NAI realm name or a wildcard name matching a
	skipping to change at page 12, line 12		skipping to change at page 12, line 12
	NAIRealm ::= UTF8String (SIZE (1..MAX))		NAIRealm ::= UTF8String (SIZE (1..MAX))
	The NAIRealm, if present, MUST contain an NAI realm as defined in		The NAIRealm, if present, MUST contain an NAI realm as defined in
	[I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot-		[I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot-
	separated part of the NAI with the single character "*" to indicate a		separated part of the NAI with the single character "*" to indicate a
	wildcard match for "all labels in this part". Further features of		wildcard match for "all labels in this part". Further features of
	regular expressions, such as a number of characters followed by a *		regular expressions, such as a number of characters followed by a *
	to indicate a common prefix inside the part, are not permitted.		to indicate a common prefix inside the part, are not permitted.
	The comparison of a NAIRealm to the NAI realm as derived from user		The comparison of an NAIRealm to the NAI realm as derived from user
	input with this algorithm is a byte-by-byte comparison, except for		input with this algorithm is a byte-by-byte comparison, except for
	the optional leftmost dot-separated part of the value whose content		the optional leftmost dot-separated part of the value whose content
	is a single "*" character; such labels match all strings in the same		is a single "*" character; such labels match all strings in the same
	dot-separated part of the NAI realm. If at least one of the		dot-separated part of the NAI realm. If at least one of the
	sAN:otherName:NAIRealm values matches the NAI realm, the server is		sAN:otherName:NAIRealm values matches the NAI realm, the server is
	considered authorized; if none matches, the server is considered		considered authorized; if none matches, the server is considered
	unauthorized.		unauthorized.
	Since multiple names and multiple name forms may occur in the		Since multiple names and multiple name forms may occur in the
	subjectAltName extension, an arbitrary number of NAIRealms can be		subjectAltName extension, an arbitrary number of NAIRealms can be
	skipping to change at page 13, line 13		skipping to change at page 13, line 13
	Authorization) where a RADIUS entity which acts as a forwarding		Authorization) where a RADIUS entity which acts as a forwarding
	server for one or more realms receives a request with a realm for		server for one or more realms receives a request with a realm for
	which it is not authoritative, and which no explicit next hop is		which it is not authoritative, and which no explicit next hop is
	configured. It is only applicable for		configured. It is only applicable for
	a. new user sessions, i.e. for the initial Access-Request.		a. new user sessions, i.e. for the initial Access-Request.
	Subsequent messages concerning this session, for example Access-		Subsequent messages concerning this session, for example Access-
	Challenges and Access-Accepts use the previously-established		Challenges and Access-Accepts use the previously-established
	communication channel between client and server.		communication channel between client and server.
	b. the first accounting ticket for a user session		b. the first accounting ticket for a user session.
	c. the first RADIUS DynAuth packet for a user session		c. the first RADIUS DynAuth packet for a user session.
	3.2. Configuration Variables		3.2. Configuration Variables
	The algorithm contains various variables for timeouts. These		The algorithm contains various variables for timeouts. These
	variables are named here and reasonable default values are provided.		variables are named here and reasonable default values are provided.
	Implementations wishing to deviate from these defaults should make		Implementations wishing to deviate from these defaults should make
	they understand the implications of changes.		they understand the implications of changes.
	DNS_TIMEOUT: maximum amount of time to wait for the complete set		DNS_TIMEOUT: maximum amount of time to wait for the complete set
	of all DNS queries to complete: Default = 3 seconds		of all DNS queries to complete: Default = 3 seconds
	skipping to change at page 14, line 48		skipping to change at page 14, line 48
	Note well: The attribute User-Name is defined to contain UTF-8 text.		Note well: The attribute User-Name is defined to contain UTF-8 text.
	In practice, the content may or may not be UTF-8. Even if UTF-8, it		In practice, the content may or may not be UTF-8. Even if UTF-8, it
	may or may not map to a domain name in the realm part. Implementors		may or may not map to a domain name in the realm part. Implementors
	MUST take possible conversion error paths into consideration when		MUST take possible conversion error paths into consideration when
	parsing incoming User-Name attributes. This document describes		parsing incoming User-Name attributes. This document describes
	server discovery only for well-formed realms mapping to DNS domain		server discovery only for well-formed realms mapping to DNS domain
	names in UTF-8 encoding. The result of all other possible contents		names in UTF-8 encoding. The result of all other possible contents
	of User-Name is unspecified; this includes, but is not limited to:		of User-Name is unspecified; this includes, but is not limited to:
	Usage of separators other than @		Usage of separators other than @.
	Encoding of User-Name in local encodings		Encoding of User-Name in local encodings.
	UTF-8 realms which fail the conversion rules as per [RFC5891]
			UTF-8 realms which fail the conversion rules as per [RFC5891].
	UTF-8 realms which end with a . ("dot") character.		UTF-8 realms which end with a . ("dot") character.
	For the last bullet point, "trailing dot", special precautions should		For the last bullet point, "trailing dot", special precautions should
	be taken to avoid problems when resolving servers with the algorithm		be taken to avoid problems when resolving servers with the algorithm
	below: they may resolve to a RADIUS server even if the peer RADIUS		below: they may resolve to a RADIUS server even if the peer RADIUS
	server only is configured to handle the realm without the trailing		server only is configured to handle the realm without the trailing
	dot. If that RADIUS server again uses NAI discovery to determine the		dot. If that RADIUS server again uses NAI discovery to determine the
	authoritative server, the server will forward the request to		authoritative server, the server will forward the request to
	localhost, resulting in a tight endless loop.		localhost, resulting in a tight endless loop.
	skipping to change at page 18, line 16		skipping to change at page 18, line 16
	The host's name resolution library may need to contact outside		The host's name resolution library may need to contact outside
	entities to perform the name resolution (e.g. authoritative name		entities to perform the name resolution (e.g. authoritative name
	servers for a domain), and since the NAI discovery algorithm is based		servers for a domain), and since the NAI discovery algorithm is based
	on uncontrollable user input, the destination of the lookups is out		on uncontrollable user input, the destination of the lookups is out
	of control of the server that performs NAI discovery. If such		of control of the server that performs NAI discovery. If such
	outside entities are misconfigured or unreachable, the algorithm		outside entities are misconfigured or unreachable, the algorithm
	above may need an unacceptably long time to terminate. Many RADIUS		above may need an unacceptably long time to terminate. Many RADIUS
	implementations time out after five seconds of delay between Request		implementations time out after five seconds of delay between Request
	and Response. It is not useful to wait until the host name		and Response. It is not useful to wait until the host name
	resolution library signals a time-out of its name resolution		resolution library signals a timeout of its name resolution
	algorithms. The algorithm therefore control execution time with		algorithms. The algorithm therefore control execution time with
	TIMER. Execution of the NAI discovery algorithm SHOULD be non-		TIMER. Execution of the NAI discovery algorithm SHOULD be non-
	blocking (i.e. allow other requests to be processed in parallel to		blocking (i.e. allow other requests to be processed in parallel to
	the execution of the algorithm).		the execution of the algorithm).
	3.4.6. Example		3.4.6. Example
	Assume		Assume
	a user from the Technical University of Munich, Germany, has a		a user from the Technical University of Munich, Germany, has a
	skipping to change at page 18, line 50		skipping to change at page 18, line 50
	DNS_TIMEOUT = 3 seconds		DNS_TIMEOUT = 3 seconds
	MIN_EFF_TTL = 60 seconds		MIN_EFF_TTL = 60 seconds
	BACKOFF_TIME = 3600 seconds		BACKOFF_TIME = 3600 seconds
	If DNS contains the following records:		If DNS contains the following records:
	xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s"		xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s"
	"aaa+auth:radius.tls" "" _myradius._tcp.xn--tu-mnchen-t9a.example.		"aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen-
			t9a.example.
	xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s"		xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s"
	"fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example.		"fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example.
	_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083		_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083
	radsecserver.xn--tu-mnchen-t9a.example.		radsecserver.xn--tu-mnchen-t9a.example.
	_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083		_myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083
	backupserver.xn--tu-mnchen-t9a.example.		backupserver.xn--tu-mnchen-t9a.example.
	skipping to change at page 19, line 37		skipping to change at page 19, line 37
	2. R = "tu-m[U+00FC]nchen.example"		2. R = "tu-m[U+00FC]nchen.example"
	3. NOOP		3. NOOP
	4. name resolution library converts R to xn--tu-mnchen-t9a.example		4. name resolution library converts R to xn--tu-mnchen-t9a.example
	5. TIMER starts.		5. TIMER starts.
	6. Result:		6. Result:
	(TTL = 47) 50 50 "s" "aaa+auth:radius.tls" ""		(TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" ""
	_myradius._tcp.xn--tu-mnchen-t9a.example.		_myradius._tcp.xn--tu-mnchen-t9a.example.
	(TTL = 522) 50 50 "s" "fooservice:bar.dccp" ""		(TTL = 522) 50 50 "s" "fooservice:bar.dccp" ""
	_abc123._def.xn--tu-mnchen-t9a.example.		_abc123._def.xn--tu-mnchen-t9a.example.
	7. Result:		7. Result:
	(TTL = 47) 50 50 "s" "aaa+auth:radius.tls" ""		(TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" ""
	_myradius._tcp.xn--tu-mnchen-t9a.example.		_myradius._tcp.xn--tu-mnchen-t9a.example.
	8. NOOP		8. NOOP
	9. Successive resolution performs SRV query for label		9. Successive resolution performs SRV query for label
	_myradius._tcp.xn--tu-mnchen-t9a.example, which results in		_myradius._tcp.xn--tu-mnchen-t9a.example, which results in
	(TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example.		(TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example.
	(TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example.		(TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example.
	skipping to change at page 21, line 34		skipping to change at page 21, line 34
	5. Security Considerations		5. Security Considerations
	When using DNS without DNSSEC security extensions and validation for		When using DNS without DNSSEC security extensions and validation for
	all of the replies to NAPTR, SRV and A/AAAA requests as described in		all of the replies to NAPTR, SRV and A/AAAA requests as described in
	section Section 3, the result O can not be trusted. Even if it can		section Section 3, the result O can not be trusted. Even if it can
	be trusted (i.e. DNSSEC is in use), actual authorization of the		be trusted (i.e. DNSSEC is in use), actual authorization of the
	discovered server to provide service for the given realm needs to be		discovered server to provide service for the given realm needs to be
	verified. A mechanism from section Section 2.1.1.3 or equivalent		verified. A mechanism from section Section 2.1.1.3 or equivalent
	MUST be used to verify authorization.		MUST be used to verify authorization.
	The algorithm has a configurable completion time-out DNS_TIMEOUT		The algorithm has a configurable completion timeout DNS_TIMEOUT
	defaulting to three seconds for RADIUS' operational reasons. The		defaulting to three seconds for RADIUS' operational reasons. The
	lookup of DNS resource records based on unverified user input is an		lookup of DNS resource records based on unverified user input is an
	attack vector for DoS attacks: an attacker might intentionally craft		attack vector for DoS attacks: an attacker might intentionally craft
	bogus DNS zones which take a very long time to reply (e.g. due to a		bogus DNS zones which take a very long time to reply (e.g. due to a
	particularly byzantine tree structure, or artificial delays in		particularly byzantine tree structure, or artificial delays in
	responses).		responses).
	To mitigate this DoS vector, implementations SHOULD consider rate-		To mitigate this DoS vector, implementations SHOULD consider rate-
	limiting either their amount of new executions of the dynamic		limiting either their amount of new executions of the dynamic
	discovery algorithm as a whole, or the amount of intermediate		discovery algorithm as a whole, or the amount of intermediate
	skipping to change at page 24, line 20		skipping to change at page 24, line 20
	o S-NAPTR Application Service Tags registry		o S-NAPTR Application Service Tags registry
	* aaa+auth		* aaa+auth
	* aaa+acct		* aaa+acct
	* aaa+dynauth		* aaa+dynauth
	o S-NAPTR Application Protocol Tags registry		o S-NAPTR Application Protocol Tags registry
	* radius.tls		* radius.tls.tcp
	* radius.dtls		* radius.dtls.udp
	This document reserves the use of the "radiustls" and "radiusdtls"		This document reserves the use of the "radiustls" and "radiusdtls"
	service names. Registration information as per [RFC6335] section		service names. Registration information as per [RFC6335] section
	8.1.1 is as follows:		8.1.1 is as follows:
	Service Name: radiustls; radiusdtls		Service Name: radiustls; radiusdtls
	Transport Protocols: TCP, UDP		Transport Protocols: TCP, UDP
	Assignee: IESG <iesg@ietf.org>		Assignee: IESG <iesg@ietf.org>
	skipping to change at page 24, line 45		skipping to change at page 24, line 45
	Description: Authentication, Accounting and Dynamic authorization		Description: Authentication, Accounting and Dynamic authorization
	via the RADIUS protocol. These service names are used to		via the RADIUS protocol. These service names are used to
	construct the SRV service labels "_radiustls" and "_radiusdtls"		construct the SRV service labels "_radiustls" and "_radiusdtls"
	for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.		for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.
	Reference: RFC Editor Note: please insert the RFC number of this		Reference: RFC Editor Note: please insert the RFC number of this
	document. The protocol does not use broadcast, multicast or		document. The protocol does not use broadcast, multicast or
	anycast communication.		anycast communication.
	This document requests the creation of a new IANA registry named		This specification makes use of the SRV Protocol identifiers "_tcp"
	"RADIUS/TLS SRV Protocol Registry" with the following initial		and "_udp" which are mentioned as early as [RFC2782] but do not
	entries:		appear to be assigned in an actual registry. Since they are in wide-
			spread use in other protocols, this specification refrains from
	o _tcp		requesting a new registry "RADIUS/TLS SRV Protocol Registry" and
			continues to make use of these tags implicitly.
	o _udp
	This document requires that a number of Object Identifiers be		This document requires that a number of Object Identifiers be
	assigned. They re now under the control of IANA following [I-D		assigned. They are now under the control of IANA following [RFC7299]
	.housley-pkix-oids].
	IANA is requested to assign the following identifiers:		IANA is requested to assign the following identifiers:
	TBD99 is to be assigned from the "SMI Security for PKIX Module		TBD99 is to be assigned from the "SMI Security for PKIX Module
	Identifier Registry". The suggested description is id-mod-nai-		Identifier Registry". The suggested description is id-mod-nai-
	realm-08.		realm-08.
	TBD98 is to be assigned from the "SMI Security for PKIX Other Name		TBD98 is to be assigned from the "SMI Security for PKIX Other Name
	Forms Registry." The suggested description is id-on-nai.		Forms Registry." The suggested description is id-on-nai.
	skipping to change at page 26, line 17		skipping to change at page 26, line 12
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.		[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
	Aboba, "Carrying Location Objects in RADIUS and Diameter",		Aboba, "Carrying Location Objects in RADIUS and Diameter",
	RFC 5580, August 2009.		RFC 5580, August 2009.
	[RFC5891] Klensin, J., "Internationalized Domain Names in		[RFC5891] Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol", RFC 5891, August 2010.		Applications (IDNA): Protocol", RFC 5891, August 2010.
	[I-D.ietf-radext-dtls]
	DeKok, A., "DTLS as a Transport Layer for RADIUS", draft-
	ietf-radext-dtls-07 (work in progress), October 2013.
	[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,		[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
	"Transport Layer Security (TLS) Encryption for RADIUS",		"Transport Layer Security (TLS) Encryption for RADIUS",
	RFC 6614, May 2012.		RFC 6614, May 2012.
			[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
			Transport Layer for RADIUS", RFC 7360, September 2014.
	[I-D.ietf-radext-nai]		[I-D.ietf-radext-nai]
	DeKok, A., "The Network Access Identifier", draft-ietf-		DeKok, A., "The Network Access Identifier", draft-ietf-
	radext-nai-05 (work in progress), November 2013.		radext-nai-08 (work in progress), September 2014.
	8.2. Informative References		8.2. Informative References
	[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible		[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
	Authentication Protocol (EAP) Method Requirements for		Authentication Protocol (EAP) Method Requirements for
	Wireless LANs", RFC 4017, March 2005.		Wireless LANs", RFC 4017, March 2005.
	[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.		[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
	Cheshire, "Internet Assigned Numbers Authority (IANA)		Cheshire, "Internet Assigned Numbers Authority (IANA)
	Procedures for the Management of the Service Name and		Procedures for the Management of the Service Name and
	Transport Protocol Port Number Registry", BCP 165, RFC		Transport Protocol Port Number Registry", BCP 165, RFC
	6335, August 2011.		6335, August 2011.
	[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,		[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	"Diameter Base Protocol", RFC 6733, October 2012.		"Diameter Base Protocol", RFC 6733, October 2012.
			[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
			Working Group", RFC 7299, July 2014.
			[I-D.wierenga-ietf-eduroam]
			Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
			architecture for network roaming", draft-wierenga-ietf-
			eduroam-04 (work in progress), August 2014.
	Appendix A. Appendix A: ASN.1 Syntax of NAIRealm		Appendix A. Appendix A: ASN.1 Syntax of NAIRealm
	PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6)		PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6)
	internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)		internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-nai-realm-08 (TBD99) }		id-mod-nai-realm-08 (TBD99) }
	DEFINITIONS EXPLICIT TAGS ::=		DEFINITIONS EXPLICIT TAGS ::=
	BEGIN		BEGIN
End of changes. 43 change blocks.
	69 lines changed or deleted		73 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/