idnits 2.17.1 draft-ietf-radext-dynamic-discovery-13.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 6 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 (March 06, 2015) is 3311 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 (-05) exists of draft-wierenga-ietf-eduroam-04 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 7, 2015 AirSpayce 6 March 06, 2015 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-13 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 7, 2015. 34 Copyright Notice 36 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . 5 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 54 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 6 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.1. DNS Resource Record (RR) definition . . . . . . . . . . . 7 57 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 12 60 2.2. Definition of the X.509 certificate property 61 SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 13 62 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 15 63 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 15 64 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 16 65 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 17 67 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 17 68 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 18 69 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 18 70 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 19 71 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 20 72 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21 73 4. Operations and Manageability Considerations . . . . . . . . . 23 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 75 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 79 8.2. Informative References . . . . . . . . . . . . . . . . . 29 80 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 30 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 Where realms can be partitioned (e.g. according to their top-level 108 domain ending), forwarding of requests can be realised with a 109 hierarchy of RADIUS servers, all serving their partition of the realm 110 space. Figure 1 show an example of this hierarchical routing. 112 +-------+ 113 | | 114 | . | 115 | | 116 +---+---+ 117 / | \ 118 +----------------/ | \---------------------+ 119 | | | 120 | | | 121 | | | 122 +--+---+ +--+--+ +----+---+ 123 | | | | | | 124 | .edu | . . . | .nl | . . . | .ac.uk | 125 | | | | | | 126 +--+---+ +--+--+ +----+---+ 127 / | \ | \ | 128 / | \ | \ | 129 / | \ | \ | 130 +-----+ | +-----+ | +------+ | 131 | | | | | | 132 | | | | | | 133 +---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+ 134 | | | | | | | | | | | | 135 |utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk| 136 | | | | | | | | | | | | 137 +----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+ 138 | | 139 | | 140 +--+--+ +--+--+ 141 | | | | 142 +-+-----+-+ | | 143 | | +-----+ 144 +---------+ 145 user: paul@surfnet.nl surfnet.nl Authentication server 147 Figure 1: RADIUS hierarchy based on Top-Level Domain partitioning 149 However, such partitioning is not always possible. As an example, in 150 one real-life deployment, the administrative boundaries and RADIUS 151 forwarding servers are are organised along country borders, but 152 generic top-level domains such as .edu do not map to this choice of 153 boundaries (see [I-D.wierenga-ietf-eduroam] for details). These 154 situations can benefit significantly from a distributed mechanism for 155 storing realm and server reachability information. This document 156 describes one such mechanism: storage of realm-to-server mappings in 157 DNS; realm-based request forwarding can then be realised without a 158 static hierarchy such as in the following figure: 160 --------- 161 / \ 162 --------- ------------ 163 / \ 164 | DNS - 165 ----------| \ 166 / \ surfnet.nl NAPTR? | 167 (1) / ---- -> radius.surfnet.nl / 168 / \ / 169 / -------- --------- 170 / \---------/ 171 | 172 | --------------------------------------- 173 | / (2) RADIUS \ 174 | | | 175 +---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+ 176 | | | | | | | | | | | | 177 |utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk| 178 | | | | | | | | | | | | 179 +----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+ 180 | | 181 | | 182 +--+--+ +--+--+ 183 | | | | 184 +-+-----+-+ | | 185 | | +-----+ 186 +---------+ 187 user: paul@surfnet.nl surfnet.nl Authentication server 189 Figure 2: RADIUS hierarchy based on Top-Level Domain partitioning 191 This document also specifies various approaches for verifying that 192 server information which was retrieved from DNS was from an 193 authorised party; e.g. an organisation which is not at all part of a 194 given roaming consortium may alter its own DNS records to yield a 195 result for its own realm. 197 1.1. Requirements Language 199 In this document, several words are used to signify the requirements 200 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 201 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 202 and "OPTIONAL" in this document are to be interpreted as described in 203 RFC 2119. [RFC2119] 205 1.2. Terminology 207 RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a 208 new connection. 210 RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a 211 RADIUS/TLS port and accepts new connections 213 RADIUS/TLS node: a RADIUS/TLS client or server 215 [RFC4282] and its designated successor [I-D.ietf-radext-nai] define 216 the terms NAI, realm, consortium. RFC Editor Note: please remove the 217 RFC4282 reference here and in the Normative References section prior 218 to publication and replace the draft NAI spec with its then-allocated 219 RFC number. 221 1.3. Document Status 223 This document is an Experimental RFC. 225 The communities expected to use this document are roaming consortia 226 whose authentication services are based on the RADIUS protocol. 228 The duration of the experiment is undetermined; as soon as enough 229 experience is collected on the choice points mentioned below, it is 230 expected to be obsoleted by a standards-track version of the protocol 231 which trims down the choice points. 233 If that removal of choice points obsoletes tags or service names as 234 defined in this document and allocated by IANA, these items will be 235 returned to IANA as per the provisions in [RFC6335]. 237 The document provides a discovery mechanism for RADIUS which is very 238 similar to the approach that is taken with the Diameter protocol 239 [RFC6733]. As such, the basic approach (using Naming Authority 240 Pointer (NAPTR) records in DNS domains which match NAI realms) is not 241 of very experimental nature. 243 However, the document offers a few choice points and extensions which 244 go beyond the provisions for Diameter. The list of major additions/ 245 deviations is 247 o Provisions for determining the authority of a server to act for 248 users of a realm (declared out of scope for Diameter) 250 o much more in-depth guidance on DNS regarding timeouts, failure 251 conditions, alteration of Time-To-Live (TTL) information than the 252 Diameter counterpart 254 o a partially correct routing error detection during DNS lookups 256 2. Definitions 258 2.1. DNS Resource Record (RR) definition 260 DNS definitions of RADIUS/TLS servers can be either S-NAPTR records 261 (see [RFC3958]) or Service Record (SRV) records. When both are 262 defined, the resolution algorithm prefers S-NAPTR results (see 263 Section 3.4 below). 265 2.1.1. S-NAPTR 267 2.1.1.1. Registration of Application Service and Protocol Tags 269 This specification defines three S-NAPTR service tags: 271 +-----------------+-----------------------------------------+ 272 | Service Tag | Use | 273 +-----------------+-----------------------------------------+ 274 | aaa+auth | RADIUS Authentication, i.e. traffic as | 275 | | defined in [RFC2865] | 276 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 277 | aaa+acct | RADIUS Accounting, i.e. traffic as | 278 | | defined in [RFC2866] | 279 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 280 | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | 281 | | traffic as defined in [RFC5176] | 282 +-----------------+-----------------------------------------+ 284 Figure 3: List of Service Tags 286 This specification defines two S-NAPTR protocol tags: 288 +-----------------+-----------------------------------------+ 289 | Protocol Tag | Use | 290 +-----------------+-----------------------------------------+ 291 | radius.tls.tcp | RADIUS transported over TLS as defined | 292 | | in [RFC6614] | 293 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 294 | radius.dtls.udp | RADIUS transported over DTLS as defined | 295 | | in [RFC7360] | 296 +-----------------+-----------------------------------------+ 298 Figure 4: List of Protocol Tags 300 Note well: 302 The S-NAPTR service and protocols are unrelated to the IANA 303 Service Name and Transport Protocol Number registry 305 The delimiter '.' in the protocol tags is only a separator for 306 human reading convenience - not for structure or namespacing; it 307 MUST NOT be parsed in any way by the querying application or 308 resolver. 310 The use of the separator '.' is common also in other protocols' 311 protocol tags. This is coincidence and does not imply a shared 312 semantics with such protocols. 314 2.1.1.2. Definition of Conditions for Retry/Failure 316 RADIUS is a time-critical protocol; RADIUS clients which do not 317 receive an answer after a configurable, but short, amount of time, 318 will consider the request failed. Due to this, there is little 319 leeway for extensive retries. 321 As a general rule, only error conditions which generate an immediate 322 response from the other end are eligible for a retry of a discovered 323 target. Any error condition involving timeouts, or the absence of a 324 reply for more than one second during the connection setup phase is 325 to be considered a failure; the next target in the set of discovered 326 NAPTR targets is to be tried. 328 Note that [RFC3958] already defines that a failure to identify the 329 server as being authoritative for the realm is always considered a 330 failure; so even if a discovered target returns a wrong credential 331 instantly, it is not eligible for retry. 333 Furthermore, the contacted RADIUS/TLS server verifies during 334 connection setup whether or not it finds the connecting RADIUS/TLS 335 client authorized or not. If the connecting RADIUS/TLS client is not 336 found acceptable, the server will close the TLS connection 337 immediately with an appropriate alert. Such TLS handshake failures 338 are permanently fatal and not eligible for retry, unless the 339 connecting client has more X.509 certificates to try; in this case, a 340 retry with the remainder of its set of certificates SHOULD be 341 attempted. 343 If the TLS session setup to a discovered target does not succeed, 344 that target (as identified by IP address and port number) SHOULD be 345 ignored from the result set of any subsequent executions of the 346 discovery algorithm at least until the target's Effective TTL has 347 expired or until the entity which executes the algorithm changes its 348 TLS context to either send a new client certificate or expect a 349 different server certificate. 351 2.1.1.3. Server Identification and Handshake 353 After the algorithm in this document has been executed, a RADIUS/TLS 354 session as per [RFC6614] is established. Since the dynamic discovery 355 algorithm does not have provisions to establish confidential keying 356 material between the RADIUS/TLS client (i.e. the server which 357 executes the discovery algorithm) and the RADIUS/TLS server which was 358 discovered, TLS-PKS ciphersuites cannot be used for in the subsequent 359 TLS handshake. Only TLS ciphersuites using X.509 certificates can be 360 used with this algorithm. 362 There are numerous ways to define which certificates are acceptable 363 for use in this context. This document defines one mandatory-to- 364 implement mechanism which allows to verify whether the contacted host 365 is authoritative for an NAI realm or not. It also gives one example 366 of another mechanism which is currently in wide-spread deployment, 367 and one possible approach based on DNSSEC which is yet unimplemented. 369 For the approaches which use trust roots (see the following two 370 sections), a typical deployment will use a dedicated trust store for 371 RADIUS/TLS certificate authorities, particularly a trust store which 372 is independent from default "browser" trust stores. Often, this will 373 be one or few CAs, and they only issue certificates for the specific 374 purpose of establishing RADIUS server-to-server trust. It is 375 important not to trust a large set of CAs which operate outside the 376 control of the roaming consortium, for their issuance of certificates 377 with the properties important for authorisation (such as NAIRealm and 378 policyOID below) is difficult to verify. Therefore, clients SHOULD 379 NOT be pre-configured with a list of known public CAs by the vendor 380 or manufacturer. Instead, the clients SHOULD start off with an empty 381 CA list. The addition of a CA SHOULD be done only when manually 382 configured by an administrator. 384 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 386 Verification of authority to provide AAA services over RADIUS/TLS is 387 a two-step process. 389 Step 1 is the verification of certificate wellformedness and validity 390 as per [RFC5280] and whether it was issued from a root certificate 391 which is deemed trustworthy by the RADIUS/TLS client. 393 Step 2 is to compare the value of algorithm's variable "R" after the 394 execution of step 3 of the discovery algorithm in Section 3.4.3 below 395 (i.e. after a consortium name mangling, but before conversion to a 396 form usable by the name resolution library) to all values of the 397 contacted RADIUS/TLS server's X.509 certificate property 398 "subjectAlternativeName:otherName:NAIRealm" as defined in 399 Section 2.2. 401 2.1.1.3.2. Other mechanism: Trust Roots + policyOID 403 Verification of authority to provide AAA services over RADIUS/TLS is 404 a two-step process. 406 Step 1 is the verification of certificate wellformedness and validity 407 as per [RFC5280] and whether it was issued from a root certificate 408 which is deemed trustworthy by the RADIUS/TLS client. 410 Step 2 is to compare the values of the contacted RADIUS/TLS server's 411 X.509 certificate's extensions of type "Policy OID" to a list of 412 configured acceptable Policy OIDs for the roaming consortium. If one 413 of the configured OIDs is found in the certificate's Policy OID 414 extensions, then the server is considered authorized; if there is no 415 match, the server is considered unauthorized. 417 This mechanism is inferior to the mandatory-to-implement mechanism in 418 the previous section because all authorized servers are validated by 419 the same OID value; the mechanism is not fine-grained enough to 420 express authority for one specific realm inside the consortium. If 421 the consortium contains members which are hostile against other 422 members, this weakness can be exploited by one RADIUS/TLS server 423 impersonating another if DNS responses can be spoofed by the hostile 424 member. 426 The shortcomings in server identification can be partially mitigated 427 by using the RADIUS infrastructure only with authentication payloads 428 which provide mutual authentication and credential protection (i.e. 429 EAP types passing the criteria of [RFC4017]): using mutual 430 authentication prevents the hostile server from mimicking the real 431 EAP server (it can't terminate the EAP authentication unnoticed 432 because it does not have the server certificate from the real EAP 433 server); protection of credentials prevents the impersonating server 434 from learning usernames and passwords of the ongoing EAP conversation 435 (other RADIUS attributes pertaining to the authentication, such as 436 the EAP peer's Calling-Station-ID, can still be learned though). 438 2.1.1.3.3. Other mechanism: DNSSEC / DANE 440 Where DNSSEC is used, the results of the algorithm can be trusted; 441 i.e. the entity which executes the algorithm can be certain that the 442 realm that triggered the discovery is actually served by the server 443 that was discovered via DNS. However, this does not guarantee that 444 the server is also authorized (i.e. a recognised member of the 445 roaming consortium). 447 The authorization can be sketched using DNSSEC+DANE as follows: if 448 DANE/TLSA records of all authorized servers are put into a DNSSEC 449 zone with a common, consortium-specific branch of the DNS tree, then 450 the entity executing the algorithm can retrieve TLSA Resource Records 451 (TLSA RR) for the label "realm.commonroot" and verify that the 452 presented server certificate during the RADIUS/TLS handshake matches 453 the information in the TLSA record. 455 Example: 457 Realm = "example.com" 459 Common Branch = "idp.roaming-consortium.example. 461 label for TLSA query = "example.com.idp.roaming- 462 consortium.example. 464 result of discovery algorithm for realm "example.com" = 465 192.0.2.1:2083 467 ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : 468 "FAIL" ) 470 2.1.1.3.4. Client Authentication and Authorisation 472 Note that RADIUS/TLS connections always mutually authenticate the 473 RADIUS server and the RADIUS client. This specification provides an 474 algorithm for a RADIUS client to contact and verify authorization of 475 a RADIUS server only. During connection setup, the RADIUS server 476 also needs to verify whether it considers the connecting RADIUS 477 client authorized; this is outside the scope of this specification. 479 2.1.2. SRV 481 This specification defines two SRV prefixes (i.e. two values for the 482 "_service._proto" part of an SRV RR as per [RFC2782]): 484 +-----------------+-----------------------------------------+ 485 | SRV Label | Use | 486 +-----------------+-----------------------------------------+ 487 | _radiustls._tcp | RADIUS transported over TLS as defined | 488 | | in [RFC6614] | 489 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 490 | _radiustls._udp | RADIUS transported over DTLS as defined | 491 | | in [RFC7360] | 492 +-----------------+-----------------------------------------+ 494 Figure 5: List of SRV Labels 496 Just like NAPTR records, the lookup and subsequent follow-up of SRV 497 records may yield more than one server to contact in a prioritised 498 list. [RFC2782] does not specify rules regarding "Definition of 499 Conditions for Retry/Failure", nor "Server Identification and 500 Handshake". This specification defines that the rules for these two 501 topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be 502 used both for targets retrieved via an initial NAPTR RR as well as 503 for targets retrieved via an initial SRV RR (i.e. in the absence of 504 NAPTR RRs). 506 2.1.3. Optional name mangling 508 It is expected that in most cases, the SRV and/or NAPTR label used 509 for the records is the DNS A-label representation of the literal 510 realm name for which the server is the authoritative RADIUS server 511 (i.e. the realm name after conversion according to section 5 of 512 [RFC5891]). 514 However, arbitrary other labels or service tags may be used if, for 515 example, a roaming consortium uses realm names which are not 516 associated to DNS names or special-purpose consortia where a globally 517 valid discovery is not a use case. Such other labels require a 518 consortium-wide agreement about the transformation from realm name to 519 lookup label, and/or which service tag to use. 521 Examples: 523 a. A general-purpose RADIUS server for realm example.com might have 524 DNS entries as follows: 526 example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" 527 _radiustls._tcp.foobar.example.com. 529 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 530 radsec.example.com. 532 b. The consortium "foo" provides roaming services for its members 533 only. The realms used are of the form enterprise-name.example. 534 The consortium operates a special purpose DNS server for the 535 (private) TLD "example" which all RADIUS servers use to resolve 536 realm names. "Company, Inc." is part of the consortium. On the 537 consortium's DNS server, realm company.example might have the 538 following DNS entries: 540 company.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls.udp" 541 "" roamserv.company.example 543 c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses 544 realms based on DNS, but provides its services to a closed 545 community only. However, a AAA domain participating in eduroam 546 may also want to expose AAA services to other, general-purpose, 547 applications (on the same or other RADIUS servers). Due to that, 548 the eduroam consortium uses the service tag "x-eduroam" for 549 authentication purposes and eduroam RADIUS servers use this tag 550 to look up other eduroam servers. An eduroam participant 551 example.org which also provides general-purpose AAA on a 552 different server uses the general "aaa+auth" tag: 554 example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" 555 _radiustls._tcp.eduroam.example.org. 557 example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" 558 _radiustls._tcp.aaa.example.org 560 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 561 eduroam.example.org. 563 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 564 default.example.org. 566 2.2. Definition of the X.509 certificate property 567 SubjectAltName:otherName:NAIRealm 569 This specification retrieves IP addresses and port numbers from the 570 Domain Name System which are subsequently used to authenticate users 571 via the RADIUS/TLS protocol. Since the Domain Name System is not 572 necessarily trustworthy (e.g. if DNSSEC is not deployed for the 573 queried domain name), it is important to verify that the server which 574 was contacted is authorized to service requests for the user which 575 triggered the discovery process. 577 The input to the algorithm is an NAI realm as specified in 578 Section 3.4.1. As a consequence, the X.509 certificate of the server 579 which is ultimately contacted for user authentication needs to be 580 able to express that it is authorized to handle requests for that 581 realm. 583 Current subjectAltName fields do not semantically allow to express an 584 NAI realm; the field subjectAltName:dNSName is syntactically a good 585 match but would inappropriately conflate DNS names and NAI realm 586 names. Thus, this specification defines a new subjectAltName field 587 to hold either a single NAI realm name or a wildcard name matching a 588 set of NAI realms. 590 The subjectAltName:otherName:sRVName field certifies that a 591 certificate holder is authorized to provide a service; this can be 592 compared to the target of DNS label's SRV resource record. If the 593 Domain Name System is insecure, it is required that the label of the 594 SRV record itself is known-correct. In this specification, that 595 label is not known-correct; it is potentially derived from a 596 (potentially untrusted) NAPTR resource record of another label. If 597 DNS is not secured with DNSSEC, the NAPTR resource record may have 598 been altered by an attacker with access to the Domain Name System 599 resolution, and thus the label to lookup the SRV record for may 600 already be tainted. This makes subjectAltName:otherName:sRVName not 601 a trusted comparison item. 603 Further to this, this specification's NAPTR entries may be of type 604 "A" which do not involve resolution of any SRV records, which again 605 makes subjectAltName:otherName:sRVName unsuited for this purpose. 607 This section defines the NAIRealm name as a form of otherName from 608 the GeneralName structure in SubjectAltName defined in [RFC5280]. 610 id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } 612 NAIRealm ::= UTF8String (SIZE (1..MAX)) 614 The NAIRealm, if present, MUST contain an NAI realm as defined in 615 [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot- 616 separated part of the NAI with the single character "*" to indicate a 617 wildcard match for "all labels in this part". Further features of 618 regular expressions, such as a number of characters followed by a * 619 to indicate a common prefix inside the part, are not permitted. 621 The comparison of an NAIRealm to the NAI realm as derived from user 622 input with this algorithm is a byte-by-byte comparison, except for 623 the optional leftmost dot-separated part of the value whose content 624 is a single "*" character; such labels match all strings in the same 625 dot-separated part of the NAI realm. If at least one of the 626 sAN:otherName:NAIRealm values matches the NAI realm, the server is 627 considered authorized; if none matches, the server is considered 628 unauthorized. 630 Since multiple names and multiple name forms may occur in the 631 subjectAltName extension, an arbitrary number of NAIRealms can be 632 specified in a certificate. 634 Examples: 636 +---------------------+-------------------+-----------------------+ 637 | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | 638 +---------------------+-------------------+-----------------------+ 639 | foo.example | foo.example | YES | 640 | foo.example | *.example | YES | 641 | bar.foo.example | *.example | NO | 642 | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | 643 | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | 644 | bar.foo.example | *.*.example | NO (NAIRealm invalid) | 645 | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | 646 | sub.bar.foo.example | *.bar.foo.example | YES | 647 +-----------------+-----------------------------------------------+ 649 Figure 6: Examples for NAI realm vs. certificate matching 651 Appendix A contains the ASN.1 definition of the above objects. 653 3. DNS-based NAPTR/SRV Peer Discovery 655 3.1. Applicability 657 Dynamic server discovery as defined in this document is only 658 applicable for new AAA transactions and per service (i.e. distinct 659 discovery is needed for Authentication, Accounting, and Dynamic 660 Authorization) where a RADIUS entity which acts as a forwarding 661 server for one or more realms receives a request with a realm for 662 which it is not authoritative, and which no explicit next hop is 663 configured. It is only applicable for 665 a. new user sessions, i.e. for the initial Access-Request. 666 Subsequent messages concerning this session, for example Access- 667 Challenges and Access-Accepts use the previously-established 668 communication channel between client and server. 670 b. the first accounting ticket for a user session. 672 c. the first RADIUS DynAuth packet for a user session. 674 3.2. Configuration Variables 676 The algorithm contains various variables for timeouts. These 677 variables are named here and reasonable default values are provided. 678 Implementations wishing to deviate from these defaults should make 679 they understand the implications of changes. 681 DNS_TIMEOUT: maximum amount of time to wait for the complete set 682 of all DNS queries to complete: Default = 3 seconds 684 MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 685 seconds 687 BACKOFF_TIME: if no conclusive DNS response was retrieved after 688 DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME 689 has elapsed. Default = 600 seconds 691 3.3. Terms 693 Positive DNS response: a response which contains the RR that was 694 queried for. 696 Negative DNS response: a response which does not contain the RR that 697 was queried for, but contains an SOA record along with a TTL 698 indicating cache duration for this negative result. 700 DNS Error: Where the algorithm states "name resolution returns with 701 an error", this shall mean that either the DNS request timed out, or 702 a DNS response which is neither a positive nor a negative response 703 (e.g. SERVFAIL). 705 Effective TTL: The validity period for discovered RADIUS/TLS target 706 hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { 707 MIN_EFF_TTL, min { DNS TTL values } } 709 SRV lookup: for the purpose of this specification, SRV lookup 710 procedures are defined as per [RFC2782], but excluding that RFCs "A" 711 fallback as defined in its section "Usage Rules", final "else" 712 clause. 714 Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead 715 to a tree of results, whose leafs are the IP addresses to contact. 716 The branches of the tree are ordered according to their order/ 717 preference DNS properties. An implementation is executing greedy 718 result evaluation if it uses a depth-first search in the tree along 719 the highest order results, attempts to connect to the corresponding 720 resulting IP addresses, and only backtracks to other branches if the 721 higher ordered results did not end in successful connection attempts. 723 3.4. Realm to RADIUS server resolution algorithm 725 3.4.1. Input 727 For RADIUS Authentication and RADIUS Accounting server discovery, 728 input I to the algorithm is the RADIUS User-Name attribute with 729 content of the form "user@realm"; the literal @ sign being the 730 separator between a local user identifier within a realm and its 731 realm. The use of multiple literal @ signs in a User-Name is 732 strongly discouraged; but if present, the last @ sign is to be 733 considered the separator. All previous instances of the @ sign are 734 to be considered part of the local user identifier. 736 For RADIUS DynAuth Server discovery, input I to the algorithm is the 737 domain name of the operator of a RADIUS realm as was communicated 738 during user authentication using the Operator-Name attribute 739 ([RFC5580], section 4.1). Only Operator-Name values with the 740 namespace "1" are supported by this algorithm - the input to the 741 algorithm is the actual domain name, preceeded with an "@" (but 742 without the "1" namespace identifier byte of that attribute). 744 Note well: The attribute User-Name is defined to contain UTF-8 text. 745 In practice, the content may or may not be UTF-8. Even if UTF-8, it 746 may or may not map to a domain name in the realm part. Implementors 747 MUST take possible conversion error paths into consideration when 748 parsing incoming User-Name attributes. This document describes 749 server discovery only for well-formed realms mapping to DNS domain 750 names in UTF-8 encoding. The result of all other possible contents 751 of User-Name is unspecified; this includes, but is not limited to: 753 Usage of separators other than @. 755 Encoding of User-Name in local encodings. 757 UTF-8 realms which fail the conversion rules as per [RFC5891]. 759 UTF-8 realms which end with a . ("dot") character. 761 For the last bullet point, "trailing dot", special precautions should 762 be taken to avoid problems when resolving servers with the algorithm 763 below: they may resolve to a RADIUS server even if the peer RADIUS 764 server only is configured to handle the realm without the trailing 765 dot. If that RADIUS server again uses NAI discovery to determine the 766 authoritative server, the server will forward the request to 767 localhost, resulting in a tight endless loop. 769 3.4.2. Output 771 Output O of the algorithm is a two-tuple consisting of: O-1) a set of 772 tuples {hostname; port; protocol; order/preference; Effective TTL} - 773 the set can be empty; and O-2) an integer: if the set in the first 774 part of the tuple is empty, the integer contains the Effective TTL 775 for backoff timeout, if the set is not empty, the integer is set to 0 776 (and not used). 778 3.4.3. Algorithm 780 The algorithm to determine the RADIUS server to contact is as 781 follows: 783 1. Determine P = (position of last "@" character) in I. 785 2. generate R = (substring from P+1 to end of I) 787 3. modify R according to agreed consortium procedures if applicable 789 4. convert R to a representation usable by the name resolution 790 library if needed 792 5. Initialize TIMER = 0; start TIMER. If TIMER reaches 793 DNS_TIMEOUT, continue at step 20. 795 6. Using the host's name resolution library, perform a NAPTR query 796 for R (see "Delay considerations" below). If the result is a 797 negative DNS response, O-2 = Effective TTL ( TTL value of the 798 SOA record ) and continue at step 13. If name resolution 799 returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and 800 terminate. 802 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 803 "aaa+dynauth" as appropriate. Keep note of the protocol tag and 804 remaining TTL of each of the discovered NAPTR records. 806 8. If no records found, continue at step 13. 808 9. For the extracted NAPTRs, perform successive resolution as 809 defined in [RFC3958], section 2.2. An implementation MAY use 810 greedy result evaluation according to the NAPTR order/preference 811 fields (i.e. can execute the subsequent steps of this algorithm 812 for the highest-order entry in the set of results, and only 813 lookup the remainder of the set if necessary). 815 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 816 BACKOFF_TIME and terminate. 818 11. O' = (set of {hostname; port; protocol; order/preference; 819 Effective TTL ( all DNS TTLs that led to this hostname ) } for 820 all terminal lookup results). 822 12. Proceed with step 18. 824 13. Generate R' = (prefix R with "_radiustls._tcp." and/or 825 "_radiustls._udp.") 827 14. Using the host's name resolution library, perform SRV lookup 828 with R' as label (see "Delay considerations" below). 830 15. If name resolution returns with error, O-1 = { empty set }, O-2 831 = BACKOFF_TIME and terminate. 833 16. If the result is a negative DNS response, O-1 = { empty set }, 834 O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) } 835 and terminate. 837 17. O' = (set of {hostname; port; protocol; order/preference; 838 Effective TTL ( all DNS TTLs that led to this result ) } for all 839 hostnames). 841 18. Generate O-1 by resolving hostnames in O' into corresponding A 842 and/or AAAA addresses: O-1 = (set of {IP address; port; 843 protocol; order/preference; Effective TTL ( all DNS TTLs that 844 led to this result ) } for all hostnames ), O-2 = 0. 846 19. For each element in O-1, test if the original request which 847 triggered dynamic discovery was received on {IP address; port}. 848 If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, 849 Terminate (see next section for a rationale). If no, O is the 850 result of dynamic discovery. Terminate. 852 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 854 3.4.4. Validity of results 856 The dynamic discovery algorithm is used by servers which do not have 857 sufficient configuration information to process an incoming request 858 on their own. If the discovery algorithm result contains the 859 server's own listening address (IP address and port), then there is a 860 potential for an endless forwarding loop. If the listening address 861 is the DNS result with the highest priorty, the server will enter a 862 tight loop (the server would forward the request to itself, 863 triggering dynamic discovery again in a perpetual loop). If the 864 address has a lower priority in the set of results, there is a 865 potential loop with intermediate hops in between (the server could 866 forward to another host with a higher priority, which might use DNS 867 itself and forward the packet back to the first server). The 868 underlying reason that enables these loops is that the server 869 executing the discovery algorithm is seriously misconfigured in that 870 it does not recognise the request as one that is to be processed by 871 itself. RADIUS has no built-in loop detection, so any such loops 872 would remain undetected. So, if step 18 of the algorithm discovers 873 such a possible-loop situation, the algorithm should be aborted and 874 an error logged. Note that this safeguard does not provide perfect 875 protection against routing loops. One reason which might introduce a 876 loop include the possiblity that a subsequent hop has a statically 877 configured next-hop which leads to an earlier host in the loop. 878 Another reason for occuring loops is if the algorithm was executed 879 with greedy result evaluation, and the own address was in a lower- 880 priority branch of the result set which was not retrieved from DNS at 881 all, and thus can't be detected. 883 After executing the above algorithm, the RADIUS server establishes a 884 connection to a home server from the result set. This connection can 885 potentially remain open for an indefinite amount of time. This 886 conflicts with the possibility of changing device and network 887 configurations on the receiving end. Typically, TTL values for 888 records in the name resolution system are used to indicate how long 889 it is safe to rely on the results of the name resolution. If these 890 TTLs are very low, thrashing of connections becomes possible; the 891 Effective TTL mitigates that risk. When a connection is open and the 892 smallest of the Effective TTL value which was learned during 893 discovering the server has not expired, subsequent new user sessions 894 for the realm which corresponds to that open connection SHOULD re-use 895 the existing connection and SHOULD NOT re-execute the dynamic 896 discovery algorithm nor open a new connection. To allow for a change 897 of configuration, a RADIUS server SHOULD re-execute the dynamic 898 discovery algorithm after the Effective TTL that is associated with 899 this connection has expired. The server MAY keep the session open 900 during this re-assessment to avoid closure and immediate re-opening 901 of the connection should the result not have changed. 903 Should the algorithm above terminate with O-1 = empty set, the RADIUS 904 server SHOULD NOT attempt another execution of this algorithm for the 905 same target realm before the timeout O-2 has passed. 907 3.4.5. Delay considerations 909 The host's name resolution library may need to contact outside 910 entities to perform the name resolution (e.g. authoritative name 911 servers for a domain), and since the NAI discovery algorithm is based 912 on uncontrollable user input, the destination of the lookups is out 913 of control of the server that performs NAI discovery. If such 914 outside entities are misconfigured or unreachable, the algorithm 915 above may need an unacceptably long time to terminate. Many RADIUS 916 implementations time out after five seconds of delay between Request 917 and Response. It is not useful to wait until the host name 918 resolution library signals a timeout of its name resolution 919 algorithms. The algorithm therefore controls execution time with 920 TIMER. Execution of the NAI discovery algorithm SHOULD be non- 921 blocking (i.e. allow other requests to be processed in parallel to 922 the execution of the algorithm). 924 3.4.6. Example 926 Assume 928 a user from the Technical University of Munich, Germany, has a 929 RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". 931 The name resolution library on the RADIUS forwarding server does 932 not have the realm tu-m[U+00FC]nchen.example in its forwarding 933 configuration, but uses DNS for name resolution and has configured 934 the use of Dynamic Discovery to discover RADIUS servers. 936 It is IPv6-enabled and prefers AAAA records over A records. 938 It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP 939 /2083. 941 May the configuration variables be 943 DNS_TIMEOUT = 3 seconds 945 MIN_EFF_TTL = 60 seconds 947 BACKOFF_TIME = 3600 seconds 949 If DNS contains the following records: 951 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 952 "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen- 953 t9a.example. 955 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 956 "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. 958 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 959 radsecserver.xn--tu-mnchen-t9a.example. 961 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 962 backupserver.xn--tu-mnchen-t9a.example. 964 radsecserver.xn--tu-mnchen-t9a.example. IN AAAA 965 2001:0DB8::202:44ff:fe0a:f704 967 radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 969 backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 971 Then the algorithm executes as follows, with I = 972 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 973 in use: 975 1. P = 7 977 2. R = "tu-m[U+00FC]nchen.example" 979 3. NOOP 981 4. name resolution library converts R to xn--tu-mnchen-t9a.example 983 5. TIMER starts. 985 6. Result: 987 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 988 _myradius._tcp.xn--tu-mnchen-t9a.example. 990 (TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" 991 _abc123._def.xn--tu-mnchen-t9a.example. 993 7. Result: 995 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 996 _myradius._tcp.xn--tu-mnchen-t9a.example. 998 8. NOOP 1000 9. Successive resolution performs SRV query for label 1001 _myradius._tcp.xn--tu-mnchen-t9a.example, which results in 1003 (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. 1005 (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. 1007 10. NOOP 1008 11. O' = { 1010 (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 1011 60), 1013 (backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60) 1015 } // minimum TTL is 47, up'ed to MIN_EFF_TTL 1017 12. Continuing at 18. 1019 13. (not executed) 1021 14. (not executed) 1023 15. (not executed) 1025 16. (not executed) 1027 17. (not executed) 1029 18. O-1 = { 1031 (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), 1033 (192.0.2.7; 2083; RADIUS/TLS; 20; 60) 1035 }; O-2 = 0 1037 19. No match with own listening address; terminate with tuple (O-1, 1038 O-2) from previous step. 1040 The implementation will then attempt to connect to two servers, with 1041 preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ 1042 TLS protocol. 1044 4. Operations and Manageability Considerations 1046 The discovery algorithm as defined in this document contains several 1047 options; the major ones being use of NAPTR vs. SRV; how to determine 1048 the authorization status of a contacted server for a given realm; 1049 which trust anchors to consider trustworthy for the RADIUS 1050 conversation setup. 1052 Random parties which do not agree on the same set of options may not 1053 be able to interoperate. However, such a global interoperability is 1054 not intended by this document. 1056 Discovery as per this document becomes important inside a roaming 1057 consortium, which has set up roaming agreements with the other 1058 partners. Such roaming agreements require much more than a technical 1059 means of server discovery; there are administrative and contractual 1060 considerations at play (service contracts, backoffice compensations, 1061 procedures, ...). 1063 A roaming consortium's roaming agreement must include a profile of 1064 which choice points of this document to use. So long as the roaming 1065 consortium can settle on one deployment profile, they will be able to 1066 interoperate based on that choice; this per-consortium 1067 interoperability is the intended scope of this document. 1069 5. Security Considerations 1071 When using DNS without DNSSEC security extensions and validation for 1072 all of the replies to NAPTR, SRV and A/AAAA requests as described in 1073 section Section 3, the result O can not be trusted. Even if it can 1074 be trusted (i.e. DNSSEC is in use), actual authorization of the 1075 discovered server to provide service for the given realm needs to be 1076 verified. A mechanism from section Section 2.1.1.3 or equivalent 1077 MUST be used to verify authorization. 1079 The algorithm has a configurable completion timeout DNS_TIMEOUT 1080 defaulting to three seconds for RADIUS' operational reasons. The 1081 lookup of DNS resource records based on unverified user input is an 1082 attack vector for DoS attacks: an attacker might intentionally craft 1083 bogus DNS zones which take a very long time to reply (e.g. due to a 1084 particularly byzantine tree structure, or artificial delays in 1085 responses). 1087 To mitigate this DoS vector, implementations SHOULD consider rate- 1088 limiting either their amount of new executions of the dynamic 1089 discovery algorithm as a whole, or the amount of intermediate 1090 responses to track, or at least the number of pending DNS queries. 1091 Implementations MAY choose lower values than the default for 1092 DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They 1093 MAY also continue their attempt to resolve DNS records even after 1094 DNS_TIMEOUT has passed; a subsequent request for the same realm might 1095 benefit from retrieving the results anyway. The amount of time to 1096 spent waiting for a result will influence the impact of a possible 1097 DoS attack; the waiting time value is implementation dependent and 1098 outside the scope of this specification. 1100 With Dynamic Discovery being enabled for a RADIUS Server, and 1101 depending on the deployment scenario, the server may need to open up 1102 its target IP address and port for the entire internet, because 1103 arbitrary clients may discover it as a target for their 1104 authentication requests. If such clients are not part of the roaming 1105 consortium, the RADIUS/TLS connection setup phase will fail (which is 1106 intended) but the computational cost for the connection attempt is 1107 significant. With the port for a TLS-based service open, the RADIUS 1108 server shares all the typical attack vectors for services based on 1109 TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with 1110 Dynamic Discovery should consider these attack vectors and take 1111 appropriate counter-measures (e.g. blacklisting known-bad IPs on a 1112 firewall, rate-limiting new connection attempts, etc.). 1114 6. Privacy Considerations 1116 The classic RADIUS operational model (known, pre-configured peers, 1117 shared secret security, mostly plaintext communication) and this new 1118 RADIUS dynamic discovery model (peer discovery with DNS, PKI security 1119 and packet confidentiality) differ significantly in their impact on 1120 the privacy of end users trying to authenticate to a RADIUS server. 1122 With classic RADIUS, traffic in large environments gets aggregated by 1123 statically configured clearinghouses. The packets sent to those 1124 clearinghouses and their responses are mostly unprotected. As a 1125 consequence, 1127 o All intermediate IP hops can inspect most of the packet payload in 1128 clear text, including the User-Name and Calling-Station-Id 1129 attributes, and can observe which client sent the packet to which 1130 clearinghouse. This allows the creation of mobility profiles for 1131 any passive observer on the IP path. 1133 o The existence of a central clearinghouse creates an opportunity 1134 for the clearinghouse to trivially create the same mobility 1135 profiles. The clearinghouse may or may not be trusted not to do 1136 this, e.g. by sufficiently threatening contractual obligations. 1138 o In addition to that, with the clearinghouse being a RADIUS 1139 intermediate in possession of a valid shared secret, the 1140 clearinghouse can observe and record even the security-critical 1141 RADIUS attributes such as User-Password. This risk may be 1142 mitigated by choosing authentication payloads which are 1143 cryptographically secured and do not use the attribute User- 1144 Password - such as certain EAP types. 1146 o There is no additional information disclosure to parties outside 1147 the IP path between the RADIUS client and server (in particular, 1148 no DNS servers learn about realms of current ongoing 1149 authentications). 1151 With RADIUS and dynamic discovery, 1152 o This protocol allows for RADIUS clients to identify and directly 1153 connect to the RADIUS home server. This can eliminate the use of 1154 clearinghouses to do forwarding of requests, and it also 1155 eliminates the ability of the clearinghouse to then aggregate the 1156 user information that flows through it. However, there exist 1157 reasons why clearinghouses might still be used. One reason to 1158 keep a clearinghouse is to act as a gateway for multiple backends 1159 in a company; another reason may be a requirement to sanitise 1160 RADIUS datagrams (filter attributes, tag requests with new 1161 attributes, ... ). 1163 o Even where intermediate proxies continue to be used for reasons 1164 unrelated to dynamic discovery, the number of such intermediates 1165 may be reduced by removing those proxies which are only deployed 1166 for pure request routing reasons. This reduces the number of 1167 entities which can inspect the RADIUS traffic. 1169 o RADIUS clients which make use of dynamic discovery will need to 1170 query the Domain Name System, and use a user's realm name as the 1171 query label. A passive observer on the IP path between the RADIUS 1172 client and the DNS server(s) being queried can learn that a user 1173 of that specific realm was trying to authenticate at that RADIUS 1174 client at a certain point in time. This may or may not be 1175 sufficient for the passive observer to create a mobility profile. 1176 During the recursive DNS resolution, a fair number of DNS servers 1177 and the IP hops in between those get to learn that information. 1178 Not every single authentication triggers DNS lookups, so there is 1179 no one-to-one relation of leaked realm information and the number 1180 of authentications for that realm. 1182 o Since dynamic discovery operates on a RADIUS hop-by-hop basis, 1183 there is no guarantee that the RADIUS payload is not transmitted 1184 between RADIUS systems which do not make use of this algorithm, 1185 and possibly using other transports such as RADIUS/UDP. On such 1186 hops, the enhanced privacy is jeopardized. 1188 In summary, with classic RADIUS, few intermediate entities learn very 1189 detailed data about every ongoing authentications, while with dynamic 1190 discovery, many entities learn only very little about recently 1191 authenticated realms. 1193 7. IANA Considerations 1195 This document requests IANA registration of the following entries in 1196 existing registries: 1198 o S-NAPTR Application Service Tags registry 1199 * aaa+auth 1201 * aaa+acct 1203 * aaa+dynauth 1205 o S-NAPTR Application Protocol Tags registry 1207 * radius.tls.tcp 1209 * radius.dtls.udp 1211 This document reserves the use of the "radiustls" and "radiusdtls" 1212 service names. Registration information as per [RFC6335] section 1213 8.1.1 is as follows: 1215 Service Name: radiustls; radiusdtls 1217 Transport Protocols: TCP, UDP 1219 Assignee: IESG 1221 Contact: IETF Chair 1223 Description: Authentication, Accounting and Dynamic authorization 1224 via the RADIUS protocol. These service names are used to 1225 construct the SRV service labels "_radiustls" and "_radiusdtls" 1226 for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. 1228 Reference: RFC Editor Note: please insert the RFC number of this 1229 document. The protocol does not use broadcast, multicast or 1230 anycast communication. 1232 This specification makes use of the SRV Protocol identifiers "_tcp" 1233 and "_udp" which are mentioned as early as [RFC2782] but do not 1234 appear to be assigned in an actual registry. Since they are in wide- 1235 spread use in other protocols, this specification refrains from 1236 requesting a new registry "RADIUS/TLS SRV Protocol Registry" and 1237 continues to make use of these tags implicitly. 1239 This document requires that a number of Object Identifiers be 1240 assigned. They are now under the control of IANA following [RFC7299] 1242 IANA is requested to assign the following identifiers: 1244 TBD99 is to be assigned from the "SMI Security for PKIX Module 1245 Identifier Registry". The suggested description is id-mod-nai- 1246 realm-08. 1248 TBD98 is to be assigned from the "SMI Security for PKIX Other Name 1249 Forms Registry." The suggested description is id-on-nai. 1251 RFC Editor Note: please replace the occurences of TBD98 and TBD99 in 1252 Appendix A of the document with the actually assigned numbers. 1254 8. References 1256 8.1. Normative References 1258 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1259 Requirement Levels", BCP 14, RFC 2119, March 1997. 1261 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1262 specifying the location of services (DNS SRV)", RFC 2782, 1263 February 2000. 1265 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1266 "Remote Authentication Dial In User Service (RADIUS)", RFC 1267 2865, June 2000. 1269 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1271 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1272 Service Location Using SRV RRs and the Dynamic Delegation 1273 Discovery Service (DDDS)", RFC 3958, January 2005. 1275 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1276 Network Access Identifier", RFC 4282, December 2005. 1278 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1279 Aboba, "Dynamic Authorization Extensions to Remote 1280 Authentication Dial In User Service (RADIUS)", RFC 5176, 1281 January 2008. 1283 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1284 Housley, R., and W. Polk, "Internet X.509 Public Key 1285 Infrastructure Certificate and Certificate Revocation List 1286 (CRL) Profile", RFC 5280, May 2008. 1288 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 1289 Aboba, "Carrying Location Objects in RADIUS and Diameter", 1290 RFC 5580, August 2009. 1292 [RFC5891] Klensin, J., "Internationalized Domain Names in 1293 Applications (IDNA): Protocol", RFC 5891, August 2010. 1295 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1296 "Transport Layer Security (TLS) Encryption for RADIUS", 1297 RFC 6614, May 2012. 1299 [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a 1300 Transport Layer for RADIUS", RFC 7360, September 2014. 1302 [I-D.ietf-radext-nai] 1303 DeKok, A., "The Network Access Identifier", draft-ietf- 1304 radext-nai-15 (work in progress), December 2014. 1306 8.2. Informative References 1308 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1309 Authentication Protocol (EAP) Method Requirements for 1310 Wireless LANs", RFC 4017, March 2005. 1312 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1313 Cheshire, "Internet Assigned Numbers Authority (IANA) 1314 Procedures for the Management of the Service Name and 1315 Transport Protocol Port Number Registry", BCP 165, RFC 1316 6335, August 2011. 1318 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1319 "Diameter Base Protocol", RFC 6733, October 2012. 1321 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1322 Working Group", RFC 7299, July 2014. 1324 [I-D.wierenga-ietf-eduroam] 1325 Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1326 architecture for network roaming", draft-wierenga-ietf- 1327 eduroam-04 (work in progress), August 2014. 1329 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm 1331 PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6) 1332 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1333 id-mod-nai-realm-08 (TBD99) } 1335 DEFINITIONS EXPLICIT TAGS ::= 1337 BEGIN 1339 -- EXPORTS ALL -- 1341 IMPORTS 1343 id-pkix 1344 FROM PKIX1Explicit-2009 1345 {iso(1) identified-organization(3) dod(6) internet(1) 1346 security(5) mechanisms(5) pkix(7) id-mod(0) 1347 id-mod-pkix1-explicit-02(51)} 1348 -- from RFC 5280, RFC 5912 1350 OTHER-NAME 1351 FROM PKIX1Implicit-2009 1352 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1353 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1354 -- from RFC 5280, RFC 5912 1355 ; 1357 -- Service Name Object Identifier 1359 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1361 id-on-nai OBJECT IDENTIFIER ::= { id-on TBD98 } 1363 -- Service Name 1365 naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }} 1367 NAIRealm ::= UTF8String (SIZE (1..MAX)) 1369 END 1371 Authors' Addresses 1373 Stefan Winter 1374 Fondation RESTENA 1375 6, rue Richard Coudenhove-Kalergi 1376 Luxembourg 1359 1377 LUXEMBOURG 1379 Phone: +352 424409 1 1380 Fax: +352 422473 1381 EMail: stefan.winter@restena.lu 1382 URI: http://www.restena.lu. 1384 Mike McCauley 1385 AirSpayce Pty Ltd 1386 9 Bulbul Place 1387 Currumbin Waters QLD 4223 1388 AUSTRALIA 1390 Phone: +61 7 5598 7474 1391 EMail: mikem@airspayce.com 1392 URI: http://www.airspayce.com