doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt

   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 \f
  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 \f
 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 \f
 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 \f