| blob | 24538254868bc623d26c08465d0012202d56877b |
7 INTERNET-DRAFT Ken Hornstein
8 <draft-ietf-krb-wg-krb-dns-locate-03.txt> NRL
9 July 29, 2002 Jeffrey Altman
10 Expires: January 29, 2003 Columbia University
14 Distributing Kerberos KDC and Realm Information with DNS
17 Status of this Memo
19 This document is an Internet-Draft and is in full conformance with
20 all provisions of Section 10 of RFC2026.
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.
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."
32 The list of current Internet-Drafts can be accessed at
33 http://www.ietf.org/ietf/1id-abstracts.txt
35 The list of Internet-Draft Shadow Directories can be accessed at
36 http://www.ietf.org/shadow.html.
38 Distribution of this memo is unlimited. It is filed as <draft-ietf-
39 krb-wg-krb-dns-locate-03.txt>, and expires on January 29, 2003.
40 Please send comments to the authors.
42 Abstract
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.
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
58 Hornstein, Altman [Page 1]
59 \f
60 RFC DRAFT July 29, 2002
63 using cross-realm authentication.
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.
70 DNS vs. Kerberos - Case Sensitivity of Realm Names
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.
83 Overview - KDC location information
85 KDC location information is to be stored using the DNS SRV RR [RFC
86 2052]. The format of this RR is as follows:
88 Service.Proto.Realm TTL Class SRV Priority Weight Port Target
90 The Service name for Kerberos is always "_kerberos".
92 The Proto can be either "_udp", "_tcp", or "_tls._tcp". If these SRV
93 records are to be used, a "_udp" record MUST be included. If the
94 Kerberos implementation supports TCP transport, a "_tcp" record MUST
95 be included. When using "_tcp" with "_kerberos", this indicates a
96 "raw" TCP connection without any additional encapsulation. A
97 "_tls._tcp" record MUST be specified for all Kerberos implementations
98 that support communication with the KDC across TCP sockets encapsu-
99 lated using TLS [RFC2246].
101 The Realm is the Kerberos realm that this record corresponds to.
103 TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
104 ing as defined in RFC 2052.
106 As per RFC 2052 the Port number should be the value assigned to "ker-
107 beros" by the Internet Assigned Number Authority (88).
114 Hornstein, Altman [Page 2]
115 \f
116 RFC DRAFT July 29, 2002
119 Example - KDC location information
121 These are DNS records for a Kerberos realm ASDF.COM. It has two Ker-
122 beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be
123 directed to kdc1.asdf.com first as per the specified priority.
124 Weights are not used in these records.
126 _kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
127 _kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
128 _kerberos._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
129 _kerberos._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
130 _kerberos._tls._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
131 _kerberos._tls._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
133 Overview - Kerberos password changing server location information
135 Kerberos password changing server [KERB-CHG] location is to be stored
136 using the DNS SRV RR [RFC 2052]. The format of this RR is as fol-
137 lows:
139 Service.Proto.Realm TTL Class SRV Priority Weight Port Target
141 The Service name for the password server is always "_kpasswd".
143 The Proto MUST be "_udp".
145 The Realm is the Kerberos realm that this record corresponds to.
147 TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
148 ing as defined in RFC 2052.
150 As per RFC 2052 the Port number should be the value assigned to
151 "kpasswd" by the Internet Assigned Number Authority (464).
153 Overview - Kerberos admin server location information
155 Kerberos admin location information is to be stored using the DNS SRV
156 RR [RFC 2052]. The format of this RR is as follows:
158 Service.Proto.Realm TTL Class SRV Priority Weight Port Target
160 The Service name for the admin server is always "_kerberos-adm".
162 The Proto can be either "_udp" or "_tcp". If these records are to be
163 used, a "_tcp" record MUST be included. If the Kerberos admin imple-
164 mentation supports UDP transport, a "_udp" record SHOULD be included.
166 The Realm is the Kerberos realm that this record corresponds to.
170 Hornstein, Altman [Page 3]
171 \f
172 RFC DRAFT July 29, 2002
175 TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
176 ing as defined in RFC 2052.
178 As per RFC 2052 the Port number should be the value assigned to
179 "kerberos-adm" by the Internet Assigned Number Authority (749).
181 Note that there is no formal definition of a Kerberos admin protocol,
182 so the use of this record is optional and implementation-dependent.
184 Example - Kerberos administrative server location information
186 These are DNS records for a Kerberos realm ASDF.COM. It has one
187 administrative server, kdc1.asdf.com.
189 _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 749 kdc1.asdf.com.
191 Overview - Hostname/domain name to Kerberos realm mapping
193 Information on the mapping of DNS hostnames and domain names to Ker-
194 beros realms is stored using DNS TXT records [RFC 1035]. These
195 records have the following format.
197 Service.Name TTL Class TXT Realm
199 The Service field is always "_kerberos", and prefixes all entries of
200 this type.
202 The Name is a DNS hostname or domain name. This is explained in
203 greater detail below.
205 TTL, Class, and TXT have the standard DNS meaning as defined in RFC
206 1035.
208 The Realm is the data for the TXT RR, and consists simply of the Ker-
209 beros realm that corresponds to the Name specified.
211 When a Kerberos client wishes to utilize a host-specific service, it
212 will perform a DNS TXT query, using the hostname in the Name field of
213 the DNS query. If the record is not found, the first label of the
214 name is stripped and the query is retried.
216 Compliant implementations MUST query the full hostname and the most
217 specific domain name (the hostname with the first label removed).
218 Compliant implementations SHOULD try stripping all subsequent labels
219 until a match is found or the Name field is empty.
226 Hornstein, Altman [Page 4]
227 \f
228 RFC DRAFT July 29, 2002
231 Example - Hostname/domain name to Kerberos realm mapping
233 For the previously mentioned ASDF.COM realm and domain, some sample
234 records might be as follows:
236 _kerberos.asdf.com. IN TXT "ASDF.COM"
237 _kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM"
238 _kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM"
240 Let us suppose that in this case, a Kerberos client wishes to use a
241 Kerberized service on the host foo.asdf.com. It would first query:
243 _kerberos.foo.asdf.com. IN TXT
245 Finding no match, it would then query:
247 _kerberos.asdf.com. IN TXT
249 And find an answer of ASDF.COM. This would be the realm that
250 foo.asdf.com resides in.
252 If another Kerberos client wishes to use a Kerberized service on the
253 host salesserver.asdf.com, it would query:
255 _kerberos.salesserver.asdf.com IN TXT
257 And find an answer of SALES.ASDF.COM.
259 Security considerations
261 As DNS is deployed today, it is an unsecure service. Thus the infor-
262 mation returned by it cannot be trusted.
264 Current practice for REALM to KDC mapping is to use hostnames to
265 indicate KDC hosts (stored in some implementation-dependent location,
266 but generally a local config file). These hostnames are vulnerable
267 to the standard set of DNS attacks (denial of service, spoofed
268 entries, etc). The design of the Kerberos protocol limits attacks of
269 this sort to denial of service. However, the use of SRV records does
270 not change this attack in any way. They have the same vulnerabili-
271 ties that already exist in the common practice of using hostnames for
272 KDC locations.
274 Current practice for HOSTNAME to REALM mapping is to provide a local
275 configuration of mappings of hostname or domain name to realm which
276 are then mapped to KDCs. But this again is vulnerable to spoofing
277 via CNAME records that point to hosts in other domains. This has the
278 same effect as when a TXT record is spoofed. In a realm with no
282 Hornstein, Altman [Page 5]
283 \f
284 RFC DRAFT July 29, 2002
287 cross-realm trusts this is a DoS attack. However, when cross-realm
288 trusts are used it is possible to redirect a client to use a comprom-
289 ised realm.
291 What this implies is that it is possible to cause a client to be
292 authenticated to a host other than the one desired by the end user.
293 In a single realm scenario a spoofed DNS response can cause a client
294 to be redirected to an attacker's host, but the authentication would
295 fail. However, in the cross-realm scenario an attacker who has
296 administrative control over a realm that has a cross-realm trust
297 established with the local realm, the attacker can redirect the
298 client to a host for which valid credentials would be issued by the
299 attacker's KDC. Since the credentials are valid there are no authen-
300 tication failures and the client believes they are connected to the
301 desired host.
303 This is not an exploit of the Kerberos protocol but of the Kerberos
304 trust model. The same can be done to any application that must
305 resolve the hostname in order to determine which domain a non-FQDN
306 belongs to.
308 Implementations SHOULD provide a way of specifying this information
309 locally without the use of DNS. However, to make this feature
310 worthwhile a lack of any configuration information on a client should
311 be interpretted as permission to use DNS.
313 Expiration
315 This Internet-Draft expires on January 29, 2003.
317 References
320 [RFC1510]
321 The Kerberos Network Authentication System; Kohl, Newman; Sep-
322 tember 1993.
324 [RFC1035]
325 Domain Names - Implementation and Specification; Mockapetris;
326 November 1987
328 [RFC2782]
329 A DNS RR for specifying the location of services (DNS SRV); Gul-
330 brandsen, Vixie; Feburary 2000
332 [KERB-CHG]
333 Kerberos Change Password Protocol; Horowitz;
334 ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
338 Hornstein, Altman [Page 6]
339 \f
340 RFC DRAFT July 29, 2002
343 password-02.txt
345 [RFC2246]
346 The TLS Protocol - Version 1.0 (TLS); Dierks, Allen; January
347 1999
349 Authors' Addresses
351 Ken Hornstein
352 US Naval Research Laboratory
353 Bldg A-49, Room 2
354 4555 Overlook Avenue
355 Washington DC 20375 USA
357 Phone: +1 (202) 404-4765
358 EMail: kenh@cmf.nrl.navy.mil
360 Jeffrey Altman
361 The Kermit Project
362 Columbia University
363 612 West 115th Street #716
364 New York NY 10025-7799 USA
366 Phone: +1 (212) 854-1344
367 EMail: jaltman@columbia.edu
394 Hornstein, Altman [Page 7]
395 \f