idnits 2.17.1 draft-ietf-radext-dynamic-discovery-02.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 : ---------------------------------------------------------------------------- -- 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 (March 05, 2010) is 5159 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-03) exists of draft-dekok-radext-dtls-01 == Outdated reference: A later version (-12) exists of draft-ietf-radext-radsec-06 Summary: 1 error (**), 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: September 6, 2010 OSC 6 March 05, 2010 8 NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS 9 draft-ietf-radext-dynamic-discovery-02 11 Abstract 13 This document specifies a means to find authoritative AAA servers for 14 a given NAI realm. It can be used in conjunction with RADIUS over 15 TLS and RADIUS over DTLS. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 6, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . . 3 61 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. DNS RR definition . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Realm to AAA server resolution algorithm . . . . . . . . . 5 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 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 [I-D.ietf-radext-radsec] instance 81 which initiates a new connection. 83 RADIUS/TLS Server: a RADIUS/TLS [I-D.ietf-radext-radsec] instance 84 which listens on a 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 AAA server receives a request 94 with a NAI realm for which no home AAA server is known. I.e. where 95 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, Access-Accepts, Accounting 101 Messages or Change-of-Authorisation messages use the previously- 102 established communication channel between client and 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 Section 2.3 109 below). 111 This specification defines two S-NAPTR service tag: a general-purpose 112 tag "nai-roaming" and a special-purpose tag "eduroam" for the eduroam 113 roaming consortium. This specification defines two S-NAPTR protocol 114 tags: "radius.tls" for RADIUS over TLS [I-D.ietf-radext-radsec] and 115 "radius.dtls" for RADIUS over DTLS [I-D.dekok-radext-dtls]. 117 This specification defines the SRV prefix "_radiustls._tcp" for 118 RADIUS over TLS [I-D.ietf-radext-radsec] and "_radiustls._udp" for 119 RADIUS over DTLS [I-D.dekok-radext-dtls]. It is expected that in 120 most cases, the label used for the records is the DNS representation 121 (punycode) of the literal realm name for which the server is the AAA 122 server. 124 However, arbitrary other labels may be used if, for example, a 125 roaming consortium uses realm names which are not associated to DNS 126 names or special-purpose consortia where a globally valid discovery 127 is not a use case. Such other labels require a consortium-wide 128 agreement about the transformation from realm name to lookup label. 130 Examples: 132 a. A general-purpose AAA server for realm example.com might have DNS 133 entries as follows: 135 example.com. IN NAPTR 50 50 "s" "nai-roaming:radius.tls" "" 136 _radiustls._tcp.foobar.example.com. 138 _radiustls._tcp.example.com. IN SRV 0 10 2083 139 radsec.example.com. 141 b. The consortium "foo" provides roaming services for its members 142 only. The realms used are of the form enterprise-name.example. 143 The consortium operates a special purpose DNS server for the 144 (private) TLD "example" which all AAA servers use to resolve 145 realm names. "Bad, Inc." is part of the consortium. On the 146 consortium's DNS server, realm bad.example might have the 147 following DNS entries: 149 bad.example IN NAPTR 50 50 "a" "nai-roaming:radius.dtls" "" 150 "very.bad.example" 152 c. the eduroam consortium uses realms based on DNS, but provides its 153 services to a closed community only. However, a AAA domain 154 participating in eduroam may also want to expose AAA services to 155 other, general-purpose, applications (on the same or other AAA 156 servers). Due to that, the eduroam consortium uses the service 157 tag "eduroam" and eduroam AAA servers use this tag to look up 158 other eduroam servers. An eduroam participant example.org which 159 also provides general-purpose AAA on a different server uses the 160 general "nai-roaming" tag: 162 example.org. IN NAPTR 50 50 "s" "eduroam:radius.tls" "" 163 _radiustls._tcp.eduroam.example.org. 165 example.org. IN NAPTR 50 50 "s" "nai-roaming:radius.tls" "" 166 _radiustls._tcp.aaa.example.org 168 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 169 eduroam.example.org. 171 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 172 default.example.org. 174 2.3. Realm to AAA server resolution algorithm 176 Input I to the algorithm is a User-Name in the form of a NAI as 177 defined in [RFC4282] as extracted from the User-Name attribute in an 178 Access-Request. Output O of the algorithm is a set of hostname:port 179 and an associated order/preference; the set can be empty. 181 Note well: The attribute User-Name does not necessarily contain well- 182 formed NAIs and may not even contain well-formed UTF-8 strings. This 183 document describes server discovery only for well-formed NAIs in 184 UTF-8 encoding. The result of all other possible contents of User- 185 Name is unspecified; this includes, but is not limited to: 187 Usage of separators other than @ 189 Usage of multiple @ separators 191 Encoding of User-Name in local encodings 193 The algorithm to determine the AAA server to contact is as follows: 195 1. Determine P = (position of first "@" character) in I. 197 2. generate R = (substring from P+1 to end of I) 199 3. Optional: modify R according to agreed consortium procedures 201 4. Using the host's name resolution library, perform a NAPTR query 202 for R. If no result, continue at step 9. If name resolution 203 returns with error, O = { }. Terminate. 205 5. Extract NAPTR records with service tag "nai-roaming" (replace 206 with other service tags where applicable). 208 6. If no result, continue at step 9. 210 7. Evaluate NAPTR result(s) for desired protocol tag, perform 211 subsequent lookup steps until lookup yields one or more 212 hostnames. O = (set of {Order/Preference, hostname:port} for 213 all lookup results). 215 8. Terminate. 217 9. Generate R' = (prefix R with "_radiustls._tcp." or 218 "_radiustls._udp") 220 10. Using the host's name resolution library, perform SRV lookup 221 with R' as label. 223 11. If name resolution returns with error, O = { }. Terminate. 225 12. If no result, O = {}; terminate. 227 13. Perform subsequent lookup steps until lookup yields one or more 228 hostnames. O = (set of {Order/Preference, hostname} for all 229 hostnames). Terminate. 231 Example: Assume a user from the Technical University of Munich, 232 Germany, has a RADIUS User-Name of 233 "foobar@tu-m[U+00FC]nchen.example". If DNS contains the following 234 records: 236 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "nai- 237 roaming:radius.tls" "" _radiustls._tcp.xn--tu-mnchen-t9a.example. 239 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "fooservice: 240 bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. 242 _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 243 radsec.xn--tu-mnchen-t9a.example. 245 _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 246 backup.xn--tu-mnchen-t9a.example. 248 radsec.xn--tu-mnchen-t9a.example. IN AAAA 2001:0DB8::202:44ff: 249 fe0a:f704 251 radsec.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 253 backup.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 255 Then the algorithm executes as follows, with I = 256 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 257 in use: 259 1. P = 7 260 2. R = "tu-m[U+00FC]nchen.example" 262 3. NOOP 264 4. Query result: ( 50 50 "s" "nai-roaming:radius.tls" "" 265 _radiustls._tcp.xn--tu-mnchen-t9a.example. ; 50 50 "s" 266 "fooservice:bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. ) 268 5. Result: 50 50 "s" "nai-roaming:radius.tls" "" 269 _radiustls._tcp.xn--tu-mnchen-t9a.example. 271 6. NOOP 273 7. O = {(10,radsec.xn--tu-mnchen-t9a.example.:2083),(20,backup.xn-- 274 tu-mnchen-t9a. example.:2083)} 276 8. Terminate. 278 9. (not executed) 280 10. (not executed) 282 11. (not executed) 284 12. (not executed) 286 13. (not executed) 288 The implementation will then attempt to connect to two servers, with 289 preference to radsec.xn--tu-mnchen-t9a.example.:2083, using either 290 the AAAA or A addresses depending on the host configuration and its 291 IP stack's capabilities. 293 3. Security Considerations 295 When using DNS without security, the replies to NAPTR, SRV and A/AAAA 296 requests as described in section Section 2 can not be trusted. 297 RADIUS transports have an out-of-DNS-band means to verify that the 298 discovery attempt led to the intended target (TLS/DTLS: ceritifcate 299 verification or TLS shared secret ciphers; UDP/TCP: the RADIUS shared 300 secret) and are safe from DNS-based redirection attacks. [Note: 301 assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT 302 deliver the shared secret in the DNS response!] 304 The discovery process is always susceptible to bidding down attacks 305 if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well 306 as for RADIUS/TLS and/or RADIUS/DTLS. While the SRV query will 307 expose both transports, an attacker in the routing path might 308 suppress the subsequent A/AAAA results for the TLS or DTLS peer and 309 trick the initiating peer into using the weakly protected UDP or TCP 310 transports. The use of DNSSEC can not fully mitigate this attack, 311 since it does not provide a means to detect packet suppression. The 312 only way to disable such bidding down attacks is by intiating 313 connections only to the peer(s) which match or exceed a configured 314 minimum security level. All implementations SHOULD provide a means 315 to configure the administratively desired minimum security level. 317 4. IANA Considerations 319 This document requests IANA registration of the following S-NAPTR 320 parameters: 322 o Application Service Tags 324 * nai-roaming 326 * eduroam 328 o Application Protocol Tags 330 * radius.tls 332 * radius.dtls 334 5. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to 337 Indicate Requirement Levels", BCP 14, 338 RFC 2119, March 1997. 340 [RFC3958] Daigle, L. and A. Newton, "Domain-Based 341 Application Service Location Using SRV RRs 342 and the Dynamic Delegation Discovery 343 Service (DDDS)", RFC 3958, January 2005. 345 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. 346 Eronen, "The Network Access Identifier", 347 RFC 4282, December 2005. 349 [I-D.dekok-radext-dtls] DeKok, A., "DTLS as a Transport Layer for 350 RADIUS", draft-dekok-radext-dtls-01 (work 351 in progress), June 2009. 353 [I-D.ietf-radext-radsec] Winter, S., McCauley, M., Venaas, S., and 354 K. Wierenga, "TLS encryption for RADIUS 355 over TCP", draft-ietf-radext-radsec-06 356 (work in progress), March 2010. 358 Authors' Addresses 360 Stefan Winter 361 Fondation RESTENA 362 6, rue Richard Coudenhove-Kalergi 363 Luxembourg 1359 364 LUXEMBOURG 366 Phone: +352 424409 1 367 Fax: +352 422473 368 EMail: stefan.winter@restena.lu 369 URI: http://www.restena.lu. 371 Mike McCauley 372 Open Systems Consultants 373 9 Bulbul Place 374 Currumbin Waters QLD 4223 375 AUSTRALIA 377 Phone: +61 7 5598 7474 378 Fax: +61 7 5598 7070 379 EMail: mikem@open.com.au 380 URI: http://www.open.com.au.