diff --git a/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt b/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt new file mode 100644 index 000000000..a6dec9d1e --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt @@ -0,0 +1,339 @@ + + + + + + +INTERNET-DRAFT Ken Hornstein + NRL +February 28, 2001 Jeffrey Altman +Expires: August 28, 2001 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 , and expires on August 28, 2001. + 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 February 28, 2001 + + + 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" 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, 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). + +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. + + + + +Hornstein, Altman [Page 2] + +RFC DRAFT February 28, 2001 + + + _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, 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. + + 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. + + + + + +Hornstein, Altman [Page 3] + +RFC DRAFT February 28, 2001 + + +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. + +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: + + + +Hornstein, Altman [Page 4] + +RFC DRAFT February 28, 2001 + + + _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 + 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 + + + +Hornstein, Altman [Page 5] + +RFC DRAFT February 28, 2001 + + + be interpretted as permission to use DNS. + +Expiration + + This Internet-Draft expires on August 28, 2001. + +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] +