draft-ietf-radext-dynamic-discovery-13.txt		draft-ietf-radext-dynamic-discovery-14.txt
	RADIUS Extensions Working Group S. Winter		RADIUS Extensions Working Group S. Winter
	Internet-Draft RESTENA		Internet-Draft RESTENA
	Intended status: Experimental M. McCauley		Intended status: Experimental M. McCauley
	Expires: September 7, 2015 AirSpayce		Expires: October 12, 2015 AirSpayce
	March 06, 2015		April 10, 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-13		draft-ietf-radext-dynamic-discovery-14
	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 7, 2015.		This Internet-Draft will expire on October 12, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	skipping to change at page 6, line 15		skipping to change at page 6, line 15
	1.2. Terminology		1.2. Terminology
	RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a		RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a
	new connection.		new connection.
	RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a		RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a
	RADIUS/TLS port and accepts new connections		RADIUS/TLS port and accepts new connections
	RADIUS/TLS node: a RADIUS/TLS client or server		RADIUS/TLS node: a RADIUS/TLS client or server
	[RFC4282] and its designated successor [I-D.ietf-radext-nai] define		[I-D.ietf-radext-nai] defines the terms NAI, realm, consortium.
	the terms NAI, realm, consortium. RFC Editor Note: please remove the
	RFC4282 reference here and in the Normative References section prior
	to publication and replace the draft NAI spec with its then-allocated
	RFC number.
	1.3. Document Status		1.3. Document Status
	This document is an Experimental RFC.		This document is an Experimental RFC.
	The communities expected to use this document are roaming consortia		The communities expected to use this document are roaming consortia
	whose authentication services are based on the RADIUS protocol.		whose authentication services are based on the RADIUS protocol.
	The duration of the experiment is undetermined; as soon as enough		The duration of the experiment is undetermined; as soon as enough
	experience is collected on the choice points mentioned below, it is		experience is collected on the choice points mentioned below, it is
	skipping to change at page 6, line 47		skipping to change at page 6, line 43
	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 Naming Authority		[RFC6733]. As such, the basic approach (using Naming Authority
	Pointer (NAPTR) records in DNS domains which match NAI realms) is not		Pointer (NAPTR) records in DNS domains which match NAI realms) is not
	of very experimental nature.		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
	skipping to change at page 8, line 8		skipping to change at page 8, line 6
	| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |		| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
	| radius.dtls.udp | RADIUS transported over DTLS as defined |		| radius.dtls.udp | RADIUS transported over DTLS as defined |
	| | in [RFC7360] |		| | in [RFC7360] |
	+-----------------+-----------------------------------------+		+-----------------+-----------------------------------------+
	Figure 4: 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.
	The use of the separator '.' is common also in other protocols'		The use of the separator '.' is common also in other protocols'
	protocol tags. This is coincidence and does not imply a shared		protocol tags. This is coincidence and does not imply a shared
	semantics with such protocols.		semantics with such protocols.
	skipping to change at page 8, line 46		skipping to change at page 8, line 44
	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
	connection setup whether or not it finds the connecting RADIUS/TLS		connection setup whether or not it finds the connecting RADIUS/TLS
	client authorized or not. If the connecting RADIUS/TLS client is not		client authorized or not. If the connecting RADIUS/TLS client is not
	found acceptable, the server will close the TLS connection		found acceptable, the server will close the TLS connection
	immediately with an appropriate alert. Such TLS handshake failures		immediately with an appropriate alert. Such TLS handshake failures
	are permanently fatal and not eligible for retry, unless the		are permanently fatal and not eligible for retry, unless the
	connecting client has more X.509 certificates to try; in this case, a		connecting client has more X.509 certificates to try; in this case, a
	retry with the remainder of its set of certificates SHOULD be		retry with the remainder of its set of certificates SHOULD be
	attempted.		attempted. Not trying all available client certificates potentially
			creates a DoS for the end-user whose authentication attempt triggered
			the discovery; one of the neglected certificates might have led to a
			successful RADIUS connection and subsequent end-user authentication.
	If the TLS session setup to a discovered target does not succeed,		If the TLS session setup to a discovered target does not succeed,
	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 (see
	expired or until the entity which executes the algorithm changes its		Section 3.3) has expired or until the entity which executes the
	TLS context to either send a new client certificate or expect a		algorithm changes its TLS context to either send a new client
	different server certificate.		certificate or expect a 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 discovery		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-PSK ciphersuites cannot be used in the subsequent TLS
	TLS handshake. Only TLS ciphersuites using X.509 certificates can be		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		For the approaches which use trust roots (see the following two
	skipping to change at page 11, line 5		skipping to change at page 11, line 6
	(other RADIUS attributes pertaining to the authentication, such as		(other RADIUS attributes pertaining to the authentication, such as
	the EAP peer's Calling-Station-ID, can still be learned though).		the EAP peer's Calling-Station-ID, can still be learned though).
	2.1.1.3.3. Other mechanism: DNSSEC / DANE		2.1.1.3.3. Other mechanism: DNSSEC / DANE
	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 server still needs to present an X.509
			certificate proving its authority to serve a particular realm.
	The authorization can be sketched using DNSSEC+DANE as follows: if		The authorization can be sketched using DNSSEC+DANE as follows: DANE/
	DANE/TLSA records of all authorized servers are put into a DNSSEC		TLSA records of all authorized servers are put into a DNSSEC zone
	zone with a common, consortium-specific branch of the DNS tree, then		which contains all known and authorised realms; the zone is rooted in
	the entity executing the algorithm can retrieve TLSA Resource Records		a common, consortium-agreed branch of the DNS tree. The entity
	(TLSA RR) for the label "realm.commonroot" and verify that the		executing the algorithm uses the realm information from the
	presented server certificate during the RADIUS/TLS handshake matches		authentication attempt, and then attempts to retrieve TLSA Resource
	the information in the TLSA record.		Records (TLSA RR) for the DNS label "realm.commonroot". It then
			verifies that the presented server certificate during the RADIUS/TLS
			handshake matches 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 12, line 5		skipping to change at page 12, line 5
	algorithm for a RADIUS client to contact and verify authorization of		algorithm for a RADIUS client to contact and verify authorization of
	a RADIUS server only. During connection setup, the RADIUS server		a RADIUS server only. During connection setup, the RADIUS server
	also needs to verify whether it considers the connecting RADIUS		also needs to verify whether it considers the connecting RADIUS
	client authorized; this is outside the scope of this specification.		client authorized; this is outside the scope of this specification.
	2.1.2. SRV		2.1.2. SRV
	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 |		| _radiusdtls._udp | RADIUS transported over DTLS as defined |
	| | in [RFC7360] |		| | in [RFC7360] |
	+-----------------+-----------------------------------------+		+-------------------+-----------------------------------------+
	Figure 5: 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
	skipping to change at page 13, line 13		skipping to change at page 13, line 13
	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.udp"		company.example. IN NAPTR 50 50 "a"
	"" roamserv.company.example		"aaa+auth:radius.dtls.udp" "" roamserv.company.example.
	c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses		c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses
	realms based on DNS, but provides its services to a closed		realms based on DNS, but provides its services to a closed
	community only. However, a AAA domain participating in eduroam		community only. However, a AAA domain participating in eduroam
	may also want to expose AAA services to other, general-purpose,		may also want to expose AAA services to other, general-purpose,
	applications (on the same or other RADIUS servers). Due to that,		applications (on the same or other RADIUS servers). Due to that,
	the eduroam consortium uses the service tag "x-eduroam" for		the eduroam consortium uses the service tag "x-eduroam" for
	authentication purposes and eduroam RADIUS servers use this tag		authentication purposes and eduroam RADIUS servers use this tag
	to look up other eduroam servers. An eduroam participant		to look up other eduroam servers. An eduroam participant
	example.org which also provides general-purpose AAA on a		example.org which also provides general-purpose AAA on a
	different server uses the general "aaa+auth" tag:		different server uses the general "aaa+auth" tag:
	example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" ""		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.tcp" ""		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. Regardless whether the results from DNS
	necessarily trustworthy (e.g. if DNSSEC is not deployed for the		discovery are trustworthy or not (e.g. DNSSEC in use), it is always
	queried domain name), it is important to verify that the server which		important to verify that the server which was contacted is authorized
	was contacted is authorized to service requests for the user which		to service requests for the user which triggered the discovery
	triggered the discovery process.		process.
	The input to the algorithm is an 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
	skipping to change at page 14, line 39		skipping to change at page 14, line 39
	makes subjectAltName:otherName:sRVName unsuited for this purpose.		makes subjectAltName:otherName:sRVName unsuited for this purpose.
	This section defines the NAIRealm name as a form of otherName from		This section defines the NAIRealm name as a form of otherName from
	the GeneralName structure in SubjectAltName defined in [RFC5280].		the GeneralName structure in SubjectAltName defined in [RFC5280].
	id-on-nai OBJECT IDENTIFIER ::= { id-on XXX }		id-on-nai OBJECT IDENTIFIER ::= { id-on XXX }
	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 the leftmost dot-separated
	separated part of the NAI with the single character "*" to indicate a		label of the NAI with the single character "*" to indicate a wildcard
	wildcard match for "all labels in this part". Further features of		match for "all labels in this part". Further features of regular
	regular expressions, such as a number of characters followed by a *		expressions, such as a number of characters followed by a * to
	to indicate a common prefix inside the part, are not permitted.		indicate a common prefix inside the part, are not permitted.
	The comparison of an 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.
	skipping to change at page 20, line 37		skipping to change at page 20, line 37
	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
	smallest of the Effective TTL value which was learned during		smallest of the Effective TTL value which was learned during
	discovering the server has not expired, subsequent new user sessions		discovering the server has not expired, subsequent new user sessions
	for the realm which corresponds to that open connection SHOULD re-use		for the realm which corresponds to that open connection SHOULD re-use
	the existing connection and SHOULD NOT re-execute the dynamic		the existing connection and SHOULD NOT re-execute the dynamic
	discovery algorithm nor open a new connection. To allow for a change		discovery algorithm nor open a new connection. To allow for a change
	of configuration, a RADIUS server SHOULD re-execute the dynamic		of configuration, a RADIUS server SHOULD re-execute the dynamic
	discovery algorithm after the Effective TTL that is associated with		discovery algorithm after the Effective TTL that is associated with
	this connection has expired. The server MAY keep the session open		this connection has expired. The server SHOULD keep the session open
	during this re-assessment to avoid closure and immediate re-opening		during this re-assessment to avoid closure and immediate re-opening
	of the connection should the result not have changed.		of the connection should the result not have changed.
	Should the algorithm above terminate with O-1 = empty set, the RADIUS		Should the algorithm above terminate with O-1 = empty set, the RADIUS
	server SHOULD NOT attempt another execution of this algorithm for the		server SHOULD NOT attempt another execution of this algorithm for the
	same target realm before the timeout O-2 has passed.		same target realm before the timeout O-2 has passed.
	3.4.5. Delay considerations		3.4.5. Delay considerations
	The host's name resolution library may need to contact outside		The host's name resolution library may need to contact outside
	skipping to change at page 24, line 22		skipping to change at page 24, line 22
	A roaming consortium's roaming agreement must include a profile of		A roaming consortium's roaming agreement must include a profile of
	which choice points of this document to use. So long as the roaming		which choice points of this document to use. So long as the roaming
	consortium can settle on one deployment profile, they will be able to		consortium can settle on one deployment profile, they will be able to
	interoperate based on that choice; this per-consortium		interoperate based on that choice; this per-consortium
	interoperability is the intended scope of this document.		interoperability is the intended scope of this document.
	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 of the discovery process can not be
	be trusted (i.e. DNSSEC is in use), actual authorization of the		trusted. Even if it can be trusted (i.e. DNSSEC is in use), actual
	discovered server to provide service for the given realm needs to be		authorization of the discovered server to provide service for the
	verified. A mechanism from section Section 2.1.1.3 or equivalent		given realm needs to be verified. A mechanism from section
	MUST be used to verify authorization.		Section 2.1.1.3 or equivalent MUST be used to verify authorization.
	The algorithm has a configurable completion timeout 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-
	skipping to change at page 27, line 22		skipping to change at page 27, line 22
	* radius.tls.tcp		* radius.tls.tcp
	* radius.dtls.udp		* 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 (for radiustls), UDP (for radiusdtls)
	Assignee: IESG <iesg@ietf.org>		Assignee: IESG <iesg@ietf.org>
	Contact: IETF Chair <chair@ietf.org>		Contact: IETF Chair <chair@ietf.org>
	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.
	skipping to change at page 28, line 32		skipping to change at page 28, line 32
	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)", RFC		"Remote Authentication Dial In User Service (RADIUS)", RFC
	2865, June 2000.		2865, June 2000.
	[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.		[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
	[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application		[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
	Service Location Using SRV RRs and the Dynamic Delegation		Service Location Using SRV RRs and the Dynamic Delegation
	Discovery Service (DDDS)", RFC 3958, January 2005.		Discovery Service (DDDS)", RFC 3958, January 2005.
	[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
	Network Access Identifier", RFC 4282, December 2005.
	[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.		[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
	Aboba, "Dynamic Authorization Extensions to Remote		Aboba, "Dynamic Authorization Extensions to Remote
	Authentication Dial In User Service (RADIUS)", RFC 5176,		Authentication Dial In User Service (RADIUS)", RFC 5176,
	January 2008.		January 2008.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	skipping to change at page 29, line 37		skipping to change at page 29, line 33
	[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		[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
	Working Group", RFC 7299, July 2014.		Working Group", RFC 7299, July 2014.
	[I-D.wierenga-ietf-eduroam]		[I-D.wierenga-ietf-eduroam]
	Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam		Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
	architecture for network roaming", draft-wierenga-ietf-		architecture for network roaming", draft-wierenga-ietf-
	eduroam-04 (work in progress), August 2014.		eduroam-05 (work in progress), March 2015.
	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. 21 change blocks.
	59 lines changed or deleted		58 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/