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