idnits 2.17.1 draft-ietf-radext-dynamic-discovery-14.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 (April 10, 2015) is 3304 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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: October 12, 2015 AirSpayce 6 April 10, 2015 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-14 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 October 12, 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 [I-D.ietf-radext-nai] defines the terms NAI, realm, consortium. 217 1.3. Document Status 219 This document is an Experimental RFC. 221 The communities expected to use this document are roaming consortia 222 whose authentication services are based on the RADIUS protocol. 224 The duration of the experiment is undetermined; as soon as enough 225 experience is collected on the choice points mentioned below, it is 226 expected to be obsoleted by a standards-track version of the protocol 227 which trims down the choice points. 229 If that removal of choice points obsoletes tags or service names as 230 defined in this document and allocated by IANA, these items will be 231 returned to IANA as per the provisions in [RFC6335]. 233 The document provides a discovery mechanism for RADIUS which is very 234 similar to the approach that is taken with the Diameter protocol 235 [RFC6733]. As such, the basic approach (using Naming Authority 236 Pointer (NAPTR) records in DNS domains which match NAI realms) is not 237 of very experimental nature. 239 However, the document offers a few choice points and extensions which 240 go beyond the provisions for Diameter. The list of major additions/ 241 deviations is 243 o provisions for determining the authority of a server to act for 244 users of a realm (declared out of scope for Diameter) 246 o much more in-depth guidance on DNS regarding timeouts, failure 247 conditions, alteration of Time-To-Live (TTL) information than the 248 Diameter counterpart 250 o a partially correct routing error detection during DNS lookups 252 2. Definitions 254 2.1. DNS Resource Record (RR) definition 256 DNS definitions of RADIUS/TLS servers can be either S-NAPTR records 257 (see [RFC3958]) or Service Record (SRV) records. When both are 258 defined, the resolution algorithm prefers S-NAPTR results (see 259 Section 3.4 below). 261 2.1.1. S-NAPTR 263 2.1.1.1. Registration of Application Service and Protocol Tags 265 This specification defines three S-NAPTR service tags: 267 +-----------------+-----------------------------------------+ 268 | Service Tag | Use | 269 +-----------------+-----------------------------------------+ 270 | aaa+auth | RADIUS Authentication, i.e. traffic as | 271 | | defined in [RFC2865] | 272 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 273 | aaa+acct | RADIUS Accounting, i.e. traffic as | 274 | | defined in [RFC2866] | 275 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 276 | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | 277 | | traffic as defined in [RFC5176] | 278 +-----------------+-----------------------------------------+ 280 Figure 3: List of Service Tags 282 This specification defines two S-NAPTR protocol tags: 284 +-----------------+-----------------------------------------+ 285 | Protocol Tag | Use | 286 +-----------------+-----------------------------------------+ 287 | radius.tls.tcp | RADIUS transported over TLS as defined | 288 | | in [RFC6614] | 289 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 290 | radius.dtls.udp | RADIUS transported over DTLS as defined | 291 | | in [RFC7360] | 292 +-----------------+-----------------------------------------+ 294 Figure 4: List of Protocol Tags 296 Note well: 298 The S-NAPTR service and protocols are unrelated to the IANA 299 Service Name and Transport Protocol Number registry. 301 The delimiter '.' in the protocol tags is only a separator for 302 human reading convenience - not for structure or namespacing; it 303 MUST NOT be parsed in any way by the querying application or 304 resolver. 306 The use of the separator '.' is common also in other protocols' 307 protocol tags. This is coincidence and does not imply a shared 308 semantics with such protocols. 310 2.1.1.2. Definition of Conditions for Retry/Failure 312 RADIUS is a time-critical protocol; RADIUS clients which do not 313 receive an answer after a configurable, but short, amount of time, 314 will consider the request failed. Due to this, there is little 315 leeway for extensive retries. 317 As a general rule, only error conditions which generate an immediate 318 response from the other end are eligible for a retry of a discovered 319 target. Any error condition involving timeouts, or the absence of a 320 reply for more than one second during the connection setup phase is 321 to be considered a failure; the next target in the set of discovered 322 NAPTR targets is to be tried. 324 Note that [RFC3958] already defines that a failure to identify the 325 server as being authoritative for the realm is always considered a 326 failure; so even if a discovered target returns a wrong credential 327 instantly, it is not eligible for retry. 329 Furthermore, the contacted RADIUS/TLS server verifies during 330 connection setup whether or not it finds the connecting RADIUS/TLS 331 client authorized or not. If the connecting RADIUS/TLS client is not 332 found acceptable, the server will close the TLS connection 333 immediately with an appropriate alert. Such TLS handshake failures 334 are permanently fatal and not eligible for retry, unless the 335 connecting client has more X.509 certificates to try; in this case, a 336 retry with the remainder of its set of certificates SHOULD be 337 attempted. Not trying all available client certificates potentially 338 creates a DoS for the end-user whose authentication attempt triggered 339 the discovery; one of the neglected certificates might have led to a 340 successful RADIUS connection and subsequent end-user authentication. 342 If the TLS session setup to a discovered target does not succeed, 343 that target (as identified by IP address and port number) SHOULD be 344 ignored from the result set of any subsequent executions of the 345 discovery algorithm at least until the target's Effective TTL (see 346 Section 3.3) has expired or until the entity which executes the 347 algorithm changes its TLS context to either send a new client 348 certificate or expect a different server certificate. 350 2.1.1.3. Server Identification and Handshake 352 After the algorithm in this document has been executed, a RADIUS/TLS 353 session as per [RFC6614] is established. Since the dynamic discovery 354 algorithm does not have provisions to establish confidential keying 355 material between the RADIUS/TLS client (i.e. the server which 356 executes the discovery algorithm) and the RADIUS/TLS server which was 357 discovered, TLS-PSK ciphersuites cannot be used in the subsequent TLS 358 handshake. Only TLS ciphersuites using X.509 certificates can be 359 used with this algorithm. 361 There are numerous ways to define which certificates are acceptable 362 for use in this context. This document defines one mandatory-to- 363 implement mechanism which allows to verify whether the contacted host 364 is authoritative for an NAI realm or not. It also gives one example 365 of another mechanism which is currently in wide-spread deployment, 366 and one possible approach based on DNSSEC which is yet unimplemented. 368 For the approaches which use trust roots (see the following two 369 sections), a typical deployment will use a dedicated trust store for 370 RADIUS/TLS certificate authorities, particularly a trust store which 371 is independent from default "browser" trust stores. Often, this will 372 be one or few CAs, and they only issue certificates for the specific 373 purpose of establishing RADIUS server-to-server trust. It is 374 important not to trust a large set of CAs which operate outside the 375 control of the roaming consortium, for their issuance of certificates 376 with the properties important for authorisation (such as NAIRealm and 377 policyOID below) is difficult to verify. Therefore, clients SHOULD 378 NOT be pre-configured with a list of known public CAs by the vendor 379 or manufacturer. Instead, the clients SHOULD start off with an empty 380 CA list. The addition of a CA SHOULD be done only when manually 381 configured by an administrator. 383 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 385 Verification of authority to provide AAA services over RADIUS/TLS is 386 a two-step process. 388 Step 1 is the verification of certificate wellformedness and validity 389 as per [RFC5280] and whether it was issued from a root certificate 390 which is deemed trustworthy by the RADIUS/TLS client. 392 Step 2 is to compare the value of algorithm's variable "R" after the 393 execution of step 3 of the discovery algorithm in Section 3.4.3 below 394 (i.e. after a consortium name mangling, but before conversion to a 395 form usable by the name resolution library) to all values of the 396 contacted RADIUS/TLS server's X.509 certificate property 397 "subjectAlternativeName:otherName:NAIRealm" as defined in 398 Section 2.2. 400 2.1.1.3.2. Other mechanism: Trust Roots + policyOID 402 Verification of authority to provide AAA services over RADIUS/TLS is 403 a two-step process. 405 Step 1 is the verification of certificate wellformedness and validity 406 as per [RFC5280] and whether it was issued from a root certificate 407 which is deemed trustworthy by the RADIUS/TLS client. 409 Step 2 is to compare the values of the contacted RADIUS/TLS server's 410 X.509 certificate's extensions of type "Policy OID" to a list of 411 configured acceptable Policy OIDs for the roaming consortium. If one 412 of the configured OIDs is found in the certificate's Policy OID 413 extensions, then the server is considered authorized; if there is no 414 match, the server is considered unauthorized. 416 This mechanism is inferior to the mandatory-to-implement mechanism in 417 the previous section because all authorized servers are validated by 418 the same OID value; the mechanism is not fine-grained enough to 419 express authority for one specific realm inside the consortium. If 420 the consortium contains members which are hostile against other 421 members, this weakness can be exploited by one RADIUS/TLS server 422 impersonating another if DNS responses can be spoofed by the hostile 423 member. 425 The shortcomings in server identification can be partially mitigated 426 by using the RADIUS infrastructure only with authentication payloads 427 which provide mutual authentication and credential protection (i.e. 428 EAP types passing the criteria of [RFC4017]): using mutual 429 authentication prevents the hostile server from mimicking the real 430 EAP server (it can't terminate the EAP authentication unnoticed 431 because it does not have the server certificate from the real EAP 432 server); protection of credentials prevents the impersonating server 433 from learning usernames and passwords of the ongoing EAP conversation 434 (other RADIUS attributes pertaining to the authentication, such as 435 the EAP peer's Calling-Station-ID, can still be learned though). 437 2.1.1.3.3. Other mechanism: DNSSEC / DANE 439 Where DNSSEC is used, the results of the algorithm can be trusted; 440 i.e. the entity which executes the algorithm can be certain that the 441 realm that triggered the discovery is actually served by the server 442 that was discovered via DNS. However, this does not guarantee that 443 the server is also authorized (i.e. a recognised member of the 444 roaming consortium). The server still needs to present an X.509 445 certificate proving its authority to serve a particular realm. 447 The authorization can be sketched using DNSSEC+DANE as follows: DANE/ 448 TLSA records of all authorized servers are put into a DNSSEC zone 449 which contains all known and authorised realms; the zone is rooted in 450 a common, consortium-agreed branch of the DNS tree. The entity 451 executing the algorithm uses the realm information from the 452 authentication attempt, and then attempts to retrieve TLSA Resource 453 Records (TLSA RR) for the DNS label "realm.commonroot". It then 454 verifies that the presented server certificate during the RADIUS/TLS 455 handshake matches the information in the TLSA record. 457 Example: 459 Realm = "example.com" 461 Common Branch = "idp.roaming-consortium.example. 463 label for TLSA query = "example.com.idp.roaming- 464 consortium.example. 466 result of discovery algorithm for realm "example.com" = 467 192.0.2.1:2083 469 ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : 470 "FAIL" ) 472 2.1.1.3.4. Client Authentication and Authorisation 474 Note that RADIUS/TLS connections always mutually authenticate the 475 RADIUS server and the RADIUS client. This specification provides an 476 algorithm for a RADIUS client to contact and verify authorization of 477 a RADIUS server only. During connection setup, the RADIUS server 478 also needs to verify whether it considers the connecting RADIUS 479 client authorized; this is outside the scope of this specification. 481 2.1.2. SRV 483 This specification defines two SRV prefixes (i.e. two values for the 484 "_service._proto" part of an SRV RR as per [RFC2782]): 486 +-------------------+-----------------------------------------+ 487 | SRV Label | Use | 488 +-------------------+-----------------------------------------+ 489 | _radiustls._tcp | RADIUS transported over TLS as defined | 490 | | in [RFC6614] | 491 | - - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 492 | _radiusdtls._udp | RADIUS transported over DTLS as defined | 493 | | in [RFC7360] | 494 +-------------------+-----------------------------------------+ 496 Figure 5: List of SRV Labels 498 Just like NAPTR records, the lookup and subsequent follow-up of SRV 499 records may yield more than one server to contact in a prioritised 500 list. [RFC2782] does not specify rules regarding "Definition of 501 Conditions for Retry/Failure", nor "Server Identification and 502 Handshake". This specification defines that the rules for these two 503 topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be 504 used both for targets retrieved via an initial NAPTR RR as well as 505 for targets retrieved via an initial SRV RR (i.e. in the absence of 506 NAPTR RRs). 508 2.1.3. Optional name mangling 510 It is expected that in most cases, the SRV and/or NAPTR label used 511 for the records is the DNS A-label representation of the literal 512 realm name for which the server is the authoritative RADIUS server 513 (i.e. the realm name after conversion according to section 5 of 514 [RFC5891]). 516 However, arbitrary other labels or service tags may be used if, for 517 example, a roaming consortium uses realm names which are not 518 associated to DNS names or special-purpose consortia where a globally 519 valid discovery is not a use case. Such other labels require a 520 consortium-wide agreement about the transformation from realm name to 521 lookup label, and/or which service tag to use. 523 Examples: 525 a. A general-purpose RADIUS server for realm example.com might have 526 DNS entries as follows: 528 example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" 529 _radiustls._tcp.foobar.example.com. 531 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 532 radsec.example.com. 534 b. The consortium "foo" provides roaming services for its members 535 only. The realms used are of the form enterprise-name.example. 536 The consortium operates a special purpose DNS server for the 537 (private) TLD "example" which all RADIUS servers use to resolve 538 realm names. "Company, Inc." is part of the consortium. On the 539 consortium's DNS server, realm company.example might have the 540 following DNS entries: 542 company.example. IN NAPTR 50 50 "a" 543 "aaa+auth:radius.dtls.udp" "" roamserv.company.example. 545 c. The eduroam consortium (see [I-D.wierenga-ietf-eduroam] uses 546 realms based on DNS, but provides its services to a closed 547 community only. However, a AAA domain participating in eduroam 548 may also want to expose AAA services to other, general-purpose, 549 applications (on the same or other RADIUS servers). Due to that, 550 the eduroam consortium uses the service tag "x-eduroam" for 551 authentication purposes and eduroam RADIUS servers use this tag 552 to look up other eduroam servers. An eduroam participant 553 example.org which also provides general-purpose AAA on a 554 different server uses the general "aaa+auth" tag: 556 example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls.tcp" "" 557 _radiustls._tcp.eduroam.example.org. 559 example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls.tcp" "" 560 _radiustls._tcp.aaa.example.org. 562 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 563 eduroam.example.org. 565 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 566 default.example.org. 568 2.2. Definition of the X.509 certificate property 569 SubjectAltName:otherName:NAIRealm 571 This specification retrieves IP addresses and port numbers from the 572 Domain Name System which are subsequently used to authenticate users 573 via the RADIUS/TLS protocol. Regardless whether the results from DNS 574 discovery are trustworthy or not (e.g. DNSSEC in use), it is always 575 important to verify that the server which was contacted is authorized 576 to service requests for the user which triggered the discovery 577 process. 579 The input to the algorithm is an NAI realm as specified in 580 Section 3.4.1. As a consequence, the X.509 certificate of the server 581 which is ultimately contacted for user authentication needs to be 582 able to express that it is authorized to handle requests for that 583 realm. 585 Current subjectAltName fields do not semantically allow to express an 586 NAI realm; the field subjectAltName:dNSName is syntactically a good 587 match but would inappropriately conflate DNS names and NAI realm 588 names. Thus, this specification defines a new subjectAltName field 589 to hold either a single NAI realm name or a wildcard name matching a 590 set of NAI realms. 592 The subjectAltName:otherName:sRVName field certifies that a 593 certificate holder is authorized to provide a service; this can be 594 compared to the target of DNS label's SRV resource record. If the 595 Domain Name System is insecure, it is required that the label of the 596 SRV record itself is known-correct. In this specification, that 597 label is not known-correct; it is potentially derived from a 598 (potentially untrusted) NAPTR resource record of another label. If 599 DNS is not secured with DNSSEC, the NAPTR resource record may have 600 been altered by an attacker with access to the Domain Name System 601 resolution, and thus the label to lookup the SRV record for may 602 already be tainted. This makes subjectAltName:otherName:sRVName not 603 a trusted comparison item. 605 Further to this, this specification's NAPTR entries may be of type 606 "A" which do not involve resolution of any SRV records, which again 607 makes subjectAltName:otherName:sRVName unsuited for this purpose. 609 This section defines the NAIRealm name as a form of otherName from 610 the GeneralName structure in SubjectAltName defined in [RFC5280]. 612 id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } 614 NAIRealm ::= UTF8String (SIZE (1..MAX)) 616 The NAIRealm, if present, MUST contain an NAI realm as defined in 617 [I-D.ietf-radext-nai]. It MAY substitute the leftmost dot-separated 618 label of the NAI with the single character "*" to indicate a wildcard 619 match for "all labels in this part". Further features of regular 620 expressions, such as a number of characters followed by a * to 621 indicate a common prefix inside the part, are not permitted. 623 The comparison of an NAIRealm to the NAI realm as derived from user 624 input with this algorithm is a byte-by-byte comparison, except for 625 the optional leftmost dot-separated part of the value whose content 626 is a single "*" character; such labels match all strings in the same 627 dot-separated part of the NAI realm. If at least one of the 628 sAN:otherName:NAIRealm values matches the NAI realm, the server is 629 considered authorized; if none matches, the server is considered 630 unauthorized. 632 Since multiple names and multiple name forms may occur in the 633 subjectAltName extension, an arbitrary number of NAIRealms can be 634 specified in a certificate. 636 Examples: 638 +---------------------+-------------------+-----------------------+ 639 | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | 640 +---------------------+-------------------+-----------------------+ 641 | foo.example | foo.example | YES | 642 | foo.example | *.example | YES | 643 | bar.foo.example | *.example | NO | 644 | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | 645 | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | 646 | bar.foo.example | *.*.example | NO (NAIRealm invalid) | 647 | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | 648 | sub.bar.foo.example | *.bar.foo.example | YES | 649 +-----------------+-----------------------------------------------+ 651 Figure 6: Examples for NAI realm vs. certificate matching 653 Appendix A contains the ASN.1 definition of the above objects. 655 3. DNS-based NAPTR/SRV Peer Discovery 657 3.1. Applicability 659 Dynamic server discovery as defined in this document is only 660 applicable for new AAA transactions and per service (i.e. distinct 661 discovery is needed for Authentication, Accounting, and Dynamic 662 Authorization) where a RADIUS entity which acts as a forwarding 663 server for one or more realms receives a request with a realm for 664 which it is not authoritative, and which no explicit next hop is 665 configured. It is only applicable for 667 a. new user sessions, i.e. for the initial Access-Request. 668 Subsequent messages concerning this session, for example Access- 669 Challenges and Access-Accepts use the previously-established 670 communication channel between client and server. 672 b. the first accounting ticket for a user session. 674 c. the first RADIUS DynAuth packet for a user session. 676 3.2. Configuration Variables 678 The algorithm contains various variables for timeouts. These 679 variables are named here and reasonable default values are provided. 680 Implementations wishing to deviate from these defaults should make 681 they understand the implications of changes. 683 DNS_TIMEOUT: maximum amount of time to wait for the complete set 684 of all DNS queries to complete: Default = 3 seconds 686 MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 687 seconds 689 BACKOFF_TIME: if no conclusive DNS response was retrieved after 690 DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME 691 has elapsed. Default = 600 seconds 693 3.3. Terms 695 Positive DNS response: a response which contains the RR that was 696 queried for. 698 Negative DNS response: a response which does not contain the RR that 699 was queried for, but contains an SOA record along with a TTL 700 indicating cache duration for this negative result. 702 DNS Error: Where the algorithm states "name resolution returns with 703 an error", this shall mean that either the DNS request timed out, or 704 a DNS response which is neither a positive nor a negative response 705 (e.g. SERVFAIL). 707 Effective TTL: The validity period for discovered RADIUS/TLS target 708 hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { 709 MIN_EFF_TTL, min { DNS TTL values } } 711 SRV lookup: for the purpose of this specification, SRV lookup 712 procedures are defined as per [RFC2782], but excluding that RFCs "A" 713 fallback as defined in its section "Usage Rules", final "else" 714 clause. 716 Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead 717 to a tree of results, whose leafs are the IP addresses to contact. 718 The branches of the tree are ordered according to their order/ 719 preference DNS properties. An implementation is executing greedy 720 result evaluation if it uses a depth-first search in the tree along 721 the highest order results, attempts to connect to the corresponding 722 resulting IP addresses, and only backtracks to other branches if the 723 higher ordered results did not end in successful connection attempts. 725 3.4. Realm to RADIUS server resolution algorithm 727 3.4.1. Input 729 For RADIUS Authentication and RADIUS Accounting server discovery, 730 input I to the algorithm is the RADIUS User-Name attribute with 731 content of the form "user@realm"; the literal @ sign being the 732 separator between a local user identifier within a realm and its 733 realm. The use of multiple literal @ signs in a User-Name is 734 strongly discouraged; but if present, the last @ sign is to be 735 considered the separator. All previous instances of the @ sign are 736 to be considered part of the local user identifier. 738 For RADIUS DynAuth Server discovery, input I to the algorithm is the 739 domain name of the operator of a RADIUS realm as was communicated 740 during user authentication using the Operator-Name attribute 741 ([RFC5580], section 4.1). Only Operator-Name values with the 742 namespace "1" are supported by this algorithm - the input to the 743 algorithm is the actual domain name, preceeded with an "@" (but 744 without the "1" namespace identifier byte of that attribute). 746 Note well: The attribute User-Name is defined to contain UTF-8 text. 747 In practice, the content may or may not be UTF-8. Even if UTF-8, it 748 may or may not map to a domain name in the realm part. Implementors 749 MUST take possible conversion error paths into consideration when 750 parsing incoming User-Name attributes. This document describes 751 server discovery only for well-formed realms mapping to DNS domain 752 names in UTF-8 encoding. The result of all other possible contents 753 of User-Name is unspecified; this includes, but is not limited to: 755 Usage of separators other than @. 757 Encoding of User-Name in local encodings. 759 UTF-8 realms which fail the conversion rules as per [RFC5891]. 761 UTF-8 realms which end with a . ("dot") character. 763 For the last bullet point, "trailing dot", special precautions should 764 be taken to avoid problems when resolving servers with the algorithm 765 below: they may resolve to a RADIUS server even if the peer RADIUS 766 server only is configured to handle the realm without the trailing 767 dot. If that RADIUS server again uses NAI discovery to determine the 768 authoritative server, the server will forward the request to 769 localhost, resulting in a tight endless loop. 771 3.4.2. Output 773 Output O of the algorithm is a two-tuple consisting of: O-1) a set of 774 tuples {hostname; port; protocol; order/preference; Effective TTL} - 775 the set can be empty; and O-2) an integer: if the set in the first 776 part of the tuple is empty, the integer contains the Effective TTL 777 for backoff timeout, if the set is not empty, the integer is set to 0 778 (and not used). 780 3.4.3. Algorithm 782 The algorithm to determine the RADIUS server to contact is as 783 follows: 785 1. Determine P = (position of last "@" character) in I. 787 2. generate R = (substring from P+1 to end of I) 789 3. modify R according to agreed consortium procedures if applicable 791 4. convert R to a representation usable by the name resolution 792 library if needed 794 5. Initialize TIMER = 0; start TIMER. If TIMER reaches 795 DNS_TIMEOUT, continue at step 20. 797 6. Using the host's name resolution library, perform a NAPTR query 798 for R (see "Delay considerations" below). If the result is a 799 negative DNS response, O-2 = Effective TTL ( TTL value of the 800 SOA record ) and continue at step 13. If name resolution 801 returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and 802 terminate. 804 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 805 "aaa+dynauth" as appropriate. Keep note of the protocol tag and 806 remaining TTL of each of the discovered NAPTR records. 808 8. If no records found, continue at step 13. 810 9. For the extracted NAPTRs, perform successive resolution as 811 defined in [RFC3958], section 2.2. An implementation MAY use 812 greedy result evaluation according to the NAPTR order/preference 813 fields (i.e. can execute the subsequent steps of this algorithm 814 for the highest-order entry in the set of results, and only 815 lookup the remainder of the set if necessary). 817 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 818 BACKOFF_TIME and terminate. 820 11. O' = (set of {hostname; port; protocol; order/preference; 821 Effective TTL ( all DNS TTLs that led to this hostname ) } for 822 all terminal lookup results). 824 12. Proceed with step 18. 826 13. Generate R' = (prefix R with "_radiustls._tcp." and/or 827 "_radiustls._udp.") 829 14. Using the host's name resolution library, perform SRV lookup 830 with R' as label (see "Delay considerations" below). 832 15. If name resolution returns with error, O-1 = { empty set }, O-2 833 = BACKOFF_TIME and terminate. 835 16. If the result is a negative DNS response, O-1 = { empty set }, 836 O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) } 837 and terminate. 839 17. O' = (set of {hostname; port; protocol; order/preference; 840 Effective TTL ( all DNS TTLs that led to this result ) } for all 841 hostnames). 843 18. Generate O-1 by resolving hostnames in O' into corresponding A 844 and/or AAAA addresses: O-1 = (set of {IP address; port; 845 protocol; order/preference; Effective TTL ( all DNS TTLs that 846 led to this result ) } for all hostnames ), O-2 = 0. 848 19. For each element in O-1, test if the original request which 849 triggered dynamic discovery was received on {IP address; port}. 850 If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, 851 Terminate (see next section for a rationale). If no, O is the 852 result of dynamic discovery. Terminate. 854 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 856 3.4.4. Validity of results 858 The dynamic discovery algorithm is used by servers which do not have 859 sufficient configuration information to process an incoming request 860 on their own. If the discovery algorithm result contains the 861 server's own listening address (IP address and port), then there is a 862 potential for an endless forwarding loop. If the listening address 863 is the DNS result with the highest priorty, the server will enter a 864 tight loop (the server would forward the request to itself, 865 triggering dynamic discovery again in a perpetual loop). If the 866 address has a lower priority in the set of results, there is a 867 potential loop with intermediate hops in between (the server could 868 forward to another host with a higher priority, which might use DNS 869 itself and forward the packet back to the first server). The 870 underlying reason that enables these loops is that the server 871 executing the discovery algorithm is seriously misconfigured in that 872 it does not recognise the request as one that is to be processed by 873 itself. RADIUS has no built-in loop detection, so any such loops 874 would remain undetected. So, if step 18 of the algorithm discovers 875 such a possible-loop situation, the algorithm should be aborted and 876 an error logged. Note that this safeguard does not provide perfect 877 protection against routing loops. One reason which might introduce a 878 loop include the possiblity that a subsequent hop has a statically 879 configured next-hop which leads to an earlier host in the loop. 880 Another reason for occuring loops is if the algorithm was executed 881 with greedy result evaluation, and the own address was in a lower- 882 priority branch of the result set which was not retrieved from DNS at 883 all, and thus can't be detected. 885 After executing the above algorithm, the RADIUS server establishes a 886 connection to a home server from the result set. This connection can 887 potentially remain open for an indefinite amount of time. This 888 conflicts with the possibility of changing device and network 889 configurations on the receiving end. Typically, TTL values for 890 records in the name resolution system are used to indicate how long 891 it is safe to rely on the results of the name resolution. If these 892 TTLs are very low, thrashing of connections becomes possible; the 893 Effective TTL mitigates that risk. When a connection is open and the 894 smallest of the Effective TTL value which was learned during 895 discovering the server has not expired, subsequent new user sessions 896 for the realm which corresponds to that open connection SHOULD re-use 897 the existing connection and SHOULD NOT re-execute the dynamic 898 discovery algorithm nor open a new connection. To allow for a change 899 of configuration, a RADIUS server SHOULD re-execute the dynamic 900 discovery algorithm after the Effective TTL that is associated with 901 this connection has expired. The server SHOULD keep the session open 902 during this re-assessment to avoid closure and immediate re-opening 903 of the connection should the result not have changed. 905 Should the algorithm above terminate with O-1 = empty set, the RADIUS 906 server SHOULD NOT attempt another execution of this algorithm for the 907 same target realm before the timeout O-2 has passed. 909 3.4.5. Delay considerations 911 The host's name resolution library may need to contact outside 912 entities to perform the name resolution (e.g. authoritative name 913 servers for a domain), and since the NAI discovery algorithm is based 914 on uncontrollable user input, the destination of the lookups is out 915 of control of the server that performs NAI discovery. If such 916 outside entities are misconfigured or unreachable, the algorithm 917 above may need an unacceptably long time to terminate. Many RADIUS 918 implementations time out after five seconds of delay between Request 919 and Response. It is not useful to wait until the host name 920 resolution library signals a timeout of its name resolution 921 algorithms. The algorithm therefore controls execution time with 922 TIMER. Execution of the NAI discovery algorithm SHOULD be non- 923 blocking (i.e. allow other requests to be processed in parallel to 924 the execution of the algorithm). 926 3.4.6. Example 928 Assume 930 a user from the Technical University of Munich, Germany, has a 931 RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". 933 The name resolution library on the RADIUS forwarding server does 934 not have the realm tu-m[U+00FC]nchen.example in its forwarding 935 configuration, but uses DNS for name resolution and has configured 936 the use of Dynamic Discovery to discover RADIUS servers. 938 It is IPv6-enabled and prefers AAAA records over A records. 940 It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP 941 /2083. 943 May the configuration variables be 945 DNS_TIMEOUT = 3 seconds 947 MIN_EFF_TTL = 60 seconds 949 BACKOFF_TIME = 3600 seconds 951 If DNS contains the following records: 953 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 954 "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen- 955 t9a.example. 957 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 958 "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. 960 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 961 radsecserver.xn--tu-mnchen-t9a.example. 963 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 964 backupserver.xn--tu-mnchen-t9a.example. 966 radsecserver.xn--tu-mnchen-t9a.example. IN AAAA 967 2001:0DB8::202:44ff:fe0a:f704 969 radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 971 backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 973 Then the algorithm executes as follows, with I = 974 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 975 in use: 977 1. P = 7 979 2. R = "tu-m[U+00FC]nchen.example" 981 3. NOOP 983 4. name resolution library converts R to xn--tu-mnchen-t9a.example 985 5. TIMER starts. 987 6. Result: 989 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 990 _myradius._tcp.xn--tu-mnchen-t9a.example. 992 (TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" 993 _abc123._def.xn--tu-mnchen-t9a.example. 995 7. Result: 997 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 998 _myradius._tcp.xn--tu-mnchen-t9a.example. 1000 8. NOOP 1002 9. Successive resolution performs SRV query for label 1003 _myradius._tcp.xn--tu-mnchen-t9a.example, which results in 1005 (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. 1007 (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. 1009 10. NOOP 1010 11. O' = { 1012 (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 1013 60), 1015 (backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60) 1017 } // minimum TTL is 47, up'ed to MIN_EFF_TTL 1019 12. Continuing at 18. 1021 13. (not executed) 1023 14. (not executed) 1025 15. (not executed) 1027 16. (not executed) 1029 17. (not executed) 1031 18. O-1 = { 1033 (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), 1035 (192.0.2.7; 2083; RADIUS/TLS; 20; 60) 1037 }; O-2 = 0 1039 19. No match with own listening address; terminate with tuple (O-1, 1040 O-2) from previous step. 1042 The implementation will then attempt to connect to two servers, with 1043 preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ 1044 TLS protocol. 1046 4. Operations and Manageability Considerations 1048 The discovery algorithm as defined in this document contains several 1049 options; the major ones being use of NAPTR vs. SRV; how to determine 1050 the authorization status of a contacted server for a given realm; 1051 which trust anchors to consider trustworthy for the RADIUS 1052 conversation setup. 1054 Random parties which do not agree on the same set of options may not 1055 be able to interoperate. However, such a global interoperability is 1056 not intended by this document. 1058 Discovery as per this document becomes important inside a roaming 1059 consortium, which has set up roaming agreements with the other 1060 partners. Such roaming agreements require much more than a technical 1061 means of server discovery; there are administrative and contractual 1062 considerations at play (service contracts, backoffice compensations, 1063 procedures, ...). 1065 A roaming consortium's roaming agreement must include a profile of 1066 which choice points of this document to use. So long as the roaming 1067 consortium can settle on one deployment profile, they will be able to 1068 interoperate based on that choice; this per-consortium 1069 interoperability is the intended scope of this document. 1071 5. Security Considerations 1073 When using DNS without DNSSEC security extensions and validation for 1074 all of the replies to NAPTR, SRV and A/AAAA requests as described in 1075 section Section 3, the result of the discovery process can not be 1076 trusted. Even if it can be trusted (i.e. DNSSEC is in use), actual 1077 authorization of the discovered server to provide service for the 1078 given realm needs to be verified. A mechanism from section 1079 Section 2.1.1.3 or equivalent MUST be used to verify authorization. 1081 The algorithm has a configurable completion timeout DNS_TIMEOUT 1082 defaulting to three seconds for RADIUS' operational reasons. The 1083 lookup of DNS resource records based on unverified user input is an 1084 attack vector for DoS attacks: an attacker might intentionally craft 1085 bogus DNS zones which take a very long time to reply (e.g. due to a 1086 particularly byzantine tree structure, or artificial delays in 1087 responses). 1089 To mitigate this DoS vector, implementations SHOULD consider rate- 1090 limiting either their amount of new executions of the dynamic 1091 discovery algorithm as a whole, or the amount of intermediate 1092 responses to track, or at least the number of pending DNS queries. 1093 Implementations MAY choose lower values than the default for 1094 DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They 1095 MAY also continue their attempt to resolve DNS records even after 1096 DNS_TIMEOUT has passed; a subsequent request for the same realm might 1097 benefit from retrieving the results anyway. The amount of time to 1098 spent waiting for a result will influence the impact of a possible 1099 DoS attack; the waiting time value is implementation dependent and 1100 outside the scope of this specification. 1102 With Dynamic Discovery being enabled for a RADIUS Server, and 1103 depending on the deployment scenario, the server may need to open up 1104 its target IP address and port for the entire internet, because 1105 arbitrary clients may discover it as a target for their 1106 authentication requests. If such clients are not part of the roaming 1107 consortium, the RADIUS/TLS connection setup phase will fail (which is 1108 intended) but the computational cost for the connection attempt is 1109 significant. With the port for a TLS-based service open, the RADIUS 1110 server shares all the typical attack vectors for services based on 1111 TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with 1112 Dynamic Discovery should consider these attack vectors and take 1113 appropriate counter-measures (e.g. blacklisting known-bad IPs on a 1114 firewall, rate-limiting new connection attempts, etc.). 1116 6. Privacy Considerations 1118 The classic RADIUS operational model (known, pre-configured peers, 1119 shared secret security, mostly plaintext communication) and this new 1120 RADIUS dynamic discovery model (peer discovery with DNS, PKI security 1121 and packet confidentiality) differ significantly in their impact on 1122 the privacy of end users trying to authenticate to a RADIUS server. 1124 With classic RADIUS, traffic in large environments gets aggregated by 1125 statically configured clearinghouses. The packets sent to those 1126 clearinghouses and their responses are mostly unprotected. As a 1127 consequence, 1129 o All intermediate IP hops can inspect most of the packet payload in 1130 clear text, including the User-Name and Calling-Station-Id 1131 attributes, and can observe which client sent the packet to which 1132 clearinghouse. This allows the creation of mobility profiles for 1133 any passive observer on the IP path. 1135 o The existence of a central clearinghouse creates an opportunity 1136 for the clearinghouse to trivially create the same mobility 1137 profiles. The clearinghouse may or may not be trusted not to do 1138 this, e.g. by sufficiently threatening contractual obligations. 1140 o In addition to that, with the clearinghouse being a RADIUS 1141 intermediate in possession of a valid shared secret, the 1142 clearinghouse can observe and record even the security-critical 1143 RADIUS attributes such as User-Password. This risk may be 1144 mitigated by choosing authentication payloads which are 1145 cryptographically secured and do not use the attribute User- 1146 Password - such as certain EAP types. 1148 o There is no additional information disclosure to parties outside 1149 the IP path between the RADIUS client and server (in particular, 1150 no DNS servers learn about realms of current ongoing 1151 authentications). 1153 With RADIUS and dynamic discovery, 1154 o This protocol allows for RADIUS clients to identify and directly 1155 connect to the RADIUS home server. This can eliminate the use of 1156 clearinghouses to do forwarding of requests, and it also 1157 eliminates the ability of the clearinghouse to then aggregate the 1158 user information that flows through it. However, there exist 1159 reasons why clearinghouses might still be used. One reason to 1160 keep a clearinghouse is to act as a gateway for multiple backends 1161 in a company; another reason may be a requirement to sanitise 1162 RADIUS datagrams (filter attributes, tag requests with new 1163 attributes, ... ). 1165 o Even where intermediate proxies continue to be used for reasons 1166 unrelated to dynamic discovery, the number of such intermediates 1167 may be reduced by removing those proxies which are only deployed 1168 for pure request routing reasons. This reduces the number of 1169 entities which can inspect the RADIUS traffic. 1171 o RADIUS clients which make use of dynamic discovery will need to 1172 query the Domain Name System, and use a user's realm name as the 1173 query label. A passive observer on the IP path between the RADIUS 1174 client and the DNS server(s) being queried can learn that a user 1175 of that specific realm was trying to authenticate at that RADIUS 1176 client at a certain point in time. This may or may not be 1177 sufficient for the passive observer to create a mobility profile. 1178 During the recursive DNS resolution, a fair number of DNS servers 1179 and the IP hops in between those get to learn that information. 1180 Not every single authentication triggers DNS lookups, so there is 1181 no one-to-one relation of leaked realm information and the number 1182 of authentications for that realm. 1184 o Since dynamic discovery operates on a RADIUS hop-by-hop basis, 1185 there is no guarantee that the RADIUS payload is not transmitted 1186 between RADIUS systems which do not make use of this algorithm, 1187 and possibly using other transports such as RADIUS/UDP. On such 1188 hops, the enhanced privacy is jeopardized. 1190 In summary, with classic RADIUS, few intermediate entities learn very 1191 detailed data about every ongoing authentications, while with dynamic 1192 discovery, many entities learn only very little about recently 1193 authenticated realms. 1195 7. IANA Considerations 1197 This document requests IANA registration of the following entries in 1198 existing registries: 1200 o S-NAPTR Application Service Tags registry 1201 * aaa+auth 1203 * aaa+acct 1205 * aaa+dynauth 1207 o S-NAPTR Application Protocol Tags registry 1209 * radius.tls.tcp 1211 * radius.dtls.udp 1213 This document reserves the use of the "radiustls" and "radiusdtls" 1214 service names. Registration information as per [RFC6335] section 1215 8.1.1 is as follows: 1217 Service Name: radiustls; radiusdtls 1219 Transport Protocols: TCP (for radiustls), UDP (for radiusdtls) 1221 Assignee: IESG 1223 Contact: IETF Chair 1225 Description: Authentication, Accounting and Dynamic authorization 1226 via the RADIUS protocol. These service names are used to 1227 construct the SRV service labels "_radiustls" and "_radiusdtls" 1228 for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. 1230 Reference: RFC Editor Note: please insert the RFC number of this 1231 document. The protocol does not use broadcast, multicast or 1232 anycast communication. 1234 This specification makes use of the SRV Protocol identifiers "_tcp" 1235 and "_udp" which are mentioned as early as [RFC2782] but do not 1236 appear to be assigned in an actual registry. Since they are in wide- 1237 spread use in other protocols, this specification refrains from 1238 requesting a new registry "RADIUS/TLS SRV Protocol Registry" and 1239 continues to make use of these tags implicitly. 1241 This document requires that a number of Object Identifiers be 1242 assigned. They are now under the control of IANA following [RFC7299] 1244 IANA is requested to assign the following identifiers: 1246 TBD99 is to be assigned from the "SMI Security for PKIX Module 1247 Identifier Registry". The suggested description is id-mod-nai- 1248 realm-08. 1250 TBD98 is to be assigned from the "SMI Security for PKIX Other Name 1251 Forms Registry." The suggested description is id-on-nai. 1253 RFC Editor Note: please replace the occurences of TBD98 and TBD99 in 1254 Appendix A of the document with the actually assigned numbers. 1256 8. References 1258 8.1. Normative References 1260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1261 Requirement Levels", BCP 14, RFC 2119, March 1997. 1263 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1264 specifying the location of services (DNS SRV)", RFC 2782, 1265 February 2000. 1267 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1268 "Remote Authentication Dial In User Service (RADIUS)", RFC 1269 2865, June 2000. 1271 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1273 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1274 Service Location Using SRV RRs and the Dynamic Delegation 1275 Discovery Service (DDDS)", RFC 3958, January 2005. 1277 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1278 Aboba, "Dynamic Authorization Extensions to Remote 1279 Authentication Dial In User Service (RADIUS)", RFC 5176, 1280 January 2008. 1282 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1283 Housley, R., and W. Polk, "Internet X.509 Public Key 1284 Infrastructure Certificate and Certificate Revocation List 1285 (CRL) Profile", RFC 5280, May 2008. 1287 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 1288 Aboba, "Carrying Location Objects in RADIUS and Diameter", 1289 RFC 5580, August 2009. 1291 [RFC5891] Klensin, J., "Internationalized Domain Names in 1292 Applications (IDNA): Protocol", RFC 5891, August 2010. 1294 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1295 "Transport Layer Security (TLS) Encryption for RADIUS", 1296 RFC 6614, May 2012. 1298 [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a 1299 Transport Layer for RADIUS", RFC 7360, September 2014. 1301 [I-D.ietf-radext-nai] 1302 DeKok, A., "The Network Access Identifier", draft-ietf- 1303 radext-nai-15 (work in progress), December 2014. 1305 8.2. Informative References 1307 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1308 Authentication Protocol (EAP) Method Requirements for 1309 Wireless LANs", RFC 4017, March 2005. 1311 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1312 Cheshire, "Internet Assigned Numbers Authority (IANA) 1313 Procedures for the Management of the Service Name and 1314 Transport Protocol Port Number Registry", BCP 165, RFC 1315 6335, August 2011. 1317 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1318 "Diameter Base Protocol", RFC 6733, October 2012. 1320 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1321 Working Group", RFC 7299, July 2014. 1323 [I-D.wierenga-ietf-eduroam] 1324 Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1325 architecture for network roaming", draft-wierenga-ietf- 1326 eduroam-05 (work in progress), March 2015. 1328 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm 1330 PKIXNaiRealm08 {iso(1) identified-organization(3) dod(6) 1331 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1332 id-mod-nai-realm-08 (TBD99) } 1334 DEFINITIONS EXPLICIT TAGS ::= 1336 BEGIN 1338 -- EXPORTS ALL -- 1340 IMPORTS 1342 id-pkix 1343 FROM PKIX1Explicit-2009 1344 {iso(1) identified-organization(3) dod(6) internet(1) 1345 security(5) mechanisms(5) pkix(7) id-mod(0) 1346 id-mod-pkix1-explicit-02(51)} 1347 -- from RFC 5280, RFC 5912 1349 OTHER-NAME 1350 FROM PKIX1Implicit-2009 1351 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1352 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1353 -- from RFC 5280, RFC 5912 1354 ; 1356 -- Service Name Object Identifier 1358 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1360 id-on-nai OBJECT IDENTIFIER ::= { id-on TBD98 } 1362 -- Service Name 1364 naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }} 1366 NAIRealm ::= UTF8String (SIZE (1..MAX)) 1368 END 1370 Authors' Addresses 1372 Stefan Winter 1373 Fondation RESTENA 1374 6, rue Richard Coudenhove-Kalergi 1375 Luxembourg 1359 1376 LUXEMBOURG 1378 Phone: +352 424409 1 1379 Fax: +352 422473 1380 EMail: stefan.winter@restena.lu 1381 URI: http://www.restena.lu. 1383 Mike McCauley 1384 AirSpayce Pty Ltd 1385 9 Bulbul Place 1386 Currumbin Waters QLD 4223 1387 AUSTRALIA 1389 Phone: +61 7 5598 7474 1390 EMail: mikem@airspayce.com 1391 URI: http://www.airspayce.com