idnits 2.17.1 draft-ietf-radext-dynamic-discovery-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 03, 2014) is 3707 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-13) exists of draft-ietf-radext-dtls-07 == Outdated reference: A later version (-15) exists of draft-ietf-radext-nai-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Extensions Working Group S. Winter 3 Internet-Draft RESTENA 4 Intended status: Experimental M. McCauley 5 Expires: September 4, 2014 OSC 6 March 03, 2014 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-11 11 Abstract 13 This document specifies a means to find authoritative RADIUS servers 14 for a given realm. It is used in conjunction with either RADIUS/TLS 15 and RADIUS/DTLS. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 4, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 4 57 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9 60 2.2. Definition of the X.509 certificate property 61 SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11 62 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12 63 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12 64 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13 65 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14 67 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14 68 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 15 69 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 15 70 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 17 71 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 18 72 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 18 73 4. Operations and Manageability Considerations . . . . . . . . . 20 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 79 8.2. Informative References . . . . . . . . . . . . . . . . . 26 80 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 27 82 1. Introduction 84 RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, 85 RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers 86 (clients, servers). 88 Where more than one administrative entity collaborates for RADIUS 89 authentication of their respective customers (a "roaming 90 consortium"), the Network Access Identifier (NAI) 91 [I-D.ietf-radext-nai] is the suggested way of differentiating users 92 between those entities; the part of a username to the right of the @ 93 delimiter in a NAI is called the user's "realm". Where many realms 94 and RADIUS forwarding servers are in use, the number of realms to be 95 forwarded and the corresponding number of servers to configure may be 96 significant. Where new realms with new servers are added or details 97 of existing servers change on a regular basis, maintaining a single 98 monolithic configuration file for all these details may prove too 99 cumbersome to be useful. 101 Furthermore, in cases where a roaming consortium consists of 102 independently working branches (e.g. departments, national 103 subsidiaries), each with their own forwarding servers, and who add or 104 change their realm lists at their own discretion, there is additional 105 complexity in synchronising the changed data across all branches. 107 These situations can benefit significantly from a distributed 108 mechanism for storing realm and server reachability information. 109 This document describes one such mechanism: storage of realm-to- 110 server mappings in DNS. 112 This document also specifies various approaches for verifying that 113 server information which was retrieved from DNS was from an 114 authorised party; e.g. an organisation which is not at all part of a 115 given roaming consortium may alter its own DNS records to yield a 116 result for its own realm. 118 1.1. Requirements Language 120 In this document, several words are used to signify the requirements 121 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 123 and "OPTIONAL" in this document are to be interpreted as described in 124 RFC 2119. [RFC2119] 126 1.2. Terminology 128 RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a 129 new connection. 131 RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a 132 RADIUS/TLS port and accepts new connections 134 RADIUS/TLS node: a RADIUS/TLS client or server 136 [RFC4282] and its designated successor [I-D.ietf-radext-nai] define 137 the terms NAI, realm, consortium. RFC Editor Note: please remove the 138 RFC4282 reference here and in the Normative References section prior 139 to publication and replace the draft NAI spec with its then-allocated 140 RFC number. 142 1.3. Document Status 144 This document is an Experimental RFC. 146 The communities expected to use this document are roaming consortia 147 whose authentication services are based on the RADIUS protocol. 149 The duration of the experiment is undetermined; as soon as enough 150 experience is collected on the choice points mentioned below, it is 151 expected to be obsoleted by a standards-track version of the protocol 152 which trims down the choice points. 154 If that removal of choice points obsoletes tags or service names as 155 defined in this document and allocated by IANA, these items will be 156 returned to IANA as per the provisions in [RFC6335]. 158 The document provides a discovery mechanism for RADIUS which is very 159 similar to the approach that is taken with the Diameter protocol 160 [RFC6733]. As such, the basic approach (using NAPTR records in DNS 161 domains which match NAI realms) is not of very experimental nature. 163 However, the document offers a few choice points and extensions which 164 go beyond the provisions for Diameter. The list of major additions/ 165 deviations is 167 o a fallback mechanism using SRV records, should no matching NAPTR 168 records be found (not defined for Diameter) 170 o Provisions for determining the authority of a server to act for 171 users of a realm (declared out of scope for Diameter) 173 o much more in-depth guidance on DNS regarding timeouts, failure 174 conditions, alteration of TTLs (not considered for Diameter) 176 o a partially correct routing error detection (not considered for 177 Diameter) 179 2. Definitions 181 2.1. DNS RR definition 183 DNS definitions of RADIUS/TLS servers can be either S-NAPTR records 184 (see [RFC3958]) or SRV records. When both are defined, the 185 resolution algorithm prefers S-NAPTR results (see Section 3.4 below). 187 2.1.1. S-NAPTR 189 2.1.1.1. Registration of Application Service and Protocol Tags 191 This specification defines three S-NAPTR service tags: 193 +-----------------+-----------------------------------------+ 194 | Service Tag | Use | 195 +-----------------+-----------------------------------------+ 196 | aaa+auth | RADIUS Authentication, i.e. traffic as | 197 | | defined in [RFC2865] | 198 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 199 | aaa+acct | RADIUS Accounting, i.e. traffic as | 200 | | defined in [RFC2866] | 201 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 202 | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | 203 | | traffic as defined in [RFC5176] | 204 +--------------- --+-----------------------------------------+ 206 Figure 1: List of Service Tags 208 This specification defines two S-NAPTR protocol tags: 210 +-----------------+-----------------------------------------+ 211 | Protocol Tag | Use | 212 +-----------------+-----------------------------------------+ 213 | radius.tls | RADIUS transported over TLS as defined | 214 | | in [RFC6614] | 215 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 216 | radius.dtls | RADIUS transported over DTLS as defined | 217 | | in [I-D.ietf-radext-dtls] | 218 +-----------------+-----------------------------------------+ 220 Figure 2: List of Protocol Tags 222 Note well: 224 The S-NAPTR service and protocols are unrelated to the IANA 225 Service Name and Transport Protocol Number registry 227 The delimiter '.' in the protocol tags is only a separator for 228 human reading convenience - not for structure or namespacing; it 229 MUST NOT be parsed in any way by the querying application or 230 resolver. 232 The use of the separator '.' is common also in other protocols' 233 protocol tags. This is coincidence and does not imply a shared 234 semantics with such protocols. 236 2.1.1.2. Definition of Conditions for Retry/Failure 238 RADIUS is a time-critical protocol; RADIUS clients which do not 239 receive an answer after a configurable, but short, amount of time, 240 will consider the request failed. Due to this, there is little 241 leeway for extensive retries. 243 As a general rule, only error conditions which generate an immediate 244 response from the other end are eligible for a retry of a discovered 245 target. Any error condition involving time-outs, or the absence of a 246 reply for more than one second during the connection setup phase is 247 to be considered a failure; the next target in the set of discovered 248 NAPTR targets is to be tried. 250 Note that [RFC3958] already defines that a failure to identify the 251 server as being authoritative for the realm is always considered a 252 failure; so even if a discovered target returns a wrong credential 253 instantly, it is not eligible for retry. 255 Furthermore, the contacted RADIUS/TLS server verifies during 256 connection setup whether or not it finds the connecting RADIUS/TLS 257 client authorized or not. If the connecting RADIUS/TLS client is not 258 found acceptable, the server will close the TLS connection 259 immediately with an appropriate alert. Such TLS handshake failures 260 are permanently fatal and not eligible for retry, unless the 261 connecting client has more X.509 certificates to try; in this case, a 262 retry with the remainder of its set of certificates SHOULD be 263 attempted. 265 If the TLS session setup to a discovered target does not succeed, 266 that target (as identified by IP address and port number) SHOULD be 267 ignored from the result set of any subsequent executions of the 268 discovery algorithm at least until the target's Effective TTL has 269 expired or until the entity which executes the algorithm changes its 270 TLS context to either send a new client certificate or expect a 271 different server certificate. 273 2.1.1.3. Server Identification and Handshake 275 After the algorithm in this document has been executed, a RADIUS/TLS 276 session as per [RFC6614] is established. Since the dynamic discover 277 algorithm does not have provisions to establish confidential keying 278 material between the RADIUS/TLS client (i.e. the server which 279 executes the discovery algorithm) and the RADIUS/TLS server which was 280 discovered, TLS-PKS ciphersuites cannot be used for in the subsequent 281 TLS handshake. Only TLS ciphersuites using X.509 certificates can be 282 used with this algorithm. 284 There are numerous ways to define which certificates are acceptable 285 for use in this context. This document defines one mandatory-to- 286 implement mechanism which allows to verify whether the contacted host 287 is authoritative for a NAI realm or not. It also gives one example 288 of another mechanism which is currently in wide-spread deployment, 289 and one possible approach based on DNSSEC which is yet unimplemented. 291 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 293 Verification of authority to provide AAA services over RADIUS/TLS is 294 a two-step process. 296 Step 1 is the verification of certificate wellformedness and validity 297 as per [RFC5280] and whether it was issued from a root certificate 298 which is deemed trustworthy by the RADIUS/TLS client. 300 Step 2 is to compare the value of algorithm's variable "R" after the 301 execution of step 3 of the discovery algorithm in Section 3.4.3 below 302 (i.e. after a consortium name mangling, but before conversion to a 303 form usable by the name resolution library) to all values of the 304 contacted RADIUS/TLS server's X.509 certificate property 305 "subjectAlternativeName:otherName:NAIRealm" as defined in 306 Section 2.2. 308 2.1.1.3.2. Other mechanism: Trust Roots + policyOID 310 Verification of authority to provide AAA services over RADIUS/TLS is 311 a two-step process. 313 Step 1 is the verification of certificate wellformedness and validity 314 as per [RFC5280] and whether it was issued from a root certificate 315 which is deemed trustworthy by the RADIUS/TLS client. 317 Step 2 is to compare the values of the contacted RADIUS/TLS server's 318 X.509 certificate's extensions of type "Policy OID" to a list of 319 configured acceptable Policy OIDs for the roaming consortium. If one 320 of the configured OIDs is found in the certificate's Policy OID 321 extensions, then the server is considered authorized; if there is no 322 match, the server is considered unauthorized. 324 This mechanism is inferior to the mandatory-to-implement mechanism in 325 the previous section because all authorized servers are validated by 326 the same OID value; the mechanism is not fine-grained enough to 327 express authority for one specific realm inside the consortium. If 328 the consortium contains members which are hostile against other 329 members, this weakness can be exploited by one RADIUS/TLS server 330 impersonating another if DNS responses can be spoofed by the hostile 331 member. 333 The shortcomings in server identification can be partially mitigated 334 by using the RADIUS infrastructure only with authentication payloads 335 which provide mutual authentication and credential protection (i.e. 336 EAP types passing the criteria of [RFC4017]): using mutual 337 authentication prevents the hostile server from mimicking the real 338 EAP server (it can't terminate the EAP authentication unnoticed 339 because it does not have the server certificate from the real EAP 340 server); protection of credentials prevents the impersonating server 341 from learning usernames and passwords of the ongoing EAP conversation 342 (other RADIUS attributes pertaining to the authentication, such as 343 the EAP peer's Calling-Station-ID, can still be learned though). 345 2.1.1.3.3. Other mechanism: DNSSEC / DANE 347 Where DNSSEC is used, the results of the algorithm can be trusted; 348 i.e. the entity which executes the algorithm can be certain that the 349 realm that triggered the discovery is actually served by the server 350 that was discovered via DNS. However, this does not guarantee that 351 the server is also authorized (i.e. a recognised member of the 352 roaming consortium). 354 The authorization can be sketched using DNSSEC+DANE as follows: if 355 DANE/TLSA records of all authorized servers are put into a DNSSEC 356 zone with a common, consortium-specific branch of the DNS tree, then 357 the entity executing the algorithm can retrieve TLSA RRs for the 358 label "realm.commonroot" and verify that the presented server 359 certificate during the RADIUS/TLS handshake matches the information 360 in the TLSA record. 362 Example: 364 Realm = "example.com" 366 Common Branch = "idp.roaming-consortium.example. 368 label for TLSA query = "example.com.idp.roaming- 369 consortium.example. 371 result of discovery algorithm for realm "example.com" = 372 192.0.2.1:2083 374 ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : 375 "FAIL" ) 377 2.1.1.3.4. Client Authentication and Authorisation 379 Note that RADIUS/TLS connections always mutually authenticate the 380 RADIUS server and the RADIUS client. This specification provides an 381 algorithm for a RADIUS client to contact and verify authorization of 382 a RADIUS server only. During connection setup, the RADIUS server 383 also needs to verify whether it considers the connecting RADIUS 384 client authorized; this is outside the scope of this specification. 386 2.1.2. SRV 388 This specification defines two SRV prefixes (i.e. two values for the 389 "_service._proto" part of an SRV RR as per [RFC2782]): 391 +-----------------+-----------------------------------------+ 392 | SRV Label | Use | 393 +-----------------+-----------------------------------------+ 394 | _radiustls._tcp | RADIUS transported over TLS as defined | 395 | | in [RFC6614] | 396 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 397 | _radiustls._udp | RADIUS transported over DTLS as defined | 398 | | in [I-D.ietf-radext-dtls] | 399 +-----------------+-----------------------------------------+ 401 Figure 3: List of SRV Labels 403 Just like NAPTR records, the lookup and subsequent follow-up of SRV 404 records may yield more than one server to contact in a prioritised 405 list. [RFC2782] does not specify rules regarding "Definition of 406 Conditions for Retry/Failure", nor "Server Identification and 407 Handshake". This specification defines that the rules for these two 408 topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be 409 used both for targets retrieved via an initial NAPTR RR as well as 410 for targets retrieved via an initial SRV RR (i.e. in the absence of 411 NAPTR RRs). 413 2.1.3. Optional name mangling 415 It is expected that in most cases, the SRV and/or NAPTR label used 416 for the records is the DNS A-label representation of the literal 417 realm name for which the server is the authoritative RADIUS server 418 (i.e. the realm name after conversion according to section 5 of 419 [RFC5891]). 421 However, arbitrary other labels or service tags may be used if, for 422 example, a roaming consortium uses realm names which are not 423 associated to DNS names or special-purpose consortia where a globally 424 valid discovery is not a use case. Such other labels require a 425 consortium-wide agreement about the transformation from realm name to 426 lookup label, and/or which service tag to use. 428 Examples: 430 a. A general-purpose RADIUS server for realm example.com might have 431 DNS entries as follows: 433 example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 434 _radiustls._tcp.foobar.example.com. 436 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 437 radsec.example.com. 439 b. The consortium "foo" provides roaming services for its members 440 only. The realms used are of the form enterprise-name.example. 441 The consortium operates a special purpose DNS server for the 442 (private) TLD "example" which all RADIUS servers use to resolve 443 realm names. "Company, Inc." is part of the consortium. On the 444 consortium's DNS server, realm company.example might have the 445 following DNS entries: 447 company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" "" 448 roamserv.company.example 450 c. The eduroam consortium uses realms based on DNS, but provides its 451 services to a closed community only. However, a AAA domain 452 participating in eduroam may also want to expose AAA services to 453 other, general-purpose, applications (on the same or other RADIUS 454 servers). Due to that, the eduroam consortium uses the service 455 tag "x-eduroam" for authentication purposes and eduroam RADIUS 456 servers use this tag to look up other eduroam servers. An 457 eduroam participant example.org which also provides general- 458 purpose AAA on a different server uses the general "aaa+auth" 459 tag: 461 example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" "" 462 _radiustls._tcp.eduroam.example.org. 464 example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 465 _radiustls._tcp.aaa.example.org 467 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 468 eduroam.example.org. 470 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 471 default.example.org. 473 2.2. Definition of the X.509 certificate property 474 SubjectAltName:otherName:NAIRealm 476 This specification retrieves IP addresses and port numbers from the 477 Domain Name System which are subsequently used to authenticate users 478 via the RADIUS/TLS protocol. Since the Domain Name System is not 479 necessarily trustworthy (e.g. if DNSSEC is not deployed for the 480 queried domain name), it is important to verify that the server which 481 was contacted is authorized to service requests for the user which 482 triggered the discovery process. 484 The input to the algorithm is a NAI realm as specified in 485 Section 3.4.1. As a consequence, the X.509 certificate of the server 486 which is ultimately contacted for user authentication needs to be 487 able to express that it is authorized to handle requests for that 488 realm. 490 Current subjectAltName fields do not semantically allow to express an 491 NAI realm; the field subjectAltName:dNSName is syntactically a good 492 match but would inappropriately conflate DNS names and NAI realm 493 names. Thus, this specification defines a new subjectAltName field 494 to hold either a single NAI realm name or a wildcard name matching a 495 set of NAI realms. 497 The subjectAltName:otherName:sRVName field certifies that a 498 certificate holder is authorized to provide a service; this can be 499 compared to the target of DNS label's SRV resource record. If the 500 Domain Name System is insecure, it is required that the label of the 501 SRV record itself is known-correct. In this specification, that 502 label is not known-correct; it is potentially derived from a 503 (potentially untrusted) NAPTR resource record of another label. If 504 DNS is not secured with DNSSEC, the NAPTR resource record may have 505 been altered by an attacker with access to the Domain Name System 506 resolution, and thus the label to lookup the SRV record for may 507 already be tainted. This makes subjectAltName:otherName:sRVName not 508 a trusted comparison item. 510 Further to this, this specification's NAPTR entries may be of type 511 "A" which do not involve resolution of any SRV records, which again 512 makes subjectAltName:otherName:sRVName unsuited for this purpose. 514 This section defines the NAIRealm name as a form of otherName from 515 the GeneralName structure in SubjectAltName defined in [RFC5280]. 517 id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } 519 NAIRealm ::= UTF8String (SIZE (1..MAX)) 521 The NAIRealm, if present, MUST contain an NAI realm as defined in 522 [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot- 523 separated part of the NAI with the single character "*" to indicate a 524 wildcard match for "all labels in this part". Further features of 525 regular expressions, such as a number of characters followed by a * 526 to indicate a common prefix inside the part, are not permitted. 528 The comparison of a NAIRealm to the NAI realm as derived from user 529 input with this algorithm is a byte-by-byte comparison, except for 530 the optional leftmost dot-separated part of the value whose content 531 is a single "*" character; such labels match all strings in the same 532 dot-separated part of the NAI realm. If at least one of the 533 sAN:otherName:NAIRealm values matches the NAI realm, the server is 534 considered authorized; if none matches, the server is considered 535 unauthorized. 537 Since multiple names and multiple name forms may occur in the 538 subjectAltName extension, an arbitrary number of NAIRealms can be 539 specified in a certificate. 541 Examples: 543 +---------------------+-------------------+-----------------------+ 544 | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | 545 +---------------------+-------------------+-----------------------+ 546 | foo.example | foo.example | YES | 547 | foo.example | *.example | YES | 548 | bar.foo.example | *.example | NO | 549 | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | 550 | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | 551 | bar.foo.example | *.*.example | NO (NAIRealm invalid) | 552 | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | 553 | sub.bar.foo.example | *.bar.foo.example | YES | 554 +-----------------+-----------------------------------------------+ 556 Figure 4: Examples for NAI realm vs. certificate matching 558 Appendix A contains the ASN.1 definition of the above objects. 560 3. DNS-based NAPTR/SRV Peer Discovery 562 3.1. Applicability 564 Dynamic server discovery as defined in this document is only 565 applicable for new AAA transactions and per service (i.e. distinct 566 discovery is needed for Authentication, Accounting, and Dynamic 567 Authorization) where a RADIUS entity which acts as a forwarding 568 server for one or more realms receives a request with a realm for 569 which it is not authoritative, and which no explicit next hop is 570 configured. It is only applicable for 572 a. new user sessions, i.e. for the initial Access-Request. 573 Subsequent messages concerning this session, for example Access- 574 Challenges and Access-Accepts use the previously-established 575 communication channel between client and server. 577 b. the first accounting ticket for a user session 579 c. the first RADIUS DynAuth packet for a user session 581 3.2. Configuration Variables 583 The algorithm contains various variables for timeouts. These 584 variables are named here and reasonable default values are provided. 585 Implementations wishing to deviate from these defaults should make 586 they understand the implications of changes. 588 DNS_TIMEOUT: maximum amount of time to wait for the complete set 589 of all DNS queries to complete: Default = 3 seconds 591 MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 592 seconds 594 BACKOFF_TIME: if no conclusive DNS response was retrieved after 595 DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME 596 has elapsed. Default = 600 seconds 598 3.3. Terms 600 Positive DNS response: a response which contains the RR that was 601 queried for. 603 Negative DNS response: a response which does not contain the RR that 604 was queried for, but contains an SOA record along with a TTL 605 indicating cache duration for this negative result. 607 DNS Error: Where the algorithm states "name resolution returns with 608 an error", this shall mean that either the DNS request timed out, or 609 a DNS response which is neither a positive nor a negative response 610 (e.g. SERVFAIL). 612 Effective TTL: The validity period for discovered RADIUS/TLS target 613 hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { 614 MIN_EFF_TTL, min { DNS TTL values } } 615 SRV lookup: for the purpose of this specification, SRV lookup 616 procedures are defined as per [RFC2782], but excluding that RFCs "A" 617 fallback as defined in its section "Usage Rules", final "else" 618 clause. 620 Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead 621 to a tree of results, whose leafs are the IP addresses to contact. 622 The branches of the tree are ordered according to their order/ 623 preference DNS properties. An implementation is executing greedy 624 result evaluation if it uses a depth-first search in the tree along 625 the highest order results, attempts to connect to the corresponding 626 resulting IP addresses, and only backtracks to other branches if the 627 higher ordered results did not end in successful connection attempts. 629 3.4. Realm to RADIUS server resolution algorithm 631 3.4.1. Input 633 For RADIUS Authentication and RADIUS Accounting server discovery, 634 input I to the algorithm is the RADIUS User-Name attribute with 635 content of the form "user@realm"; the literal @ sign being the 636 separator between a local user identifier within a realm and its 637 realm. The use of multiple literal @ signs in a User-Name is 638 strongly discouraged; but if present, the last @ sign is to be 639 considered the separator. All previous instances of the @ sign are 640 to be considered part of the local user identifier. 642 For RADIUS DynAuth Server discovery, input I to the algorithm is the 643 domain name of the operator of a RADIUS realm as was communicated 644 during user authentication using the Operator-Name attribute 645 ([RFC5580], section 4.1). Only Operator-Name values with the 646 namespace "1" are supported by this algorithm - the input to the 647 algorithm is the actual domain name, preceeded with an "@" (but 648 without the "1" namespace identifier byte of that attribute). 650 Note well: The attribute User-Name is defined to contain UTF-8 text. 651 In practice, the content may or may not be UTF-8. Even if UTF-8, it 652 may or may not map to a domain name in the realm part. Implementors 653 MUST take possible conversion error paths into consideration when 654 parsing incoming User-Name attributes. This document describes 655 server discovery only for well-formed realms mapping to DNS domain 656 names in UTF-8 encoding. The result of all other possible contents 657 of User-Name is unspecified; this includes, but is not limited to: 659 Usage of separators other than @ 661 Encoding of User-Name in local encodings 662 UTF-8 realms which fail the conversion rules as per [RFC5891] 664 UTF-8 realms which end with a . ("dot") character. 666 For the last bullet point, "trailing dot", special precautions should 667 be taken to avoid problems when resolving servers with the algorithm 668 below: they may resolve to a RADIUS server even if the peer RADIUS 669 server only is configured to handle the realm without the trailing 670 dot. If that RADIUS server again uses NAI discovery to determine the 671 authoritative server, the server will forward the request to 672 localhost, resulting in a tight endless loop. 674 3.4.2. Output 676 Output O of the algorithm is a two-tuple consisting of: O-1) a set of 677 tuples {hostname; port; protocol; order/preference; Effective TTL} - 678 the set can be empty; and O-2) an integer: if the set in the first 679 part of the tuple is empty, the integer contains the Effective TTL 680 for backoff timeout, if the set is not empty, the integer is set to 0 681 (and not used). 683 3.4.3. Algorithm 685 The algorithm to determine the RADIUS server to contact is as 686 follows: 688 1. Determine P = (position of last "@" character) in I. 690 2. generate R = (substring from P+1 to end of I) 692 3. modify R according to agreed consortium procedures if applicable 694 4. convert R to a representation usable by the name resolution 695 library if needed 697 5. Initialize TIMER = 0; start TIMER. If TIMER reaches 698 DNS_TIMEOUT, continue at step 20. 700 6. Using the host's name resolution library, perform a NAPTR query 701 for R (see "Delay considerations" below). If the result is a 702 negative DNS response, O-2 = Effective TTL ( TTL value of the 703 SOA record ) and continue at step 13. If name resolution 704 returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and 705 terminate. 707 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 708 "aaa+dynauth" as appropriate. Keep note of the protocol tag and 709 remaining TTL of each of the discovered NAPTR records. 711 8. If no records found, continue at step 13. 713 9. For the extracted NAPTRs, perform successive resolution as 714 defined in [RFC3958], section 2.2. An implementation MAY use 715 greedy result evaluation according to the NAPTR order/preference 716 fields (i.e. can execute the subsequent steps of this algorithm 717 for the highest-order entry in the set of results, and only 718 lookup the remainder of the set if necessary). 720 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 721 BACKOFF_TIME and terminate. 723 11. O' = (set of {hostname; port; protocol; order/preference; 724 Effective TTL ( all DNS TTLs that led to this hostname ) } for 725 all terminal lookup results). 727 12. Proceed with step 18. 729 13. Generate R' = (prefix R with "_radiustls._tcp." and/or 730 "_radiustls._udp.") 732 14. Using the host's name resolution library, perform SRV lookup 733 with R' as label (see "Delay considerations" below). 735 15. If name resolution returns with error, O-1 = { empty set }, O-2 736 = BACKOFF_TIME and terminate. 738 16. If the result is a negative DNS response, O-1 = { empty set }, 739 O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) } 740 and terminate. 742 17. O' = (set of {hostname; port; protocol; order/preference; 743 Effective TTL ( all DNS TTLs that led to this result ) } for all 744 hostnames). 746 18. Generate O-1 by resolving hostnames in O' into corresponding A 747 and/or AAAA addresses: O-1 = (set of {IP address; port; 748 protocol; order/preference; Effective TTL ( all DNS TTLs that 749 led to this result ) } for all hostnames ), O-2 = 0. 751 19. For each element in O-1, test if the original request which 752 triggered dynamic discovery was received on {IP address; port}. 753 If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, 754 Terminate (see next section for a rationale). If no, O is the 755 result of dynamic discovery. Terminate. 757 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 759 3.4.4. Validity of results 761 The dynamic discovery algorithm is used by servers which do not have 762 sufficient configuration information to process an incoming request 763 on their own. If the discovery algorithm result contains the 764 server's own listening address (IP address and port), then this will 765 either lead to a tight loop (if that DNS entry has topmost priority, 766 the server would forward the request to itself, triggering dynamic 767 discovery again in a perpetual loop), or lead to a potential loop 768 with intermediate hops in between (the server could forward to 769 another host with a higher priority, which might use DNS itself and 770 forward the packet back to the first server). The underlying reason 771 that enables these loops is that the server executing the discovery 772 algorithm is seriously misconfigured in that it does not recognise 773 the request as one that is to be processed by itself. RADIUS has no 774 built-in loop detection, so any such loops would remain undetected. 775 So, if step 18 of the algorithm discovers such a possible-loop 776 situation, the algorithm should be aborted and an error logged. Note 777 that this safeguard does not provide perfect protection against 778 routing loops: other reasons include the possiblity that a subsequent 779 hop has a statically configured next-hop which leads to an earlier 780 host in the loop; or the algorithm execution was executed with greedy 781 result evaluation, and the own address was in a lower-priority branch 782 of the result set which was not retrieved from DNS at all. 784 After executing the above algorithm, the RADIUS server establishes a 785 connection to a home server from the result set. This connection can 786 potentially remain open for an indefinite amount of time. This 787 conflicts with the possibility of changing device and network 788 configurations on the receiving end. Typically, TTL values for 789 records in the name resolution system are used to indicate how long 790 it is safe to rely on the results of the name resolution. If these 791 TTLs are very low, thrashing of connections becomes possible; the 792 Effective TTL mitigates that risk. When a connection is open and the 793 smallest of the Effective TTL value which was learned during 794 discovering the server has not expired, subsequent new user sessions 795 for the realm which corresponds to that open connection SHOULD re-use 796 the existing connection and SHOULD NOT re-execute the dynamic 797 discovery algorithm nor open a new connection. To allow for a change 798 of configuration, a RADIUS server SHOULD re-execute the dynamic 799 discovery algorithm after the Effective TTL that is associated with 800 this connection has expired. The server MAY keep the session open 801 during this re-assessment to avoid closure and immediate re-opening 802 of the connection should the result not have changed. 804 Should the algorithm above terminate with O-1 = empty set, the RADIUS 805 server SHOULD NOT attempt another execution of this algorithm for the 806 same target realm before the timeout O-2 has passed. 808 3.4.5. Delay considerations 810 The host's name resolution library may need to contact outside 811 entities to perform the name resolution (e.g. authoritative name 812 servers for a domain), and since the NAI discovery algorithm is based 813 on uncontrollable user input, the destination of the lookups is out 814 of control of the server that performs NAI discovery. If such 815 outside entities are misconfigured or unreachable, the algorithm 816 above may need an unacceptably long time to terminate. Many RADIUS 817 implementations time out after five seconds of delay between Request 818 and Response. It is not useful to wait until the host name 819 resolution library signals a time-out of its name resolution 820 algorithms. The algorithm therefore control execution time with 821 TIMER. Execution of the NAI discovery algorithm SHOULD be non- 822 blocking (i.e. allow other requests to be processed in parallel to 823 the execution of the algorithm). 825 3.4.6. Example 827 Assume 829 a user from the Technical University of Munich, Germany, has a 830 RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". 832 The name resolution library on the RADIUS forwarding server does 833 not have the realm tu-m[U+00FC]nchen.example in its forwarding 834 configuration, but uses DNS for name resolution and has configured 835 the use of Dynamic Discovery to discover RADIUS servers. 837 It is IPv6-enabled and prefers AAAA records over A records. 839 It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP 840 /2083. 842 May the configuration variables be 844 DNS_TIMEOUT = 3 seconds 846 MIN_EFF_TTL = 60 seconds 848 BACKOFF_TIME = 3600 seconds 850 If DNS contains the following records: 852 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 853 "aaa+auth:radius.tls" "" _myradius._tcp.xn--tu-mnchen-t9a.example. 855 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 856 "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. 858 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 859 radsecserver.xn--tu-mnchen-t9a.example. 861 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 862 backupserver.xn--tu-mnchen-t9a.example. 864 radsecserver.xn--tu-mnchen-t9a.example. IN AAAA 865 2001:0DB8::202:44ff:fe0a:f704 867 radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 869 backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 871 Then the algorithm executes as follows, with I = 872 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 873 in use: 875 1. P = 7 877 2. R = "tu-m[U+00FC]nchen.example" 879 3. NOOP 881 4. name resolution library converts R to xn--tu-mnchen-t9a.example 883 5. TIMER starts. 885 6. Result: 887 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" 888 _myradius._tcp.xn--tu-mnchen-t9a.example. 890 (TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" 891 _abc123._def.xn--tu-mnchen-t9a.example. 893 7. Result: 895 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" 896 _myradius._tcp.xn--tu-mnchen-t9a.example. 898 8. NOOP 900 9. Successive resolution performs SRV query for label 901 _myradius._tcp.xn--tu-mnchen-t9a.example, which results in 902 (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. 904 (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. 906 10. NOOP 908 11. O' = { 910 (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 911 60), 913 (backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60) 915 } // minimum TTL is 47, up'ed to MIN_EFF_TTL 917 12. Continuing at 18. 919 13. (not executed) 921 14. (not executed) 923 15. (not executed) 925 16. (not executed) 927 17. (not executed) 929 18. O-1 = { 931 (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), 933 (192.0.2.7; 2083; RADIUS/TLS; 20; 60) 935 }; O-2 = 0 937 19. No match with own listening address; terminate with tuple (O-1, 938 O-2) from previous step. 940 The implementation will then attempt to connect to two servers, with 941 preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ 942 TLS protocol. 944 4. Operations and Manageability Considerations 946 The discovery algorithm as defined in this document contains several 947 options; the major ones being use of NAPTR vs. SRV; how to determine 948 the authorization status of a contacted server for a given realm; 949 which trust anchors to consider trustworthy for the RADIUS 950 conversation setup. 952 Random parties which do not agree on the same set of options may not 953 be able to interoperate. However, such a global interoperability is 954 not intended by this document. 956 Discovery as per this document becomes important inside a roaming 957 consortium, which has set up roaming agreements with the other 958 partners. Such roaming agreements require much more than a technical 959 means of server discovery; there are administrative and contractual 960 considerations at play (service contracts, backoffice compensations, 961 procedures, ...). 963 A roaming consortium's roaming agreement must include a profile of 964 which choice points of this document to use. So long as the roaming 965 consortium can settle on one deployment profile, they will be able to 966 interoperate based on that choice; this per-consortium 967 interoperability is the intended scope of this document. 969 5. Security Considerations 971 When using DNS without DNSSEC security extensions and validation for 972 all of the replies to NAPTR, SRV and A/AAAA requests as described in 973 section Section 3, the result O can not be trusted. Even if it can 974 be trusted (i.e. DNSSEC is in use), actual authorization of the 975 discovered server to provide service for the given realm needs to be 976 verified. A mechanism from section Section 2.1.1.3 or equivalent 977 MUST be used to verify authorization. 979 The algorithm has a configurable completion time-out DNS_TIMEOUT 980 defaulting to three seconds for RADIUS' operational reasons. The 981 lookup of DNS resource records based on unverified user input is an 982 attack vector for DoS attacks: an attacker might intentionally craft 983 bogus DNS zones which take a very long time to reply (e.g. due to a 984 particularly byzantine tree structure, or artificial delays in 985 responses). 987 To mitigate this DoS vector, implementations SHOULD consider rate- 988 limiting either their amount of new executions of the dynamic 989 discovery algorithm as a whole, or the amount of intermediate 990 responses to track, or at least the number of pending DNS queries. 991 Implementations MAY choose lower values than the default for 992 DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They 993 MAY also continue their attempt to resolve DNS records even after 994 DNS_TIMEOUT has passed; a subsequent request for the same realm might 995 benefit from retrieving the results anyway. The amount of time to 996 spent waiting for a result will influence the impact of a possible 997 DoS attack; the waiting time value is implementation dependent and 998 outside the scope of this specification. 1000 With Dynamic Discovery being enabled for a RADIUS Server, and 1001 depending on the deployment scenario, the server may need to open up 1002 its target IP address and port for the entire internet, because 1003 arbitrary clients may discover it as a target for their 1004 authentication requests. If such clients are not part of the roaming 1005 consortium, the RADIUS/TLS connection setup phase will fail (which is 1006 intended) but the computational cost for the connection attempt is 1007 significant. With the port for a TLS-based service open, the RADIUS 1008 server shares all the typical attack vectors for services based on 1009 TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with 1010 Dynamic Discovery should consider these attack vectors and take 1011 appropriate counter-measures (e.g. blacklisting known-bad IPs on a 1012 firewall, rate-limiting new connection attempts, etc.). 1014 6. Privacy Considerations 1016 The classic RADIUS operational model (known, pre-configured peers, 1017 shared secret security, mostly plaintext communication) and this new 1018 RADIUS dynamic discovery model (peer discovery with DNS, PKI security 1019 and packet confidentiality) differ significantly in their impact on 1020 the privacy of end users trying to authenticate to a RADIUS server. 1022 With classic RADIUS, traffic in large environments gets aggregated by 1023 statically configured clearinghouses. The packets sent to those 1024 clearinghouses and their responses are mostly unprotected. As a 1025 consequence, 1027 o All intermediate IP hops can inspect most of the packet payload in 1028 clear text, including the User-Name and Calling-Station-Id 1029 attributes, and can observe which client sent the packet to which 1030 clearinghouse. This allows the creation of mobility profiles for 1031 any passive observer on the IP path. 1033 o The existence of a central clearinghouse creates an opportunity 1034 for the clearinghouse to trivially create the same mobility 1035 profiles. The clearinghouse may or may not be trusted not to do 1036 this, e.g. by sufficiently threatening contractual obligations. 1038 o In addition to that, with the clearinghouse being a RADIUS 1039 intermediate in possession of a valid shared secret, the 1040 clearinghouse can observe and record even the security-critical 1041 RADIUS attributes such as User-Password. This risk may be 1042 mitigated by choosing authentication payloads which are 1043 cryptographically secured and do not use the attribute User- 1044 Password - such as certain EAP types. 1046 o There is no additional information disclosure to parties outside 1047 the IP path between the RADIUS client and server (in particular, 1048 no DNS servers learn about realms of current ongoing 1049 authentications). 1051 With RADIUS and dynamic discovery, 1053 o This protocol allows for RADIUS clients to identify and directly 1054 connect to the RADIUS home server. This can eliminate the use of 1055 clearinghouses to do forwarding of requests, and it also 1056 eliminates the ability of the clearinghouse to then aggregate the 1057 user information that flows through it. However, there exist 1058 reasons why clearinghouses might still be used. One reason to 1059 keep a clearinghouse is to act as a gateway for multiple backends 1060 in a company; another reason may be a requirement to sanitise 1061 RADIUS datagrams (filter attributes, tag requests with new 1062 attributes, ... ). 1064 o Even where intermediate proxies continue to be used for reasons 1065 unrelated to dynamic discovery, the number of such intermediates 1066 may be reduced by removing those proxies which are only deployed 1067 for pure request routing reasons. This reduces the number of 1068 entities which can inspect the RADIUS traffic. 1070 o RADIUS clients which make use of dynamic discovery will need to 1071 query the Domain Name System, and use a user's realm name as the 1072 query label. A passive observer on the IP path between the RADIUS 1073 client and the DNS server(s) being queried can learn that a user 1074 of that specific realm was trying to authenticate at that RADIUS 1075 client at a certain point in time. This may or may not be 1076 sufficient for the passive observer to create a mobility profile. 1077 During the recursive DNS resolution, a fair number of DNS servers 1078 and the IP hops in between those get to learn that information. 1079 Not every single authentication triggers DNS lookups, so there is 1080 no one-to-one relation of leaked realm information and the number 1081 of authentications for that realm. 1083 o Since dynamic discovery operates on a RADIUS hop-by-hop basis, 1084 there is no guarantee that the RADIUS payload is not transmitted 1085 between RADIUS systems which do not make use of this algorithm, 1086 and possibly using other transports such as RADIUS/UDP. On such 1087 hops, the enhanced privacy is jeopardized. 1089 In summary, with classic RADIUS, few intermediate entities learn very 1090 detailed data about every ongoing authentications, while with dynamic 1091 discovery, many entities learn only very little about recently 1092 authenticated realms. 1094 7. IANA Considerations 1096 This document requests IANA registration of the following entries in 1097 existing registries: 1099 o S-NAPTR Application Service Tags registry 1101 * aaa+auth 1103 * aaa+acct 1105 * aaa+dynauth 1107 o S-NAPTR Application Protocol Tags registry 1109 * radius.tls 1111 * radius.dtls 1113 This document reserves the use of the "radiustls" and "radiusdtls" 1114 service names. Registration information as per [RFC6335] section 1115 8.1.1 is as follows: 1117 Service Name: radiustls; radiusdtls 1119 Transport Protocols: TCP, UDP 1121 Assignee: IESG 1123 Contact: IETF Chair 1125 Description: Authentication, Accounting and Dynamic authorization 1126 via the RADIUS protocol. These service names are used to 1127 construct the SRV service labels "_radiustls" and "_radiusdtls" 1128 for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. 1130 Reference: RFC Editor Note: please insert the RFC number of this 1131 document. The protocol does not use broadcast, multicast or 1132 anycast communication. 1134 This document requests the creation of a new IANA registry named 1135 "RADIUS/TLS SRV Protocol Registry" with the following initial 1136 entries: 1138 o _tcp 1140 o _udp 1141 This document requires that a number of Object Identifiers be 1142 assigned. They re now under the control of IANA following [I-D 1143 .housley-pkix-oids]. 1145 IANA is requested to assign the following identifiers: 1147 TBD99 is to be assigned from the "SMI Security for PKIX Module 1148 Identifier Registry". The suggested description is id-mod-nai- 1149 realm-08. 1151 TBD98 is to be assigned from the "SMI Security for PKIX Other Name 1152 Forms Registry." The suggested description is id-on-nai. 1154 RFC Editor Note: please replace the occurences of TBD98 and TBD99 in 1155 Appendix A of the document with the actually assigned numbers. 1157 8. References 1159 8.1. Normative References 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", BCP 14, RFC 2119, March 1997. 1164 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1165 specifying the location of services (DNS SRV)", RFC 2782, 1166 February 2000. 1168 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1169 "Remote Authentication Dial In User Service (RADIUS)", RFC 1170 2865, June 2000. 1172 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1174 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1175 Service Location Using SRV RRs and the Dynamic Delegation 1176 Discovery Service (DDDS)", RFC 3958, January 2005. 1178 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1179 Network Access Identifier", RFC 4282, December 2005. 1181 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1182 Aboba, "Dynamic Authorization Extensions to Remote 1183 Authentication Dial In User Service (RADIUS)", RFC 5176, 1184 January 2008. 1186 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1187 Housley, R., and W. Polk, "Internet X.509 Public Key 1188 Infrastructure Certificate and Certificate Revocation List 1189 (CRL) Profile", RFC 5280, May 2008. 1191 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 1192 Aboba, "Carrying Location Objects in RADIUS and Diameter", 1193 RFC 5580, August 2009. 1195 [RFC5891] Klensin, J., "Internationalized Domain Names in 1196 Applications (IDNA): Protocol", RFC 5891, August 2010. 1198 [I-D.ietf-radext-dtls] 1199 DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- 1200 ietf-radext-dtls-07 (work in progress), October 2013. 1202 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1203 "Transport Layer Security (TLS) Encryption for RADIUS", 1204 RFC 6614, May 2012. 1206 [I-D.ietf-radext-nai] 1207 DeKok, A., "The Network Access Identifier", draft-ietf- 1208 radext-nai-05 (work in progress), November 2013. 1210 8.2. Informative References 1212 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1213 Authentication Protocol (EAP) Method Requirements for 1214 Wireless LANs", RFC 4017, March 2005. 1216 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1217 Cheshire, "Internet Assigned Numbers Authority (IANA) 1218 Procedures for the Management of the Service Name and 1219 Transport Protocol Port Number Registry", BCP 165, RFC 1220 6335, August 2011. 1222 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1223 "Diameter Base Protocol", RFC 6733, October 2012. 1225 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm 1227 PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6) 1228 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1229 id-mod-nai-realm-08 (TBD99) } 1231 DEFINITIONS EXPLICIT TAGS ::= 1233 BEGIN 1235 -- EXPORTS ALL -- 1237 IMPORTS 1239 id-pkix 1240 FROM PKIX1Explicit-2009 1241 {iso(1) identified-organization(3) dod(6) internet(1) 1242 security(5) mechanisms(5) pkix(7) id-mod(0) 1243 id-mod-pkix1-explicit-02(51)} 1244 -- from RFC 5280, RFC 5912 1246 OTHER-NAME 1247 FROM PKIX1Implicit-2009 1248 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1249 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1250 -- from RFC 5280, RFC 5912 1251 ; 1253 -- Service Name Object Identifier 1255 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1257 id-on-nai OBJECT IDENTIFIER ::= { id-on TBD98 } 1259 -- Service Name 1261 naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }} 1263 NAIRealm ::= UTF8String (SIZE (1..MAX)) 1265 END 1267 Authors' Addresses 1269 Stefan Winter 1270 Fondation RESTENA 1271 6, rue Richard Coudenhove-Kalergi 1272 Luxembourg 1359 1273 LUXEMBOURG 1275 Phone: +352 424409 1 1276 Fax: +352 422473 1277 EMail: stefan.winter@restena.lu 1278 URI: http://www.restena.lu. 1280 Mike McCauley 1281 Open Systems Consultants 1282 9 Bulbul Place 1283 Currumbin Waters QLD 4223 1284 AUSTRALIA 1286 Phone: +61 7 5598 7474 1287 Fax: +61 7 5598 7070 1288 EMail: mikem@open.com.au 1289 URI: http://www.open.com.au.