idnits 2.17.1 draft-ietf-radext-dynamic-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 abstract seems to contain references ([RFC4282]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances 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 (July 13, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 3 errors (**), 0 flaws (~~), 2 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: January 14, 2010 OSC 6 July 13, 2009 8 NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS 9 draft-ietf-radext-dynamic-discovery-01 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies a means to find authoritative AAA servers for 48 a given NAI realm as defined in [RFC4282]. It can be used in 49 conjunction with RADIUS over TLS and RADIUS over DTLS. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . . 3 57 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. DNS RR definition . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. Realm to AAA server resolution algorithm . . . . . . . . . 5 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 1.1. Requirements Language 68 In this document, several words are used to signify the requirements 69 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 70 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 71 and "OPTIONAL" in this document are to be interpreted as described in 72 RFC 2119. [RFC2119] 74 1.2. Terminology 76 RadSec node: a RadSec client or server 78 RadSec Client: a RadSec instance which initiates a new connection. 80 RadSec Server: a RadSec instance which listens on a RadSec port and 81 accepts new connections 83 2. DNS-based NAPTR/SRV Peer Discovery 85 2.1. Applicability 87 Dynamic server discovery as defined in this document is only 88 applicable for AAA transactions where a AAA server receives a request 89 with a NAI realm for which no home AAA server is known. I.e. where 90 static server configuration does not contain a known home 91 authentication server, or where the server configuration explicitly 92 states that the realm destination is to be looked up dynamically. 93 Furthermore, it is only applicable for new user sessions, i.e. for 94 the initial Access-Request. Subsequent messages concerning this 95 session, for example Access-Challenges, Access-Accepts, Accounting 96 Messages or Change-of-Authorisation messages use the previously- 97 established communication channel between client and server. 99 2.2. DNS RR definition 101 DNS definitions of RadSec servers can be either NAPTR records or SRV 102 records. When both are defined, the resolution algorithm prefers 103 NAPTR results (see section Section 2.3 below). The NAPTR service 104 field used is "AAAS+RADSECT". The SRV prefix used is "_radsec._tcp". 105 It is expected that in most cases, the label used for the records is 106 the DNS representation (punycode) of the literal realm name for which 107 the server is the AAA server. 109 However, arbitrary other labels may be used if, for example, a 110 roaming consortium uses realm names which are not associated to DNS 111 names or special-purpose consortia where a globally valid discovery 112 is not a use case. Such other labels require a consortium-wide 113 agreement about the transformation from realm name to lookup label. 115 Examples: 117 a. A general-purpose AAA server for realm example.com might have DNS 118 entries as follows: 120 example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" 121 _radsec._tcp.foobar.example.com. 123 _radsec._tcp.example.com. IN SRV 0 10 2083 124 radsec.example.com. 126 b. Consortium "foo" provides roaming services for banks. The realms 127 used are of the form enterprise-name.foobankroam. The consortium 128 operates a special purpose DNS server for the (private) TLD 129 "foobankroam" which all AAA servers use to resolve realm names. 130 "Rupt, Inc." is part of the consortium. On the consortium's DNS 131 server, realm bank-rupt.foobankroam might have the following DNS 132 entries: 134 bank-rupt.foobankroam IN NAPTR 50 50 "a" "AAAS+RADSECT" "" 135 "triple-a.bank-rupt.com" 137 _radsec._tcp.bank-rupt.foobankroam IN SRV 0 10 2083 triple-a- 138 backup.bank-rupt.com" 140 c. the eduroam consortium uses realms based on DNS, but provides its 141 services to a closed community only. However, a AAA domain 142 participating in eduroam may also want to expose AAA services to 143 other, general-purpose, applications (on the same or other AAA 144 servers). Due to that, the eduroam consortium uses labels 145 prefixed with "eduroam." and eduroam AAA servers use these labels 146 to look up servers. An eduroam participant which also provides 147 general-purpose AAA on a different server might have the 148 following DNS entries: 150 eduroam.restena.lu. IN NAPTR 50 50 "a" "AAAS+RADSECT" "" aaa- 151 eduroam.restena.lu 153 restena.lu. IN NAPTR 50 50 "a" "AAAS+RADSECT" "" aaa- 154 default.restena.lu 156 _radsec._tcp.eduroam.restena.lu. IN SRV 0 10 2083 aaa- 157 eduroam.restena.lu. 159 _radsec._tcp.restena.lu. IN SRV 0 10 2083 aaa- 160 default.restena.lu. 162 2.3. Realm to AAA server resolution algorithm 164 Input I to the algorithm is a User-Name in the form of a NAI as 165 defined in [RFC4282] as extracted from the User-Name attribute in an 166 Access-Request. Output O of the algorithm is a set of hostname:port 167 and an assoiciated order/preference; the set can be empty. 169 Note well: The attribute User-Name does not necessarily contain well- 170 formed NAIs and may not even contain well-formed UTF-8 strings. This 171 document describes server discovery only for well-formed NAIs in 172 UTF-8 encoding. The result of all other possible contents of User- 173 Name is unspecified; this includes, but is not limited to: 175 Usage of separators other than @ 177 Usage of multiple @ separators 179 Encoding of User-Name in local encodings 181 The algorithm to determine the AAA server to contact is as follows: 183 1. Determine P = (position of first "@" character) in I. 185 2. generate R = (substring from P+1 to end of I) 187 3. Optional: modify R according to agreed consortium procedures 189 4. Using the host's name resolution library, perform a NAPTR query 190 for service "AAAS+RADSECT" for R 192 5. If name resolution returns with error, O = { }. Terminate. 194 6. If no result, continue at step 9. 196 7. Evaluate NAPTR result, perform subsequent lookup steps until 197 lookup yields one or more hostnames. O = (set of {Order/ 198 Preference, hostname:port} for all lookup results). 200 8. Terminate. 202 9. Generate R' = (prefix R with "_radsec._tcp.") 204 10. Using the host's name resolution library, perform SRV lookup 205 with R' as label. 207 11. If name resolution returns with error, O = { }. Terminate. 209 12. If no result, O = {}; terminate. 211 13. Perform subsequent lookup steps until lookup yields one or more 212 hostnames. O = (set of {Order/Preference, hostname} for all 213 hostnames). Terminate. 215 Example: Assume a user from the Technical University of Munich, 216 Germany, has a RADIUS User-Name of 217 "foobar@tu-m[U+00FC]nchen.example". If DNS contains the following 218 records: 220 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" 221 _radsec._tcp.xn--tu-mnchen-t9a.example. 223 _radsec._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 224 radsec.xn--tu-mnchen-t9a.example. 226 _radsec._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 227 backup.xn--tu-mnchen-t9a.example. 229 radsec.xn--tu-mnchen-t9a.example. IN AAAA 2001:0DB8::202:44ff: 230 fe0a:f704 232 radsec.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 234 backup.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 236 Then the algorithm executes as follows, with I = 237 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 238 in use: 240 1. P = 7 242 2. R = "tu-m[U+00FC]nchen.example" 244 3. NOOP 246 4. Query result: ( 0 10 2083 radsec.xn--tu-mnchen-t9a.example. ; 0 247 20 2083 backup.xn--tu-mnchen-t9a.example. ) 249 5. NOOP 251 6. NOOP 253 7. O = {(10,radsec.xn--tu-mnchen-t9a.example.:2083),(20,backup.xn-- 254 tu-mnchen-t9a.example.:2083)} 256 8. Terminate. 258 9. (not executed) 260 10. (not executed) 262 11. (not executed) 264 12. (not executed) 266 13. (not executed) 268 The implementation will then attempt to connect to two servers, with 269 preference to radsec.xn--tu-mnchen-t9a.example.:2083, using either 270 the AAAA or A addresses depending on the host configuration and its 271 IP stack's capabilities. 273 3. Security Considerations 275 When using DNS without security, the replies to NAPTR, SRV and A/AAAA 276 requests as described in section Section 2 can not be trusted. 277 RADIUS transports have an out-of-DNS-band means to verify that the 278 discovery attempt led to the intended target (TLS/DTLS: ceritifcate 279 verification or TLS shared secret ciphers; UDP/TCP: the RADIUS shared 280 secret) and are safe from DNS-based redirection attacks. [Note: 281 assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT 282 deliver the shared secret in the DNS response!] 284 The discovery process is always susceptible to bidding down attacks 285 if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well 286 as for RADIUS/TLS and/or RADIUS/DTLS. While the SRV query will 287 expose both transports, an attacker in the routing path might 288 suppress the subsequent A/AAAA results for the TLS or DTLS peer and 289 trick the initiating peer into using the weakly protected UDP or TCP 290 transports. The use of DNSSEC can not fully mitigate this attack, 291 since it does not provide a means to detect packet suppression. The 292 only way to disable such bidding down attacks is by intiating 293 connections only to the peer(s) which match or exceed a configured 294 minimum security level. All implementations SHOULD provide a means 295 to configure the administratively desired minimum security level. 297 4. IANA Considerations 299 This document contains no actions for IANA. Maybe. Not sure about 300 the labels "AAAS+RADSECT" and "_radsec._tcp.". 302 5. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 308 Network Access Identifier", RFC 4282, December 2005. 310 Authors' Addresses 312 Stefan Winter 313 Fondation RESTENA 314 6, rue Richard Coudenhove-Kalergi 315 Luxembourg 1359 316 LUXEMBOURG 318 Phone: +352 424409 1 319 Fax: +352 422473 320 EMail: stefan.winter@restena.lu 321 URI: http://www.restena.lu. 323 Mike McCauley 324 Open Systems Consultants 325 9 Bulbul Place 326 Currumbin Waters QLD 4223 327 AUSTRALIA 329 Phone: +61 7 5598 7474 330 Fax: +61 7 5598 7070 331 EMail: mikem@open.com.au 332 URI: http://www.open.com.au.