340 lines
11 KiB
Plaintext
340 lines
11 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
INTERNET-DRAFT Ken Hornstein
|
||
<draft-ietf-cat-krb-dns-locate-02.txt> NRL
|
||
March 10, 2000 Jeffrey Altman
|
||
Expires: September 10, 2000 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-02.txt>, and expires on September 10, 2000. 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 March 10, 2000
|
||
|
||
|
||
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.
|
||
|
||
DNS vs. Kerberos - Case Sensitivity of Realm Names
|
||
|
||
In Kerberos, realm names are case sensitive. While it is strongly
|
||
encouraged that all realm names be all upper case this recommendation
|
||
has not been adopted by all sites. Some sites use all lower case
|
||
names and other use mixed case. DNS on the other hand is case insen-
|
||
sitive for queries but is case preserving for responses to TXT
|
||
queries. Since "MYREALM", "myrealm", and "MyRealm" are all different
|
||
it is necessary that the DNS entries be distinguishable.
|
||
|
||
Since the recommend realm names are all upper case, we will not
|
||
require any quoting to be applied to upper case names. If the realm
|
||
name contains lower case characters each character is to be quoted by
|
||
a '=' character. So "MyRealm" would be represented as "M=yR=e=a=l=m"
|
||
and "myrealm" as "=m=y=r=e=a=l=m". If the realm name contains the
|
||
'=' character it will be represented as "==".
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
Hornstein, Altman [Page 2]
|
||
|
||
RFC DRAFT March 10, 2000
|
||
|
||
|
||
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 - Kerberos password changing server location information
|
||
|
||
Kerberos password changing server [KERB-CHG] location is to be stored
|
||
using the DNS SRV RR [RFC 2052]. The format of this RR is as fol-
|
||
lows:
|
||
|
||
Service.Proto.Realm TTL Class SRV Priority Weight Port Target
|
||
|
||
The Service name for the password server is always "_kpasswd".
|
||
|
||
The Proto MUST be "_udp".
|
||
|
||
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.
|
||
|
||
Overview - Kerberos admin server location information
|
||
|
||
Kerberos admin 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 the admin server is always "_kerberos-adm".
|
||
|
||
The Proto can be either "_udp" or "_tcp". If these records are to be
|
||
used, a "_tcp" record MUST be included. If the Kerberos admin imple-
|
||
mentation supports UDP transport, a "_udp" 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.
|
||
|
||
Note that there is no formal definition of a Kerberos admin protocol,
|
||
so the use of this record is optional and implementation-dependent.
|
||
|
||
Example - Kerberos administrative server location information
|
||
|
||
These are DNS records for a Kerberos realm ASDF.COM. It has one
|
||
administrative server, kdc1.asdf.com.
|
||
|
||
|
||
|
||
|
||
Hornstein, Altman [Page 3]
|
||
|
||
RFC DRAFT March 10, 2000
|
||
|
||
|
||
_kerberos-adm._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"
|
||
_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:
|
||
|
||
|
||
|
||
|
||
Hornstein, Altman [Page 4]
|
||
|
||
RFC DRAFT March 10, 2000
|
||
|
||
|
||
_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.
|
||
|
||
Current practice for REALM to KDC mapping 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 vulnerabili-
|
||
ties that already exist in the common practice of using hostnames for
|
||
KDC locations.
|
||
|
||
Current practice for HOSTNAME to REALM mapping is to provide a local
|
||
configuration of mappings of hostname or domain name to realm which
|
||
are then mapped to KDCs. But this again is vulnerable to spoofing
|
||
via CNAME records that point to hosts in other domains. This has the
|
||
same effect as when a TXT record is spoofed. In a realm with no
|
||
cross-realm trusts this is a DoS attack. However, when cross-realm
|
||
trusts are used it is possible to redirect a client to use a comprom-
|
||
ised realm.
|
||
|
||
This is not an exploit of the Kerberos protocol but of the Kerberos
|
||
trust model. The same can be done to any application that must
|
||
resolve the hostname in order to determine which domain a non-FQDN
|
||
belongs to.
|
||
|
||
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 information on a client should
|
||
be interpretted as permission to use DNS.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hornstein, Altman [Page 5]
|
||
|
||
RFC DRAFT March 10, 2000
|
||
|
||
|
||
Expiration
|
||
|
||
This Internet-Draft expires on September 10, 2000.
|
||
|
||
References
|
||
|
||
|
||
[RFC1510]
|
||
The Kerberos Network Authentication System; Kohl, Newman; Sep-
|
||
tember 1993.
|
||
|
||
[RFC1035]
|
||
Domain Names - Implementation and Specification; Mockapetris;
|
||
November 1987
|
||
|
||
[RFC2782]
|
||
A DNS RR for specifying the location of services (DNS SRV); Gul-
|
||
brandsen, Vixie; Feburary 2000
|
||
|
||
[KERB-CHG]
|
||
Kerberos Change Password Protocol; Horowitz;
|
||
ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
|
||
password-02.txt
|
||
|
||
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 6]
|
||
|