1 2 3 4 5 6 7INTERNET-DRAFT Ken Hornstein 8<draft-ietf-krb-wg-krb-dns-locate-02.txt> NRL 9February 28, 2001 Jeffrey Altman 10Expires: August 28, 2001 Columbia University 11 12 13 14 Distributing Kerberos KDC and Realm Information with DNS 15 16 17Status of this Memo 18 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 21 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. 26 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." 31 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 37 38 Distribution of this memo is unlimited. It is filed as <draft-ietf- 39 krb-wg-krb-dns-locate-02.txt>, and expires on August 28, 2001. 40 Please send comments to the authors. 41 42Abstract 43 44 Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- 45 col [RFC????] describe any mechanism for clients to learn critical 46 configuration information necessary for proper operation of the pro- 47 tocol. Such information includes the location of Kerberos key dis- 48 tribution centers or a mapping between DNS domains and Kerberos 49 realms. 50 51 Current Kerberos implementations generally store such configuration 52 information in a file on each client machine. Experience has shown 53 this method of storing configuration information presents problems 54 with out-of-date information and scaling problems, especially when 55 56 57 58Hornstein, Altman [Page 1] 59 60RFC DRAFT February 28, 2001 61 62 63 using cross-realm authentication. 64 65 This memo describes a method for using the Domain Name System 66 [RFC1035] for storing such configuration information. Specifically, 67 methods for storing KDC location and hostname/domain name to realm 68 mapping information are discussed. 69 70DNS vs. Kerberos - Case Sensitivity of Realm Names 71 72 In Kerberos, realm names are case sensitive. While it is strongly 73 encouraged that all realm names be all upper case this recommendation 74 has not been adopted by all sites. Some sites use all lower case 75 names and other use mixed case. DNS on the other hand is case insen- 76 sitive for queries but is case preserving for responses to TXT 77 queries. Since "MYREALM", "myrealm", and "MyRealm" are all different 78 it is necessary that only one of the possible combinations of upper 79 and lower case characters be used. This restriction may be lifted in 80 the future as the DNS naming scheme is expanded to support non-ASCII 81 names. 82 83Overview - KDC location information 84 85 KDC location information is to be stored using the DNS SRV RR [RFC 86 2052]. The format of this RR is as follows: 87 88 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 89 90 The Service name for Kerberos is always "_kerberos". 91 92 The Proto can be either "_udp" or "_tcp". If these records are to be 93 used, a "_udp" record MUST be included. If the Kerberos implementa- 94 tion supports TCP transport, a "_tcp" record SHOULD be included. 95 96 The Realm is the Kerberos realm that this record corresponds to. 97 98 TTL, Class, SRV, Priority, Weight, and Target have the standard mean- 99 ing as defined in RFC 2052. 100 101 As per RFC 2052 the Port number should be the value assigned to "ker- 102 beros" by the Internet Assigned Number Authority (88). 103 104Example - KDC location information 105 106 These are DNS records for a Kerberos realm ASDF.COM. It has two Ker- 107 beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be 108 directed to kdc1.asdf.com first as per the specified priority. 109 Weights are not used in these records. 110 111 112 113 114Hornstein, Altman [Page 2] 115 116RFC DRAFT February 28, 2001 117 118 119 _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 120 _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 121 122Overview - Kerberos password changing server location information 123 124 Kerberos password changing server [KERB-CHG] location is to be stored 125 using the DNS SRV RR [RFC 2052]. The format of this RR is as fol- 126 lows: 127 128 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 129 130 The Service name for the password server is always "_kpasswd". 131 132 The Proto MUST be "_udp". 133 134 The Realm is the Kerberos realm that this record corresponds to. 135 136 TTL, Class, SRV, Priority, Weight, and Target have the standard mean- 137 ing as defined in RFC 2052. 138 139 As per RFC 2052 the Port number should be the value assigned to 140 "kpasswd" by the Internet Assigned Number Authority (464). 141 142Overview - Kerberos admin server location information 143 144 Kerberos admin location information is to be stored using the DNS SRV 145 RR [RFC 2052]. The format of this RR is as follows: 146 147 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 148 149 The Service name for the admin server is always "_kerberos-adm". 150 151 The Proto can be either "_udp" or "_tcp". If these records are to be 152 used, a "_tcp" record MUST be included. If the Kerberos admin imple- 153 mentation supports UDP transport, a "_udp" record SHOULD be included. 154 155 The Realm is the Kerberos realm that this record corresponds to. 156 157 TTL, Class, SRV, Priority, Weight, and Target have the standard mean- 158 ing as defined in RFC 2052. 159 160 As per RFC 2052 the Port number should be the value assigned to 161 "kerberos-adm" by the Internet Assigned Number Authority (749). 162 163 Note that there is no formal definition of a Kerberos admin protocol, 164 so the use of this record is optional and implementation-dependent. 165 166 167 168 169 170Hornstein, Altman [Page 3] 171 172RFC DRAFT February 28, 2001 173 174 175Example - Kerberos administrative server location information 176 177 These are DNS records for a Kerberos realm ASDF.COM. It has one 178 administrative server, kdc1.asdf.com. 179 180 _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 749 kdc1.asdf.com. 181 182Overview - Hostname/domain name to Kerberos realm mapping 183 184 Information on the mapping of DNS hostnames and domain names to Ker- 185 beros realms is stored using DNS TXT records [RFC 1035]. These 186 records have the following format. 187 188 Service.Name TTL Class TXT Realm 189 190 The Service field is always "_kerberos", and prefixes all entries of 191 this type. 192 193 The Name is a DNS hostname or domain name. This is explained in 194 greater detail below. 195 196 TTL, Class, and TXT have the standard DNS meaning as defined in RFC 197 1035. 198 199 The Realm is the data for the TXT RR, and consists simply of the Ker- 200 beros realm that corresponds to the Name specified. 201 202 When a Kerberos client wishes to utilize a host-specific service, it 203 will perform a DNS TXT query, using the hostname in the Name field of 204 the DNS query. If the record is not found, the first label of the 205 name is stripped and the query is retried. 206 207 Compliant implementations MUST query the full hostname and the most 208 specific domain name (the hostname with the first label removed). 209 Compliant implementations SHOULD try stripping all subsequent labels 210 until a match is found or the Name field is empty. 211 212Example - Hostname/domain name to Kerberos realm mapping 213 214 For the previously mentioned ASDF.COM realm and domain, some sample 215 records might be as follows: 216 217 _kerberos.asdf.com. IN TXT "ASDF.COM" 218 _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM" 219 _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM" 220 221 Let us suppose that in this case, a Kerberos client wishes to use a 222 Kerberized service on the host foo.asdf.com. It would first query: 223 224 225 226Hornstein, Altman [Page 4] 227 228RFC DRAFT February 28, 2001 229 230 231 _kerberos.foo.asdf.com. IN TXT 232 233 Finding no match, it would then query: 234 235 _kerberos.asdf.com. IN TXT 236 237 And find an answer of ASDF.COM. This would be the realm that 238 foo.asdf.com resides in. 239 240 If another Kerberos client wishes to use a Kerberized service on the 241 host salesserver.asdf.com, it would query: 242 243 _kerberos.salesserver.asdf.com IN TXT 244 245 And find an answer of SALES.ASDF.COM. 246 247Security considerations 248 249 As DNS is deployed today, it is an unsecure service. Thus the infor- 250 mation returned by it cannot be trusted. 251 252 Current practice for REALM to KDC mapping is to use hostnames to 253 indicate KDC hosts (stored in some implementation-dependent location, 254 but generally a local config file). These hostnames are vulnerable 255 to the standard set of DNS attacks (denial of service, spoofed 256 entries, etc). The design of the Kerberos protocol limits attacks of 257 this sort to denial of service. However, the use of SRV records does 258 not change this attack in any way. They have the same vulnerabili- 259 ties that already exist in the common practice of using hostnames for 260 KDC locations. 261 262 Current practice for HOSTNAME to REALM mapping is to provide a local 263 configuration of mappings of hostname or domain name to realm which 264 are then mapped to KDCs. But this again is vulnerable to spoofing 265 via CNAME records that point to hosts in other domains. This has the 266 same effect as when a TXT record is spoofed. In a realm with no 267 cross-realm trusts this is a DoS attack. However, when cross-realm 268 trusts are used it is possible to redirect a client to use a comprom- 269 ised realm. 270 271 This is not an exploit of the Kerberos protocol but of the Kerberos 272 trust model. The same can be done to any application that must 273 resolve the hostname in order to determine which domain a non-FQDN 274 belongs to. 275 276 Implementations SHOULD provide a way of specifying this information 277 locally without the use of DNS. However, to make this feature 278 worthwhile a lack of any configuration information on a client should 279 280 281 282Hornstein, Altman [Page 5] 283 284RFC DRAFT February 28, 2001 285 286 287 be interpretted as permission to use DNS. 288 289Expiration 290 291 This Internet-Draft expires on August 28, 2001. 292 293References 294 295 296 [RFC1510] 297 The Kerberos Network Authentication System; Kohl, Newman; Sep- 298 tember 1993. 299 300 [RFC1035] 301 Domain Names - Implementation and Specification; Mockapetris; 302 November 1987 303 304 [RFC2782] 305 A DNS RR for specifying the location of services (DNS SRV); Gul- 306 brandsen, Vixie; Feburary 2000 307 308 [KERB-CHG] 309 Kerberos Change Password Protocol; Horowitz; 310 ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg- 311 password-02.txt 312 313Authors' Addresses 314 315 Ken Hornstein 316 US Naval Research Laboratory 317 Bldg A-49, Room 2 318 4555 Overlook Avenue 319 Washington DC 20375 USA 320 321 Phone: +1 (202) 404-4765 322 EMail: kenh@cmf.nrl.navy.mil 323 324 Jeffrey Altman 325 The Kermit Project 326 Columbia University 327 612 West 115th Street #716 328 New York NY 10025-7799 USA 329 330 Phone: +1 (212) 854-1344 331 EMail: jaltman@columbia.edu 332 333 334 335 336 337 338Hornstein, Altman [Page 6] 339 340