home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / id-krb-dns-03.txt < prev    next >
Text File  |  2020-01-01  |  12KB  |  344 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. INTERNET-DRAFT                                             Ken Hornstein
  8. <draft-ietf-cat-krb-dns-locate-03.txt>                               NRL
  9. November 22, 2000                                         Jeffrey Altman
  10. Expires: May 22, 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.    cat-krb-dns-locate-03.txt>, and expires on May 22, 2001.  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.  
  60. RFC DRAFT                                              November 22, 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 only one of the possible combinations of upper
  79.    and lower case characters be used.  This restriction may be lifted
  80.    in 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
  99.    meaning as defined in RFC 2052.
  100.  
  101.    As per RFC 2052 the Port number should be the value assigned to
  102.    "kerberos" 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.  
  110.  
  111.  
  112. Hornstein, Altman                                               [Page 2]
  113.  
  114. RFC DRAFT                                              November 22, 2000
  115.  
  116.  
  117.    Weights are not used in these records.
  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
  137.    meaning 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
  158.    meaning 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. Example - Kerberos administrative server location information
  167.  
  168.    These are DNS records for a Kerberos realm ASDF.COM.  It has one
  169.    administrative server, kdc1.asdf.com.
  170.  
  171.  
  172.  
  173.  
  174. Hornstein, Altman                                               [Page 3]
  175.  
  176. RFC DRAFT                                              November 22, 2000
  177.  
  178.  
  179.    _kerberos-adm._tcp.ASDF.COM.    IN      SRV     0 0 749 kdc1.asdf.com.
  180.  
  181. Overview - Hostname/domain name to Kerberos realm mapping
  182.  
  183.    Information on the mapping of DNS hostnames and domain names to Ker-
  184.    beros realms is stored using DNS TXT records [RFC 1035].  These
  185.    records have the following format.
  186.  
  187.    Service.Name TTL Class TXT Realm
  188.  
  189.    The Service field is always "_kerberos", and prefixes all entries of
  190.    this type.
  191.  
  192.    The Name is a DNS hostname or domain name.  This is explained in
  193.    greater detail below.
  194.  
  195.    TTL, Class, and TXT have the standard DNS meaning as defined in RFC
  196.    1035.
  197.  
  198.    The Realm is the data for the TXT RR, and consists simply of the Ker-
  199.    beros realm that corresponds to the Name specified.
  200.  
  201.    When a Kerberos client wishes to utilize a host-specific service, it
  202.    will perform a DNS TXT query, using the hostname in the Name field of
  203.    the DNS query.  If the record is not found, the first label of the
  204.    name is stripped and the query is retried.
  205.  
  206.    Compliant implementations MUST query the full hostname and the most
  207.    specific domain name (the hostname with the first label removed).
  208.    Compliant implementations SHOULD try stripping all subsequent labels
  209.    until a match is found or the Name field is empty.
  210.  
  211. Example - Hostname/domain name to Kerberos realm mapping
  212.  
  213.    For the previously mentioned ASDF.COM realm and domain, some sample
  214.    records might be as follows:
  215.  
  216.    _kerberos.asdf.com.             IN      TXT     "ASDF.COM"
  217.    _kerberos.mrkserver.asdf.com.   IN      TXT     "MARKETING.ASDF.COM"
  218.    _kerberos.salesserver.asdf.com. IN      TXT     "SALES.ASDF.COM"
  219.  
  220.    Let us suppose that in this case, a Kerberos client wishes to use a
  221.    Kerberized service on the host foo.asdf.com.  It would first query:
  222.  
  223.    _kerberos.foo.asdf.com. IN TXT
  224.  
  225.    Finding no match, it would then query:
  226.  
  227.  
  228.  
  229.  
  230. Hornstein, Altman                                               [Page 4]
  231.  
  232. RFC DRAFT                                              November 22, 2000
  233.  
  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.    be interpretted as permission to use DNS.
  280.  
  281.  
  282.  
  283.                                                            
  284.  
  285.  
  286. Hornstein, Altman                                               [Page 5]
  287.  
  288. RFC DRAFT                                              November 22, 2000
  289.  
  290.  
  291. Expiration
  292.  
  293.    This Internet-Draft expires on September 10, 2000.
  294.  
  295. References
  296.  
  297.  
  298.    [RFC1510]
  299.         The Kerberos Network Authentication System; Kohl, Newman; Sep-
  300.         tember 1993.
  301.  
  302.    [RFC1035]
  303.         Domain Names - Implementation and Specification; Mockapetris;
  304.         November 1987
  305.  
  306.    [RFC2782]
  307.         A DNS RR for specifying the location of services (DNS SRV); Gul-
  308.         brandsen, Vixie; Feburary 2000
  309.  
  310.    [KERB-CHG]
  311.         Kerberos Change Password Protocol; Horowitz;
  312.         ftp://ds.internic.net/internet-drafts/draft-ietf-cat-kerb-chg-
  313.         password-02.txt
  314.  
  315. Authors' Addresses
  316.  
  317.    Ken Hornstein
  318.    US Naval Research Laboratory
  319.    Bldg A-49, Room 2
  320.    4555 Overlook Avenue
  321.    Washington DC  20375 USA
  322.  
  323.    Phone: +1 (202) 404-4765
  324.    EMail: kenh@cmf.nrl.navy.mil
  325.  
  326.    Jeffrey Altman
  327.    The Kermit Project
  328.    Columbia University
  329.    612 West 115th Street #716
  330.    New York NY 10025-7799 USA
  331.  
  332.    Phone: +1 (212) 854-1344
  333.    EMail: jaltman@columbia.edu
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342. Hornstein, Altman                                               [Page 6]
  343.  
  344.