251 lines
9.2 KiB
Plaintext
251 lines
9.2 KiB
Plaintext
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]
|