doc/standardisation/draft-ietf-cat-krb-dns-locate-00.txt

   1 INTERNET-DRAFT                                             Ken Hornstein
   2 <draft-ietf-cat-krb-dns-locate-00.txt>                               NRL
   3 June 21, 1999                                             Jeffrey Altman
   4 Expires: December 21, 1999                           Columbia University
   5
   6           Distributing Kerberos KDC and Realm Information with DNS
   7
   8 Status of this Memo
   9
  10    This document is an Internet-Draft and is in full conformance with
  11    all provisions of Section 10 of RFC2026.
  12
  13    Internet-Drafts are working documents of the Internet Engineering
  14    Task Force (IETF), its areas, and its working groups.  Note that
  15    other groups may also distribute working documents as Internet-
  16    Drafts.
  17
  18    Internet-Drafts are draft documents valid for a maximum of six months
  19    and may be updated, replaced, or obsoleted by other documents at any
  20    time.  It is inappropriate to use Internet- Drafts as reference
  21    material or to cite them other than as "work in progress."
  22
  23    The list of current Internet-Drafts can be accessed at
  24    http://www.ietf.org/ietf/1id-abstracts.txt
  25
  26    The list of Internet-Draft Shadow Directories can be accessed at
  27    http://www.ietf.org/shadow.html.
  28
  29    Distribution of this memo is unlimited.  It is filed as <draft-ietf-
  30    cat-krb-dns-locate-00.txt>, and expires on December 21, 1999.  Please
  31    send comments to the authors.
  32
  33 Abstract
  34
  35    Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
  36    col [RFC????] describe any mechanism for clients to learn critical
  37    configuration information necessary for proper operation of the pro-
  38    tocol.  Such information includes the location of Kerberos key dis-
  39    tribution centers or a mapping between DNS domains and Kerberos
  40    realms.
  41
  42    Current Kerberos implementations generally store such configuration
  43    information in a file on each client machine.  Experience has shown
  44    this method of storing configuration information presents problems
  45    with out-of-date information and scaling problems, especially when
  46
  47 Hornstein, Altman                                               [Page 1]
  48
  49 RFC DRAFT                                                  June 21, 1999
  50
  51    using cross-realm authentication.
  52
  53    This memo describes a method for using the Domain Name System
  54    [RFC1035] for storing such configuration information.  Specifically,
  55    methods for storing KDC location and hostname/domain name to realm
  56    mapping information are discussed.
  57
  58 Overview - KDC location information
  59
  60    KDC location information is to be stored using the DNS SRV RR [RFC
  61    2052].  The format of this RR is as follows:
  62
  63    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
  64
  65    The Service name for Kerberos is always "_kerberos".
  66
  67    The Proto can be either "_udp" or "_tcp".  If these records are to be
  68    used, a "_udp" record MUST be included.  If the Kerberos implementa-
  69    tion supports TCP transport, a "_tcp" record SHOULD be included.
  70
  71    The Realm is the Kerberos realm that this record corresponds to.
  72
  73    TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
  74    meaning as defined in RFC 2052.
  75
  76 Example - KDC location information
  77
  78    These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
  79    beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
  80    directed to kdc1.asdf.com first as per the specified priority.
  81    Weights are not used in these records.
  82
  83    _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
  84    _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
  85
  86 Overview - KAdmin location information
  87
  88    Kadmin location information is to be stored using the DNS SRV RR [RFC
  89    2052].  The format of this RR is as follows:
  90
  91    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
  92
  93    The Service name for Kadmin is always "_kadmin".
  94
  95    The Proto can be either "_udp" or "_tcp".  If these records are to be
  96    used, a "_tcp" record MUST be included.  If the Kadmin implementation
  97    supports UDP transport, a "_udp" record SHOULD be included.
  98
  99 Hornstein, Altman                                               [Page 2]
 100
 101 RFC DRAFT                                                  June 21, 1999
 102
 103    The Realm is the Kerberos realm that this record corresponds to.
 104
 105    TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
 106    meaning as defined in RFC 2052.
 107
 108 Example - Kadmin location information
 109
 110    These are DNS records for a Kerberos realm ASDF.COM.  It has one Kad-
 111    min server, kdc1.asdf.com.
 112
 113    _kadmin._tcp.ASDF.COM.  IN      SRV     0 0 88 kdc1.asdf.com.
 114
 115 Overview - Hostname/domain name to Kerberos realm mapping
 116
 117    Information on the mapping of DNS hostnames and domain names to Ker-
 118    beros realms is stored using DNS TXT records [RFC 1035].  These
 119    records have the following format.
 120
 121    Service.Name TTL Class TXT Realm
 122
 123    The Service field is always "_kerberos", and prefixes all entries of
 124    this type.
 125
 126    The Name is a DNS hostname or domain name.  This is explained in
 127    greater detail below.
 128
 129    TTL, Class, and TXT have the standard DNS meaning as defined in RFC
 130    1035.
 131
 132    The Realm is the data for the TXT RR, and consists simply of the Ker-
 133    beros realm that corresponds to the Name specified.
 134
 135    When a Kerberos client wishes to utilize a host-specific service, it
 136    will perform a DNS TXT query, using the hostname in the Name field of
 137    the DNS query.  If the record is not found, the first label of the
 138    name is stripped and the query is retried.
 139
 140    Compliant implementations MUST query the full hostname and the most
 141    specific domain name (the hostname with the first label removed).
 142    Compliant implementations SHOULD try stripping all subsequent labels
 143    until a match is found or the Name field is empty.
 144
 145 Example - Hostname/domain name to Kerberos realm mapping
 146
 147    For the previously mentioned ASDF.COM realm and domain, some sample
 148    records might be as follows:
 149
 150    _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
 151
 152 Hornstein, Altman                                               [Page 3]
 153
 154 RFC DRAFT                                                  June 21, 1999
 155
 156    _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
 157    _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
 158
 159    Let us suppose that in this case, a Kerberos client wishes to use a
 160    Kerberized service on the host foo.asdf.com.  It would first query:
 161
 162    _kerberos.foo.asdf.com. IN TXT
 163
 164    Finding no match, it would then query:
 165
 166    _kerberos.asdf.com. IN TXT
 167
 168    And find an answer of ASDF.COM.  This would be the realm that
 169    foo.asdf.com resides in.
 170
 171    If another Kerberos client wishes to use a Kerberized service on the
 172    host salesserver.asdf.com, it would query:
 173
 174    _kerberos.salesserver.asdf.com IN TXT
 175
 176    And find an answer of SALES.ASDF.COM.
 177
 178 Security considerations
 179
 180    As DNS is deployed today, it is an unsecure service.  Thus the infor-
 181    mation returned by it cannot be trusted.  However, the use of DNS to
 182    store this configuration information does not introduce any new secu-
 183    rity risks to the Kerberos protocol.
 184
 185    Current practice is to use hostnames to indicate KDC hosts (stored in
 186    some implementation-dependent location, but generally a local config
 187    file).  These hostnames are vulnerable to the standard set of DNS
 188    attacks (denial of service, spoofed entries, etc).  The design of the
 189    Kerberos protocol limits attacks of this sort to denial of service.
 190    However, the use of SRV records does not change this attack in any
 191    way.  They have the same vulnerabilities that already exist in the
 192    common practice of using hostnames for KDC locations.
 193
 194    The same holds true for the TXT records used to indicate the domain
 195    name to realm mapping.  Current practice is to configure these map-
 196    pings locally.  But this again is vulnerable to spoofing via CNAME
 197    records that point to hosts in other domains.  This has the same
 198    effect as a spoofed TXT record.
 199
 200    While the described protocol does not introduce any new security
 201    risks to the best of our knowledge, implementations SHOULD provide a
 202    way of specifying this information locally without the use of DNS.
 203    However, to make this feature worthwhile a lack of any configuration
 204
 205 Hornstein, Altman                                               [Page 4]
 206
 207 RFC DRAFT                                                  June 21, 1999
 208
 209    information on a client should be interpretted as permission to use
 210    DNS.
 211
 212 Expiration
 213
 214    This Internet-Draft expires on December 21, 1999.
 215
 216 References
 217
 218    [RFC1510]
 219         The Kerberos Network Authentication System; Kohl, Newman; Sep-
 220         tember 1993.
 221
 222    [RFC1035]
 223         Domain Names - Implementation and Specification; Mockapetris;
 224         November 1987
 225
 226    [RFC2052]
 227         A DNS RR for specifying the location of services (DNS SRV); Gul-
 228         brandsen, Vixie; October 1996
 229
 230 Authors' Addresses
 231
 232    Ken Hornstein
 233    US Naval Research Laboratory
 234    Bldg A-49, Room 2
 235    4555 Overlook Avenue
 236    Washington DC  20375 USA
 237
 238    Phone: +1 (202) 404-4765
 239    EMail: kenh@cmf.nrl.navy.mil
 240
 241    Jeffrey Altman
 242    The Kermit Project
 243    Columbia University
 244    612 West 115th Street #716
 245    New York NY 10025-7799 USA
 246
 247    Phone: +1 (212) 854-1344
 248    EMail: jaltman@columbia.edu
 249
 250 Hornstein, Altman                                               [Page 5]