draft-ietf-radext-dynamic-discovery-07.txt   draft-ietf-radext-dynamic-discovery-08.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: January 05, 2014 OSC Expires: April 19, 2014 OSC
July 04, 2013 October 16, 2013
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-07 draft-ietf-radext-dynamic-discovery-08
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 January 05, 2014. This Internet-Draft will expire on April 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 20 skipping to change at page 2, line 20
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3
2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Remarks . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Remarks . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . 10
3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Configuration Variables . . . . . . . . . . . . . . . . . 11 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 11
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Realm to RADIUS server resolution algorithm . . . . . . . 12 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 12
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 13 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 13
3.4.4. Validity of results . . . . . . . . . . . . . . . . . 15 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 15
3.4.5. Delay considerations . . . . . . . . . . . . . . . . 16 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 16
3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
6. Normative References . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 21 7. Normative References . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 23
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/TLS,
RADIUS/DTLS) requires manual configuration of all peers (clients, RADIUS/DTLS) requires manual configuration of all peers (clients,
servers). servers).
Where RADIUS forwarding servers are in use, the number of realms to Where RADIUS forwarding servers are in use, the number of realms to
be forwarded and the corresponding number of servers to configure may be forwarded and the corresponding number of servers to configure may
be significant. Where new realms with new servers are added or be significant. Where new realms with new servers are added or
skipping to change at page 5, line 24 skipping to change at page 5, line 24
failure; so even if a discovered target returns a wrong credential failure; so even if a discovered target returns a wrong credential
instantly, it is not eligible for retry. instantly, it is not eligible for retry.
Furthermore, the contacted RADIUS/TLS server verifies during Furthermore, the contacted RADIUS/TLS server verifies during
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. are permanently fatal and not eligible for retry.
If the TLS session setup to a discovered target does not succeed,
that target (as identified by IP address and port number) SHOULD be
ignored from the result set of any subsequent executions of the
discovery algorithm at least until the target's Effective TTL has
expired or until the entity which executes the algorithm changes its
TLS context to either send a new client 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 algorithm does session as per [RFC6614] is established. Since the algorithm does
not allow to derive confidential keying material between the RADIUS/ not allow to derive confidential keying material between the RADIUS/
TLS client (i.e. the server which executes the discovery algorithm) TLS client (i.e. the server which executes the discovery algorithm)
and the RADIUS/TLS server which was discovered, TLS-PSK ciphersuites and the RADIUS/TLS server which was discovered, TLS-PSK ciphersuites
can not be used for the subsequent TLS handshake in the RADIUS/TLS can not be used for the subsequent TLS handshake in the RADIUS/TLS
conversation. Only TLS ciphersuites using X.509 certificates can be conversation. Only TLS ciphersuites using X.509 certificates can be
used with this algorithm. used with this algorithm.
skipping to change at page 6, line 17 skipping to change at page 6, line 26
"subjectAlternativeName:otherName:NAIRealm" as defined in "subjectAlternativeName:otherName:NAIRealm" as defined in
Section 2.2. The comparison is a byte-by-byte comparison, except for Section 2.2. The comparison is a byte-by-byte comparison, except for
dot-separated parts of the value whose content is a single "*" dot-separated parts of the value whose content is a single "*"
character; such labels match all strings in the same part of the NAI character; such labels match all strings in the same part of the NAI
realm. If at least one of the sAN:otherName:NAIRealm values matches realm. If at least one of the sAN:otherName:NAIRealm values matches
the NAI realm, the server is considered authorized; if none matches, the NAI realm, the server is considered authorized; if none matches,
the server is considered unauthorized. the server is considered unauthorized.
Examples: Examples:
+-----------------+---------------------------------------------+ +-----------------+-----------------------------------------------+
| NAI realm | sAN:otherName:NAIRealm | MATCH? | | NAI realm | NAIRealm | MATCH? |
+-----------------+---------------------------------------------+ +-----------------+-----------------------------------------------+
| foo.example | foo.example | YES | | foo.example | foo.example | YES |
| foo.example | *.example | YES | | foo.example | *.example | YES |
| bar.foo.example | *.example | NO | | bar.foo.example | *.example | NO |
| bar.foo.example | bar.*.example | YES | | bar.foo.example | bar.*.example | NO (NAIRealm invalid) |
| bar.foo.example | *.*.example | YES | | bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.*.example | NO | | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | sub.bar.foo.example | YES | | sub.bar.foo.example | *.bar.foo.example | YES |
+-----------------+---------------------------------------------+ +-----------------+-----------------------------------------------+
Figure 3: Examples for NAI realm vs. certificate matching Figure 3: Examples for NAI realm vs. certificate matching
2.1.1.3.2. Other mechanism: Trust Roots + policyOID 2.1.1.3.2. Other mechanism: Trust Roots + policyOID
Verification of authority to provide AAA services over RADIUS/TLS is Verification of authority to provide AAA services over RADIUS/TLS is
a two-step process. a two-step process.
Step 1 is the verification of certificate wellformedness and validity Step 1 is the verification of certificate wellformedness and validity
as per [RFC5280] and whether it was issued from a root certificate as per [RFC5280] and whether it was issued from a root certificate
skipping to change at page 10, line 50 skipping to change at page 11, line 4
a trusted comparison item. a trusted comparison item.
Further to this, this specification's NAPTR entries may be of type Further to this, this specification's NAPTR entries may be of type
"A" which do not involve resolution of any SRV records, which again "A" which do not involve resolution of any SRV records, which again
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 all dot-separated [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot-
parts of the NAI with the single character "*" to indicate a wildcard separated part of the NAI with the single character "*" to indicate a
match for "all labels in this part". Further features of regular wildcard match for "all labels in this part". Further features of
expressions, such as a number of characters followed by a * to regular expressions, such as a number of characters followed by a *
indicate a common prefix inside the part, are not permitted. to indicate a common prefix inside the part, are not permitted.
This subjectAltName MAY occur more than once in a certificate. This subjectAltName MAY occur more than once in a certificate.
Appendix A contains the ASN.1 definition of the above objects. Appendix A contains the ASN.1 definition of the above objects.
3. DNS-based NAPTR/SRV Peer Discovery 3. DNS-based NAPTR/SRV Peer Discovery
3.1. Applicability 3.1. Applicability
Dynamic server discovery as defined in this document is only Dynamic server discovery as defined in this document is only
skipping to change at page 12, line 25 skipping to change at page 12, line 28
Effective TTL: The validity period for discovered RADIUS/TLS target Effective TTL: The validity period for discovered RADIUS/TLS target
hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { hosts. Calculated as: Effective TTL (set of DNS TTL values) = max {
MIN_EFF_TTL, min { DNS TTL values } } MIN_EFF_TTL, min { DNS TTL values } }
SRV lookup: for the purpose of this specification, SRV lookup SRV lookup: for the purpose of this specification, SRV lookup
procedures are defined as per [RFC2782], but excluding that RFCs "A" procedures are defined as per [RFC2782], but excluding that RFCs "A"
fallback as defined in its section "Usage Rules", final "else" fallback as defined in its section "Usage Rules", final "else"
clause. clause.
Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead
to a tree of results, whose leafs are the IP addresses to contact.
The branches of the tree are ordered according to their order/
preference DNS properties. An implementation is executing greedy
result evaluation if it uses a depth-first search in the tree along
the highest order results, attempts to connect to the corresponding
resulting IP addresses, and only backtracks to other branches if the
higher ordered results did not end in successful connection attempts.
3.4. Realm to RADIUS server resolution algorithm 3.4. Realm to RADIUS server resolution algorithm
3.4.1. Input 3.4.1. Input
For RADIUS Authentication and RADIUS Accounting server discovery, For RADIUS Authentication and RADIUS Accounting server discovery,
input I to the algorithm is the RADIUS User-Name attribute with input I to the algorithm is the RADIUS User-Name attribute with
content of the form "user@realm"; the literal @ sign being the content of the form "user@realm"; the literal @ sign being the
separator between a local user identifier within a realm and its separator between a local user identifier within a realm and its
realm. The use of multiple literal @ signs in a User-Name is realm. The use of multiple literal @ signs in a User-Name is
strongly discouraged; but if present, the last @ sign is to be strongly discouraged; but if present, the last @ sign is to be
skipping to change at page 14, line 15 skipping to change at page 14, line 26
returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and
terminate. terminate.
7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct",
"aaa+dynauth" as appropriate. Keep note of the remaining TTL of "aaa+dynauth" as appropriate. Keep note of the remaining TTL of
each of the discovered NAPTR records. each of the discovered NAPTR records.
8. If no records found, continue at step 13. 8. If no records found, continue at step 13.
9. For the extracted NAPTRs, perform successive resolution as 9. For the extracted NAPTRs, perform successive resolution as
defined in [RFC3958], section 2.2.4, with the additional defined in [RFC3958], section 2.2. An implementation MAY use
reservation that all records are to be immediately pursued greedy result evaluation according to the NAPTR order/preference
through terminal lookup, i.e. have resulted in hostnames. fields (i.e. can execute the subsequent steps of this algorithm
Failure to achieve terminal lookup for individual records is for the highest-order entry in the set of results, and only
non-fatal. lookup the remainder of the set if necessary).
10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 =
BACKOFF_TIME and terminate. BACKOFF_TIME and terminate.
11. O' = (set of {hostname; port; order/preference; Effective TTL ( 11. O' = (set of {hostname; port; order/preference; Effective TTL (
all DNS TTLs that led to this hostname ) } for all terminal all DNS TTLs that led to this hostname ) } for all terminal
lookup results). lookup results).
12. Proceed with step 18. 12. Proceed with step 18.
skipping to change at page 15, line 30 skipping to change at page 15, line 42
the server would forward the request to itself, triggering dynamic the server would forward the request to itself, triggering dynamic
discovery again in a perpetual loop), or lead to a potential loop discovery again in a perpetual loop), or lead to a potential loop
with intermediate hops in between (the server could forward to with intermediate hops in between (the server could forward to
another host with a higher priority, which might use DNS itself and another host with a higher priority, which might use DNS itself and
forward the packet back to the first server). The underlying reason forward the packet back to the first server). The underlying reason
that enables these loops is that the server executing the discovery that enables these loops is that the server executing the discovery
algorithm is seriously misconfigured in that it does not recognise algorithm is seriously misconfigured in that it does not recognise
the request as one that is to be processed by itself. RADIUS has no the request as one that is to be processed by itself. RADIUS has no
built-in loop detection, so any such loops would remain undetected. built-in loop detection, so any such loops would remain undetected.
So, if step 18 of the algorithm discovers such a possible-loop So, if step 18 of the algorithm discovers such a possible-loop
situation, the algorithm should be aborted and an error logged. situation, the algorithm should be aborted and an error logged. Note
that this safeguard does not provide perfect protection against
routing loops: other reasons include the possiblity that a subsequent
hop has a statically configured next-hop which leads to an earlier
host in the loop; or the algorithm execution was executed with greedy
result evaluation, and the own address was in a lower-priority branch
of the result set which was not retrieved from DNS at all.
After executing the above algorithm, the RADIUS server establishes a After executing the above algorithm, the RADIUS server establishes a
connection to a home server from the result set. This connection can connection to a home server from the result set. This connection can
potentially remain open for an indefinite amount of time. This potentially remain open for an indefinite amount of time. This
conflicts with the possibility of changing device and network conflicts with the possibility of changing device and network
configurations on the receiving end. Typically, TTL values for configurations on the receiving end. Typically, TTL values for
records in the name resolution system are used to indicate how long records in the name resolution system are used to indicate how long
it is safe to rely on the results of the name resolution. If these it is safe to rely on the results of the name resolution. If these
TTLs are very low, thrashing of connections becomes possible; the TTLs are very low, thrashing of connections becomes possible; the
Effective TTL mitigates that risk. When a connection is open and the Effective TTL mitigates that risk. When a connection is open and the
skipping to change at page 19, line 42 skipping to change at page 20, line 7
responses to track, or at least the number of pending DNS queries. responses to track, or at least the number of pending DNS queries.
Implementations MAY choose lower values than the default for Implementations MAY choose lower values than the default for
DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They
MAY also continue their attempt to resolve DNS records even after MAY also continue their attempt to resolve DNS records even after
DNS_TIMEOUT has passed; a subsequent request for the same realm might DNS_TIMEOUT has passed; a subsequent request for the same realm might
benefit from retrieving the results anyway. The amount of time to benefit from retrieving the results anyway. The amount of time to
spent waiting for a result will influence the impact of a possible spent waiting for a result will influence the impact of a possible
DoS attack; the waiting time value is implementation dependent and DoS attack; the waiting time value is implementation dependent and
outside the scope of this specification. outside the scope of this specification.
5. IANA Considerations With Dynamic Discovery being enabled for a RADIUS Server, and
depending on the deployment scenario, the server may need to open up
its target IP address and port for the entire internet, because
arbitrary clients may discover it as a target for their
authentication requests. If such clients are not part of the roaming
consortium, the RADIUS/TLS connection setup phase will fail (which is
intended) but the computational cost for the connection attempt is
significant. With the port for a TLS-based service open, the RADIUS
server shares all the typical attack vectors for services based on
TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with
Dynamic Discovery should consider these attack vectors and take
appropriate counter-measures (e.g. blacklisting known-bad IPs on a
firewall, rate-limiting new connection attempts, etc.).
5. Privacy Considerations
The classic RADIUS operational model (known, pre-configured peers,
shared secret security, mostly plaintext communication) and this new
RADIUS dynamic discovery model (peer discovery with DNS, PKI security
and packet confidentiality) differ significantly in their impact on
the privacy of end users trying to authenticate to a RADIUS server.
With classic RADIUS, traffic in large environments gets aggregated by
statically configured clearinghouses. The packets sent to those
clearinghouses and their responses are mostly unprotected. As a
consequence,
o All intermediate IP hops can inspect most of the packet payload in
clear text, including the User-Name and Calling-Station-Id
attributes, and can observe which client sent the packet to which
clearinghouse. This allows the creation of mobility profiles for
any passive observer on the IP path.
o The existence of a central clearinghouse creates an opportunity
for the clearinghouse to trivially create the same mobility
profiles. The clearinghouse may or may not be trusted not to do
this, e.g. by sufficiently threatening contractual obligations.
o In addition to that, with the clearinghouse being a RADIUS
intermediate in possession of a valid shared secret, the
clearinghouse can observe and record even the security-critical
RADIUS attributes such as User-Password. This risk may be
mitigated by choosing authentication payloads which are
cryptographically secured and do not use the attribute User-
Password - such as certain EAP types.
o There is no additional information disclosure to parties outside
the IP path between the RADIUS client and server (in aprticular,
no DNS servers learn about realms of current ongoing
authentications).
With RADIUS and dynamic discovery,
o Passive observers on the IP path cannot inspect any part of the
RADIUS payload. They can observe source and destination of the
traffic flow, but can not easily use this information to create
mobility profiles because the user who tries to authenticate is
not identifiable due to the encrypted payload.
o Clearinghouses can be eliminated by RADIUS clients directly
contacting the RADIUS home server, if this is desired. The
possibility of aggregation of user information in the
clearinghouse thus does not manifest. Note that despite the
technical possibility of avoid clearinghouses, they may still
remain in operation for other reasons.
o RADIUS clients which make use of dynamic discovery will need to
query the Domain Name System, and use a user's realm name as the
query label. A passive observer on the IP path between the RADIUS
client and the DNS server(s) being queried can learn that a user
of that specific realm was trying to authenticate at that RADIUS
client at a certain point in time. This may or may not be
sufficient for the passive observer to create a mobility profile.
During the recursive DNS resolution, a fair number of DNS servers
and the IP hops in between those get to learn that information.
Not every single authentication triggers DNS lookups, so there is
no one-to-one relation of leaked realm information and the number
of authentications for that realm.
In summary, with classic RADIUS, few intermediate entities learn very
detailed data about every ongoing authentications, while with dynamic
discovery, many entities learn only very little about recently
authenticated realms.
6. 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
skipping to change at page 20, line 23 skipping to change at page 22, line 23
Service labels. Service labels.
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
6. Normative References This specification allocates a X.509 certificate property "NAIRealm"
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. 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
 End of changes. 14 change blocks. 
33 lines changed or deleted 149 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/