draft-ietf-radext-dynamic-discovery-12.txt		draft-ietf-radext-dynamic-discovery-13.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 30, 2015 OSC		Expires: September 7, 2015 AirSpayce
	October 27, 2014		March 06, 2015
	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-12		draft-ietf-radext-dynamic-discovery-13
	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 April 30, 2015.		This Internet-Draft will expire on September 7, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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 . . . . . . . . . . . . . . . . . . 5
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4		1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 6
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. DNS Resource Record definition . . . . . . . . . . . . . 4		2.1. DNS Resource Record (RR) definition . . . . . . . . . . . 7
	2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4		2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9		2.1.3. Optional name mangling . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . 13
	3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12		3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 15
	3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12		3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 15
	3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13		3.2. Configuration Variables . . . . . . . . . . . . . . . . . 16
	3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14		3.4. Realm to RADIUS server resolution algorithm . . . . . . . 17
	3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14		3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 17
	3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 15		3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 18
	3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 15		3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
	3.4.4. Validity of results . . . . . . . . . . . . . . . . . 17		3.4.4. Validity of results . . . . . . . . . . . . . . . . . 19
	3.4.5. Delay considerations . . . . . . . . . . . . . . . . 18		3.4.5. Delay considerations . . . . . . . . . . . . . . . . 20
	3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 18		3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21
	4. Operations and Manageability Considerations . . . . . . . . . 20		4. Operations and Manageability Considerations . . . . . . . . . 23
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 21		5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
	8.1. Normative References . . . . . . . . . . . . . . . . . . 25		8.1. Normative References . . . . . . . . . . . . . . . . . . 28
	8.2. Informative References . . . . . . . . . . . . . . . . . 26		8.2. Informative References . . . . . . . . . . . . . . . . . 29
	Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 27		Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 30
	1. Introduction		1. Introduction
	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)
	skipping to change at page 3, line 14		skipping to change at page 3, line 14
	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
	change their realm lists at their own discretion, there is additional		change their realm lists at their own discretion, there is additional
	complexity in synchronising the changed data across all branches.		complexity in synchronising the changed data across all branches.
	These situations can benefit significantly from a distributed		Where realms can be partitioned (e.g. according to their top-level
	mechanism for storing realm and server reachability information.		domain ending), forwarding of requests can be realised with a
	This document describes one such mechanism: storage of realm-to-		hierarchy of RADIUS servers, all serving their partition of the realm
	server mappings in DNS.		space. Figure 1 show an example of this hierarchical routing.
			+-------+
			| |
			| . |
			| |
			+---+---+
			/ | \
			+----------------/ | \---------------------+
			| | |
			| | |
			| | |
			+--+---+ +--+--+ +----+---+
			| | | | | |
			| .edu | . . . | .nl | . . . | .ac.uk |
			| | | | | |
			+--+---+ +--+--+ +----+---+
			/ | \ | \ |
			/ | \ | \ |
			/ | \ | \ |
			+-----+ | +-----+ | +------+ |
			| | | | | |
			| | | | | |
			+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
			| | | | | | | | | | | |
			|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
			| | | | | | | | | | | |
			+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
			| |
			| |
			+--+--+ +--+--+
			| | | |
			+-+-----+-+ | |
			| | +-----+
			+---------+
			user: paul@surfnet.nl surfnet.nl Authentication server
			Figure 1: RADIUS hierarchy based on Top-Level Domain partitioning
			However, such partitioning is not always possible. As an example, in
			one real-life deployment, the administrative boundaries and RADIUS
			forwarding servers are are organised along country borders, but
			generic top-level domains such as .edu do not map to this choice of
			boundaries (see [I-D.wierenga-ietf-eduroam] for details). These
			situations can benefit significantly from a distributed mechanism for
			storing realm and server reachability information. This document
			describes one such mechanism: storage of realm-to-server mappings in
			DNS; realm-based request forwarding can then be realised without a
			static hierarchy such as in the following figure:
			---------
			/ \
			--------- ------------
			/ \
			| DNS -
			----------| \
			/ \ surfnet.nl NAPTR? |
			(1) / ---- -> radius.surfnet.nl /
			/ \ /
			/ -------- ---------
			/ \---------/
			|
			| ---------------------------------------
			| / (2) RADIUS \
			| | |
			+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
			| | | | | | | | | | | |
			|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
			| | | | | | | | | | | |
			+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
			| |
			| |
			+--+--+ +--+--+
			| | | |
			+-+-----+-+ | |
			| | +-----+
			+---------+
			user: paul@surfnet.nl surfnet.nl Authentication server
			Figure 2: RADIUS hierarchy based on Top-Level Domain partitioning
	This document also specifies various approaches for verifying that		This document also specifies various approaches for verifying that
	server information which was retrieved from DNS was from an		server information which was retrieved from DNS was from an
	authorised party; e.g. an organisation which is not at all part of a		authorised party; e.g. an organisation which is not at all part of a
	given roaming consortium may alter its own DNS records to yield a		given roaming consortium may alter its own DNS records to yield a
	result for its own realm.		result for its own realm.
	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
	skipping to change at page 4, line 23		skipping to change at page 6, line 39
	experience is collected on the choice points mentioned below, it is		experience is collected on the choice points mentioned below, it is
	expected to be obsoleted by a standards-track version of the protocol		expected to be obsoleted by a standards-track version of the protocol
	which trims down the choice points.		which trims down the choice points.
	If that removal of choice points obsoletes tags or service names as		If that removal of choice points obsoletes tags or service names as
	defined in this document and allocated by IANA, these items will be		defined in this document and allocated by IANA, these items will be
	returned to IANA as per the provisions in [RFC6335].		returned to IANA as per the provisions in [RFC6335].
	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 Naming Authority
	domains which match NAI realms) is not of very experimental nature.		Pointer (NAPTR) records in DNS 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 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 Time-To-Live (TTL) information than the		conditions, alteration of Time-To-Live (TTL) information than the
	Diameter counterpart		Diameter counterpart
	o a partially correct routing error detection during DNS lookups		o a partially correct routing error detection during DNS lookups
	2. Definitions		2. Definitions
	2.1. DNS Resource Record definition		2.1. DNS Resource Record (RR) 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 Service Record (SRV) records. When both are
	resolution algorithm prefers S-NAPTR results (see Section 3.4 below).		defined, the 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 21		skipping to change at page 7, line 35
	| 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 3: 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.tcp | RADIUS transported over TLS as defined |		| radius.tls.tcp | RADIUS transported over TLS as defined |
	| | in [RFC6614] |		| | in [RFC6614] |
	| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |		| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
	| radius.dtls.udp | RADIUS transported over DTLS as defined |		| radius.dtls.udp | RADIUS transported over DTLS as defined |
	| | in [RFC7360] |		| | in [RFC7360] |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	Figure 2: List of Protocol Tags		Figure 4: 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
	human reading convenience - not for structure or namespacing; it		human reading convenience - not for structure or namespacing; it
	MUST NOT be parsed in any way by the querying application or		MUST NOT be parsed in any way by the querying application or
	resolver.		resolver.
	skipping to change at page 7, line 12		skipping to change at page 9, line 25
	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 an 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.
			For the approaches which use trust roots (see the following two
			sections), a typical deployment will use a dedicated trust store for
			RADIUS/TLS certificate authorities, particularly a trust store which
			is independent from default "browser" trust stores. Often, this will
			be one or few CAs, and they only issue certificates for the specific
			purpose of establishing RADIUS server-to-server trust. It is
			important not to trust a large set of CAs which operate outside the
			control of the roaming consortium, for their issuance of certificates
			with the properties important for authorisation (such as NAIRealm and
			policyOID below) is difficult to verify. Therefore, clients SHOULD
			NOT be pre-configured with a list of known public CAs by the vendor
			or manufacturer. Instead, the clients SHOULD start off with an empty
			CA list. The addition of a CA SHOULD be done only when manually
			configured by an administrator.
	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
	which is deemed trustworthy by the RADIUS/TLS client.		which is deemed trustworthy by the RADIUS/TLS client.
	Step 2 is to compare the value of algorithm's variable "R" after the		Step 2 is to compare the value of algorithm's variable "R" after the
	skipping to change at page 9, line 29		skipping to change at page 12, line 15
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	| 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 [RFC7360] |		| | in [RFC7360] |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	Figure 3: List of SRV Labels		Figure 5: 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
	used both for targets retrieved via an initial NAPTR RR as well as		used both for targets retrieved via an initial NAPTR RR as well as
	for targets retrieved via an initial SRV RR (i.e. in the absence of		for targets retrieved via an initial SRV RR (i.e. in the absence of
	NAPTR RRs).		NAPTR RRs).
	skipping to change at page 12, line 40		skipping to change at page 15, line 26
	| foo.example | foo.example | YES |		| foo.example | foo.example | YES |
	| foo.example | *.example | YES |		| foo.example | *.example | YES |
	| bar.foo.example | *.example | NO |		| bar.foo.example | *.example | NO |
	| bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) |		| bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) |
	| bar.foo.example | bar.*.example | NO (NAIRealm invalid) |		| bar.foo.example | bar.*.example | NO (NAIRealm invalid) |
	| bar.foo.example | *.*.example | NO (NAIRealm invalid) |		| bar.foo.example | *.*.example | NO (NAIRealm invalid) |
	| sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) |		| sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) |
	| sub.bar.foo.example | *.bar.foo.example | YES |		| sub.bar.foo.example | *.bar.foo.example | YES |
	+-----------------+-----------------------------------------------+		+-----------------+-----------------------------------------------+
	Figure 4: Examples for NAI realm vs. certificate matching		Figure 6: Examples for NAI realm vs. certificate matching
	Appendix A contains the ASN.1 definition of the above objects.		Appendix A contains the ASN.1 definition of the above objects.
	3. DNS-based NAPTR/SRV Peer Discovery		3. DNS-based NAPTR/SRV Peer Discovery
	3.1. Applicability		3.1. Applicability
	Dynamic server discovery as defined in this document is only		Dynamic server discovery as defined in this document is only
	applicable for new AAA transactions and per service (i.e. distinct		applicable for new AAA transactions and per service (i.e. distinct
	discovery is needed for Authentication, Accounting, and Dynamic		discovery is needed for Authentication, Accounting, and Dynamic
	skipping to change at page 17, line 10		skipping to change at page 19, line 46
	Terminate (see next section for a rationale). If no, O is the		Terminate (see next section for a rationale). If no, O is the
	result of dynamic discovery. Terminate.		result of dynamic discovery. Terminate.
	20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate.		20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate.
	3.4.4. Validity of results		3.4.4. Validity of results
	The dynamic discovery algorithm is used by servers which do not have		The dynamic discovery algorithm is used by servers which do not have
	sufficient configuration information to process an incoming request		sufficient configuration information to process an incoming request
	on their own. If the discovery algorithm result contains the		on their own. If the discovery algorithm result contains the
	server's own listening address (IP address and port), then this will		server's own listening address (IP address and port), then there is a
	either lead to a tight loop (if that DNS entry has topmost priority,		potential for an endless forwarding loop. If the listening address
	the server would forward the request to itself, triggering dynamic		is the DNS result with the highest priorty, the server will enter a
	discovery again in a perpetual loop), or lead to a potential loop		tight loop (the server would forward the request to itself,
	with intermediate hops in between (the server could forward to		triggering dynamic discovery again in a perpetual loop). If the
	another host with a higher priority, which might use DNS itself and		address has a lower priority in the set of results, there is a
	forward the packet back to the first server). The underlying reason		potential loop with intermediate hops in between (the server could
	that enables these loops is that the server executing the discovery		forward to another host with a higher priority, which might use DNS
	algorithm is seriously misconfigured in that it does not recognise		itself and forward the packet back to the first server). The
	the request as one that is to be processed by itself. RADIUS has no		underlying reason that enables these loops is that the server
	built-in loop detection, so any such loops would remain undetected.		executing the discovery algorithm is seriously misconfigured in that
	So, if step 18 of the algorithm discovers such a possible-loop		it does not recognise the request as one that is to be processed by
	situation, the algorithm should be aborted and an error logged. Note		itself. RADIUS has no built-in loop detection, so any such loops
	that this safeguard does not provide perfect protection against		would remain undetected. So, if step 18 of the algorithm discovers
	routing loops: other reasons include the possiblity that a subsequent		such a possible-loop situation, the algorithm should be aborted and
	hop has a statically configured next-hop which leads to an earlier		an error logged. Note that this safeguard does not provide perfect
	host in the loop; or the algorithm execution was executed with greedy		protection against routing loops. One reason which might introduce a
	result evaluation, and the own address was in a lower-priority branch		loop include the possiblity that a subsequent hop has a statically
	of the result set which was not retrieved from DNS at all.		configured next-hop which leads to an earlier host in the loop.
			Another reason for occuring loops is if the algorithm was executed
			with greedy result evaluation, and the own address was in a lower-
			priority branch of the result set which was not retrieved from DNS at
			all, and thus can't be detected.
	After executing the above algorithm, the RADIUS server establishes a		After executing the above algorithm, the RADIUS server establishes a
	connection to a home server from the result set. This connection can		connection to a home server from the result set. This connection can
	potentially remain open for an indefinite amount of time. This		potentially remain open for an indefinite amount of time. This
	conflicts with the possibility of changing device and network		conflicts with the possibility of changing device and network
	configurations on the receiving end. Typically, TTL values for		configurations on the receiving end. Typically, TTL values for
	records in the name resolution system are used to indicate how long		records in the name resolution system are used to indicate how long
	it is safe to rely on the results of the name resolution. If these		it is safe to rely on the results of the name resolution. If these
	TTLs are very low, thrashing of connections becomes possible; the		TTLs are very low, thrashing of connections becomes possible; the
	Effective TTL mitigates that risk. When a connection is open and the		Effective TTL mitigates that risk. When a connection is open and the
	skipping to change at page 18, line 17		skipping to change at page 21, line 9
	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 timeout 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 controls 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
	RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example".		RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example".
	skipping to change at page 26, line 21		skipping to change at page 29, line 14
	[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		[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
	Transport Layer for RADIUS", RFC 7360, September 2014.		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-08 (work in progress), September 2014.		radext-nai-15 (work in progress), December 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
	skipping to change at page 28, line 19		skipping to change at page 31, line 19
	6, rue Richard Coudenhove-Kalergi		6, rue Richard Coudenhove-Kalergi
	Luxembourg 1359		Luxembourg 1359
	LUXEMBOURG		LUXEMBOURG
	Phone: +352 424409 1		Phone: +352 424409 1
	Fax: +352 422473		Fax: +352 422473
	EMail: stefan.winter@restena.lu		EMail: stefan.winter@restena.lu
	URI: http://www.restena.lu.		URI: http://www.restena.lu.
	Mike McCauley		Mike McCauley
	Open Systems Consultants		AirSpayce Pty Ltd
	9 Bulbul Place		9 Bulbul Place
	Currumbin Waters QLD 4223		Currumbin Waters QLD 4223
	AUSTRALIA		AUSTRALIA
	Phone: +61 7 5598 7474		Phone: +61 7 5598 7474
	Fax: +61 7 5598 7070		EMail: mikem@airspayce.com
	EMail: mikem@open.com.au		URI: http://www.airspayce.com
	URI: http://www.open.com.au.
End of changes. 21 change blocks.
	68 lines changed or deleted		169 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/