draft-ietf-radext-dynamic-discovery-10.txt		draft-ietf-radext-dynamic-discovery-11.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: August 18, 2014 OSC		Expires: September 4, 2014 OSC
	February 14, 2014		March 03, 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-10		draft-ietf-radext-dynamic-discovery-11
	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 August 18, 2014.		This Internet-Draft will expire on September 4, 2014.
	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 10		skipping to change at page 2, line 10
	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 . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4
	2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3		2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 4
	2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.3. Optional name mangling . . . . . . . . . . . . . . . 8		2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 10		SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11
	3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11		3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12
	3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11		3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12
	3.2. Configuration Variables . . . . . . . . . . . . . . . . . 12		3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13
	3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.4. Realm to RADIUS server resolution algorithm . . . . . . . 13		3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14
	3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13		3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 14		3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 15
	3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 14		3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 15
	3.4.4. Validity of results . . . . . . . . . . . . . . . . . 16		3.4.4. Validity of results . . . . . . . . . . . . . . . . . 17
	3.4.5. Delay considerations . . . . . . . . . . . . . . . . 17		3.4.5. Delay considerations . . . . . . . . . . . . . . . . 18
	3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 17		3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 18
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 19		4. Operations and Manageability Considerations . . . . . . . . . 20
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20		5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	7.1. Normative References . . . . . . . . . . . . . . . . . . 23		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	7.2. Informative References . . . . . . . . . . . . . . . . . 24		8.1. Normative References . . . . . . . . . . . . . . . . . . 25
	Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 25		8.2. Informative References . . . . . . . . . . . . . . . . . 26
			Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 27
	1. Introduction		1. Introduction
	RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS,		RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP,
	RADIUS/DTLS) requires manual configuration of all peers (clients,		RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers
	servers).		(clients, servers).
	Where RADIUS forwarding servers are in use, the number of realms to		Where more than one administrative entity collaborates for RADIUS
	be forwarded and the corresponding number of servers to configure may		authentication of their respective customers (a "roaming
	be significant. Where new realms with new servers are added or		consortium"), the Network Access Identifier (NAI)
	details of existing servers change on a regular basis, maintaining a		[I-D.ietf-radext-nai] is the suggested way of differentiating users
	single monolithic configuration file for all these details may prove		between those entities; the part of a username to the right of the @
	too cumbersome to be useful.		delimiter in a NAI is called the user's "realm". Where many realms
			and RADIUS forwarding servers are in use, the number of realms to be
			forwarded and the corresponding number of servers to configure may be
			significant. Where new realms with new servers are added or details
			of existing servers change on a regular basis, maintaining a single
			monolithic configuration file for all these details may prove too
			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, each with their own forwarding		independently working branches (e.g. departments, national
	servers, and who add or change their realm lists at their own		subsidiaries), each with their own forwarding servers, and who add or
	discretion, there is additional complexity in synchronising the		change their realm lists at their own discretion, there is additional
	changed data across all branches.		complexity in synchronising the changed data across all branches.
	These situations can benefit significantly from a distributed		These situations can benefit significantly from a distributed
	mechanism for storing realm and server reachability information.		mechanism for storing realm and server reachability information.
	This document describes one such mechanism: storage of realm-to-		This document describes one such mechanism: storage of realm-to-
	server mappings in DNS.		server mappings in DNS.
	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
	skipping to change at page 3, line 36		skipping to change at page 3, line 43
	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
			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
			This document is an Experimental RFC.
			The communities expected to use this document are roaming consortia
			whose authentication services are based on the RADIUS protocol.
			The duration of the experiment is undetermined; as soon as enough
			experience is collected on the choice points mentioned below, it is
			expected to be obsoleted by a standards-track version of the protocol
			which trims down the choice points.
			If that removal of choice points obsoletes tags or service names as
			defined in this document and allocated by IANA, these items will be
			returned to IANA as per the provisions in [RFC6335].
			The document provides a discovery mechanism for RADIUS which is very
			similar to the approach that is taken with the Diameter protocol
			[RFC6733]. As such, the basic approach (using 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
			go beyond the provisions for Diameter. The list of major additions/
			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
			users of a realm (declared out of scope for Diameter)
			o much more in-depth guidance on DNS regarding timeouts, failure
			conditions, alteration of TTLs (not considered for Diameter)
			o a partially correct routing error detection (not considered for
			Diameter)
	2. Definitions		2. Definitions
	2.1. DNS RR definition		2.1. DNS 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 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
	skipping to change at page 9, line 23		skipping to change at page 10, line 23
	example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" ""		example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" ""
	_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. "Bad, Inc." is part of the consortium. On the		realm names. "Company, Inc." is part of the consortium. On the
	consortium's DNS server, realm bad.example might have the		consortium's DNS server, realm company.example might have the
	following DNS entries:		following DNS entries:
	bad.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" ""		company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" ""
	very.bad.example		roamserv.company.example
	c. The eduroam consortium uses realms based on DNS, but provides its		c. The eduroam consortium uses realms based on DNS, but provides its
	services to a closed community only. However, a AAA domain		services to a closed community only. However, a AAA domain
	participating in eduroam may also want to expose AAA services to		participating in eduroam may also want to expose AAA services to
	other, general-purpose, applications (on the same or other RADIUS		other, general-purpose, applications (on the same or other RADIUS
	servers). Due to that, the eduroam consortium uses the service		servers). Due to that, the eduroam consortium uses the service
	tag "x-eduroam" for authentication purposes and eduroam RADIUS		tag "x-eduroam" for authentication purposes and eduroam RADIUS
	servers use this tag to look up other eduroam servers. An		servers use this tag to look up other eduroam servers. An
	eduroam participant example.org which also provides general-		eduroam participant example.org which also provides general-
	purpose AAA on a different server uses the general "aaa+auth"		purpose AAA on a different server uses the general "aaa+auth"
	skipping to change at page 19, line 15		skipping to change at page 20, line 15
	(TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example.		(TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example.
	10. NOOP		10. NOOP
	11. O' = {		11. O' = {
	(radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10;		(radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10;
	60),		60),
	(backup.xn--tu-mnchen-t9a.example.; 2083; 20; 60)		(backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60)
	} // minimum TTL is 47, up'ed to MIN_EFF_TTL		} // minimum TTL is 47, up'ed to MIN_EFF_TTL
	12. Continuing at 18.		12. Continuing at 18.
	13. (not executed)		13. (not executed)
	14. (not executed)		14. (not executed)
	15. (not executed)		15. (not executed)
	skipping to change at page 19, line 46		skipping to change at page 20, line 46
	}; O-2 = 0		}; O-2 = 0
	19. No match with own listening address; terminate with tuple (O-1,		19. No match with own listening address; terminate with tuple (O-1,
	O-2) from previous step.		O-2) from previous step.
	The implementation will then attempt to connect to two servers, with		The implementation will then attempt to connect to two servers, with
	preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/		preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/
	TLS protocol.		TLS protocol.
	4. Security Considerations		4. Operations and Manageability Considerations
			The discovery algorithm as defined in this document contains several
			options; the major ones being use of NAPTR vs. SRV; how to determine
			the authorization status of a contacted server for a given realm;
			which trust anchors to consider trustworthy for the RADIUS
			conversation setup.
			Random parties which do not agree on the same set of options may not
			be able to interoperate. However, such a global interoperability is
			not intended by this document.
			Discovery as per this document becomes important inside a roaming
			consortium, which has set up roaming agreements with the other
			partners. Such roaming agreements require much more than a technical
			means of server discovery; there are administrative and contractual
			considerations at play (service contracts, backoffice compensations,
			procedures, ...).
			A roaming consortium's roaming agreement must include a profile of
			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
			interoperate based on that choice; this per-consortium
			interoperability is the intended scope of this document.
			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 time-out DNS_TIMEOUT
	skipping to change at page 20, line 43		skipping to change at page 22, line 21
	authentication requests. If such clients are not part of the roaming		authentication requests. If such clients are not part of the roaming
	consortium, the RADIUS/TLS connection setup phase will fail (which is		consortium, the RADIUS/TLS connection setup phase will fail (which is
	intended) but the computational cost for the connection attempt is		intended) but the computational cost for the connection attempt is
	significant. With the port for a TLS-based service open, the RADIUS		significant. With the port for a TLS-based service open, the RADIUS
	server shares all the typical attack vectors for services based on		server shares all the typical attack vectors for services based on
	TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with		TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with
	Dynamic Discovery should consider these attack vectors and take		Dynamic Discovery should consider these attack vectors and take
	appropriate counter-measures (e.g. blacklisting known-bad IPs on a		appropriate counter-measures (e.g. blacklisting known-bad IPs on a
	firewall, rate-limiting new connection attempts, etc.).		firewall, rate-limiting new connection attempts, etc.).
	5. Privacy Considerations		6. Privacy Considerations
	The classic RADIUS operational model (known, pre-configured peers,		The classic RADIUS operational model (known, pre-configured peers,
	shared secret security, mostly plaintext communication) and this new		shared secret security, mostly plaintext communication) and this new
	RADIUS dynamic discovery model (peer discovery with DNS, PKI security		RADIUS dynamic discovery model (peer discovery with DNS, PKI security
	and packet confidentiality) differ significantly in their impact on		and packet confidentiality) differ significantly in their impact on
	the privacy of end users trying to authenticate to a RADIUS server.		the privacy of end users trying to authenticate to a RADIUS server.
	With classic RADIUS, traffic in large environments gets aggregated by		With classic RADIUS, traffic in large environments gets aggregated by
	statically configured clearinghouses. The packets sent to those		statically configured clearinghouses. The packets sent to those
	clearinghouses and their responses are mostly unprotected. As a		clearinghouses and their responses are mostly unprotected. As a
	skipping to change at page 22, line 29		skipping to change at page 24, line 5
	there is no guarantee that the RADIUS payload is not transmitted		there is no guarantee that the RADIUS payload is not transmitted
	between RADIUS systems which do not make use of this algorithm,		between RADIUS systems which do not make use of this algorithm,
	and possibly using other transports such as RADIUS/UDP. On such		and possibly using other transports such as RADIUS/UDP. On such
	hops, the enhanced privacy is jeopardized.		hops, the enhanced privacy is jeopardized.
	In summary, with classic RADIUS, few intermediate entities learn very		In summary, with classic RADIUS, few intermediate entities learn very
	detailed data about every ongoing authentications, while with dynamic		detailed data about every ongoing authentications, while with dynamic
	discovery, many entities learn only very little about recently		discovery, many entities learn only very little about recently
	authenticated realms.		authenticated realms.
	6. IANA Considerations		7. IANA Considerations
	This document requests IANA registration of the following entries in		This document requests IANA registration of the following entries in
	existing registries:		existing registries:
	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
	* radius.dtls		* radius.dtls
	This document reserves the use of the "_radiustls" and "_radiusdtls"		This document reserves the use of the "radiustls" and "radiusdtls"
	Service labels.		service names. Registration information as per [RFC6335] section
			8.1.1 is as follows:
			Service Name: radiustls; radiusdtls
			Transport Protocols: TCP, UDP
			Assignee: IESG <iesg@ietf.org>
			Contact: IETF Chair <chair@ietf.org>
			Description: Authentication, Accounting and Dynamic authorization
			via the RADIUS protocol. These service names are used to
			construct the SRV service labels "_radiustls" and "_radiusdtls"
			for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively.
			Reference: RFC Editor Note: please insert the RFC number of this
			document. The protocol does not use broadcast, multicast or
			anycast communication.
	This document requests the creation of a new IANA registry named		This document requests the creation of a new IANA registry named
	"RADIUS/TLS SRV Protocol Registry" with the following initial		"RADIUS/TLS SRV Protocol Registry" with the following initial
	entries:		entries:
	o _tcp		o _tcp
	o _udp		o _udp
			This document requires that a number of Object Identifiers be
			assigned. They re now under the control of IANA following [I-D
			.housley-pkix-oids].
	This specification allocates a X.509 certificate property "NAIRealm"		IANA is requested to assign the following identifiers:
	as per section Section 2.2 above, see placeholders "XXX". There is
	currently no IANA registry for the subjectAltName:otherName
	namespace. The authority for this namespace appears to be the PKIX
	working group. Before issuing the RFC, IANA should liaise with PKIX
	to ensure that a value for NAIRealm is issued; IANA should
	subsequently, prior to issuing the RFC, update the placeholders in
	said section.
	7. References		TBD99 is to be assigned from the "SMI Security for PKIX Module
			Identifier Registry". The suggested description is id-mod-nai-
			realm-08.
	7.1. Normative References		TBD98 is to be assigned from the "SMI Security for PKIX Other Name
			Forms Registry." The suggested description is id-on-nai.
			RFC Editor Note: please replace the occurences of TBD98 and TBD99 in
			Appendix A of the document with the actually assigned numbers.
			8. References
			8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
	[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 24, line 24		skipping to change at page 26, line 29
	ietf-radext-dtls-07 (work in progress), October 2013.		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.
	[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-05 (work in progress), November 2013.
	7.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.
			Cheshire, "Internet Assigned Numbers Authority (IANA)
			Procedures for the Management of the Service Name and
			Transport Protocol Port Number Registry", BCP 165, RFC
			6335, August 2011.
			[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
			"Diameter Base Protocol", RFC 6733, October 2012.
	Appendix A. Appendix A: ASN.1 Syntax of NAIRealm		Appendix A. Appendix A: ASN.1 Syntax of NAIRealm
	PKIXServiceNameSAN93 {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-dns-srv-name-93(40) }		id-mod-nai-realm-08 (TBD99) }
	DEFINITIONS EXPLICIT TAGS ::=		DEFINITIONS EXPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS ALL --		-- EXPORTS ALL --
	IMPORTS		IMPORTS
	id-pkix		id-pkix
	FROM PKIX1Explicit-2009		FROM PKIX1Explicit-2009
	{iso(1) identified-organization(3) dod(6) internet(1)		{iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkix1-explicit-02(51)}		id-mod-pkix1-explicit-02(51)}
	-- from RFC 5280		-- from RFC 5280, RFC 5912
	OTHER-NAME		OTHER-NAME
	FROM PKIX1Implicit-2009		FROM PKIX1Implicit-2009
	{iso(1) identified-organization(3) dod(6) internet(1) security(5)		{iso(1) identified-organization(3) dod(6) internet(1) security(5)
	mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}		mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
			-- from RFC 5280, RFC 5912
	;		;
	-- Service Name Object Identifier		-- Service Name Object Identifier
	id-on OBJECT IDENTIFIER ::= { id-pkix 8 }		id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
	id-on-nai OBJECT IDENTIFIER ::= { id-on 99999 }		id-on-nai OBJECT IDENTIFIER ::= { id-on TBD98 }
	-- Service Name		-- Service Name
	naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }}		naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }}
	NAIRealm ::= UTF8String (SIZE (1..MAX))		NAIRealm ::= UTF8String (SIZE (1..MAX))
	END		END
	Authors' Addresses		Authors' Addresses
End of changes. 28 change blocks.
	66 lines changed or deleted		179 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/