crypto/heimdal/doc/standardisation/draft-raeburn-krb-gssapi-krb5-3des-01.txt

   1
   2
   3
   4
   5
   6
   7 Kerberos Working Group                                        K. Raeburn
   8 Category: Informational                                              MIT
   9 Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt    November 24, 2000
  10
  11
  12          Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
  13
  14 Status of this Memo
  15
  16    This document is an Internet-Draft and is in full conformance with
  17    all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
  18    working documents of the Internet Engineering Task Force (IETF), its
  19    areas, and its working groups. Note that other groups may also
  20    distribute working documents as Internet-Drafts. Internet-Drafts are
  21    draft documents valid for a maximum of six months and may be updated,
  22    replaced, or obsoleted by other documents at any time. It is
  23    inappropriate to use Internet-Drafts as reference material or to cite
  24    them other than as "work in progress."
  25
  26    The list of current Internet-Drafts can be accessed at
  27    http://www.ietf.org/ietf/1id-abstracts.txt
  28
  29    The list of Internet-Draft Shadow Directories can be accessed at
  30    http://www.ietf.org/shadow.html.
  31
  32 1. Abstract
  33
  34    The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically
  35    enumerates encryption and checksum types, independently of how such
  36    schemes may be used in Kerberos.  In the long run, a new Kerberos-
  37    based mechanism, which does not require separately enumerating for
  38    the GSSAPI mechanism each of the various encryption types defined by
  39    Kerberos, is probably a better approach.  Various people have
  40    expressed interest in designing one, but the work has not yet been
  41    completed.
  42
  43    The MIT Kerberos 5 release version 1.2 includes support for triple-
  44    DES with key derivation [KrbRev].  Recent work by the EFF [EFF] has
  45    demonstrated the vulnerability of single-DES mechanisms to brute-
  46    force attacks by sufficiently motivated and well-funded parties.  So,
  47    in the interest of providing increased security in the near term, MIT
  48    is adding support for triple-DES to the existing mechanism
  49    implementation we ship, as an interim measure.
  50
  51
  52
  53
  54
  55
  56
  57
  58 Raeburn                                                         [Page 1]
  59 \f
  60 INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
  61
  62
  63 2. New Algorithm Identifiers
  64
  65    One new sealing algorithm is defined, for use in Wrap tokens.
  66
  67
  68    +--------------------------------------------------------------------+
  69    |          name                                octet values          |
  70    +--------------------------------------------------------------------+
  71    |         DES3-KD                                 02 00              |
  72    +--------------------------------------------------------------------+
  73
  74    This algorithm uses triple-DES with key derivation, with a usage
  75    value KG_USAGE_SEAL.  (Unlike the EncryptedData definition in
  76    [KrbRev], no integrity protection is needed, so this is "raw" triple-
  77    DES, with no checksum attached to the encrypted data.)  Padding is
  78    still to 8-byte multiples, and the IV for encrypting application data
  79    is zero.
  80
  81    One new signing algorithm is defined, for use in MIC, Wrap, and
  82    Delete tokens.
  83
  84
  85    +--------------------------------------------------------------------+
  86    |             name                               octet values        |
  87    +--------------------------------------------------------------------+
  88    |       HMAC SHA1 DES3-KD                           04 00            |
  89    +--------------------------------------------------------------------+
  90
  91    This algorithm generates an HMAC using SHA-1 and a derived DES3 key
  92    with usage KG_USAGE_SIGN, as described in [KrbRev].
  93
  94    [N.B.: The current [KrbRev] description refers to expired I-Ds from
  95    Marc Horowitz.  The text in [KrbRev] may be inadequate to produce an
  96    interoperable implementation.]
  97
  98    The checksum size for this algorithm is 20 octets.  See section 4.3
  99    below for the use of checksum lengths of other than eight bytes.
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Raeburn                                                         [Page 2]
 115 \f
 116 INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
 117
 118
 119 3. Key Derivation
 120
 121    For purposes of key derivation, we add three new usage values to the
 122    list defined in [KrbRev]; one for signing messages, one for sealing
 123    messages, and one for encrypting sequence numbers:
 124
 125
 126    +--------------------------------------------------------------------+
 127    |             name                                    value          |
 128    +--------------------------------------------------------------------+
 129    |         KG_USAGE_SEAL                                22            |
 130    |         KG_USAGE_SIGN                                23            |
 131    |         KG_USAGE_SEQ                                 24            |
 132    +--------------------------------------------------------------------+
 133
 134 4. Adjustments to Previous Definitions
 135
 136 4.1. Quality of Protection
 137
 138    The GSSAPI specification [GSSAPI] says that a zero QOP value
 139    indicates the "default".  The original specification for the Kerberos
 140    5 mechanism says that a zero QOP value (or a QOP value with the
 141    appropriate bits clear) means DES encryption.
 142
 143    Rather than forcing the use of plain DES when the application doesn't
 144    use mechanism-specific QOP values, we redefine the explicit DES QOP
 145    value as a non-zero value, and define a triple-DES value as well.
 146    Then a zero value continues to imply the default, which would be
 147    triple-DES protection when given a triple-DES session key.
 148
 149    Our values are:
 150
 151    +--------------------------------------------------------------------+
 152    |             name                  value      meaning               |
 153    +--------------------------------------------------------------------+
 154    | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1    0x0004     SHA-1 HMAC, using     |
 155    |                                              key derivation        |
 156    |                                                                    |
 157    |    GSS_KRB5_CONF_C_QOP_DES        0x0100     plain DES encryption  |
 158    |                                                                    |
 159    |  GSS_KRB5_CONF_C_QOP_DES3_KD      0x0200     triple-DES with key   |
 160    |                                              derivation            |
 161    +--------------------------------------------------------------------+
 162
 163    Rather than attempt to specify a generic mechanism for deriving a key
 164    of one type given a key of another type, and evaluate the security
 165    implications of using a short key to generate a longer key to satisfy
 166    the requested quality of protection, our implementation will simply
 167
 168
 169
 170 Raeburn                                                         [Page 3]
 171 \f
 172 INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
 173
 174
 175    return an error if the nonzero QOP value specified does not
 176    correspond to the session key type.
 177
 178 4.2. MIC Sequence Number Encryption
 179
 180    The sequence numbers are encrypted in the context key (as defined in
 181    [GSSAPI-KRB5] -- this will be either the Kerberos session key or
 182    asubkey provided by the context initiator), using whatever encryption
 183    system is designated by the type of that context key.  The IV is
 184    formed from the first N bytes of the SGN_CKSUM field, where N is the
 185    number of bytes needed for the IV.  (With all algorithms described
 186    here and in [GSSAPI-KRB5], the checksum is at least as large as the
 187    IV.)
 188
 189 4.3. Message Layout
 190
 191    Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
 192    checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was specified
 193    as being 8 bytes long.  We now change this size to be "defined by the
 194    checksum algorithm", and retroactively amend the descriptions of all
 195    the checksum algorithms described in [GSSAPI-KRB5] to explicitly
 196    specify 8-byte output.  Application data continues to immediately
 197    follow the checksum field in the Wrap token.
 198
 199    The revised message descriptions are thus:
 200
 201    MIC token:
 202
 203    Byte #             Name                Description
 204    ----------------------------------------------------------------------
 205     0..1              TOK_ID              Identification field.
 206     2..3              SGN_ALG             Integrity algorithm indicator.
 207     4..7              Filler              Contains ff ff ff ff
 208     8..15             SND_SEQ             Sequence number field.
 209    16..s+15           SGN_CKSUM           Checksum of "to-be-signed
 210                                           data", calculated according to
 211                                           algorithm specified in SGN_ALG
 212                                           field.
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Raeburn                                                         [Page 4]
 227 \f
 228 INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
 229
 230
 231    Wrap token:
 232
 233    Byte #           Name             Description
 234    ----------------------------------------------------------------------
 235     0..1            TOK_ID           Identification field.  Tokens
 236                                      emitted by GSS_Wrap() contain the
 237                                      hex value 02 01 in this field.
 238     2..3            SGN_ALG          Checksum algorithm indicator.
 239     4..5            SEAL_ALG         Sealing algorithm indicator.
 240     6..7            Filler           Contains ff ff
 241     8..15           SND_SEQ          Encrypted sequence number field.
 242    16..s+15         SGN_CKSUM        Checksum of plaintext padded data,
 243                                      calculated according to algorithm
 244                                      specified in SGN_ALG field.
 245    s+16..last       Data             encrypted or plaintext padded data
 246
 247
 248    Where "s" indicates the size of the checksum.
 249
 250    As indicated above in section 2, we define the HMAC SHA1 DES3-KD
 251    checksum algorithm to produce a 20-byte output, so encrypted data
 252    begins at byte 36.
 253
 254 5. Backwards Compatibility Considerations
 255
 256    The context initiator should request of the KDC credentials using
 257    session-key cryptosystem types supported by that implementation; if
 258    the only types returned by the KDC are not supported by the mechanism
 259    implementation, it should indicate a failure.  This may seem obvious,
 260    but early implementations of both Kerberos and the GSSAPI Kerberos
 261    mechanism supported only DES keys, so the cryptosystem compatibility
 262    question was easy to overlook.
 263
 264    Under the current mechanism, no negotiation of algorithm types
 265    occurs, so server-side (acceptor) implementations cannot request that
 266    clients not use algorithm types not understood by the server.
 267    However, administration of the server's Kerberos data (e.g., the
 268    service key) has to be done in communication with the KDC, and it is
 269    from the KDC that the client will request credentials.  The KDC could
 270    therefore be tasked with limiting session keys for a given service to
 271    types actually supported by the Kerberos and GSSAPI software on the
 272    server.
 273
 274    This does have a drawback for cases where a service principal name is
 275    used both for GSSAPI-based and non-GSSAPI-based communication (most
 276    notably the "host" service key), if the GSSAPI implementation does
 277    not understand triple-DES but the Kerberos implementation does.  It
 278    means that triple-DES session keys cannot be issued for that service
 279
 280
 281
 282 Raeburn                                                         [Page 5]
 283 \f
 284 INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
 285
 286
 287    principal, which keeps the protection of non-GSSAPI services weaker
 288    than necessary.
 289
 290    It would also be possible to have clients attempt to get single-DES
 291    session keys before trying to get triple-DES session keys, and have
 292    the KDC refuse to issue the single-DES keys only for the most
 293    critical of services, for which single-DES protection is considered
 294    inadequate.  However, that would eliminate the possibility of
 295    connecting with the more secure cryptosystem to any service that can
 296    be accessed with the weaker cryptosystem.
 297
 298    For MIT's 1.2 release, we chose to go with the former approach,
 299    putting the burden on the KDC administration and gaining the best
 300    protection possible for GSSAPI services, possibly at the cost of
 301    weaker protection of non-GSSAPI Kerberos services running earlier
 302    versions of the software.
 303
 304 6. Security Considerations
 305
 306    Various tradeoffs arise regarding the mixing of new and old software,
 307    or GSSAPI-based and non-GSSAPI Kerberos authentication.  They are
 308    discussed in section 5.
 309
 310 7. References
 311
 312    [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
 313    Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
 314    Associates, Inc., May, 1998.
 315
 316    [GSSAPI] Linn, J., "Generic Security Service Application Program
 317    Interface Version 2, Update 1", RFC 2743, January, 2000.
 318
 319    [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 320    RFC 1964, June, 1996.
 321
 322    [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
 323    Authentication Service (V5)", draft-ietf-cat-kerberos-
 324    revisions-06.txt, July 4, 2000.
 325
 326 8. Author's Address
 327
 328    Kenneth Raeburn Massachusetts Institute of Technology 77
 329    Massachusetts Avenue Cambridge, MA 02139
 330
 331 9. Full Copyright Statement
 332
 333    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 334
 335
 336
 337
 338 Raeburn                                                         [Page 6]
 339 \f
 340 INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000
 341
 342
 343    This document and translations of it may be copied and furnished to
 344    others, and derivative works that comment on or otherwise explain it
 345    or assist in its implementation may be prepared, copied, published
 346    and distributed, in whole or in part, without restriction of any
 347    kind, provided that the above copyright notice and this paragraph are
 348    included on all such copies and derivative works.  However, this
 349    document itself may not be modified in any way, such as by removing
 350    the copyright notice or references to the Internet Society or other
 351    Internet organizations, except as needed for the purpose of
 352    developing Internet standards in which case the procedures for
 353    copyrights defined in the Internet Standards process must be
 354    followed, or as required to translate it into languages other than
 355    English.
 356
 357    The limited permissions granted above are perpetual and will not be
 358    revoked by the Internet Society or its successors or assigns.
 359
 360    This document and the information contained herein is provided on an
 361    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 362    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 363    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 364    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 365    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 366
 367 10. Document Change History
 368
 369 >From -00 to -01:
 370
 371    Converted master to GNU troff and tbl, rewriting tables in the
 372    process.
 373
 374    Specify informational category only.  Modify some text to emphasize
 375    that this document intends to describe MIT's extensions.
 376
 377    Point out that while EncryptedData for 3des-kd includes a checksum,
 378    DES3-KD GSS encryption does not.
 379
 380    Shorten backwards-compatibility descriptions a little.
 381
 382    Submit to Kerberos working group rather than CAT.
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Raeburn                                                         [Page 7]
 395 \f