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

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                             Ken Hornstein
   8 <draft-ietf-krb-wg-krb-dns-locate-02.txt>                            NRL
   9 February 28, 2001                                         Jeffrey Altman
  10 Expires: August 28, 2001                             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    krb-wg-krb-dns-locate-02.txt>, and expires on August 28, 2001.
  40    Please 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                                              February 28, 2001
  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 only one of the possible combinations of upper
  79    and lower case characters be used.  This restriction may be lifted in
  80    the future as the DNS naming scheme is expanded to support non-ASCII
  81    names.
  82
  83 Overview - KDC location information
  84
  85    KDC location information is to be stored using the DNS SRV RR [RFC
  86    2052].  The format of this RR is as follows:
  87
  88    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
  89
  90    The Service name for Kerberos is always "_kerberos".
  91
  92    The Proto can be either "_udp" or "_tcp".  If these records are to be
  93    used, a "_udp" record MUST be included.  If the Kerberos implementa-
  94    tion supports TCP transport, a "_tcp" record SHOULD be included.
  95
  96    The Realm is the Kerberos realm that this record corresponds to.
  97
  98    TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
  99    ing as defined in RFC 2052.
 100
 101    As per RFC 2052 the Port number should be the value assigned to "ker-
 102    beros" by the Internet Assigned Number Authority (88).
 103
 104 Example - KDC location information
 105
 106    These are DNS records for a Kerberos realm ASDF.COM.  It has two Ker-
 107    beros servers, kdc1.asdf.com and kdc2.asdf.com.  Queries should be
 108    directed to kdc1.asdf.com first as per the specified priority.
 109    Weights are not used in these records.
 110
 111
 112
 113
 114 Hornstein, Altman                                               [Page 2]
 115 \f
 116 RFC DRAFT                                              February 28, 2001
 117
 118
 119    _kerberos._udp.ASDF.COM.        IN      SRV     0 0 88 kdc1.asdf.com.
 120    _kerberos._udp.ASDF.COM.        IN      SRV     1 0 88 kdc2.asdf.com.
 121
 122 Overview - Kerberos password changing server location information
 123
 124    Kerberos password changing server [KERB-CHG] location is to be stored
 125    using the DNS SRV RR [RFC 2052].  The format of this RR is as fol-
 126    lows:
 127
 128    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
 129
 130    The Service name for the password server is always "_kpasswd".
 131
 132    The Proto MUST be "_udp".
 133
 134    The Realm is the Kerberos realm that this record corresponds to.
 135
 136    TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
 137    ing as defined in RFC 2052.
 138
 139    As per RFC 2052 the Port number should be the value assigned to
 140    "kpasswd" by the Internet Assigned Number Authority (464).
 141
 142 Overview - Kerberos admin server location information
 143
 144    Kerberos admin location information is to be stored using the DNS SRV
 145    RR [RFC 2052].  The format of this RR is as follows:
 146
 147    Service.Proto.Realm TTL Class SRV Priority Weight Port Target
 148
 149    The Service name for the admin server is always "_kerberos-adm".
 150
 151    The Proto can be either "_udp" or "_tcp".  If these records are to be
 152    used, a "_tcp" record MUST be included.  If the Kerberos admin imple-
 153    mentation supports UDP transport, a "_udp" record SHOULD be included.
 154
 155    The Realm is the Kerberos realm that this record corresponds to.
 156
 157    TTL, Class, SRV, Priority, Weight, and Target have the standard mean-
 158    ing as defined in RFC 2052.
 159
 160    As per RFC 2052 the Port number should be the value assigned to
 161    "kerberos-adm" by the Internet Assigned Number Authority (749).
 162
 163    Note that there is no formal definition of a Kerberos admin protocol,
 164    so the use of this record is optional and implementation-dependent.
 165
 166
 167
 168
 169
 170 Hornstein, Altman                                               [Page 3]
 171 \f
 172 RFC DRAFT                                              February 28, 2001
 173
 174
 175 Example - Kerberos administrative server location information
 176
 177    These are DNS records for a Kerberos realm ASDF.COM.  It has one
 178    administrative server, kdc1.asdf.com.
 179
 180    _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 749 kdc1.asdf.com.
 181
 182 Overview - Hostname/domain name to Kerberos realm mapping
 183
 184    Information on the mapping of DNS hostnames and domain names to Ker-
 185    beros realms is stored using DNS TXT records [RFC 1035].  These
 186    records have the following format.
 187
 188    Service.Name TTL Class TXT Realm
 189
 190    The Service field is always "_kerberos", and prefixes all entries of
 191    this type.
 192
 193    The Name is a DNS hostname or domain name.  This is explained in
 194    greater detail below.
 195
 196    TTL, Class, and TXT have the standard DNS meaning as defined in RFC
 197    1035.
 198
 199    The Realm is the data for the TXT RR, and consists simply of the Ker-
 200    beros realm that corresponds to the Name specified.
 201
 202    When a Kerberos client wishes to utilize a host-specific service, it
 203    will perform a DNS TXT query, using the hostname in the Name field of
 204    the DNS query.  If the record is not found, the first label of the
 205    name is stripped and the query is retried.
 206
 207    Compliant implementations MUST query the full hostname and the most
 208    specific domain name (the hostname with the first label removed).
 209    Compliant implementations SHOULD try stripping all subsequent labels
 210    until a match is found or the Name field is empty.
 211
 212 Example - Hostname/domain name to Kerberos realm mapping
 213
 214    For the previously mentioned ASDF.COM realm and domain, some sample
 215    records might be as follows:
 216
 217    _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
 218    _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
 219    _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
 220
 221    Let us suppose that in this case, a Kerberos client wishes to use a
 222    Kerberized service on the host foo.asdf.com.  It would first query:
 223
 224
 225
 226 Hornstein, Altman                                               [Page 4]
 227 \f
 228 RFC DRAFT                                              February 28, 2001
 229
 230
 231    _kerberos.foo.asdf.com. IN TXT
 232
 233    Finding no match, it would then query:
 234
 235    _kerberos.asdf.com. IN TXT
 236
 237    And find an answer of ASDF.COM.  This would be the realm that
 238    foo.asdf.com resides in.
 239
 240    If another Kerberos client wishes to use a Kerberized service on the
 241    host salesserver.asdf.com, it would query:
 242
 243    _kerberos.salesserver.asdf.com IN TXT
 244
 245    And find an answer of SALES.ASDF.COM.
 246
 247 Security considerations
 248
 249    As DNS is deployed today, it is an unsecure service.  Thus the infor-
 250    mation returned by it cannot be trusted.
 251
 252    Current practice for REALM to KDC mapping is to use hostnames to
 253    indicate KDC hosts (stored in some implementation-dependent location,
 254    but generally a local config file).  These hostnames are vulnerable
 255    to the standard set of DNS attacks (denial of service, spoofed
 256    entries, etc).  The design of the Kerberos protocol limits attacks of
 257    this sort to denial of service.  However, the use of SRV records does
 258    not change this attack in any way.  They have the same vulnerabili-
 259    ties that already exist in the common practice of using hostnames for
 260    KDC locations.
 261
 262    Current practice for HOSTNAME to REALM mapping is to provide a local
 263    configuration of mappings of hostname or domain name to realm which
 264    are then mapped to KDCs.  But this again is vulnerable to spoofing
 265    via CNAME records that point to hosts in other domains.  This has the
 266    same effect as when a TXT record is spoofed.  In a realm with no
 267    cross-realm trusts this is a DoS attack.  However, when cross-realm
 268    trusts are used it is possible to redirect a client to use a comprom-
 269    ised realm.
 270
 271    This is not an exploit of the Kerberos protocol but of the Kerberos
 272    trust model.  The same can be done to any application that must
 273    resolve the hostname in order to determine which domain a non-FQDN
 274    belongs to.
 275
 276    Implementations SHOULD provide a way of specifying this information
 277    locally without the use of DNS.  However, to make this feature
 278    worthwhile a lack of any configuration information on a client should
 279
 280
 281
 282 Hornstein, Altman                                               [Page 5]
 283 \f
 284 RFC DRAFT                                              February 28, 2001
 285
 286
 287    be interpretted as permission to use DNS.
 288
 289 Expiration
 290
 291    This Internet-Draft expires on August 28, 2001.
 292
 293 References
 294
 295
 296    [RFC1510]
 297         The Kerberos Network Authentication System; Kohl, Newman; Sep-
 298         tember 1993.
 299
 300    [RFC1035]
 301         Domain Names - Implementation and Specification; Mockapetris;
 302         November 1987
 303
 304    [RFC2782]
 305         A DNS RR for specifying the location of services (DNS SRV); Gul-
 306         brandsen, Vixie; Feburary 2000
 307
 308    [KERB-CHG]
 309         Kerberos Change Password Protocol; Horowitz;
 310         ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
 311         password-02.txt
 312
 313 Authors' Addresses
 314
 315    Ken Hornstein
 316    US Naval Research Laboratory
 317    Bldg A-49, Room 2
 318    4555 Overlook Avenue
 319    Washington DC  20375 USA
 320
 321    Phone: +1 (202) 404-4765
 322    EMail: kenh@cmf.nrl.navy.mil
 323
 324    Jeffrey Altman
 325    The Kermit Project
 326    Columbia University
 327    612 West 115th Street #716
 328    New York NY 10025-7799 USA
 329
 330    Phone: +1 (212) 854-1344
 331    EMail: jaltman@columbia.edu
 332
 333
 334
 335
 336
 337
 338 Hornstein, Altman                                               [Page 6]
 339 \f