idnits 2.17.1 draft-ietf-radext-dynamic-discovery-05.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2012) is 4152 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-radext-dtls-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: June 16, 2013 OSC 6 December 13, 2012 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-05 11 Abstract 13 This document specifies a means to find authoritative RADIUS servers 14 for a given realm. It can be used in conjunction with RADIUS/TLS and 15 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 June 16, 2013. 34 Copyright Notice 36 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . . 3 55 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Realm to RADIUS server resolution algorithm . . . . . . . 6 58 2.3.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3.2. Output . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3.4. Validity of results . . . . . . . . . . . . . . . . . 8 62 2.3.5. Delay considerations . . . . . . . . . . . . . . . . . 9 63 2.3.6. Example . . . . . . . . . . . . . . . . . . . . . . . 9 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 1.1. Requirements Language 72 In this document, several words are used to signify the requirements 73 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 74 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 75 and "OPTIONAL" in this document are to be interpreted as described in 76 RFC 2119. [RFC2119] 78 1.2. Terminology 80 RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a 81 new connection. 83 RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a 84 RADIUS/TLS port and accepts new connections 86 RADIUS/TLS node: a RADIUS/TLS client or server 88 2. DNS-based NAPTR/SRV Peer Discovery 90 2.1. Applicability 92 Dynamic server discovery as defined in this document is only 93 applicable for AAA transactions where a RADIUS server receives a 94 request with a realm for which no home RADIUS server is known. I.e. 95 where static server configuration does not contain a known home 96 authentication server, or where the server configuration explicitly 97 states that the realm destination is to be looked up dynamically. 98 Furthermore, it is only applicable for new user sessions, i.e. for 99 the initial Access-Request. Subsequent messages concerning this 100 session, for example Access-Challenges and Access-Accepts use the 101 previously-established communication channel between client and 102 server. 104 2.2. DNS RR definition 106 DNS definitions of RADIUS/TLS servers can be either S-NAPTR records 107 (see [RFC3958]) or SRV records. When both are defined, the 108 resolution algorithm prefers S-NAPTR results (see Section 2.3 below). 110 This specification defines three S-NAPTR service tags: 112 +-----------------+-----------------------------------------+ 113 | Service Tag | Use | 114 +-----------------+-----------------------------------------+ 115 | aaa+auth | RADIUS Authentication, i.e. traffic as | 116 | | defined in [RFC2865] | 117 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 118 | aaa+acct | RADIUS Accounting, i.e. traffic as | 119 | | defined in [RFC2866] | 120 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 121 | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | 122 | | traffic as defined in [RFC5176] | 123 +--------------- --+-----------------------------------------+ 125 Figure 1: List of Service Tags 127 This specification defines two S-NAPTR protocol tags: 129 +-----------------+-----------------------------------------+ 130 | Protocol Tag | Use | 131 +-----------------+-----------------------------------------+ 132 | radius.tls | RADIUS transported over TLS as defined | 133 | | in [RFC6614] | 134 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 135 | radius.dtls | RADIUS transported over DTLS as defined | 136 | | in [I-D.ietf-radext-dtls] | 137 +-----------------+-----------------------------------------+ 139 Figure 2: List of Protocol Tags 141 Note well: 143 The S-NAPTR service and protocols are unrelated to the IANA 144 Service Name and Transport Protocol Number registry 146 The delimiter '.' in the protocol tags is only a separator for 147 human reading convenience - not for structure or namespacing; it 148 MUST NOT be parsed in any way by the querying application or 149 resolver. 151 The use of the separator '.' is common also in other protocols' 152 protocol tags. This is coincidence and does not imply a shared 153 semantics with such protocols. 155 This specification defines two SRV prefixes (i.e. two values for the 156 "_service._proto" part of an SRV RR): 158 +-----------------+-----------------------------------------+ 159 | SRV Label | Use | 160 +-----------------+-----------------------------------------+ 161 | _radiustls._tcp | RADIUS transported over TLS as defined | 162 | | in [RFC6614] | 163 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 164 | _radiustls._udp | RADIUS transported over DTLS as defined | 165 | | in [I-D.ietf-radext-dtls] | 166 +-----------------+-----------------------------------------+ 168 Figure 3: List of SRV Labels 170 It is expected that in most cases, the label used for the records is 171 the DNS representation (punycode) of the literal realm name for which 172 the server is the RADIUS server. 174 However, arbitrary other labels may be used if, for example, a 175 roaming consortium uses realm names which are not associated to DNS 176 names or special-purpose consortia where a globally valid discovery 177 is not a use case. Such other labels require a consortium-wide 178 agreement about the transformation from realm name to lookup label. 180 Examples: 182 a. A general-purpose RADIUS server for realm example.com might have 183 DNS entries as follows: 185 example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 186 _radiustls._tcp.foobar.example.com. 188 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 189 radsec.example.com. 191 b. The consortium "foo" provides roaming services for its members 192 only. The realms used are of the form enterprise-name.example. 193 The consortium operates a special purpose DNS server for the 194 (private) TLD "example" which all RADIUS servers use to resolve 195 realm names. "Bad, Inc." is part of the consortium. On the 196 consortium's DNS server, realm bad.example might have the 197 following DNS entries: 199 bad.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" "" 200 "very.bad.example" 202 c. The eduroam consortium uses realms based on DNS, but provides its 203 services to a closed community only. However, a AAA domain 204 participating in eduroam may also want to expose AAA services to 205 other, general-purpose, applications (on the same or other RADIUS 206 servers). Due to that, the eduroam consortium uses the service 207 tag "x-eduroam" for authentication purposes and eduroam RADIUS 208 servers use this tag to look up other eduroam servers. An 209 eduroam participant example.org which also provides general- 210 purpose AAA on a different server uses the general "aaa+auth" 211 tag: 213 example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" "" 214 _radiustls._tcp.eduroam.example.org. 216 example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 217 _radiustls._tcp.aaa.example.org 219 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 220 eduroam.example.org. 222 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 223 default.example.org. 225 2.3. Realm to RADIUS server resolution algorithm 227 This algorithm can be used to discover RADIUS servers (for RADIUS 228 Authentication and RADIUS Accounting) or to discover RADIUS DynAuth 229 servers. 231 2.3.1. Input 233 For RADIUS Authentication and RADIUS Accounting server discovery, 234 input I to the algorithm is the RADIUS User-Name attribute with 235 content of the form "user@realm"; the literal @ sign being the 236 separator between a local user identifier within a realm and its 237 realm. The use of multiple literal @ signs in a User-Name is 238 strongly discouraged; but if present, the last @ sign is to be 239 considered the separator. All previous instances of the @ sign are 240 to be considered part of the local user identifier. 242 For RADIUS DynAuth Server discovery, input I to the algorithm is the 243 domain name of the operator of a RADIUS realm as was communicated 244 during user authentication using the Operator-Name attribute 245 ([RFC5580], section 4.1). Only Operator-Name values with the 246 namespace "1" are supported by this algorithm - the input to the 247 algorithm is the actual domain name, preceeded with an "@" (but 248 without the "1" namespace identifier byte of that attribute). 250 Note well: The attribute User-Name is defined to contain UTF-8 text. 251 In practice, the content may or may not be UTF-8. Even if UTF-8, it 252 may or may not map to a domain name in the realm part. Implementors 253 MUST take possible conversion error paths into consideration when 254 parsing incoming User-Name attributes. This document describes 255 server discovery only for well-formed realms mapping to DNS domain 256 names in UTF-8 encoding. The result of all other possible contents 257 of User-Name is unspecified; this includes, but is not limited to: 259 Usage of separators other than @ 261 Usage of multiple @ separators 263 Encoding of User-Name in local encodings 265 UTF-8 realms which fail the conversion rules as per [RFC5891] 267 UTF-8 realms which end with a . ("dot") character. 269 For the last bullet point, "trailing dot", special precautions should 270 be taken to avoid problems when resolving servers with the algorithm 271 below: they may resolve to a RADIUS server even if the peer RADIUS 272 server only is configured to handle the realm without the trailing 273 dot. If that RADIUS server again uses NAI discovery to determine the 274 authoritative server, the server will forward the request to 275 localhost, resulting in a tight endless loop. 277 2.3.2. Output 279 Output O of the algorithm is a set of the tuple {hostname; port; 280 order/preference; TTL} - the set can be empty. 282 2.3.3. Algorithm 284 The algorithm to determine the RADIUS server to contact is as 285 follows: 287 1. Determine P = (position of last "@" character) in I. 289 2. generate R = (substring from P+1 to end of I) 291 3. Optional: modify R according to agreed consortium procedures 293 4. Using the host's name resolution library, perform a NAPTR query 294 for R (see "Delay considerations" below). The name resolution 295 library may need to convert R to a different respresentation, 296 depending on the resolution backend used. If no result, 297 continue at step 9. If name resolution returns with error, O = 298 { } and terminate. 300 5. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 301 "aaa+dynauth" as appropriate. Keep note of the remaining TTL of 302 each of the discovered NAPTR records. 304 6. If no result, continue at step 9. 306 7. Evaluate NAPTR result(s) for desired protocol tag, perform 307 subsequent lookup steps until lookup yields one or more 308 hostnames. O = (set of {hostname; port; order/preference; 309 min{all TTLs that led to this result} } for all lookup results). 310 Keep note of the remaining TTL of each of the discovered records 311 (e.g. SRV and AAAA). 313 8. Terminate. 315 9. Generate R' = (prefix R with "_radiustls._tcp." or 316 "_radiustls._udp") 318 10. Using the host's name resolution library, perform SRV lookup 319 with R' as label (see "Delay considerations" below). Keep note 320 of the TTL of each of the discovered SRV records. 322 11. If name resolution returns with error, O = { } and terminate. 324 12. If no result, O = {} and terminate. 326 13. Perform subsequent lookup steps until lookup yields one or more 327 hostnames (see "Delay considerations" below). Keep note of the 328 TTL of each of the discovered records. 330 14. O = (set of {hostname; port; order/preference; min{all TTLs that 331 led to this result} } for all hostnames). Terminate. 333 2.3.4. Validity of results 335 After executing the above algorithm, the RADIUS server establishes a 336 connection to a home server from the result set. This connection can 337 potentially remain open for an indefinite amount of time. This 338 conflicts with the possibility of changing device and network 339 configurations on the receiving end. Typically, TTL values for 340 records in the name resolution system are used to indicate how long 341 it is safe to rely on the results of the name resolution. To allow 342 for a change of configuration, a RADIUS server SHOULD re-execute the 343 algorithm above after the lowest of the TTL values that are 344 associated with this connection have expired. The server MAY keep 345 the session open during this re-assessment to avoid closure and 346 immediate re-opening of the connection should the result not have 347 changed. 349 Should the algorithm above terminate with an empty set (but no 350 error), the RADIUS server SHOULD NOT attempt another execution of 351 this algorithm for the same target realm before the negative TTL has 352 expired. 354 Should the algorithm above terminate due to an error with no TTL 355 value known (e.g. DNS SERVFAIL), the RADIUS server SHOULD NOT 356 attempt another execution of this algorithm for the same target realm 357 before a configurable timeout interval has passed. 359 2.3.5. Delay considerations 361 The host's name resolution library may need to contact outside 362 entities to perform the name resolution (e.g. authoritative name 363 servers for a domain), and since the NAI discovery algorithm is based 364 on uncontrollable user input, the destination of the lookups is out 365 of control of the server that performs NAI discovery. If such 366 outside entities are misconfigured or unreachable, the algorithm 367 above may need an unacceptably long time to terminate. Many RADIUS 368 implementations time out after five seconds of delay between Request 369 and Response. It is not useful to wait until the host name 370 resolution library signals a time-out of its name resolution 371 algorithms; instead, implementations of NAI discovery SHOULD 372 terminate the algorithm after the fixed upper bound of time of three 373 seconds. If no final output of the algorithm is available after this 374 timeout, the RADIUS server MUST assume the empty set as a result and 375 treat the pending request according to its static configuration 376 (e.g., fallback to a default route to a home server). Execution of 377 the NAI discovery algorithm SHOULD be non-blocking (i.e. allow other 378 requests to be processed in parallel to the execution of the 379 algorithm). 381 2.3.6. Example 383 Example: Assume a user from the Technical University of Munich, 384 Germany, has a RADIUS User-Name of 385 "foobar@tu-m[U+00FC]nchen.example". The name resolution library on 386 the RADIUS client uses DNS for name resolution. If DNS contains the 387 following records: 389 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "aaa+ 390 auth:radius.tls" "" _radiustls._tcp.xn--tu-mnchen-t9a.example. 392 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "fooservice: 393 bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. 395 _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 396 radsec.xn--tu-mnchen-t9a.example. 398 _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 399 backup.xn--tu-mnchen-t9a.example. 401 radsec.xn--tu-mnchen-t9a.example. IN AAAA 2001:0DB8::202:44ff: 402 fe0a:f704 404 radsec.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 406 backup.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 408 Then the algorithm executes as follows, with I = 409 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 410 in use: 412 1. P = 7 414 2. R = "tu-m[U+00FC]nchen.example" 416 3. NOOP 418 4. [name resolution library converts R to xn--tu-mnchen- 419 t9a.example] Query result: ( 50 50 "s" "aaa+auth:radius.tls" "" 420 _radiustls._tcp.xn--tu-mnchen-t9a.example. ; 50 50 "s" 421 "fooservice:bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. ) 423 5. Result: 50 50 "s" "aaa+auth:radius.tls" "" _radiustls._tcp.xn-- 424 tu-mnchen-t9a.example. 426 6. NOOP 428 7. O = {(radsec.xn--tu-mnchen-t9a.example.; 2083; 10; TTL 429 A),(backup.xn--tu-mnchen-t9a. example.;2083; 20; TTL B)} 431 8. Terminate. 433 9. (not executed) 435 10. (not executed) 437 11. (not executed) 439 12. (not executed) 441 13. (not executed) 443 14. (not executed) 445 The implementation will then attempt to connect to two servers, with 446 preference to radsec.xn--tu-mnchen-t9a.example.:2083, using either 447 the AAAA or A addresses depending on the host configuration and its 448 IP stack's capabilities. 450 3. Security Considerations 452 When using DNS without DNSSEC security extensions, the replies to 453 NAPTR, SRV and A/AAAA requests as described in section Section 2 can 454 not be trusted. RADIUS transports have an out-of-DNS-band means to 455 verify that the discovery attempt led to the intended target: 456 certificate verification or TLS-PSK keys. 458 4. IANA Considerations 460 This document requests IANA registration of the following entries in 461 existing registries: 463 o S-NAPTR Application Service Tags registry 465 * aaa+auth 467 * aaa+acct 469 * aaa+dynauth 471 o S-NAPTR Application Protocol Tags registry 473 * radius.tls 475 * radius.dtls 477 This document reserves the use of the "_radiustls" Service label. 479 This document requests the creation of a new IANA registry named 480 "RADIUS/TLS SRV Protocol Registry" with the following initial 481 entries: 483 o _tcp 485 o _udp 487 5. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to 490 Indicate Requirement Levels", BCP 14, 491 RFC 2119, March 1997. 493 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. 495 Simpson, "Remote Authentication Dial In User 496 Service (RADIUS)", RFC 2865, June 2000. 498 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, 499 June 2000. 501 [RFC3958] Daigle, L. and A. Newton, "Domain-Based 502 Application Service Location Using SRV RRs 503 and the Dynamic Delegation Discovery Service 504 (DDDS)", RFC 3958, January 2005. 506 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, 507 D., and B. Aboba, "Dynamic Authorization 508 Extensions to Remote Authentication Dial In 509 User Service (RADIUS)", RFC 5176, 510 January 2008. 512 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, 513 A., and B. Aboba, "Carrying Location Objects 514 in RADIUS and Diameter", RFC 5580, 515 August 2009. 517 [RFC5891] Klensin, J., "Internationalized Domain Names 518 in Applications (IDNA): Protocol", RFC 5891, 519 August 2010. 521 [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport Layer for 522 RADIUS", draft-ietf-radext-dtls-02 (work in 523 progress), July 2012. 525 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. 526 Wierenga, "Transport Layer Security (TLS) 527 Encryption for RADIUS", RFC 6614, May 2012. 529 Authors' Addresses 531 Stefan Winter 532 Fondation RESTENA 533 6, rue Richard Coudenhove-Kalergi 534 Luxembourg 1359 535 LUXEMBOURG 537 Phone: +352 424409 1 538 Fax: +352 422473 539 EMail: stefan.winter@restena.lu 540 URI: http://www.restena.lu. 542 Mike McCauley 543 Open Systems Consultants 544 9 Bulbul Place 545 Currumbin Waters QLD 4223 546 AUSTRALIA 548 Phone: +61 7 5598 7474 549 Fax: +61 7 5598 7070 550 EMail: mikem@open.com.au 551 URI: http://www.open.com.au.