draft-ietf-cat-krb-dns-locate-00.txt [plain text]
INTERNET-DRAFT Ken Hornstein
<draft-ietf-cat-krb-dns-locate-00.txt> NRL
June 21, 1999 Jeffrey Altman
Expires: December 21, 1999 Columbia University
Distributing Kerberos KDC and Realm Information with DNS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. It is filed as <draft-ietf-
cat-krb-dns-locate-00.txt>, and expires on December 21, 1999. Please
send comments to the authors.
Abstract
Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
col [RFC????] describe any mechanism for clients to learn critical
configuration information necessary for proper operation of the pro-
tocol. Such information includes the location of Kerberos key dis-
tribution centers or a mapping between DNS domains and Kerberos
realms.
Current Kerberos implementations generally store such configuration
information in a file on each client machine. Experience has shown
this method of storing configuration information presents problems
with out-of-date information and scaling problems, especially when
Hornstein, Altman [Page 1]
RFC DRAFT June 21, 1999
using cross-realm authentication.
This memo describes a method for using the Domain Name System
[RFC1035] for storing such configuration information. Specifically,
methods for storing KDC location and hostname/domain name to realm
mapping information are discussed.
Overview - KDC location information
KDC location information is to be stored using the DNS SRV RR [RFC
2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kerberos is always "_kerberos".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_udp" record MUST be included. If the Kerberos implementa-
tion supports TCP transport, a "_tcp" record SHOULD be included.
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
meaning as defined in RFC 2052.
Example - KDC location information
These are DNS records for a Kerberos realm ASDF.COM. It has two Ker-
beros servers, kdc1.asdf.com and kdc2.asdf.com. Queries should be
directed to kdc1.asdf.com first as per the specified priority.
Weights are not used in these records.
_kerberos._udp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
_kerberos._udp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com.
Overview - KAdmin location information
Kadmin location information is to be stored using the DNS SRV RR [RFC
2052]. The format of this RR is as follows:
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
The Service name for Kadmin is always "_kadmin".
The Proto can be either "_udp" or "_tcp". If these records are to be
used, a "_tcp" record MUST be included. If the Kadmin implementation
supports UDP transport, a "_udp" record SHOULD be included.
Hornstein, Altman [Page 2]
RFC DRAFT June 21, 1999
The Realm is the Kerberos realm that this record corresponds to.
TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
meaning as defined in RFC 2052.
Example - Kadmin location information
These are DNS records for a Kerberos realm ASDF.COM. It has one Kad-
min server, kdc1.asdf.com.
_kadmin._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com.
Overview - Hostname/domain name to Kerberos realm mapping
Information on the mapping of DNS hostnames and domain names to Ker-
beros realms is stored using DNS TXT records [RFC 1035]. These
records have the following format.
Service.Name TTL Class TXT Realm
The Service field is always "_kerberos", and prefixes all entries of
this type.
The Name is a DNS hostname or domain name. This is explained in
greater detail below.
TTL, Class, and TXT have the standard DNS meaning as defined in RFC
1035.
The Realm is the data for the TXT RR, and consists simply of the Ker-
beros realm that corresponds to the Name specified.
When a Kerberos client wishes to utilize a host-specific service, it
will perform a DNS TXT query, using the hostname in the Name field of
the DNS query. If the record is not found, the first label of the
name is stripped and the query is retried.
Compliant implementations MUST query the full hostname and the most
specific domain name (the hostname with the first label removed).
Compliant implementations SHOULD try stripping all subsequent labels
until a match is found or the Name field is empty.
Example - Hostname/domain name to Kerberos realm mapping
For the previously mentioned ASDF.COM realm and domain, some sample
records might be as follows:
_kerberos.asdf.com. IN TXT "ASDF.COM"
Hornstein, Altman [Page 3]
RFC DRAFT June 21, 1999
_kerberos.mrkserver.asdf.com. IN TXT "MARKETING.ASDF.COM"
_kerberos.salesserver.asdf.com. IN TXT "SALES.ASDF.COM"
Let us suppose that in this case, a Kerberos client wishes to use a
Kerberized service on the host foo.asdf.com. It would first query:
_kerberos.foo.asdf.com. IN TXT
Finding no match, it would then query:
_kerberos.asdf.com. IN TXT
And find an answer of ASDF.COM. This would be the realm that
foo.asdf.com resides in.
If another Kerberos client wishes to use a Kerberized service on the
host salesserver.asdf.com, it would query:
_kerberos.salesserver.asdf.com IN TXT
And find an answer of SALES.ASDF.COM.
Security considerations
As DNS is deployed today, it is an unsecure service. Thus the infor-
mation returned by it cannot be trusted. However, the use of DNS to
store this configuration information does not introduce any new secu-
rity risks to the Kerberos protocol.
Current practice is to use hostnames to indicate KDC hosts (stored in
some implementation-dependent location, but generally a local config
file). These hostnames are vulnerable to the standard set of DNS
attacks (denial of service, spoofed entries, etc). The design of the
Kerberos protocol limits attacks of this sort to denial of service.
However, the use of SRV records does not change this attack in any
way. They have the same vulnerabilities that already exist in the
common practice of using hostnames for KDC locations.
The same holds true for the TXT records used to indicate the domain
name to realm mapping. Current practice is to configure these map-
pings locally. But this again is vulnerable to spoofing via CNAME
records that point to hosts in other domains. This has the same
effect as a spoofed TXT record.
While the described protocol does not introduce any new security
risks to the best of our knowledge, implementations SHOULD provide a
way of specifying this information locally without the use of DNS.
However, to make this feature worthwhile a lack of any configuration
Hornstein, Altman [Page 4]
RFC DRAFT June 21, 1999
information on a client should be interpretted as permission to use
DNS.
Expiration
This Internet-Draft expires on December 21, 1999.
References
[RFC1510]
The Kerberos Network Authentication System; Kohl, Newman; Sep-
tember 1993.
[RFC1035]
Domain Names - Implementation and Specification; Mockapetris;
November 1987
[RFC2052]
A DNS RR for specifying the location of services (DNS SRV); Gul-
brandsen, Vixie; October 1996
Authors' Addresses
Ken Hornstein
US Naval Research Laboratory
Bldg A-49, Room 2
4555 Overlook Avenue
Washington DC 20375 USA
Phone: +1 (202) 404-4765
EMail: kenh@cmf.nrl.navy.mil
Jeffrey Altman
The Kermit Project
Columbia University
612 West 115th Street #716
New York NY 10025-7799 USA
Phone: +1 (212) 854-1344
EMail: jaltman@columbia.edu
Hornstein, Altman [Page 5]