idnits 2.17.1 draft-ietf-radext-dynamic-discovery-12.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 : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3463 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 (-15) exists of draft-ietf-radext-nai-08 == Outdated reference: A later version (-05) exists of draft-wierenga-ietf-eduroam-04 Summary: 1 error (**), 0 flaws (~~), 4 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: April 30, 2015 OSC 6 October 27, 2014 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-12 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 April 30, 2015. 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 Resource Record definition . . . . . . . . . . . . . 4 57 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4 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 an 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 Provisions for determining the authority of a server to act for 168 users of a realm (declared out of scope for Diameter) 170 o much more in-depth guidance on DNS regarding timeouts, failure 171 conditions, alteration of Time-To-Live (TTL) information than the 172 Diameter counterpart 174 o a partially correct routing error detection during DNS lookups 176 2. Definitions 178 2.1. DNS Resource Record definition 180 DNS definitions of RADIUS/TLS servers can be either S-NAPTR records 181 (see [RFC3958]) or SRV records. When both are defined, the 182 resolution algorithm prefers S-NAPTR results (see Section 3.4 below). 184 2.1.1. S-NAPTR 185 2.1.1.1. Registration of Application Service and Protocol Tags 187 This specification defines three S-NAPTR service tags: 189 +-----------------+-----------------------------------------+ 190 | Service Tag | Use | 191 +-----------------+-----------------------------------------+ 192 | aaa+auth | RADIUS Authentication, i.e. traffic as | 193 | | defined in [RFC2865] | 194 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 195 | aaa+acct | RADIUS Accounting, i.e. traffic as | 196 | | defined in [RFC2866] | 197 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 198 | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | 199 | | traffic as defined in [RFC5176] | 200 +-----------------+-----------------------------------------+ 202 Figure 1: List of Service Tags 204 This specification defines two S-NAPTR protocol tags: 206 +-----------------+-----------------------------------------+ 207 | Protocol Tag | Use | 208 +-----------------+-----------------------------------------+ 209 | radius.tls.tcp | RADIUS transported over TLS as defined | 210 | | in [RFC6614] | 211 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 212 | radius.dtls.udp | RADIUS transported over DTLS as defined | 213 | | in [RFC7360] | 214 +-----------------+-----------------------------------------+ 216 Figure 2: List of Protocol Tags 218 Note well: 220 The S-NAPTR service and protocols are unrelated to the IANA 221 Service Name and Transport Protocol Number registry 223 The delimiter '.' in the protocol tags is only a separator for 224 human reading convenience - not for structure or namespacing; it 225 MUST NOT be parsed in any way by the querying application or 226 resolver. 228 The use of the separator '.' is common also in other protocols' 229 protocol tags. This is coincidence and does not imply a shared 230 semantics with such protocols. 232 2.1.1.2. Definition of Conditions for Retry/Failure 234 RADIUS is a time-critical protocol; RADIUS clients which do not 235 receive an answer after a configurable, but short, amount of time, 236 will consider the request failed. Due to this, there is little 237 leeway for extensive retries. 239 As a general rule, only error conditions which generate an immediate 240 response from the other end are eligible for a retry of a discovered 241 target. Any error condition involving timeouts, or the absence of a 242 reply for more than one second during the connection setup phase is 243 to be considered a failure; the next target in the set of discovered 244 NAPTR targets is to be tried. 246 Note that [RFC3958] already defines that a failure to identify the 247 server as being authoritative for the realm is always considered a 248 failure; so even if a discovered target returns a wrong credential 249 instantly, it is not eligible for retry. 251 Furthermore, the contacted RADIUS/TLS server verifies during 252 connection setup whether or not it finds the connecting RADIUS/TLS 253 client authorized or not. If the connecting RADIUS/TLS client is not 254 found acceptable, the server will close the TLS connection 255 immediately with an appropriate alert. Such TLS handshake failures 256 are permanently fatal and not eligible for retry, unless the 257 connecting client has more X.509 certificates to try; in this case, a 258 retry with the remainder of its set of certificates SHOULD be 259 attempted. 261 If the TLS session setup to a discovered target does not succeed, 262 that target (as identified by IP address and port number) SHOULD be 263 ignored from the result set of any subsequent executions of the 264 discovery algorithm at least until the target's Effective TTL has 265 expired or until the entity which executes the algorithm changes its 266 TLS context to either send a new client certificate or expect a 267 different server certificate. 269 2.1.1.3. Server Identification and Handshake 271 After the algorithm in this document has been executed, a RADIUS/TLS 272 session as per [RFC6614] is established. Since the dynamic discovery 273 algorithm does not have provisions to establish confidential keying 274 material between the RADIUS/TLS client (i.e. the server which 275 executes the discovery algorithm) and the RADIUS/TLS server which was 276 discovered, TLS-PKS ciphersuites cannot be used for in the subsequent 277 TLS handshake. Only TLS ciphersuites using X.509 certificates can be 278 used with this algorithm. 280 There are numerous ways to define which certificates are acceptable 281 for use in this context. This document defines one mandatory-to- 282 implement mechanism which allows to verify whether the contacted host 283 is authoritative for an NAI realm or not. It also gives one example 284 of another mechanism which is currently in wide-spread deployment, 285 and one possible approach based on DNSSEC which is yet unimplemented. 287 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 289 Verification of authority to provide AAA services over RADIUS/TLS is 290 a two-step process. 292 Step 1 is the verification of certificate wellformedness and validity 293 as per [RFC5280] and whether it was issued from a root certificate 294 which is deemed trustworthy by the RADIUS/TLS client. 296 Step 2 is to compare the value of algorithm's variable "R" after the 297 execution of step 3 of the discovery algorithm in Section 3.4.3 below 298 (i.e. after a consortium name mangling, but before conversion to a 299 form usable by the name resolution library) to all values of the 300 contacted RADIUS/TLS server's X.509 certificate property 301 "subjectAlternativeName:otherName:NAIRealm" as defined in 302 Section 2.2. 304 2.1.1.3.2. Other mechanism: Trust Roots + policyOID 306 Verification of authority to provide AAA services over RADIUS/TLS is 307 a two-step process. 309 Step 1 is the verification of certificate wellformedness and validity 310 as per [RFC5280] and whether it was issued from a root certificate 311 which is deemed trustworthy by the RADIUS/TLS client. 313 Step 2 is to compare the values of the contacted RADIUS/TLS server's 314 X.509 certificate's extensions of type "Policy OID" to a list of 315 configured acceptable Policy OIDs for the roaming consortium. If one 316 of the configured OIDs is found in the certificate's Policy OID 317 extensions, then the server is considered authorized; if there is no 318 match, the server is considered unauthorized. 320 This mechanism is inferior to the mandatory-to-implement mechanism in 321 the previous section because all authorized servers are validated by 322 the same OID value; the mechanism is not fine-grained enough to 323 express authority for one specific realm inside the consortium. If 324 the consortium contains members which are hostile against other 325 members, this weakness can be exploited by one RADIUS/TLS server 326 impersonating another if DNS responses can be spoofed by the hostile 327 member. 329 The shortcomings in server identification can be partially mitigated 330 by using the RADIUS infrastructure only with authentication payloads 331 which provide mutual authentication and credential protection (i.e. 332 EAP types passing the criteria of [RFC4017]): using mutual 333 authentication prevents the hostile server from mimicking the real 334 EAP server (it can't terminate the EAP authentication unnoticed 335 because it does not have the server certificate from the real EAP 336 server); protection of credentials prevents the impersonating server 337 from learning usernames and passwords of the ongoing EAP conversation 338 (other RADIUS attributes pertaining to the authentication, such as 339 the EAP peer's Calling-Station-ID, can still be learned though). 341 2.1.1.3.3. Other mechanism: DNSSEC / DANE 343 Where DNSSEC is used, the results of the algorithm can be trusted; 344 i.e. the entity which executes the algorithm can be certain that the 345 realm that triggered the discovery is actually served by the server 346 that was discovered via DNS. However, this does not guarantee that 347 the server is also authorized (i.e. a recognised member of the 348 roaming consortium). 350 The authorization can be sketched using DNSSEC+DANE as follows: if 351 DANE/TLSA records of all authorized servers are put into a DNSSEC 352 zone with a common, consortium-specific branch of the DNS tree, then 353 the entity executing the algorithm can retrieve TLSA Resource Records 354 (TLSA RR) for the label "realm.commonroot" and verify that the 355 presented server certificate during the RADIUS/TLS handshake matches 356 the information in the TLSA record. 358 Example: 360 Realm = "example.com" 362 Common Branch = "idp.roaming-consortium.example. 364 label for TLSA query = "example.com.idp.roaming- 365 consortium.example. 367 result of discovery algorithm for realm "example.com" = 368 192.0.2.1:2083 370 ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : 371 "FAIL" ) 373 2.1.1.3.4. Client Authentication and Authorisation 375 Note that RADIUS/TLS connections always mutually authenticate the 376 RADIUS server and the RADIUS client. This specification provides an 377 algorithm for a RADIUS client to contact and verify authorization of 378 a RADIUS server only. During connection setup, the RADIUS server 379 also needs to verify whether it considers the connecting RADIUS 380 client authorized; this is outside the scope of this specification. 382 2.1.2. SRV 384 This specification defines two SRV prefixes (i.e. two values for the 385 "_service._proto" part of an SRV RR as per [RFC2782]): 387 +-----------------+-----------------------------------------+ 388 | SRV Label | Use | 389 +-----------------+-----------------------------------------+ 390 | _radiustls._tcp | RADIUS transported over TLS as defined | 391 | | in [RFC6614] | 392 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 393 | _radiustls._udp | RADIUS transported over DTLS as defined | 394 | | in [RFC7360] | 395 +-----------------+-----------------------------------------+ 397 Figure 3: List of SRV Labels 399 Just like NAPTR records, the lookup and subsequent follow-up of SRV 400 records may yield more than one server to contact in a prioritised 401 list. [RFC2782] does not specify rules regarding "Definition of 402 Conditions for Retry/Failure", nor "Server Identification and 403 Handshake". This specification defines that the rules for these two 404 topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be 405 used both for targets retrieved via an initial NAPTR RR as well as 406 for targets retrieved via an initial SRV RR (i.e. in the absence of 407 NAPTR RRs). 409 2.1.3. Optional name mangling 411 It is expected that in most cases, the SRV and/or NAPTR label used 412 for the records is the DNS A-label representation of the literal 413 realm name for which the server is the authoritative RADIUS server 414 (i.e. the realm name after conversion according to section 5 of 415 [RFC5891]). 417 However, arbitrary other labels or service tags may be used if, for 418 example, a roaming consortium uses realm names which are not 419 associated to DNS names or special-purpose consortia where a globally 420 valid discovery is not a use case. Such other labels require a 421 consortium-wide agreement about the transformation from realm name to 422 lookup label, and/or which service tag to use. 424 Examples: 426 a. A general-purpose RADIUS server for realm example.com might have 427 DNS entries as follows: 429 example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" 430 _radiustls._tcp.foobar.example.com. 432 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 433 radsec.example.com. 435 b. The consortium "foo" provides roaming services for its members 436 only. The realms used are of the form enterprise-name.example. 437 The consortium operates a special purpose DNS server for the 438 (private) TLD "example" which all RADIUS servers use to resolve 439 realm names. "Company, Inc." is part of the consortium. On the 440 consortium's DNS server, realm company.example might have the 441 following DNS entries: 443 company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp" 444 "" roamserv.company.example 446 c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses 447 realms based on DNS, but provides its services to a closed 448 community only. However, a AAA domain participating in eduroam 449 may also want to expose AAA services to other, general-purpose, 450 applications (on the same or other RADIUS servers). Due to that, 451 the eduroam consortium uses the service tag "x-eduroam" for 452 authentication purposes and eduroam RADIUS servers use this tag 453 to look up other eduroam servers. An eduroam participant 454 example.org which also provides general-purpose AAA on a 455 different server uses the general "aaa+auth" tag: 457 example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" 458 _radiustls._tcp.eduroam.example.org. 460 example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" 461 _radiustls._tcp.aaa.example.org 463 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 464 eduroam.example.org. 466 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 467 default.example.org. 469 2.2. Definition of the X.509 certificate property 470 SubjectAltName:otherName:NAIRealm 472 This specification retrieves IP addresses and port numbers from the 473 Domain Name System which are subsequently used to authenticate users 474 via the RADIUS/TLS protocol. Since the Domain Name System is not 475 necessarily trustworthy (e.g. if DNSSEC is not deployed for the 476 queried domain name), it is important to verify that the server which 477 was contacted is authorized to service requests for the user which 478 triggered the discovery process. 480 The input to the algorithm is an NAI realm as specified in 481 Section 3.4.1. As a consequence, the X.509 certificate of the server 482 which is ultimately contacted for user authentication needs to be 483 able to express that it is authorized to handle requests for that 484 realm. 486 Current subjectAltName fields do not semantically allow to express an 487 NAI realm; the field subjectAltName:dNSName is syntactically a good 488 match but would inappropriately conflate DNS names and NAI realm 489 names. Thus, this specification defines a new subjectAltName field 490 to hold either a single NAI realm name or a wildcard name matching a 491 set of NAI realms. 493 The subjectAltName:otherName:sRVName field certifies that a 494 certificate holder is authorized to provide a service; this can be 495 compared to the target of DNS label's SRV resource record. If the 496 Domain Name System is insecure, it is required that the label of the 497 SRV record itself is known-correct. In this specification, that 498 label is not known-correct; it is potentially derived from a 499 (potentially untrusted) NAPTR resource record of another label. If 500 DNS is not secured with DNSSEC, the NAPTR resource record may have 501 been altered by an attacker with access to the Domain Name System 502 resolution, and thus the label to lookup the SRV record for may 503 already be tainted. This makes subjectAltName:otherName:sRVName not 504 a trusted comparison item. 506 Further to this, this specification's NAPTR entries may be of type 507 "A" which do not involve resolution of any SRV records, which again 508 makes subjectAltName:otherName:sRVName unsuited for this purpose. 510 This section defines the NAIRealm name as a form of otherName from 511 the GeneralName structure in SubjectAltName defined in [RFC5280]. 513 id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } 515 NAIRealm ::= UTF8String (SIZE (1..MAX)) 517 The NAIRealm, if present, MUST contain an NAI realm as defined in 518 [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot- 519 separated part of the NAI with the single character "*" to indicate a 520 wildcard match for "all labels in this part". Further features of 521 regular expressions, such as a number of characters followed by a * 522 to indicate a common prefix inside the part, are not permitted. 524 The comparison of an NAIRealm to the NAI realm as derived from user 525 input with this algorithm is a byte-by-byte comparison, except for 526 the optional leftmost dot-separated part of the value whose content 527 is a single "*" character; such labels match all strings in the same 528 dot-separated part of the NAI realm. If at least one of the 529 sAN:otherName:NAIRealm values matches the NAI realm, the server is 530 considered authorized; if none matches, the server is considered 531 unauthorized. 533 Since multiple names and multiple name forms may occur in the 534 subjectAltName extension, an arbitrary number of NAIRealms can be 535 specified in a certificate. 537 Examples: 539 +---------------------+-------------------+-----------------------+ 540 | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | 541 +---------------------+-------------------+-----------------------+ 542 | foo.example | foo.example | YES | 543 | foo.example | *.example | YES | 544 | bar.foo.example | *.example | NO | 545 | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | 546 | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | 547 | bar.foo.example | *.*.example | NO (NAIRealm invalid) | 548 | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | 549 | sub.bar.foo.example | *.bar.foo.example | YES | 550 +-----------------+-----------------------------------------------+ 552 Figure 4: Examples for NAI realm vs. certificate matching 554 Appendix A contains the ASN.1 definition of the above objects. 556 3. DNS-based NAPTR/SRV Peer Discovery 558 3.1. Applicability 560 Dynamic server discovery as defined in this document is only 561 applicable for new AAA transactions and per service (i.e. distinct 562 discovery is needed for Authentication, Accounting, and Dynamic 563 Authorization) where a RADIUS entity which acts as a forwarding 564 server for one or more realms receives a request with a realm for 565 which it is not authoritative, and which no explicit next hop is 566 configured. It is only applicable for 568 a. new user sessions, i.e. for the initial Access-Request. 569 Subsequent messages concerning this session, for example Access- 570 Challenges and Access-Accepts use the previously-established 571 communication channel between client and server. 573 b. the first accounting ticket for a user session. 575 c. the first RADIUS DynAuth packet for a user session. 577 3.2. Configuration Variables 579 The algorithm contains various variables for timeouts. These 580 variables are named here and reasonable default values are provided. 581 Implementations wishing to deviate from these defaults should make 582 they understand the implications of changes. 584 DNS_TIMEOUT: maximum amount of time to wait for the complete set 585 of all DNS queries to complete: Default = 3 seconds 587 MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 588 seconds 590 BACKOFF_TIME: if no conclusive DNS response was retrieved after 591 DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME 592 has elapsed. Default = 600 seconds 594 3.3. Terms 596 Positive DNS response: a response which contains the RR that was 597 queried for. 599 Negative DNS response: a response which does not contain the RR that 600 was queried for, but contains an SOA record along with a TTL 601 indicating cache duration for this negative result. 603 DNS Error: Where the algorithm states "name resolution returns with 604 an error", this shall mean that either the DNS request timed out, or 605 a DNS response which is neither a positive nor a negative response 606 (e.g. SERVFAIL). 608 Effective TTL: The validity period for discovered RADIUS/TLS target 609 hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { 610 MIN_EFF_TTL, min { DNS TTL values } } 611 SRV lookup: for the purpose of this specification, SRV lookup 612 procedures are defined as per [RFC2782], but excluding that RFCs "A" 613 fallback as defined in its section "Usage Rules", final "else" 614 clause. 616 Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead 617 to a tree of results, whose leafs are the IP addresses to contact. 618 The branches of the tree are ordered according to their order/ 619 preference DNS properties. An implementation is executing greedy 620 result evaluation if it uses a depth-first search in the tree along 621 the highest order results, attempts to connect to the corresponding 622 resulting IP addresses, and only backtracks to other branches if the 623 higher ordered results did not end in successful connection attempts. 625 3.4. Realm to RADIUS server resolution algorithm 627 3.4.1. Input 629 For RADIUS Authentication and RADIUS Accounting server discovery, 630 input I to the algorithm is the RADIUS User-Name attribute with 631 content of the form "user@realm"; the literal @ sign being the 632 separator between a local user identifier within a realm and its 633 realm. The use of multiple literal @ signs in a User-Name is 634 strongly discouraged; but if present, the last @ sign is to be 635 considered the separator. All previous instances of the @ sign are 636 to be considered part of the local user identifier. 638 For RADIUS DynAuth Server discovery, input I to the algorithm is the 639 domain name of the operator of a RADIUS realm as was communicated 640 during user authentication using the Operator-Name attribute 641 ([RFC5580], section 4.1). Only Operator-Name values with the 642 namespace "1" are supported by this algorithm - the input to the 643 algorithm is the actual domain name, preceeded with an "@" (but 644 without the "1" namespace identifier byte of that attribute). 646 Note well: The attribute User-Name is defined to contain UTF-8 text. 647 In practice, the content may or may not be UTF-8. Even if UTF-8, it 648 may or may not map to a domain name in the realm part. Implementors 649 MUST take possible conversion error paths into consideration when 650 parsing incoming User-Name attributes. This document describes 651 server discovery only for well-formed realms mapping to DNS domain 652 names in UTF-8 encoding. The result of all other possible contents 653 of User-Name is unspecified; this includes, but is not limited to: 655 Usage of separators other than @. 657 Encoding of User-Name in local encodings. 659 UTF-8 realms which fail the conversion rules as per [RFC5891]. 661 UTF-8 realms which end with a . ("dot") character. 663 For the last bullet point, "trailing dot", special precautions should 664 be taken to avoid problems when resolving servers with the algorithm 665 below: they may resolve to a RADIUS server even if the peer RADIUS 666 server only is configured to handle the realm without the trailing 667 dot. If that RADIUS server again uses NAI discovery to determine the 668 authoritative server, the server will forward the request to 669 localhost, resulting in a tight endless loop. 671 3.4.2. Output 673 Output O of the algorithm is a two-tuple consisting of: O-1) a set of 674 tuples {hostname; port; protocol; order/preference; Effective TTL} - 675 the set can be empty; and O-2) an integer: if the set in the first 676 part of the tuple is empty, the integer contains the Effective TTL 677 for backoff timeout, if the set is not empty, the integer is set to 0 678 (and not used). 680 3.4.3. Algorithm 682 The algorithm to determine the RADIUS server to contact is as 683 follows: 685 1. Determine P = (position of last "@" character) in I. 687 2. generate R = (substring from P+1 to end of I) 689 3. modify R according to agreed consortium procedures if applicable 691 4. convert R to a representation usable by the name resolution 692 library if needed 694 5. Initialize TIMER = 0; start TIMER. If TIMER reaches 695 DNS_TIMEOUT, continue at step 20. 697 6. Using the host's name resolution library, perform a NAPTR query 698 for R (see "Delay considerations" below). If the result is a 699 negative DNS response, O-2 = Effective TTL ( TTL value of the 700 SOA record ) and continue at step 13. If name resolution 701 returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and 702 terminate. 704 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 705 "aaa+dynauth" as appropriate. Keep note of the protocol tag and 706 remaining TTL of each of the discovered NAPTR records. 708 8. If no records found, continue at step 13. 710 9. For the extracted NAPTRs, perform successive resolution as 711 defined in [RFC3958], section 2.2. An implementation MAY use 712 greedy result evaluation according to the NAPTR order/preference 713 fields (i.e. can execute the subsequent steps of this algorithm 714 for the highest-order entry in the set of results, and only 715 lookup the remainder of the set if necessary). 717 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 718 BACKOFF_TIME and terminate. 720 11. O' = (set of {hostname; port; protocol; order/preference; 721 Effective TTL ( all DNS TTLs that led to this hostname ) } for 722 all terminal lookup results). 724 12. Proceed with step 18. 726 13. Generate R' = (prefix R with "_radiustls._tcp." and/or 727 "_radiustls._udp.") 729 14. Using the host's name resolution library, perform SRV lookup 730 with R' as label (see "Delay considerations" below). 732 15. If name resolution returns with error, O-1 = { empty set }, O-2 733 = BACKOFF_TIME and terminate. 735 16. If the result is a negative DNS response, O-1 = { empty set }, 736 O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) } 737 and terminate. 739 17. O' = (set of {hostname; port; protocol; order/preference; 740 Effective TTL ( all DNS TTLs that led to this result ) } for all 741 hostnames). 743 18. Generate O-1 by resolving hostnames in O' into corresponding A 744 and/or AAAA addresses: O-1 = (set of {IP address; port; 745 protocol; order/preference; Effective TTL ( all DNS TTLs that 746 led to this result ) } for all hostnames ), O-2 = 0. 748 19. For each element in O-1, test if the original request which 749 triggered dynamic discovery was received on {IP address; port}. 750 If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, 751 Terminate (see next section for a rationale). If no, O is the 752 result of dynamic discovery. Terminate. 754 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 756 3.4.4. Validity of results 758 The dynamic discovery algorithm is used by servers which do not have 759 sufficient configuration information to process an incoming request 760 on their own. If the discovery algorithm result contains the 761 server's own listening address (IP address and port), then this will 762 either lead to a tight loop (if that DNS entry has topmost priority, 763 the server would forward the request to itself, triggering dynamic 764 discovery again in a perpetual loop), or lead to a potential loop 765 with intermediate hops in between (the server could forward to 766 another host with a higher priority, which might use DNS itself and 767 forward the packet back to the first server). The underlying reason 768 that enables these loops is that the server executing the discovery 769 algorithm is seriously misconfigured in that it does not recognise 770 the request as one that is to be processed by itself. RADIUS has no 771 built-in loop detection, so any such loops would remain undetected. 772 So, if step 18 of the algorithm discovers such a possible-loop 773 situation, the algorithm should be aborted and an error logged. Note 774 that this safeguard does not provide perfect protection against 775 routing loops: other reasons include the possiblity that a subsequent 776 hop has a statically configured next-hop which leads to an earlier 777 host in the loop; or the algorithm execution was executed with greedy 778 result evaluation, and the own address was in a lower-priority branch 779 of the result set which was not retrieved from DNS at all. 781 After executing the above algorithm, the RADIUS server establishes a 782 connection to a home server from the result set. This connection can 783 potentially remain open for an indefinite amount of time. This 784 conflicts with the possibility of changing device and network 785 configurations on the receiving end. Typically, TTL values for 786 records in the name resolution system are used to indicate how long 787 it is safe to rely on the results of the name resolution. If these 788 TTLs are very low, thrashing of connections becomes possible; the 789 Effective TTL mitigates that risk. When a connection is open and the 790 smallest of the Effective TTL value which was learned during 791 discovering the server has not expired, subsequent new user sessions 792 for the realm which corresponds to that open connection SHOULD re-use 793 the existing connection and SHOULD NOT re-execute the dynamic 794 discovery algorithm nor open a new connection. To allow for a change 795 of configuration, a RADIUS server SHOULD re-execute the dynamic 796 discovery algorithm after the Effective TTL that is associated with 797 this connection has expired. The server MAY keep the session open 798 during this re-assessment to avoid closure and immediate re-opening 799 of the connection should the result not have changed. 801 Should the algorithm above terminate with O-1 = empty set, the RADIUS 802 server SHOULD NOT attempt another execution of this algorithm for the 803 same target realm before the timeout O-2 has passed. 805 3.4.5. Delay considerations 807 The host's name resolution library may need to contact outside 808 entities to perform the name resolution (e.g. authoritative name 809 servers for a domain), and since the NAI discovery algorithm is based 810 on uncontrollable user input, the destination of the lookups is out 811 of control of the server that performs NAI discovery. If such 812 outside entities are misconfigured or unreachable, the algorithm 813 above may need an unacceptably long time to terminate. Many RADIUS 814 implementations time out after five seconds of delay between Request 815 and Response. It is not useful to wait until the host name 816 resolution library signals a timeout of its name resolution 817 algorithms. The algorithm therefore control execution time with 818 TIMER. Execution of the NAI discovery algorithm SHOULD be non- 819 blocking (i.e. allow other requests to be processed in parallel to 820 the execution of the algorithm). 822 3.4.6. Example 824 Assume 826 a user from the Technical University of Munich, Germany, has a 827 RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". 829 The name resolution library on the RADIUS forwarding server does 830 not have the realm tu-m[U+00FC]nchen.example in its forwarding 831 configuration, but uses DNS for name resolution and has configured 832 the use of Dynamic Discovery to discover RADIUS servers. 834 It is IPv6-enabled and prefers AAAA records over A records. 836 It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP 837 /2083. 839 May the configuration variables be 841 DNS_TIMEOUT = 3 seconds 843 MIN_EFF_TTL = 60 seconds 845 BACKOFF_TIME = 3600 seconds 847 If DNS contains the following records: 849 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 850 "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen- 851 t9a.example. 853 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 854 "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. 856 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 857 radsecserver.xn--tu-mnchen-t9a.example. 859 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 860 backupserver.xn--tu-mnchen-t9a.example. 862 radsecserver.xn--tu-mnchen-t9a.example. IN AAAA 863 2001:0DB8::202:44ff:fe0a:f704 865 radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 867 backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 869 Then the algorithm executes as follows, with I = 870 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 871 in use: 873 1. P = 7 875 2. R = "tu-m[U+00FC]nchen.example" 877 3. NOOP 879 4. name resolution library converts R to xn--tu-mnchen-t9a.example 881 5. TIMER starts. 883 6. Result: 885 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 886 _myradius._tcp.xn--tu-mnchen-t9a.example. 888 (TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" 889 _abc123._def.xn--tu-mnchen-t9a.example. 891 7. Result: 893 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 894 _myradius._tcp.xn--tu-mnchen-t9a.example. 896 8. NOOP 898 9. Successive resolution performs SRV query for label 899 _myradius._tcp.xn--tu-mnchen-t9a.example, which results in 900 (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. 902 (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. 904 10. NOOP 906 11. O' = { 908 (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 909 60), 911 (backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60) 913 } // minimum TTL is 47, up'ed to MIN_EFF_TTL 915 12. Continuing at 18. 917 13. (not executed) 919 14. (not executed) 921 15. (not executed) 923 16. (not executed) 925 17. (not executed) 927 18. O-1 = { 929 (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), 931 (192.0.2.7; 2083; RADIUS/TLS; 20; 60) 933 }; O-2 = 0 935 19. No match with own listening address; terminate with tuple (O-1, 936 O-2) from previous step. 938 The implementation will then attempt to connect to two servers, with 939 preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ 940 TLS protocol. 942 4. Operations and Manageability Considerations 944 The discovery algorithm as defined in this document contains several 945 options; the major ones being use of NAPTR vs. SRV; how to determine 946 the authorization status of a contacted server for a given realm; 947 which trust anchors to consider trustworthy for the RADIUS 948 conversation setup. 950 Random parties which do not agree on the same set of options may not 951 be able to interoperate. However, such a global interoperability is 952 not intended by this document. 954 Discovery as per this document becomes important inside a roaming 955 consortium, which has set up roaming agreements with the other 956 partners. Such roaming agreements require much more than a technical 957 means of server discovery; there are administrative and contractual 958 considerations at play (service contracts, backoffice compensations, 959 procedures, ...). 961 A roaming consortium's roaming agreement must include a profile of 962 which choice points of this document to use. So long as the roaming 963 consortium can settle on one deployment profile, they will be able to 964 interoperate based on that choice; this per-consortium 965 interoperability is the intended scope of this document. 967 5. Security Considerations 969 When using DNS without DNSSEC security extensions and validation for 970 all of the replies to NAPTR, SRV and A/AAAA requests as described in 971 section Section 3, the result O can not be trusted. Even if it can 972 be trusted (i.e. DNSSEC is in use), actual authorization of the 973 discovered server to provide service for the given realm needs to be 974 verified. A mechanism from section Section 2.1.1.3 or equivalent 975 MUST be used to verify authorization. 977 The algorithm has a configurable completion timeout DNS_TIMEOUT 978 defaulting to three seconds for RADIUS' operational reasons. The 979 lookup of DNS resource records based on unverified user input is an 980 attack vector for DoS attacks: an attacker might intentionally craft 981 bogus DNS zones which take a very long time to reply (e.g. due to a 982 particularly byzantine tree structure, or artificial delays in 983 responses). 985 To mitigate this DoS vector, implementations SHOULD consider rate- 986 limiting either their amount of new executions of the dynamic 987 discovery algorithm as a whole, or the amount of intermediate 988 responses to track, or at least the number of pending DNS queries. 989 Implementations MAY choose lower values than the default for 990 DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They 991 MAY also continue their attempt to resolve DNS records even after 992 DNS_TIMEOUT has passed; a subsequent request for the same realm might 993 benefit from retrieving the results anyway. The amount of time to 994 spent waiting for a result will influence the impact of a possible 995 DoS attack; the waiting time value is implementation dependent and 996 outside the scope of this specification. 998 With Dynamic Discovery being enabled for a RADIUS Server, and 999 depending on the deployment scenario, the server may need to open up 1000 its target IP address and port for the entire internet, because 1001 arbitrary clients may discover it as a target for their 1002 authentication requests. If such clients are not part of the roaming 1003 consortium, the RADIUS/TLS connection setup phase will fail (which is 1004 intended) but the computational cost for the connection attempt is 1005 significant. With the port for a TLS-based service open, the RADIUS 1006 server shares all the typical attack vectors for services based on 1007 TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with 1008 Dynamic Discovery should consider these attack vectors and take 1009 appropriate counter-measures (e.g. blacklisting known-bad IPs on a 1010 firewall, rate-limiting new connection attempts, etc.). 1012 6. Privacy Considerations 1014 The classic RADIUS operational model (known, pre-configured peers, 1015 shared secret security, mostly plaintext communication) and this new 1016 RADIUS dynamic discovery model (peer discovery with DNS, PKI security 1017 and packet confidentiality) differ significantly in their impact on 1018 the privacy of end users trying to authenticate to a RADIUS server. 1020 With classic RADIUS, traffic in large environments gets aggregated by 1021 statically configured clearinghouses. The packets sent to those 1022 clearinghouses and their responses are mostly unprotected. As a 1023 consequence, 1025 o All intermediate IP hops can inspect most of the packet payload in 1026 clear text, including the User-Name and Calling-Station-Id 1027 attributes, and can observe which client sent the packet to which 1028 clearinghouse. This allows the creation of mobility profiles for 1029 any passive observer on the IP path. 1031 o The existence of a central clearinghouse creates an opportunity 1032 for the clearinghouse to trivially create the same mobility 1033 profiles. The clearinghouse may or may not be trusted not to do 1034 this, e.g. by sufficiently threatening contractual obligations. 1036 o In addition to that, with the clearinghouse being a RADIUS 1037 intermediate in possession of a valid shared secret, the 1038 clearinghouse can observe and record even the security-critical 1039 RADIUS attributes such as User-Password. This risk may be 1040 mitigated by choosing authentication payloads which are 1041 cryptographically secured and do not use the attribute User- 1042 Password - such as certain EAP types. 1044 o There is no additional information disclosure to parties outside 1045 the IP path between the RADIUS client and server (in particular, 1046 no DNS servers learn about realms of current ongoing 1047 authentications). 1049 With RADIUS and dynamic discovery, 1051 o This protocol allows for RADIUS clients to identify and directly 1052 connect to the RADIUS home server. This can eliminate the use of 1053 clearinghouses to do forwarding of requests, and it also 1054 eliminates the ability of the clearinghouse to then aggregate the 1055 user information that flows through it. However, there exist 1056 reasons why clearinghouses might still be used. One reason to 1057 keep a clearinghouse is to act as a gateway for multiple backends 1058 in a company; another reason may be a requirement to sanitise 1059 RADIUS datagrams (filter attributes, tag requests with new 1060 attributes, ... ). 1062 o Even where intermediate proxies continue to be used for reasons 1063 unrelated to dynamic discovery, the number of such intermediates 1064 may be reduced by removing those proxies which are only deployed 1065 for pure request routing reasons. This reduces the number of 1066 entities which can inspect the RADIUS traffic. 1068 o RADIUS clients which make use of dynamic discovery will need to 1069 query the Domain Name System, and use a user's realm name as the 1070 query label. A passive observer on the IP path between the RADIUS 1071 client and the DNS server(s) being queried can learn that a user 1072 of that specific realm was trying to authenticate at that RADIUS 1073 client at a certain point in time. This may or may not be 1074 sufficient for the passive observer to create a mobility profile. 1075 During the recursive DNS resolution, a fair number of DNS servers 1076 and the IP hops in between those get to learn that information. 1077 Not every single authentication triggers DNS lookups, so there is 1078 no one-to-one relation of leaked realm information and the number 1079 of authentications for that realm. 1081 o Since dynamic discovery operates on a RADIUS hop-by-hop basis, 1082 there is no guarantee that the RADIUS payload is not transmitted 1083 between RADIUS systems which do not make use of this algorithm, 1084 and possibly using other transports such as RADIUS/UDP. On such 1085 hops, the enhanced privacy is jeopardized. 1087 In summary, with classic RADIUS, few intermediate entities learn very 1088 detailed data about every ongoing authentications, while with dynamic 1089 discovery, many entities learn only very little about recently 1090 authenticated realms. 1092 7. IANA Considerations 1094 This document requests IANA registration of the following entries in 1095 existing registries: 1097 o S-NAPTR Application Service Tags registry 1099 * aaa+auth 1101 * aaa+acct 1103 * aaa+dynauth 1105 o S-NAPTR Application Protocol Tags registry 1107 * radius.tls.tcp 1109 * radius.dtls.udp 1111 This document reserves the use of the "radiustls" and "radiusdtls" 1112 service names. Registration information as per [RFC6335] section 1113 8.1.1 is as follows: 1115 Service Name: radiustls; radiusdtls 1117 Transport Protocols: TCP, UDP 1119 Assignee: IESG 1121 Contact: IETF Chair 1123 Description: Authentication, Accounting and Dynamic authorization 1124 via the RADIUS protocol. These service names are used to 1125 construct the SRV service labels "_radiustls" and "_radiusdtls" 1126 for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. 1128 Reference: RFC Editor Note: please insert the RFC number of this 1129 document. The protocol does not use broadcast, multicast or 1130 anycast communication. 1132 This specification makes use of the SRV Protocol identifiers "_tcp" 1133 and "_udp" which are mentioned as early as [RFC2782] but do not 1134 appear to be assigned in an actual registry. Since they are in wide- 1135 spread use in other protocols, this specification refrains from 1136 requesting a new registry "RADIUS/TLS SRV Protocol Registry" and 1137 continues to make use of these tags implicitly. 1139 This document requires that a number of Object Identifiers be 1140 assigned. They are now under the control of IANA following [RFC7299] 1142 IANA is requested to assign the following identifiers: 1144 TBD99 is to be assigned from the "SMI Security for PKIX Module 1145 Identifier Registry". The suggested description is id-mod-nai- 1146 realm-08. 1148 TBD98 is to be assigned from the "SMI Security for PKIX Other Name 1149 Forms Registry." The suggested description is id-on-nai. 1151 RFC Editor Note: please replace the occurences of TBD98 and TBD99 in 1152 Appendix A of the document with the actually assigned numbers. 1154 8. References 1156 8.1. Normative References 1158 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1159 Requirement Levels", BCP 14, RFC 2119, March 1997. 1161 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1162 specifying the location of services (DNS SRV)", RFC 2782, 1163 February 2000. 1165 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1166 "Remote Authentication Dial In User Service (RADIUS)", RFC 1167 2865, June 2000. 1169 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1171 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1172 Service Location Using SRV RRs and the Dynamic Delegation 1173 Discovery Service (DDDS)", RFC 3958, January 2005. 1175 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1176 Network Access Identifier", RFC 4282, December 2005. 1178 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1179 Aboba, "Dynamic Authorization Extensions to Remote 1180 Authentication Dial In User Service (RADIUS)", RFC 5176, 1181 January 2008. 1183 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1184 Housley, R., and W. Polk, "Internet X.509 Public Key 1185 Infrastructure Certificate and Certificate Revocation List 1186 (CRL) Profile", RFC 5280, May 2008. 1188 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 1189 Aboba, "Carrying Location Objects in RADIUS and Diameter", 1190 RFC 5580, August 2009. 1192 [RFC5891] Klensin, J., "Internationalized Domain Names in 1193 Applications (IDNA): Protocol", RFC 5891, August 2010. 1195 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1196 "Transport Layer Security (TLS) Encryption for RADIUS", 1197 RFC 6614, May 2012. 1199 [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a 1200 Transport Layer for RADIUS", RFC 7360, September 2014. 1202 [I-D.ietf-radext-nai] 1203 DeKok, A., "The Network Access Identifier", draft-ietf- 1204 radext-nai-08 (work in progress), September 2014. 1206 8.2. Informative References 1208 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1209 Authentication Protocol (EAP) Method Requirements for 1210 Wireless LANs", RFC 4017, March 2005. 1212 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1213 Cheshire, "Internet Assigned Numbers Authority (IANA) 1214 Procedures for the Management of the Service Name and 1215 Transport Protocol Port Number Registry", BCP 165, RFC 1216 6335, August 2011. 1218 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1219 "Diameter Base Protocol", RFC 6733, October 2012. 1221 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1222 Working Group", RFC 7299, July 2014. 1224 [I-D.wierenga-ietf-eduroam] 1225 Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1226 architecture for network roaming", draft-wierenga-ietf- 1227 eduroam-04 (work in progress), August 2014. 1229 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm 1231 PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6) 1232 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1233 id-mod-nai-realm-08 (TBD99) } 1235 DEFINITIONS EXPLICIT TAGS ::= 1237 BEGIN 1239 -- EXPORTS ALL -- 1241 IMPORTS 1243 id-pkix 1244 FROM PKIX1Explicit-2009 1245 {iso(1) identified-organization(3) dod(6) internet(1) 1246 security(5) mechanisms(5) pkix(7) id-mod(0) 1247 id-mod-pkix1-explicit-02(51)} 1248 -- from RFC 5280, RFC 5912 1250 OTHER-NAME 1251 FROM PKIX1Implicit-2009 1252 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1253 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1254 -- from RFC 5280, RFC 5912 1255 ; 1257 -- Service Name Object Identifier 1259 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1261 id-on-nai OBJECT IDENTIFIER ::= { id-on TBD98 } 1263 -- Service Name 1265 naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }} 1267 NAIRealm ::= UTF8String (SIZE (1..MAX)) 1269 END 1271 Authors' Addresses 1273 Stefan Winter 1274 Fondation RESTENA 1275 6, rue Richard Coudenhove-Kalergi 1276 Luxembourg 1359 1277 LUXEMBOURG 1279 Phone: +352 424409 1 1280 Fax: +352 422473 1281 EMail: stefan.winter@restena.lu 1282 URI: http://www.restena.lu. 1284 Mike McCauley 1285 Open Systems Consultants 1286 9 Bulbul Place 1287 Currumbin Waters QLD 4223 1288 AUSTRALIA 1290 Phone: +61 7 5598 7474 1291 Fax: +61 7 5598 7070 1292 EMail: mikem@open.com.au 1293 URI: http://www.open.com.au.