crypto/heimdal-0.6.3/doc/standardisation/draft-ietf-cat-krb-dns-locate-02.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                             Ken Hornstein
   8 <draft-ietf-cat-krb-dns-locate-02.txt>                               NRL
   9 March 10, 2000                                            Jeffrey Altman
  10 Expires: September 10, 2000                          Columbia University
  11
  12
  13
  14           Distributing Kerberos KDC and Realm Information with DNS
  15
  16
  17 Status of this Memo
  18
  19    This document is an Internet-Draft and is in full conformance with
  20    all provisions of Section 10 of RFC2026.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups.  Note that
  24    other groups may also distribute working documents as Internet-
  25    Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six months
  28    and may be updated, replaced, or obsoleted by other documents at any
  29    time.  It is inappropriate to use Internet- Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html.
  37
  38    Distribution of this memo is unlimited.  It is filed as <draft-ietf-
  39    cat-krb-dns-locate-02.txt>, and expires on September 10, 2000.  Please
  40    send comments to the authors.
  41
  42 Abstract
  43
  44    Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto-
  45    col [RFC????] describe any mechanism for clients to learn critical
  46    configuration information necessary for proper operation of the pro-
  47    tocol.  Such information includes the location of Kerberos key dis-
  48    tribution centers or a mapping between DNS domains and Kerberos
  49    realms.
  50
  51    Current Kerberos implementations generally store such configuration
  52    information in a file on each client machine.  Experience has shown
  53    this method of storing configuration information presents problems
  54    with out-of-date information and scaling problems, especially when
  55
  56
  57
  58 Hornstein, Altman                                               [Page 1]
  59 \f
  60 RFC DRAFT                                                 March 10, 2000
  61
  62
  63    using cross-realm authentication.
  64
  65    This memo describes a method for using the Domain Name System
  66    [RFC1035] for storing such configuration information.  Specifically,
  67    methods for storing KDC location and hostname/domain name to realm
  68    mapping information are discussed.
  69
  70 DNS vs. Kerberos - Case Sensitivity of Realm Names
  71
  72    In Kerberos, realm names are case sensitive.  While it is strongly
  73    encouraged that all realm names be all upper case this recommendation
  74    has not been adopted by all sites.  Some sites use all lower case
  75    names and other use mixed case.  DNS on the other hand is case insen-
  76    sitive for queries but is case preserving for responses to TXT
  77    queries.  Since "MYREALM", "myrealm", and "MyRealm" are all different
  78    it is necessary that the DNS entries be distinguishable.
  79
  80    Since the recommend realm names are all upper case, we will not
  81    require any quoting to be applied to upper case names.  If the realm
  82    name contains lower case characters each character is to be quoted by
  83    a '=' character.  So "MyRealm" would be represented as "M=yR=e=a=l=m"
  84    and "myrealm" as "=m=y=r=e=a=l=m".  If the realm name contains the
  85    '=' character it will be represented as "==".
  86
  87
  88 Overview - KDC location information
  89
  90    KDC location information is to be stored using the DNS SRV RR [RFC
  91    2052].  The format of this RR is as follows:
  92
  93    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
  94
  95    The Service name for Kerberos is always "_kerberos".
  96
  97    The Proto can be either "_udp" or "_tcp".  If these records are to be
  98    used, a "_udp" record MUST be included.  If the Kerberos implementa-
  99    tion supports TCP transport, a "_tcp" record SHOULD be included.
 100
 101    The Realm is the Kerberos realm that this record corresponds to.
 102
 103    TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
 104    meaning as defined in RFC 2052.
 105
 106 Example - KDC location information
 107
 108    These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
 109    beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
 110    directed to kdc1.asdf.com first as per the specified priority.
 111
 112
 113
 114 Hornstein, Altman                                               [Page 2]
 115 \f
 116 RFC DRAFT                                                 March 10, 2000
 117
 118
 119    Weights are not used in these records.
 120
 121    _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
 122    _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
 123
 124 Overview - Kerberos password changing server location information
 125
 126    Kerberos password changing server [KERB-CHG] location is to be stored
 127    using the DNS SRV RR [RFC 2052].  The format of this RR is as fol-
 128    lows:
 129
 130    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
 131
 132    The Service name for the password server is always "_kpasswd".
 133
 134    The Proto MUST be "_udp".
 135
 136    The Realm is the Kerberos realm that this record corresponds to.
 137
 138    TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
 139    meaning as defined in RFC 2052.
 140
 141 Overview - Kerberos admin server location information
 142
 143    Kerberos admin location information is to be stored using the DNS SRV
 144    RR [RFC 2052].  The format of this RR is as follows:
 145
 146    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
 147
 148    The Service name for the admin server is always "_kerberos-adm".
 149
 150    The Proto can be either "_udp" or "_tcp".  If these records are to be
 151    used, a "_tcp" record MUST be included.  If the Kerberos admin imple-
 152    mentation supports UDP transport, a "_udp" record SHOULD be included.
 153
 154    The Realm is the Kerberos realm that this record corresponds to.
 155
 156    TTL, Class, SRV, Priority, Weight, Port, and Target have the standard
 157    meaning as defined in RFC 2052.
 158
 159    Note that there is no formal definition of a Kerberos admin protocol,
 160    so the use of this record is optional and implementation-dependent.
 161
 162 Example - Kerberos administrative server location information
 163
 164    These are DNS records for a Kerberos realm ASDF.COM.  It has one
 165    administrative server, kdc1.asdf.com.
 166
 167
 168
 169
 170 Hornstein, Altman                                               [Page 3]
 171 \f
 172 RFC DRAFT                                                 March 10, 2000
 173
 174
 175    _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 88 kdc1.asdf.com.
 176
 177 Overview - Hostname/domain name to Kerberos realm mapping
 178
 179    Information on the mapping of DNS hostnames and domain names to Ker-
 180    beros realms is stored using DNS TXT records [RFC 1035].  These
 181    records have the following format.
 182
 183    Service.Name TTL Class TXT Realm
 184
 185    The Service field is always "_kerberos", and prefixes all entries of
 186    this type.
 187
 188    The Name is a DNS hostname or domain name.  This is explained in
 189    greater detail below.
 190
 191    TTL, Class, and TXT have the standard DNS meaning as defined in RFC
 192    1035.
 193
 194    The Realm is the data for the TXT RR, and consists simply of the Ker-
 195    beros realm that corresponds to the Name specified.
 196
 197    When a Kerberos client wishes to utilize a host-specific service, it
 198    will perform a DNS TXT query, using the hostname in the Name field of
 199    the DNS query.  If the record is not found, the first label of the
 200    name is stripped and the query is retried.
 201
 202    Compliant implementations MUST query the full hostname and the most
 203    specific domain name (the hostname with the first label removed).
 204    Compliant implementations SHOULD try stripping all subsequent labels
 205    until a match is found or the Name field is empty.
 206
 207 Example - Hostname/domain name to Kerberos realm mapping
 208
 209    For the previously mentioned ASDF.COM realm and domain, some sample
 210    records might be as follows:
 211
 212    _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
 213    _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
 214    _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
 215
 216    Let us suppose that in this case, a Kerberos client wishes to use a
 217    Kerberized service on the host foo.asdf.com.  It would first query:
 218
 219    _kerberos.foo.asdf.com. IN TXT
 220
 221    Finding no match, it would then query:
 222
 223
 224
 225
 226 Hornstein, Altman                                               [Page 4]
 227 \f
 228 RFC DRAFT                                                 March 10, 2000
 229
 230
 231    _kerberos.asdf.com. IN TXT
 232
 233    And find an answer of ASDF.COM.  This would be the realm that
 234    foo.asdf.com resides in.
 235
 236    If another Kerberos client wishes to use a Kerberized service on the
 237    host salesserver.asdf.com, it would query:
 238
 239    _kerberos.salesserver.asdf.com IN TXT
 240
 241    And find an answer of SALES.ASDF.COM.
 242
 243 Security considerations
 244
 245    As DNS is deployed today, it is an unsecure service.  Thus the infor-
 246    mation returned by it cannot be trusted.
 247
 248    Current practice for REALM to KDC mapping is to use hostnames to
 249    indicate KDC hosts (stored in some implementation-dependent location,
 250    but generally a local config file).  These hostnames are vulnerable
 251    to the standard set of DNS attacks (denial of service, spoofed
 252    entries, etc).  The design of the Kerberos protocol limits attacks of
 253    this sort to denial of service.  However, the use of SRV records does
 254    not change this attack in any way.  They have the same vulnerabili-
 255    ties that already exist in the common practice of using hostnames for
 256    KDC locations.
 257
 258    Current practice for HOSTNAME to REALM mapping is to provide a local
 259    configuration of mappings of hostname or domain name to realm which
 260    are then mapped to KDCs.  But this again is vulnerable to spoofing
 261    via CNAME records that point to hosts in other domains.  This has the
 262    same effect as when a TXT record is spoofed.  In a realm with no
 263    cross-realm trusts this is a DoS attack.  However, when cross-realm
 264    trusts are used it is possible to redirect a client to use a comprom-
 265    ised realm.
 266
 267    This is not an exploit of the Kerberos protocol but of the Kerberos
 268    trust model.  The same can be done to any application that must
 269    resolve the hostname in order to determine which domain a non-FQDN
 270    belongs to.
 271
 272    Implementations SHOULD provide a way of specifying this information
 273    locally without the use of DNS.  However, to make this feature
 274    worthwhile a lack of any configuration information on a client should
 275    be interpretted as permission to use DNS.
 276
 277
 278
 279
 280
 281
 282 Hornstein, Altman                                               [Page 5]
 283 \f
 284 RFC DRAFT                                                 March 10, 2000
 285
 286
 287 Expiration
 288
 289    This Internet-Draft expires on September 10, 2000.
 290
 291 References
 292
 293
 294    [RFC1510]
 295         The Kerberos Network Authentication System; Kohl, Newman; Sep-
 296         tember 1993.
 297
 298    [RFC1035]
 299         Domain Names - Implementation and Specification; Mockapetris;
 300         November 1987
 301
 302    [RFC2782]
 303         A DNS RR for specifying the location of services (DNS SRV); Gul-
 304         brandsen, Vixie; Feburary 2000
 305
 306    [KERB-CHG]
 307         Kerberos Change Password Protocol; Horowitz;
 308         ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
 309         password-02.txt
 310
 311 Authors' Addresses
 312
 313    Ken Hornstein
 314    US Naval Research Laboratory
 315    Bldg A-49, Room 2
 316    4555 Overlook Avenue
 317    Washington DC  20375 USA
 318
 319    Phone: +1 (202) 404-4765
 320    EMail: kenh@cmf.nrl.navy.mil
 321
 322    Jeffrey Altman
 323    The Kermit Project
 324    Columbia University
 325    612 West 115th Street #716
 326    New York NY 10025-7799 USA
 327
 328    Phone: +1 (212) 854-1344
 329    EMail: jaltman@columbia.edu
 330
 331
 332
 333
 334
 335
 336
 337
 338 Hornstein, Altman                                               [Page 6]
 339 \f