draft-ietf-cat-krb-dns-locate-02.txt   [plain text]








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]