diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt new file mode 100644 index 0000000..e76a0e4 --- /dev/null +++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt @@ -0,0 +1,250 @@ +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] |
