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