diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt | 339 |
1 files changed, 0 insertions, 339 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt b/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt deleted file mode 100644 index a6dec9d..0000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -INTERNET-DRAFT Ken Hornstein -<draft-ietf-krb-wg-krb-dns-locate-02.txt> 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 <draft-ietf- - krb-wg-krb-dns-locate-02.txt>, 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] - |
