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, 0 insertions, 250 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 deleted file mode 100644 index e76a0e4..0000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt +++ /dev/null @@ -1,250 +0,0 @@ -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] |
