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/