home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-cat-kerb-key-derivation-00.txt < prev    next >
Text File  |  1996-11-27  |  8KB  |  251 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. Network Working Group                                        M. Horowitz
  7. <draft-ietf-cat-kerb-key-derivation-00.txt>             Cygnus Solutions
  8. Internet-Draft                                            November, 1996
  9.  
  10.  
  11.                      Key Derivation for Kerberos V5
  12.  
  13. Status of this Memo
  14.  
  15.    This document is an Internet-Draft.  Internet-Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its areas,
  17.    and its working groups.  Note that other groups may also distribute
  18.    working documents as Internet-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.    To learn the current status of any Internet-Draft, please check the
  26.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  27.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  28.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  29.    Rim).
  30.  
  31.    Distribution of this memo is unlimited.  Please send comments to the
  32.    <cat-ietf@mit.edu> mailing list.
  33.  
  34. Abstract
  35.  
  36.    In the Kerberos protocol [RFC1510], cryptographic keys are used in a
  37.    number of places.  In order to minimize the effect of compromising a
  38.    key, it is desirable to use a different key for each of these places.
  39.    Key derivation [Horowitz96] can be used to construct different keys
  40.    for each operation from the keys transported on the network.  For
  41.    this to be possible, a small change to the specification is
  42.    necessary.
  43.  
  44.  
  45. Overview
  46.  
  47.    Under RFC1510 as stated, key derivation could be specified as a set
  48.    of encryption types which share the same key type.  The constant for
  49.    each derivation would be a function of the encryption type.  However,
  50.    it is generally accepted that, for interoperability, key types and
  51.    encryption types must map one-to-one onto each other.  (RFC 1510 is
  52.    being revised to address this issue.)  Therefore, to use key
  53.    derivcation with Kerberos V5 requires a small change to the
  54.    specification.
  55.  
  56.    For each place where a key is used in Kerberos, a ``key usage'' must
  57.    be specified for that purpose.  The key, key usage, and
  58.    encryption/checksum type together describe the transformation from
  59.    plaintext to ciphertext, or plaintext to checksum.  For backward
  60.  
  61.  
  62.  
  63. Horowitz                                                        [Page 1]
  64.  
  65. Internet Draft       Key Derivation for Kerberos V5       November, 1996
  66.  
  67.  
  68.    compatibility, old encryption types would be defined independently of
  69.    the key usage.
  70.  
  71.  
  72. Key Usage Values
  73.  
  74.    This is a complete list of places keys are used in the kerberos
  75.    protocol, with key usage values and RFC 1510 section numbers:
  76.  
  77.       1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
  78.           client key (section 5.4.1)
  79.       2.  AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
  80.           application session key), encrypted with the service key
  81.           (section 5.4.2)
  82.       3.  AS-REP encrypted part (includes tgs session key or application
  83.           session key), encrypted with the client key (section 5.4.2)
  84.  
  85.       4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
  86.           session key (section 5.4.1)
  87.       5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
  88.           authenticator subkey (section 5.4.1)
  89.       6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
  90.           with the tgs session key (sections 5.3.2, 5.4.1)
  91.       7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
  92.           authenticator subkey), encrypted with the tgs session key
  93.           (section 5.3.2)
  94.       8.  TGS-REP encrypted part (includes application session key),
  95.           encrypted with the tgs session key (section 5.4.2)
  96.       9.  TGS-REP encrypted part (includes application session key),
  97.           encrypted with the tgs authenticator subkey (section 5.4.2)
  98.  
  99.       10. AP-REQ Authenticator cksum, keyed with the application session
  100.           key (section 5.3.2)
  101.       11. AP-REQ Authenticator (includes application authenticator
  102.           subkey), encrypted with the application session key (section
  103.           5.3.2)
  104.       12. AP-REP encrypted part (includes application session subkey),
  105.           encrypted with the application session key (section 5.5.2)
  106.  
  107.       13. KRB-PRIV encrypted part, encrypted with a key chosen by the
  108.           application (section 5.7.1)
  109.       14. KRB-CRED encrypted part, encrypted with a key chosen by the
  110.           application (section 5.6.1)
  111.       15. KRB-SAVE cksum, keyed with a key chosen by the application
  112.           (section 5.8.1)
  113.  
  114.       16. Data which is defined in some specification outside of
  115.           Kerberos to be encrypted using an RFC1510 encryption type.
  116.       17. Data which is defined in some specification outside of
  117.           Kerberos to be checksummed using an RFC1510 checksum type.
  118.  
  119.    A few of these key usages need a little clarification.  A service
  120.    which receives an AP-REQ has no way to know if the enclosed Ticket
  121.    was part of an AS-REP or TGS-REP.  Therefore, key usage 2 must always
  122.  
  123.  
  124.  
  125. Horowitz                                                        [Page 2]
  126.  
  127. Internet Draft       Key Derivation for Kerberos V5       November, 1996
  128.  
  129.  
  130.    be used for generating a Ticket, whether it is in response to an AS-
  131.    REQ or TGS-REQ.
  132.  
  133.    There might exist other documents which define protocols in terms of
  134.    the RFC1510 encryption types or checksum types.  Such documents would
  135.    not know about key usages.  In order that these documents continue to
  136.    be meaningful until they are updated, key usages 16 and 17 must be
  137.    used to derive keys for encryption and checksums, respectively.  New
  138.    protocols defined in terms of the Kerberos encryption and checksum
  139.    types should use their own key usages.  Key usages may be registered
  140.    with IANA to avoid conflicts.  Key usages shall be unsigned 32 bit
  141.    integers.  Zero is not permitted.
  142.  
  143.  
  144. Defining Cryptosystems Using Key Derivation
  145.  
  146.    Kerberos requires that the ciphertext component of EncryptedData be
  147.    tamper-resistant as well as confidential.  This implies encryption
  148.    and integrity functions, which must each use their own separate keys.
  149.    So, for each key usage, two keys must be generated, one for
  150.    encryption (Ke), and one for integrity (Ki):
  151.  
  152.       Ke = DK(protocol key, key usage | 0xAA)
  153.       Ki = DK(protocol key, key usage | 0x55)
  154.  
  155.    where the key usage is represented as a 32 bit integer in network
  156.    byte order.  The ciphertest must be generated from the plaintext as
  157.    follows:
  158.  
  159.       ciphertext = E(Ke, confounder | length | plaintext | padding) |
  160.                    H(Ki, confounder | length | plaintext | padding)
  161.  
  162.    The confounder and padding are specific to the encryption algorithm
  163.    E.
  164.  
  165.    When generating a checksum only, there is no need for a confounder or
  166.    padding.  Again, a new key (Kc) must be used.  Checksums must be
  167.    generated from the plaintext as follows:
  168.  
  169.       Kc = DK(protocol key, key usage | 0x99)
  170.  
  171.       MAC = H(Kc, length | plaintext)
  172.  
  173.    Note that each enctype is described by an encryption algorithm E and
  174.    a keyed hash algorithm H, and each checksum type is described by a
  175.    keyed hash algorithm H.  HMAC, with an appropriate hash, is
  176.    recommended for use as H.
  177.  
  178.  
  179. Security Considerations
  180.  
  181.    This entire document addresses shortcomings in the use of
  182.    cryptographic keys in Kerberos V5.
  183.  
  184.  
  185.  
  186.  
  187. Horowitz                                                        [Page 3]
  188.  
  189. Internet Draft       Key Derivation for Kerberos V5       November, 1996
  190.  
  191.  
  192. Acknowledgements
  193.  
  194.    I would like to thank Uri Blumenthal, Sam Hartman, and Bill
  195.    Sommerfeld for their contributions to this document.
  196.  
  197.  
  198. References
  199.  
  200.    [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
  201.       Integrity, and Privacy", draft-horowitz-key-derivation-00.txt,
  202.       November 1996.  [RFC1510] Kohl, J. and Neuman, C., "The Kerberos
  203.       Network Authentication Service (V5)", RFC 1510, September 1993.
  204.  
  205.  
  206. Author's Address
  207.  
  208.    Marc Horowitz
  209.    Cygnus Solutions
  210.    955 Massachusetts Avenue
  211.    Cambridge, MA 02139
  212.  
  213.    Phone: +1 617 354 7688
  214.    Email: marc@cygnus.com
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249. Horowitz                                                        [Page 4]
  250.  
  251.