1 2 3 4 5 6 7INTERNET-DRAFT Ken Hornstein 8<draft-ietf-cat-krb-dns-locate-02.txt> NRL 9March 10, 2000 Jeffrey Altman 10Expires: September 10, 2000 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 cat-krb-dns-locate-02.txt>, and expires on September 10, 2000. Please 40 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 March 10, 2000 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 the DNS entries be distinguishable. 79 80 Since the recommend realm names are all upper case, we will not 81 require any quoting to be applied to upper case names. If the realm 82 name contains lower case characters each character is to be quoted by 83 a '=' character. So "MyRealm" would be represented as "M=yR=e=a=l=m" 84 and "myrealm" as "=m=y=r=e=a=l=m". If the realm name contains the 85 '=' character it will be represented as "==". 86 87 88Overview - KDC location information 89 90 KDC location information is to be stored using the DNS SRV RR [RFC 91 2052]. The format of this RR is as follows: 92 93 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 94 95 The Service name for Kerberos is always "_kerberos". 96 97 The Proto can be either "_udp" or "_tcp". If these records are to be 98 used, a "_udp" record MUST be included. If the Kerberos implementa- 99 tion supports TCP transport, a "_tcp" record SHOULD be included. 100 101 The Realm is the Kerberos realm that this record corresponds to. 102 103 TTL, Class, SRV, Priority, Weight, Port, and Target have the standard 104 meaning as defined in RFC 2052. 105 106Example - KDC location information 107 108 These are DNS records for a Kerberos realm ASDF.COM. It has two Ker- 109 beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be 110 directed to kdc1.asdf.com first as per the specified priority. 111 112 113 114Hornstein, Altman [Page 2] 115 116RFC DRAFT March 10, 2000 117 118 119 Weights are not used in these records. 120 121 _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 122 _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 123 124Overview - Kerberos password changing server location information 125 126 Kerberos password changing server [KERB-CHG] location is to be stored 127 using the DNS SRV RR [RFC 2052]. The format of this RR is as fol- 128 lows: 129 130 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 131 132 The Service name for the password server is always "_kpasswd". 133 134 The Proto MUST be "_udp". 135 136 The Realm is the Kerberos realm that this record corresponds to. 137 138 TTL, Class, SRV, Priority, Weight, Port, and Target have the standard 139 meaning as defined in RFC 2052. 140 141Overview - Kerberos admin server location information 142 143 Kerberos admin location information is to be stored using the DNS SRV 144 RR [RFC 2052]. The format of this RR is as follows: 145 146 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 147 148 The Service name for the admin server is always "_kerberos-adm". 149 150 The Proto can be either "_udp" or "_tcp". If these records are to be 151 used, a "_tcp" record MUST be included. If the Kerberos admin imple- 152 mentation supports UDP transport, a "_udp" record SHOULD be included. 153 154 The Realm is the Kerberos realm that this record corresponds to. 155 156 TTL, Class, SRV, Priority, Weight, Port, and Target have the standard 157 meaning as defined in RFC 2052. 158 159 Note that there is no formal definition of a Kerberos admin protocol, 160 so the use of this record is optional and implementation-dependent. 161 162Example - Kerberos administrative server location information 163 164 These are DNS records for a Kerberos realm ASDF.COM. It has one 165 administrative server, kdc1.asdf.com. 166 167 168 169 170Hornstein, Altman [Page 3] 171 172RFC DRAFT March 10, 2000 173 174 175 _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 176 177Overview - Hostname/domain name to Kerberos realm mapping 178 179 Information on the mapping of DNS hostnames and domain names to Ker- 180 beros realms is stored using DNS TXT records [RFC 1035]. These 181 records have the following format. 182 183 Service.Name TTL Class TXT Realm 184 185 The Service field is always "_kerberos", and prefixes all entries of 186 this type. 187 188 The Name is a DNS hostname or domain name. This is explained in 189 greater detail below. 190 191 TTL, Class, and TXT have the standard DNS meaning as defined in RFC 192 1035. 193 194 The Realm is the data for the TXT RR, and consists simply of the Ker- 195 beros realm that corresponds to the Name specified. 196 197 When a Kerberos client wishes to utilize a host-specific service, it 198 will perform a DNS TXT query, using the hostname in the Name field of 199 the DNS query. If the record is not found, the first label of the 200 name is stripped and the query is retried. 201 202 Compliant implementations MUST query the full hostname and the most 203 specific domain name (the hostname with the first label removed). 204 Compliant implementations SHOULD try stripping all subsequent labels 205 until a match is found or the Name field is empty. 206 207Example - Hostname/domain name to Kerberos realm mapping 208 209 For the previously mentioned ASDF.COM realm and domain, some sample 210 records might be as follows: 211 212 _kerberos.asdf.com. IN TXT "ASDF.COM" 213 _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM" 214 _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM" 215 216 Let us suppose that in this case, a Kerberos client wishes to use a 217 Kerberized service on the host foo.asdf.com. It would first query: 218 219 _kerberos.foo.asdf.com. IN TXT 220 221 Finding no match, it would then query: 222 223 224 225 226Hornstein, Altman [Page 4] 227 228RFC DRAFT March 10, 2000 229 230 231 _kerberos.asdf.com. IN TXT 232 233 And find an answer of ASDF.COM. This would be the realm that 234 foo.asdf.com resides in. 235 236 If another Kerberos client wishes to use a Kerberized service on the 237 host salesserver.asdf.com, it would query: 238 239 _kerberos.salesserver.asdf.com IN TXT 240 241 And find an answer of SALES.ASDF.COM. 242 243Security considerations 244 245 As DNS is deployed today, it is an unsecure service. Thus the infor- 246 mation returned by it cannot be trusted. 247 248 Current practice for REALM to KDC mapping is to use hostnames to 249 indicate KDC hosts (stored in some implementation-dependent location, 250 but generally a local config file). These hostnames are vulnerable 251 to the standard set of DNS attacks (denial of service, spoofed 252 entries, etc). The design of the Kerberos protocol limits attacks of 253 this sort to denial of service. However, the use of SRV records does 254 not change this attack in any way. They have the same vulnerabili- 255 ties that already exist in the common practice of using hostnames for 256 KDC locations. 257 258 Current practice for HOSTNAME to REALM mapping is to provide a local 259 configuration of mappings of hostname or domain name to realm which 260 are then mapped to KDCs. But this again is vulnerable to spoofing 261 via CNAME records that point to hosts in other domains. This has the 262 same effect as when a TXT record is spoofed. In a realm with no 263 cross-realm trusts this is a DoS attack. However, when cross-realm 264 trusts are used it is possible to redirect a client to use a comprom- 265 ised realm. 266 267 This is not an exploit of the Kerberos protocol but of the Kerberos 268 trust model. The same can be done to any application that must 269 resolve the hostname in order to determine which domain a non-FQDN 270 belongs to. 271 272 Implementations SHOULD provide a way of specifying this information 273 locally without the use of DNS. However, to make this feature 274 worthwhile a lack of any configuration information on a client should 275 be interpretted as permission to use DNS. 276 277 278 279 280 281 282Hornstein, Altman [Page 5] 283 284RFC DRAFT March 10, 2000 285 286 287Expiration 288 289 This Internet-Draft expires on September 10, 2000. 290 291References 292 293 294 [RFC1510] 295 The Kerberos Network Authentication System; Kohl, Newman; Sep- 296 tember 1993. 297 298 [RFC1035] 299 Domain Names - Implementation and Specification; Mockapetris; 300 November 1987 301 302 [RFC2782] 303 A DNS RR for specifying the location of services (DNS SRV); Gul- 304 brandsen, Vixie; Feburary 2000 305 306 [KERB-CHG] 307 Kerberos Change Password Protocol; Horowitz; 308 ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg- 309 password-02.txt 310 311Authors' Addresses 312 313 Ken Hornstein 314 US Naval Research Laboratory 315 Bldg A-49, Room 2 316 4555 Overlook Avenue 317 Washington DC 20375 USA 318 319 Phone: +1 (202) 404-4765 320 EMail: kenh@cmf.nrl.navy.mil 321 322 Jeffrey Altman 323 The Kermit Project 324 Columbia University 325 612 West 115th Street #716 326 New York NY 10025-7799 USA 327 328 Phone: +1 (212) 854-1344 329 EMail: jaltman@columbia.edu 330 331 332 333 334 335 336 337 338Hornstein, Altman [Page 6] 339 340