1INTERNET-DRAFT Ken Hornstein 2<draft-ietf-cat-krb-dns-locate-00.txt> NRL 3June 21, 1999 Jeffrey Altman 4Expires: December 21, 1999 Columbia University 5 6 Distributing Kerberos KDC and Realm Information with DNS 7 8Status of this Memo 9 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 12 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 17 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 22 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 28 29 Distribution of this memo is unlimited. It is filed as <draft-ietf- 30 cat-krb-dns-locate-00.txt>, and expires on December 21, 1999. Please 31 send comments to the authors. 32 33Abstract 34 35 Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- 36 col [RFC????] describe any mechanism for clients to learn critical 37 configuration information necessary for proper operation of the pro- 38 tocol. Such information includes the location of Kerberos key dis- 39 tribution centers or a mapping between DNS domains and Kerberos 40 realms. 41 42 Current Kerberos implementations generally store such configuration 43 information in a file on each client machine. Experience has shown 44 this method of storing configuration information presents problems 45 with out-of-date information and scaling problems, especially when 46 47Hornstein, Altman [Page 1] 48 49RFC DRAFT June 21, 1999 50 51 using cross-realm authentication. 52 53 This memo describes a method for using the Domain Name System 54 [RFC1035] for storing such configuration information. Specifically, 55 methods for storing KDC location and hostname/domain name to realm 56 mapping information are discussed. 57 58Overview - KDC location information 59 60 KDC location information is to be stored using the DNS SRV RR [RFC 61 2052]. The format of this RR is as follows: 62 63 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 64 65 The Service name for Kerberos is always "_kerberos". 66 67 The Proto can be either "_udp" or "_tcp". If these records are to be 68 used, a "_udp" record MUST be included. If the Kerberos implementa- 69 tion supports TCP transport, a "_tcp" record SHOULD be included. 70 71 The Realm is the Kerberos realm that this record corresponds to. 72 73 TTL, Class, SRV, Priority, Weight, Port, and Target have the standard 74 meaning as defined in RFC 2052. 75 76Example - KDC location information 77 78 These are DNS records for a Kerberos realm ASDF.COM. It has two Ker- 79 beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be 80 directed to kdc1.asdf.com first as per the specified priority. 81 Weights are not used in these records. 82 83 _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 84 _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. 85 86Overview - KAdmin location information 87 88 Kadmin location information is to be stored using the DNS SRV RR [RFC 89 2052]. The format of this RR is as follows: 90 91 Service.Proto.Realm TTL Class SRV Priority Weight Port Target 92 93 The Service name for Kadmin is always "_kadmin". 94 95 The Proto can be either "_udp" or "_tcp". If these records are to be 96 used, a "_tcp" record MUST be included. If the Kadmin implementation 97 supports UDP transport, a "_udp" record SHOULD be included. 98 99Hornstein, Altman [Page 2] 100 101RFC DRAFT June 21, 1999 102 103 The Realm is the Kerberos realm that this record corresponds to. 104 105 TTL, Class, SRV, Priority, Weight, Port, and Target have the standard 106 meaning as defined in RFC 2052. 107 108Example - Kadmin location information 109 110 These are DNS records for a Kerberos realm ASDF.COM. It has one Kad- 111 min server, kdc1.asdf.com. 112 113 _kadmin._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. 114 115Overview - Hostname/domain name to Kerberos realm mapping 116 117 Information on the mapping of DNS hostnames and domain names to Ker- 118 beros realms is stored using DNS TXT records [RFC 1035]. These 119 records have the following format. 120 121 Service.Name TTL Class TXT Realm 122 123 The Service field is always "_kerberos", and prefixes all entries of 124 this type. 125 126 The Name is a DNS hostname or domain name. This is explained in 127 greater detail below. 128 129 TTL, Class, and TXT have the standard DNS meaning as defined in RFC 130 1035. 131 132 The Realm is the data for the TXT RR, and consists simply of the Ker- 133 beros realm that corresponds to the Name specified. 134 135 When a Kerberos client wishes to utilize a host-specific service, it 136 will perform a DNS TXT query, using the hostname in the Name field of 137 the DNS query. If the record is not found, the first label of the 138 name is stripped and the query is retried. 139 140 Compliant implementations MUST query the full hostname and the most 141 specific domain name (the hostname with the first label removed). 142 Compliant implementations SHOULD try stripping all subsequent labels 143 until a match is found or the Name field is empty. 144 145Example - Hostname/domain name to Kerberos realm mapping 146 147 For the previously mentioned ASDF.COM realm and domain, some sample 148 records might be as follows: 149 150 _kerberos.asdf.com. IN TXT "ASDF.COM" 151 152Hornstein, Altman [Page 3] 153 154RFC DRAFT June 21, 1999 155 156 _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM" 157 _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM" 158 159 Let us suppose that in this case, a Kerberos client wishes to use a 160 Kerberized service on the host foo.asdf.com. It would first query: 161 162 _kerberos.foo.asdf.com. IN TXT 163 164 Finding no match, it would then query: 165 166 _kerberos.asdf.com. IN TXT 167 168 And find an answer of ASDF.COM. This would be the realm that 169 foo.asdf.com resides in. 170 171 If another Kerberos client wishes to use a Kerberized service on the 172 host salesserver.asdf.com, it would query: 173 174 _kerberos.salesserver.asdf.com IN TXT 175 176 And find an answer of SALES.ASDF.COM. 177 178Security considerations 179 180 As DNS is deployed today, it is an unsecure service. Thus the infor- 181 mation returned by it cannot be trusted. However, the use of DNS to 182 store this configuration information does not introduce any new secu- 183 rity risks to the Kerberos protocol. 184 185 Current practice is to use hostnames to indicate KDC hosts (stored in 186 some implementation-dependent location, but generally a local config 187 file). These hostnames are vulnerable to the standard set of DNS 188 attacks (denial of service, spoofed entries, etc). The design of the 189 Kerberos protocol limits attacks of this sort to denial of service. 190 However, the use of SRV records does not change this attack in any 191 way. They have the same vulnerabilities that already exist in the 192 common practice of using hostnames for KDC locations. 193 194 The same holds true for the TXT records used to indicate the domain 195 name to realm mapping. Current practice is to configure these map- 196 pings locally. But this again is vulnerable to spoofing via CNAME 197 records that point to hosts in other domains. This has the same 198 effect as a spoofed TXT record. 199 200 While the described protocol does not introduce any new security 201 risks to the best of our knowledge, implementations SHOULD provide a 202 way of specifying this information locally without the use of DNS. 203 However, to make this feature worthwhile a lack of any configuration 204 205Hornstein, Altman [Page 4] 206 207RFC DRAFT June 21, 1999 208 209 information on a client should be interpretted as permission to use 210 DNS. 211 212Expiration 213 214 This Internet-Draft expires on December 21, 1999. 215 216References 217 218 [RFC1510] 219 The Kerberos Network Authentication System; Kohl, Newman; Sep- 220 tember 1993. 221 222 [RFC1035] 223 Domain Names - Implementation and Specification; Mockapetris; 224 November 1987 225 226 [RFC2052] 227 A DNS RR for specifying the location of services (DNS SRV); Gul- 228 brandsen, Vixie; October 1996 229 230Authors' Addresses 231 232 Ken Hornstein 233 US Naval Research Laboratory 234 Bldg A-49, Room 2 235 4555 Overlook Avenue 236 Washington DC 20375 USA 237 238 Phone: +1 (202) 404-4765 239 EMail: kenh@cmf.nrl.navy.mil 240 241 Jeffrey Altman 242 The Kermit Project 243 Columbia University 244 612 West 115th Street #716 245 New York NY 10025-7799 USA 246 247 Phone: +1 (212) 854-1344 248 EMail: jaltman@columbia.edu 249 250Hornstein, Altman [Page 5] 251