idnits 2.17.1 draft-ietf-radext-dynamic-discovery-00.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 02, 2009) is 5405 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 (~~), 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: January 3, 2010 OSC 6 July 02, 2009 8 NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS 9 draft-ietf-radext-dynamic-discovery-00 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. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 3, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document specifies a means to find authoritative AAA servers for 58 a given NAI realm as defined in [RFC4282]. It can be used in 59 conjunction with RADIUS over TLS and RADIUS over DTLS. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . . 3 67 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . . 3 68 2.2. Realm to AAA server resolution algorithm . . . . . . . . . 4 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 1.1. Requirements Language 77 In this document, several words are used to signify the requirements 78 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 79 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 80 and "OPTIONAL" in this document are to be interpreted as described in 81 RFC 2119. [RFC2119] 83 1.2. Terminology 85 RadSec node: a RadSec client or server 87 RadSec Client: a RadSec instance which initiates a new connection. 89 RadSec Server: a RadSec instance which listens on a RadSec port and 90 accepts new connections 92 2. DNS-based NAPTR/SRV Peer Discovery 94 2.1. DNS RR definition 96 DNS definitions of RadSec servers can be either NAPTR records or SRV 97 records. When both are defined, the resolution algorithm prefers 98 NAPTR results (see section Section 2.2 below). The NAPTR service 99 field used is "AAAS+RADSECT". The SRV prefix used is "_radsec._tcp". 100 It is expected that in most cases, the label used for the records is 101 the DNS representation (punycode) of the literal realm name for which 102 the server is the AAA server. 104 However, arbitrary other labels may be used if, for example, a 105 roaming consortium uses realm names which are not associated to DNS 106 names or special-purpose consortia where a globally valid discovery 107 is not a use case. Such other labels require a consortium-wide 108 agreement about the transformation from realm name to lookup label. 110 Examples: 112 a. A general-purpose AAA server for realm example.com might have DNS 113 entries as follows: 115 example.com. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" 116 _radsec._tcp.foobar.example.com. 118 _radsec._tcp.example.com. IN SRV 0 10 2083 119 radsec.example.com. 121 b. Consortium "foo" provides roaming services for banks. The realms 122 used are of the form enterprise-name.foobankroam. The consortium 123 operates a special purpose DNS server for the (private) TLD 124 "foobankroam" which all AAA servers use to resolve realm names. 125 "Rupt, Inc." is part of the consortium. On the consortium's DNS 126 server, realm bank-rupt.foobankroam might have the following DNS 127 entries: 129 bank-rupt.foobankroam IN NAPTR 50 50 "a" "AAAS+RADSECT" "" 130 "triple-a.bank-rupt.com" 132 _radsec._tcp.bank-rupt.foobankroam IN SRV 0 10 2083 triple-a- 133 backup.bank-rupt.com" 135 c. the eduroam consortium uses realms based on DNS, but provides its 136 services to a closed community only. However, a AAA domain 137 participating in eduroam may also want to expose AAA services to 138 other, general-purpose, applications (on the same or other AAA 139 servers). Due to that, the eduroam consortium uses labels 140 prefixed with "eduroam." and eduroam AAA servers use these labels 141 to look up servers. An eduroam participant which also provides 142 general-purpose AAA on a different server might have the 143 following DNS entries: 145 eduroam.restena.lu. IN NAPTR 50 50 "a" "AAAS+RADSECT" "" aaa- 146 eduroam.restena.lu 148 restena.lu. IN NAPTR 50 50 "a" "AAAS+RADSECT" "" aaa- 149 default.restena.lu 151 _radsec._tcp.eduroam.restena.lu. IN SRV 0 10 2083 aaa- 152 eduroam.restena.lu. 154 _radsec._tcp.restena.lu. IN SRV 0 10 2083 aaa- 155 default.restena.lu. 157 2.2. Realm to AAA server resolution algorithm 159 Input I to the algorithm is a User-Name in the form of a NAI as 160 defined in [RFC4282] as extracted from the User-Name attribute in an 161 Access-Request. Output O of the algorithm is a set of hostname:port 162 and an assoiciated order/preference; the set can be empty. The 163 algorithm to determine the AAA server to contact is as follows: 165 1. Determine P = (position of first "@" character) in I. 167 2. generate R = (substring from P+1 to end of I) 168 3. Optional: modify R according to agreed consortium procedures 170 4. Generate R' = ( DNS library transformation of R to an FQDN in 171 punycode) 173 5. If generation of R' failed, O = {}; terminate. 175 6. Perform NAPTR query for service "AAAS+RADSECT" with R as label 177 7. If no result, continue at step 10. 179 8. Evaluate NAPTR result, perform subsequent lookup steps until 180 lookup yields one or more hostnames. O = (set of {Order/ 181 Preference, hostname:port} for all lookup results). 183 9. Terminate. 185 10. Generate R'' = (prefix R' with "_radsec._tcp.") 187 11. Perform SRV lookup with R'' as label. If no result, O = {}; 188 terminate. 190 12. Perform subsequent lookup steps until lookup yields one or more 191 hostnames. O = (set of {Order/Preference, hostname} for all 192 hostnames). Terminate. 194 Example: Assume a user from the Technical University of Munich, 195 Germany, has a RADIUS User-Name of 196 "foobar@tu-m[U+00FC]nchen.example". If DNS contains the following 197 records: 199 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" "AAAS+RADSECT" "" 200 _radsec._tcp.xn--tu-mnchen-t9a.example. 202 _radsec._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 203 radsec.xn--tu-mnchen-t9a.example. 205 _radsec._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 206 backup.xn--tu-mnchen-t9a.example. 208 radsec.xn--tu-mnchen-t9a.example. IN AAAA 2001:0DB8::202:44ff: 209 fe0a:f704 211 radsec.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 213 backup.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 215 Then the algorithm executes as follows, with I = 216 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 217 in use: 219 1. P = 7 221 2. R = "tu-m[U+00FC]nchen.example" 223 3. NOOP 225 4. R' = "xn--tu-mnchen-t9a.example." 227 5. NOOP 229 6. Query result: ( 0 10 2083 radsec.xn--tu-mnchen-t9a.example. ; 0 230 20 2083 backup.xn--tu-mnchen-t9a.example. ) 232 7. NOOP 234 8. O = {(10,radsec.xn--tu-mnchen-t9a.example.:2083),(20,backup.xn-- 235 tu-mnchen-t9a.example.:2083)} 237 9. Terminate. 239 10. (not executed) 241 11. (not executed) 243 12. (not executed) 245 The implementation will then attempt to connect to two servers, with 246 preference to radsec.xn--tu-mnchen-t9a.example.:2083, using either 247 the AAAA or A addresses depending on the host configuration and its 248 IP stack's capabilities. 250 3. Security Considerations 252 When using DNS without security, the replies to NAPTR, SRV and A/AAAA 253 requests as described in section Section 2 can not be trusted. 254 RADIUS transports have an out-of-DNS-band means to verify that the 255 discovery attempt led to the intended target (TLS/DTLS: ceritifcate 256 verification or TLS shared secret ciphers; UDP/TCP: the RADIUS shared 257 secret) and are safe from DNS-based redirection attacks. [Note: 258 assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT 259 deliver the shared secret in the DNS response!] 261 The discovery process is always susceptible to bidding down attacks 262 if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well 263 as for RADIUS/TLS and/or RADIUS/DTLS. While the SRV query will 264 expose both transports, an attacker in the routing path might 265 suppress the subsequent A/AAAA results for the TLS or DTLS peer and 266 trick the initiating peer into using the weakly protected UDP or TCP 267 transports. The use of DNSSEC can not fully mitigate this attack, 268 since it does not provide a means to detect packet suppression. The 269 only way to disable such bidding down attacks is by intiating 270 connections only to the peer(s) which match or exceed a configured 271 minimum security level. All implementations SHOULD provide a means 272 to configure the administratively desired minimum security level. 274 4. IANA Considerations 276 This document contains no actions for IANA. Maybe. Not sure about 277 the labels "AAAS+RADSECT" and "_radsec._tcp.". 279 5. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 285 Network Access Identifier", RFC 4282, December 2005. 287 Authors' Addresses 289 Stefan Winter 290 Fondation RESTENA 291 6, rue Richard Coudenhove-Kalergi 292 Luxembourg 1359 293 LUXEMBOURG 295 Phone: +352 424409 1 296 Fax: +352 422473 297 EMail: stefan.winter@restena.lu 298 URI: http://www.restena.lu. 300 Mike McCauley 301 Open Systems Consultants 302 9 Bulbul Place 303 Currumbin Waters QLD 4223 304 AUSTRALIA 306 Phone: +61 7 5598 7474 307 Fax: +61 7 5598 7070 308 EMail: mikem@open.com.au 309 URI: http://www.open.com.au.