summaryrefslogtreecommitdiffstats
path: root/crypto/heimdal/doc/standardisation/draft-ietf-krb-wg-krb-dns-locate-02.txt
diff options
context:
space:
mode:
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.txt339
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]
-
OpenPOWER on IntegriCloud