idnits 2.17.1 draft-ietf-radext-dynamic-discovery-15.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 30, 2015) is 3284 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: November 1, 2015 AirSpayce 6 April 30, 2015 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-15 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 November 1, 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-naiRealm OBJECT IDENTIFIER ::= { id-on XXX } 614 ub-naiRealm-length INTEGER ::= 255 616 NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length)) 618 The NAIRealm, if present, MUST contain an NAI realm as defined in 619 [I-D.ietf-radext-nai]. It MAY substitute the leftmost dot-separated 620 label of the NAI with the single character "*" to indicate a wildcard 621 match for "all labels in this part". Further features of regular 622 expressions, such as a number of characters followed by a * to 623 indicate a common prefix inside the part, are not permitted. 625 The comparison of an NAIRealm to the NAI realm as derived from user 626 input with this algorithm is a byte-by-byte comparison, except for 627 the optional leftmost dot-separated part of the value whose content 628 is a single "*" character; such labels match all strings in the same 629 dot-separated part of the NAI realm. If at least one of the 630 sAN:otherName:NAIRealm values matches the NAI realm, the server is 631 considered authorized; if none matches, the server is considered 632 unauthorized. 634 Since multiple names and multiple name forms may occur in the 635 subjectAltName extension, an arbitrary number of NAIRealms can be 636 specified in a certificate. 638 Examples: 640 +---------------------+-------------------+-----------------------+ 641 | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | 642 +---------------------+-------------------+-----------------------+ 643 | foo.example | foo.example | YES | 644 | foo.example | *.example | YES | 645 | bar.foo.example | *.example | NO | 646 | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | 647 | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | 648 | bar.foo.example | *.*.example | NO (NAIRealm invalid) | 649 | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | 650 | sub.bar.foo.example | *.bar.foo.example | YES | 651 +-----------------+-----------------------------------------------+ 653 Figure 6: Examples for NAI realm vs. certificate matching 655 Appendix A contains the ASN.1 definition of the above objects. 657 3. DNS-based NAPTR/SRV Peer Discovery 659 3.1. Applicability 661 Dynamic server discovery as defined in this document is only 662 applicable for new AAA transactions and per service (i.e. distinct 663 discovery is needed for Authentication, Accounting, and Dynamic 664 Authorization) where a RADIUS entity which acts as a forwarding 665 server for one or more realms receives a request with a realm for 666 which it is not authoritative, and which no explicit next hop is 667 configured. It is only applicable for 669 a. new user sessions, i.e. for the initial Access-Request. 670 Subsequent messages concerning this session, for example Access- 671 Challenges and Access-Accepts use the previously-established 672 communication channel between client and server. 674 b. the first accounting ticket for a user session. 676 c. the first RADIUS DynAuth packet for a user session. 678 3.2. Configuration Variables 680 The algorithm contains various variables for timeouts. These 681 variables are named here and reasonable default values are provided. 682 Implementations wishing to deviate from these defaults should make 683 they understand the implications of changes. 685 DNS_TIMEOUT: maximum amount of time to wait for the complete set 686 of all DNS queries to complete: Default = 3 seconds 688 MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 689 seconds 691 BACKOFF_TIME: if no conclusive DNS response was retrieved after 692 DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME 693 has elapsed. Default = 600 seconds 695 3.3. Terms 697 Positive DNS response: a response which contains the RR that was 698 queried for. 700 Negative DNS response: a response which does not contain the RR that 701 was queried for, but contains an SOA record along with a TTL 702 indicating cache duration for this negative result. 704 DNS Error: Where the algorithm states "name resolution returns with 705 an error", this shall mean that either the DNS request timed out, or 706 a DNS response which is neither a positive nor a negative response 707 (e.g. SERVFAIL). 709 Effective TTL: The validity period for discovered RADIUS/TLS target 710 hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { 711 MIN_EFF_TTL, min { DNS TTL values } } 713 SRV lookup: for the purpose of this specification, SRV lookup 714 procedures are defined as per [RFC2782], but excluding that RFCs "A" 715 fallback as defined in its section "Usage Rules", final "else" 716 clause. 718 Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead 719 to a tree of results, whose leafs are the IP addresses to contact. 720 The branches of the tree are ordered according to their order/ 721 preference DNS properties. An implementation is executing greedy 722 result evaluation if it uses a depth-first search in the tree along 723 the highest order results, attempts to connect to the corresponding 724 resulting IP addresses, and only backtracks to other branches if the 725 higher ordered results did not end in successful connection attempts. 727 3.4. Realm to RADIUS server resolution algorithm 729 3.4.1. Input 731 For RADIUS Authentication and RADIUS Accounting server discovery, 732 input I to the algorithm is the RADIUS User-Name attribute with 733 content of the form "user@realm"; the literal @ sign being the 734 separator between a local user identifier within a realm and its 735 realm. The use of multiple literal @ signs in a User-Name is 736 strongly discouraged; but if present, the last @ sign is to be 737 considered the separator. All previous instances of the @ sign are 738 to be considered part of the local user identifier. 740 For RADIUS DynAuth Server discovery, input I to the algorithm is the 741 domain name of the operator of a RADIUS realm as was communicated 742 during user authentication using the Operator-Name attribute 743 ([RFC5580], section 4.1). Only Operator-Name values with the 744 namespace "1" are supported by this algorithm - the input to the 745 algorithm is the actual domain name, preceeded with an "@" (but 746 without the "1" namespace identifier byte of that attribute). 748 Note well: The attribute User-Name is defined to contain UTF-8 text. 749 In practice, the content may or may not be UTF-8. Even if UTF-8, it 750 may or may not map to a domain name in the realm part. Implementors 751 MUST take possible conversion error paths into consideration when 752 parsing incoming User-Name attributes. This document describes 753 server discovery only for well-formed realms mapping to DNS domain 754 names in UTF-8 encoding. The result of all other possible contents 755 of User-Name is unspecified; this includes, but is not limited to: 757 Usage of separators other than @. 759 Encoding of User-Name in local encodings. 761 UTF-8 realms which fail the conversion rules as per [RFC5891]. 763 UTF-8 realms which end with a . ("dot") character. 765 For the last bullet point, "trailing dot", special precautions should 766 be taken to avoid problems when resolving servers with the algorithm 767 below: they may resolve to a RADIUS server even if the peer RADIUS 768 server only is configured to handle the realm without the trailing 769 dot. If that RADIUS server again uses NAI discovery to determine the 770 authoritative server, the server will forward the request to 771 localhost, resulting in a tight endless loop. 773 3.4.2. Output 775 Output O of the algorithm is a two-tuple consisting of: O-1) a set of 776 tuples {hostname; port; protocol; order/preference; Effective TTL} - 777 the set can be empty; and O-2) an integer: if the set in the first 778 part of the tuple is empty, the integer contains the Effective TTL 779 for backoff timeout, if the set is not empty, the integer is set to 0 780 (and not used). 782 3.4.3. Algorithm 784 The algorithm to determine the RADIUS server to contact is as 785 follows: 787 1. Determine P = (position of last "@" character) in I. 789 2. generate R = (substring from P+1 to end of I) 791 3. modify R according to agreed consortium procedures if applicable 793 4. convert R to a representation usable by the name resolution 794 library if needed 796 5. Initialize TIMER = 0; start TIMER. If TIMER reaches 797 DNS_TIMEOUT, continue at step 20. 799 6. Using the host's name resolution library, perform a NAPTR query 800 for R (see "Delay considerations" below). If the result is a 801 negative DNS response, O-2 = Effective TTL ( TTL value of the 802 SOA record ) and continue at step 13. If name resolution 803 returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and 804 terminate. 806 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 807 "aaa+dynauth" as appropriate. Keep note of the protocol tag and 808 remaining TTL of each of the discovered NAPTR records. 810 8. If no records found, continue at step 13. 812 9. For the extracted NAPTRs, perform successive resolution as 813 defined in [RFC3958], section 2.2. An implementation MAY use 814 greedy result evaluation according to the NAPTR order/preference 815 fields (i.e. can execute the subsequent steps of this algorithm 816 for the highest-order entry in the set of results, and only 817 lookup the remainder of the set if necessary). 819 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 820 BACKOFF_TIME and terminate. 822 11. O' = (set of {hostname; port; protocol; order/preference; 823 Effective TTL ( all DNS TTLs that led to this hostname ) } for 824 all terminal lookup results). 826 12. Proceed with step 18. 828 13. Generate R' = (prefix R with "_radiustls._tcp." and/or 829 "_radiustls._udp.") 831 14. Using the host's name resolution library, perform SRV lookup 832 with R' as label (see "Delay considerations" below). 834 15. If name resolution returns with error, O-1 = { empty set }, O-2 835 = BACKOFF_TIME and terminate. 837 16. If the result is a negative DNS response, O-1 = { empty set }, 838 O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) } 839 and terminate. 841 17. O' = (set of {hostname; port; protocol; order/preference; 842 Effective TTL ( all DNS TTLs that led to this result ) } for all 843 hostnames). 845 18. Generate O-1 by resolving hostnames in O' into corresponding A 846 and/or AAAA addresses: O-1 = (set of {IP address; port; 847 protocol; order/preference; Effective TTL ( all DNS TTLs that 848 led to this result ) } for all hostnames ), O-2 = 0. 850 19. For each element in O-1, test if the original request which 851 triggered dynamic discovery was received on {IP address; port}. 852 If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, 853 Terminate (see next section for a rationale). If no, O is the 854 result of dynamic discovery. Terminate. 856 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 858 3.4.4. Validity of results 860 The dynamic discovery algorithm is used by servers which do not have 861 sufficient configuration information to process an incoming request 862 on their own. If the discovery algorithm result contains the 863 server's own listening address (IP address and port), then there is a 864 potential for an endless forwarding loop. If the listening address 865 is the DNS result with the highest priorty, the server will enter a 866 tight loop (the server would forward the request to itself, 867 triggering dynamic discovery again in a perpetual loop). If the 868 address has a lower priority in the set of results, there is a 869 potential loop with intermediate hops in between (the server could 870 forward to another host with a higher priority, which might use DNS 871 itself and forward the packet back to the first server). The 872 underlying reason that enables these loops is that the server 873 executing the discovery algorithm is seriously misconfigured in that 874 it does not recognise the request as one that is to be processed by 875 itself. RADIUS has no built-in loop detection, so any such loops 876 would remain undetected. So, if step 18 of the algorithm discovers 877 such a possible-loop situation, the algorithm should be aborted and 878 an error logged. Note that this safeguard does not provide perfect 879 protection against routing loops. One reason which might introduce a 880 loop include the possiblity that a subsequent hop has a statically 881 configured next-hop which leads to an earlier host in the loop. 882 Another reason for occuring loops is if the algorithm was executed 883 with greedy result evaluation, and the own address was in a lower- 884 priority branch of the result set which was not retrieved from DNS at 885 all, and thus can't be detected. 887 After executing the above algorithm, the RADIUS server establishes a 888 connection to a home server from the result set. This connection can 889 potentially remain open for an indefinite amount of time. This 890 conflicts with the possibility of changing device and network 891 configurations on the receiving end. Typically, TTL values for 892 records in the name resolution system are used to indicate how long 893 it is safe to rely on the results of the name resolution. If these 894 TTLs are very low, thrashing of connections becomes possible; the 895 Effective TTL mitigates that risk. When a connection is open and the 896 smallest of the Effective TTL value which was learned during 897 discovering the server has not expired, subsequent new user sessions 898 for the realm which corresponds to that open connection SHOULD re-use 899 the existing connection and SHOULD NOT re-execute the dynamic 900 discovery algorithm nor open a new connection. To allow for a change 901 of configuration, a RADIUS server SHOULD re-execute the dynamic 902 discovery algorithm after the Effective TTL that is associated with 903 this connection has expired. The server SHOULD keep the session open 904 during this re-assessment to avoid closure and immediate re-opening 905 of the connection should the result not have changed. 907 Should the algorithm above terminate with O-1 = empty set, the RADIUS 908 server SHOULD NOT attempt another execution of this algorithm for the 909 same target realm before the timeout O-2 has passed. 911 3.4.5. Delay considerations 913 The host's name resolution library may need to contact outside 914 entities to perform the name resolution (e.g. authoritative name 915 servers for a domain), and since the NAI discovery algorithm is based 916 on uncontrollable user input, the destination of the lookups is out 917 of control of the server that performs NAI discovery. If such 918 outside entities are misconfigured or unreachable, the algorithm 919 above may need an unacceptably long time to terminate. Many RADIUS 920 implementations time out after five seconds of delay between Request 921 and Response. It is not useful to wait until the host name 922 resolution library signals a timeout of its name resolution 923 algorithms. The algorithm therefore controls execution time with 924 TIMER. Execution of the NAI discovery algorithm SHOULD be non- 925 blocking (i.e. allow other requests to be processed in parallel to 926 the execution of the algorithm). 928 3.4.6. Example 930 Assume 932 a user from the Technical University of Munich, Germany, has a 933 RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". 935 The name resolution library on the RADIUS forwarding server does 936 not have the realm tu-m[U+00FC]nchen.example in its forwarding 937 configuration, but uses DNS for name resolution and has configured 938 the use of Dynamic Discovery to discover RADIUS servers. 940 It is IPv6-enabled and prefers AAAA records over A records. 942 It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP 943 /2083. 945 May the configuration variables be 947 DNS_TIMEOUT = 3 seconds 949 MIN_EFF_TTL = 60 seconds 951 BACKOFF_TIME = 3600 seconds 953 If DNS contains the following records: 955 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 956 "aaa+auth:radius.tls.tcp" "" _myradius._tcp.xn--tu-mnchen- 957 t9a.example. 959 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 960 "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. 962 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 963 radsecserver.xn--tu-mnchen-t9a.example. 965 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 966 backupserver.xn--tu-mnchen-t9a.example. 968 radsecserver.xn--tu-mnchen-t9a.example. IN AAAA 969 2001:0DB8::202:44ff:fe0a:f704 971 radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 973 backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 975 Then the algorithm executes as follows, with I = 976 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 977 in use: 979 1. P = 7 981 2. R = "tu-m[U+00FC]nchen.example" 983 3. NOOP 985 4. name resolution library converts R to xn--tu-mnchen-t9a.example 987 5. TIMER starts. 989 6. Result: 991 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 992 _myradius._tcp.xn--tu-mnchen-t9a.example. 994 (TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" 995 _abc123._def.xn--tu-mnchen-t9a.example. 997 7. Result: 999 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls.tcp" "" 1000 _myradius._tcp.xn--tu-mnchen-t9a.example. 1002 8. NOOP 1004 9. Successive resolution performs SRV query for label 1005 _myradius._tcp.xn--tu-mnchen-t9a.example, which results in 1007 (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. 1009 (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. 1011 10. NOOP 1012 11. O' = { 1014 (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 1015 60), 1017 (backup.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 20; 60) 1019 } // minimum TTL is 47, up'ed to MIN_EFF_TTL 1021 12. Continuing at 18. 1023 13. (not executed) 1025 14. (not executed) 1027 15. (not executed) 1029 16. (not executed) 1031 17. (not executed) 1033 18. O-1 = { 1035 (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), 1037 (192.0.2.7; 2083; RADIUS/TLS; 20; 60) 1039 }; O-2 = 0 1041 19. No match with own listening address; terminate with tuple (O-1, 1042 O-2) from previous step. 1044 The implementation will then attempt to connect to two servers, with 1045 preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ 1046 TLS protocol. 1048 4. Operations and Manageability Considerations 1050 The discovery algorithm as defined in this document contains several 1051 options; the major ones being use of NAPTR vs. SRV; how to determine 1052 the authorization status of a contacted server for a given realm; 1053 which trust anchors to consider trustworthy for the RADIUS 1054 conversation setup. 1056 Random parties which do not agree on the same set of options may not 1057 be able to interoperate. However, such a global interoperability is 1058 not intended by this document. 1060 Discovery as per this document becomes important inside a roaming 1061 consortium, which has set up roaming agreements with the other 1062 partners. Such roaming agreements require much more than a technical 1063 means of server discovery; there are administrative and contractual 1064 considerations at play (service contracts, backoffice compensations, 1065 procedures, ...). 1067 A roaming consortium's roaming agreement must include a profile of 1068 which choice points of this document to use. So long as the roaming 1069 consortium can settle on one deployment profile, they will be able to 1070 interoperate based on that choice; this per-consortium 1071 interoperability is the intended scope of this document. 1073 5. Security Considerations 1075 When using DNS without DNSSEC security extensions and validation for 1076 all of the replies to NAPTR, SRV and A/AAAA requests as described in 1077 section Section 3, the result of the discovery process can not be 1078 trusted. Even if it can be trusted (i.e. DNSSEC is in use), actual 1079 authorization of the discovered server to provide service for the 1080 given realm needs to be verified. A mechanism from section 1081 Section 2.1.1.3 or equivalent MUST be used to verify authorization. 1083 The algorithm has a configurable completion timeout DNS_TIMEOUT 1084 defaulting to three seconds for RADIUS' operational reasons. The 1085 lookup of DNS resource records based on unverified user input is an 1086 attack vector for DoS attacks: an attacker might intentionally craft 1087 bogus DNS zones which take a very long time to reply (e.g. due to a 1088 particularly byzantine tree structure, or artificial delays in 1089 responses). 1091 To mitigate this DoS vector, implementations SHOULD consider rate- 1092 limiting either their amount of new executions of the dynamic 1093 discovery algorithm as a whole, or the amount of intermediate 1094 responses to track, or at least the number of pending DNS queries. 1095 Implementations MAY choose lower values than the default for 1096 DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They 1097 MAY also continue their attempt to resolve DNS records even after 1098 DNS_TIMEOUT has passed; a subsequent request for the same realm might 1099 benefit from retrieving the results anyway. The amount of time to 1100 spent waiting for a result will influence the impact of a possible 1101 DoS attack; the waiting time value is implementation dependent and 1102 outside the scope of this specification. 1104 With Dynamic Discovery being enabled for a RADIUS Server, and 1105 depending on the deployment scenario, the server may need to open up 1106 its target IP address and port for the entire internet, because 1107 arbitrary clients may discover it as a target for their 1108 authentication requests. If such clients are not part of the roaming 1109 consortium, the RADIUS/TLS connection setup phase will fail (which is 1110 intended) but the computational cost for the connection attempt is 1111 significant. With the port for a TLS-based service open, the RADIUS 1112 server shares all the typical attack vectors for services based on 1113 TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with 1114 Dynamic Discovery should consider these attack vectors and take 1115 appropriate counter-measures (e.g. blacklisting known-bad IPs on a 1116 firewall, rate-limiting new connection attempts, etc.). 1118 6. Privacy Considerations 1120 The classic RADIUS operational model (known, pre-configured peers, 1121 shared secret security, mostly plaintext communication) and this new 1122 RADIUS dynamic discovery model (peer discovery with DNS, PKI security 1123 and packet confidentiality) differ significantly in their impact on 1124 the privacy of end users trying to authenticate to a RADIUS server. 1126 With classic RADIUS, traffic in large environments gets aggregated by 1127 statically configured clearinghouses. The packets sent to those 1128 clearinghouses and their responses are mostly unprotected. As a 1129 consequence, 1131 o All intermediate IP hops can inspect most of the packet payload in 1132 clear text, including the User-Name and Calling-Station-Id 1133 attributes, and can observe which client sent the packet to which 1134 clearinghouse. This allows the creation of mobility profiles for 1135 any passive observer on the IP path. 1137 o The existence of a central clearinghouse creates an opportunity 1138 for the clearinghouse to trivially create the same mobility 1139 profiles. The clearinghouse may or may not be trusted not to do 1140 this, e.g. by sufficiently threatening contractual obligations. 1142 o In addition to that, with the clearinghouse being a RADIUS 1143 intermediate in possession of a valid shared secret, the 1144 clearinghouse can observe and record even the security-critical 1145 RADIUS attributes such as User-Password. This risk may be 1146 mitigated by choosing authentication payloads which are 1147 cryptographically secured and do not use the attribute User- 1148 Password - such as certain EAP types. 1150 o There is no additional information disclosure to parties outside 1151 the IP path between the RADIUS client and server (in particular, 1152 no DNS servers learn about realms of current ongoing 1153 authentications). 1155 With RADIUS and dynamic discovery, 1156 o This protocol allows for RADIUS clients to identify and directly 1157 connect to the RADIUS home server. This can eliminate the use of 1158 clearinghouses to do forwarding of requests, and it also 1159 eliminates the ability of the clearinghouse to then aggregate the 1160 user information that flows through it. However, there exist 1161 reasons why clearinghouses might still be used. One reason to 1162 keep a clearinghouse is to act as a gateway for multiple backends 1163 in a company; another reason may be a requirement to sanitise 1164 RADIUS datagrams (filter attributes, tag requests with new 1165 attributes, ... ). 1167 o Even where intermediate proxies continue to be used for reasons 1168 unrelated to dynamic discovery, the number of such intermediates 1169 may be reduced by removing those proxies which are only deployed 1170 for pure request routing reasons. This reduces the number of 1171 entities which can inspect the RADIUS traffic. 1173 o RADIUS clients which make use of dynamic discovery will need to 1174 query the Domain Name System, and use a user's realm name as the 1175 query label. A passive observer on the IP path between the RADIUS 1176 client and the DNS server(s) being queried can learn that a user 1177 of that specific realm was trying to authenticate at that RADIUS 1178 client at a certain point in time. This may or may not be 1179 sufficient for the passive observer to create a mobility profile. 1180 During the recursive DNS resolution, a fair number of DNS servers 1181 and the IP hops in between those get to learn that information. 1182 Not every single authentication triggers DNS lookups, so there is 1183 no one-to-one relation of leaked realm information and the number 1184 of authentications for that realm. 1186 o Since dynamic discovery operates on a RADIUS hop-by-hop basis, 1187 there is no guarantee that the RADIUS payload is not transmitted 1188 between RADIUS systems which do not make use of this algorithm, 1189 and possibly using other transports such as RADIUS/UDP. On such 1190 hops, the enhanced privacy is jeopardized. 1192 In summary, with classic RADIUS, few intermediate entities learn very 1193 detailed data about every ongoing authentications, while with dynamic 1194 discovery, many entities learn only very little about recently 1195 authenticated realms. 1197 7. IANA Considerations 1199 This document requests IANA registration of the following entries in 1200 existing registries: 1202 o S-NAPTR Application Service Tags registry 1203 * aaa+auth 1205 * aaa+acct 1207 * aaa+dynauth 1209 o S-NAPTR Application Protocol Tags registry 1211 * radius.tls.tcp 1213 * radius.dtls.udp 1215 This document reserves the use of the "radiustls" and "radiusdtls" 1216 service names. Registration information as per [RFC6335] section 1217 8.1.1 is as follows: 1219 Service Name: radiustls; radiusdtls 1221 Transport Protocols: TCP (for radiustls), UDP (for radiusdtls) 1223 Assignee: IESG 1225 Contact: IETF Chair 1227 Description: Authentication, Accounting and Dynamic authorization 1228 via the RADIUS protocol. These service names are used to 1229 construct the SRV service labels "_radiustls" and "_radiusdtls" 1230 for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. 1232 Reference: RFC Editor Note: please insert the RFC number of this 1233 document. The protocol does not use broadcast, multicast or 1234 anycast communication. 1236 This specification makes use of the SRV Protocol identifiers "_tcp" 1237 and "_udp" which are mentioned as early as [RFC2782] but do not 1238 appear to be assigned in an actual registry. Since they are in wide- 1239 spread use in other protocols, this specification refrains from 1240 requesting a new registry "RADIUS/TLS SRV Protocol Registry" and 1241 continues to make use of these tags implicitly. 1243 This document requires that a number of Object Identifiers be 1244 assigned. They are now under the control of IANA following [RFC7299] 1246 IANA is requested to assign the following identifiers: 1248 TBD99 is to be assigned from the "SMI Security for PKIX Module 1249 Identifier Registry". The suggested description is id-mod-nai- 1250 realm-08. 1252 TBD98 is to be assigned from the "SMI Security for PKIX Other Name 1253 Forms Registry." The suggested description is id-on-naiRealm. 1255 RFC Editor Note: please replace the occurences of TBD98 and TBD99 in 1256 Appendix A of the document with the actually assigned numbers. 1258 8. References 1260 8.1. Normative References 1262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1263 Requirement Levels", BCP 14, RFC 2119, March 1997. 1265 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1266 specifying the location of services (DNS SRV)", RFC 2782, 1267 February 2000. 1269 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1270 "Remote Authentication Dial In User Service (RADIUS)", RFC 1271 2865, June 2000. 1273 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1275 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1276 Service Location Using SRV RRs and the Dynamic Delegation 1277 Discovery Service (DDDS)", RFC 3958, January 2005. 1279 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1280 Aboba, "Dynamic Authorization Extensions to Remote 1281 Authentication Dial In User Service (RADIUS)", RFC 5176, 1282 January 2008. 1284 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1285 Housley, R., and W. Polk, "Internet X.509 Public Key 1286 Infrastructure Certificate and Certificate Revocation List 1287 (CRL) Profile", RFC 5280, May 2008. 1289 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 1290 Aboba, "Carrying Location Objects in RADIUS and Diameter", 1291 RFC 5580, August 2009. 1293 [RFC5891] Klensin, J., "Internationalized Domain Names in 1294 Applications (IDNA): Protocol", RFC 5891, August 2010. 1296 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1297 "Transport Layer Security (TLS) Encryption for RADIUS", 1298 RFC 6614, May 2012. 1300 [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a 1301 Transport Layer for RADIUS", RFC 7360, September 2014. 1303 [I-D.ietf-radext-nai] 1304 DeKok, A., "The Network Access Identifier", draft-ietf- 1305 radext-nai-15 (work in progress), December 2014. 1307 8.2. Informative References 1309 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1310 Authentication Protocol (EAP) Method Requirements for 1311 Wireless LANs", RFC 4017, March 2005. 1313 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1314 Cheshire, "Internet Assigned Numbers Authority (IANA) 1315 Procedures for the Management of the Service Name and 1316 Transport Protocol Port Number Registry", BCP 165, RFC 1317 6335, August 2011. 1319 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1320 "Diameter Base Protocol", RFC 6733, October 2012. 1322 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1323 Working Group", RFC 7299, July 2014. 1325 [I-D.wierenga-ietf-eduroam] 1326 Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 1327 architecture for network roaming", draft-wierenga-ietf- 1328 eduroam-05 (work in progress), March 2015. 1330 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-naiRealm OBJECT IDENTIFIER ::= { id-on TBD98 } 1363 -- Service Name 1365 naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-naiRealm }} 1367 ub-naiRealm-length INTEGER ::= 255 1369 NAIRealm ::= UTF8String (SIZE (1..ub-naiRealm-length)) 1371 END 1373 Authors' Addresses 1375 Stefan Winter 1376 Fondation RESTENA 1377 6, rue Richard Coudenhove-Kalergi 1378 Luxembourg 1359 1379 LUXEMBOURG 1381 Phone: +352 424409 1 1382 Fax: +352 422473 1383 EMail: stefan.winter@restena.lu 1384 URI: http://www.restena.lu. 1386 Mike McCauley 1387 AirSpayce Pty Ltd 1388 9 Bulbul Place 1389 Currumbin Waters QLD 4223 1390 AUSTRALIA 1392 Phone: +61 7 5598 7474 1393 EMail: mikem@airspayce.com 1394 URI: http://www.airspayce.com