INTERNET-DRAFT Ken Hornstein <draft-ietf-krb-wg-krb-dns-locate-03.txt> NRL July 29, 2002 Jeffrey Altman Expires: January 29, 2003 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- krb-wg-krb-dns-locate-03.txt>, and expires on January 29, 2003. 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 July 29, 2002 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 only one of the possible combinations of upper and lower case characters be used. This restriction may be lifted in the future as the DNS naming scheme is expanded to support non-ASCII names. 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", "_tcp", or "_tls._tcp". If these SRV records are to be used, a "_udp" record MUST be included. If the Kerberos implementation supports TCP transport, a "_tcp" record MUST be included. When using "_tcp" with "_kerberos", this indicates a "raw" TCP connection without any additional encapsulation. A "_tls._tcp" record MUST be specified for all Kerberos implementations that support communication with the KDC across TCP sockets encapsu- lated using TLS [RFC2246]. The Realm is the Kerberos realm that this record corresponds to. TTL, Class, SRV, Priority, Weight, and Target have the standard mean- ing as defined in RFC 2052. As per RFC 2052 the Port number should be the value assigned to "ker- beros" by the Internet Assigned Number Authority (88). Hornstein, Altman [Page 2]
RFC DRAFT July 29, 2002 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. _kerberos._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._tcp.ASDF.COM. IN SRV 1 0 88 kdc2.asdf.com. _kerberos._tls._tcp.ASDF.COM. IN SRV 0 0 88 kdc1.asdf.com. _kerberos._tls._tcp.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, and Target have the standard mean- ing as defined in RFC 2052. As per RFC 2052 the Port number should be the value assigned to "kpasswd" by the Internet Assigned Number Authority (464). 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. Hornstein, Altman [Page 3]
RFC DRAFT July 29, 2002 TTL, Class, SRV, Priority, Weight, and Target have the standard mean- ing as defined in RFC 2052. As per RFC 2052 the Port number should be the value assigned to "kerberos-adm" by the Internet Assigned Number Authority (749). 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. _kerberos-adm._tcp.ASDF.COM. IN SRV 0 0 749 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. Hornstein, Altman [Page 4]
RFC DRAFT July 29, 2002 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: _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 Hornstein, Altman [Page 5]
RFC DRAFT July 29, 2002 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. What this implies is that it is possible to cause a client to be authenticated to a host other than the one desired by the end user. In a single realm scenario a spoofed DNS response can cause a client to be redirected to an attacker's host, but the authentication would fail. However, in the cross-realm scenario an attacker who has administrative control over a realm that has a cross-realm trust established with the local realm, the attacker can redirect the client to a host for which valid credentials would be issued by the attacker's KDC. Since the credentials are valid there are no authen- tication failures and the client believes they are connected to the desired host. 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. Expiration This Internet-Draft expires on January 29, 2003. 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- Hornstein, Altman [Page 6]
RFC DRAFT July 29, 2002 password-02.txt [RFC2246] The TLS Protocol - Version 1.0 (TLS); Dierks, Allen; January 1999 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 7]
