7
INTERNET-DRAFT Ken Hornstein
8
<draft-ietf-cat-krb-dns-locate-02.txt> NRL
9
March 10, 2000 Jeffrey Altman
10
Expires: September 10, 2000 Columbia University
14
Distributing Kerberos KDC and Realm Information with DNS
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-
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
cat-krb-dns-locate-02.txt>, and expires on September 10, 2000. Please
40
send comments to the authors.
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
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]
60
RFC DRAFT March 10, 2000
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 the DNS entries be distinguishable.
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 "==".
88
Overview - KDC location information
90
KDC location information is to be stored using the DNS SRV RR [RFC
91
2052]. The format of this RR is as follows:
93
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
95
The Service name for Kerberos is always "_kerberos".
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.
101
The Realm is the Kerberos realm that this record corresponds to.
103
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
104
meaning as defined in RFC 2052.
106
Example - KDC location information
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.
114
Hornstein, Altman [Page 2]
116
RFC DRAFT March 10, 2000
119
Weights are not used in these records.
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.
124
Overview - Kerberos password changing server location information
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-
130
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
132
The Service name for the password server is always "_kpasswd".
134
The Proto MUST be "_udp".
136
The Realm is the Kerberos realm that this record corresponds to.
138
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
139
meaning as defined in RFC 2052.
141
Overview - Kerberos admin server location information
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:
146
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
148
The Service name for the admin server is always "_kerberos-adm".
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.
154
The Realm is the Kerberos realm that this record corresponds to.
156
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
157
meaning as defined in RFC 2052.
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.
162
Example - Kerberos administrative server location information
164
These are DNS records for a Kerberos realm ASDF.COM. It has one
165
administrative server, kdc1.asdf.com.
170
Hornstein, Altman [Page 3]
172
RFC DRAFT March 10, 2000
175
_kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
177
Overview - Hostname/domain name to Kerberos realm mapping
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.
183
Service.Name TTL Class TXT Realm
185
The Service field is always "_kerberos", and prefixes all entries of
188
The Name is a DNS hostname or domain name. This is explained in
189
greater detail below.
191
TTL, Class, and TXT have the standard DNS meaning as defined in RFC
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.
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.
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.
207
Example - Hostname/domain name to Kerberos realm mapping
209
For the previously mentioned ASDF.COM realm and domain, some sample
210
records might be as follows:
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"
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:
219
_kerberos.foo.asdf.com. IN TXT
221
Finding no match, it would then query:
226
Hornstein, Altman [Page 4]
228
RFC DRAFT March 10, 2000
231
_kerberos.asdf.com. IN TXT
233
And find an answer of ASDF.COM. This would be the realm that
234
foo.asdf.com resides in.
236
If another Kerberos client wishes to use a Kerberized service on the
237
host salesserver.asdf.com, it would query:
239
_kerberos.salesserver.asdf.com IN TXT
241
And find an answer of SALES.ASDF.COM.
243
Security considerations
245
As DNS is deployed today, it is an unsecure service. Thus the infor-
246
mation returned by it cannot be trusted.
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
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-
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
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.
282
Hornstein, Altman [Page 5]
284
RFC DRAFT March 10, 2000
289
This Internet-Draft expires on September 10, 2000.
295
The Kerberos Network Authentication System; Kohl, Newman; Sep-
299
Domain Names - Implementation and Specification; Mockapetris;
303
A DNS RR for specifying the location of services (DNS SRV); Gul-
304
brandsen, Vixie; Feburary 2000
307
Kerberos Change Password Protocol; Horowitz;
308
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
314
US Naval Research Laboratory
317
Washington DC 20375 USA
319
Phone: +1 (202) 404-4765
320
EMail: kenh@cmf.nrl.navy.mil
325
612 West 115th Street #716
326
New York NY 10025-7799 USA
328
Phone: +1 (212) 854-1344
329
EMail: jaltman@columbia.edu
338
Hornstein, Altman [Page 6]
added
removed
doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt
