doc/standardisation/draft-raeburn-cat-gssapi-krb5-3des-00.txt

   1 CAT Working Group                                           K. Raeburn
   2 Internet-draft                                                     MIT
   3 Category:                                                July 14, 2000
   4 Updates: RFC 1964
   5 Document: draft-raeburn-cat-gssapi-krb5-3des-00.txt
   6
   7         Triple-DES Support for the Kerberos 5 GSSAPI Mechanism
   8
   9 Status of this Memo
  10
  11    This document is an Internet-Draft and is in full conformance with
  12    all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts
  13    are working documents of the Internet Engineering Task Force
  14    (IETF), its areas, and its working groups. Note that other groups
  15    may also distribute working documents as
  16    Internet-Drafts. Internet-Drafts are draft documents valid for a
  17    maximum of six months and may be updated, replaced, or obsoleted by
  18    other documents at any time. It is inappropriate to use
  19    Internet-Drafts as reference material or to cite them other than as
  20    "work in progress."
  21
  22    The list of current Internet-Drafts can be accessed at
  23    http://www.ietf.org/ietf/1id-abstracts.txt
  24
  25    The list of Internet-Draft Shadow Directories can be accessed at
  26    http://www.ietf.org/shadow.html.
  27
  28 1. Abstract
  29
  30    The MIT Kerberos 5 release version 1.2 includes support for
  31    triple-DES with key derivation [KrbRev].  Recent work by the EFF
  32    [EFF] has demonstrated the vulnerability of single-DES mechanisms
  33    to brute-force attacks by sufficiently motivated and well-funded
  34    parties.
  35
  36    The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5]
  37    specifically enumerates encryption and checksum types,
  38    independently of how such schemes may be used in Kerberos.  In the
  39    long run, a new Kerberos-based mechanism, which does not require
  40    separately enumerating for the GSSAPI mechanism each of the
  41    encryption types defined by Kerberos, appears to be a better
  42    approach.  Efforts to produce such a specification are under way.
  43
  44    In the interest of providing increased security in the interim,
  45    however, MIT is proposing adding support for triple-DES to the
  46    existing mechanism, as described here.
  47
  48 2. Conventions Used in this Document
  49
  50    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  51    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
  52    this document are to be interpreted as described in RFC 2119.
  53
  54 3. New Algorithm Identifiers
  55
  56    One new sealing algorithm is defined, for use in WRAP tokens:
  57
  58 \f   02 00 - DES3-KD
  59
  60    This algorithm uses triple-DES with key derivation, with a usage
  61    value KG_USAGE_SEAL.  Padding is still to 8-byte multiples, and the
  62    IV for encrypting application data is zero.
  63
  64    One new signing algorithm is defined, for use in MIC, Wrap, and
  65    Delete tokens:
  66
  67    04 00 - HMAC SHA1 DES3-KD
  68
  69    This algorithm generates an HMAC using SHA-1 and a derived DES3 key
  70    with usage KG_USAGE_SIGN, as (ought to be described) in [KrbRev].
  71
  72    [XXX: The current [KrbRev] description refers to expired I-Ds from
  73    Marc Horowitz.  The text in [KrbRev] may be inadequate to produce
  74    an interoperable implementation.]
  75
  76    The checksum size for this algorithm is 20 octets.  See section 5.3
  77    below for the use of checksum lengths of other than eight bytes.
  78
  79 4. Key Derivation
  80
  81    For purposes of key derivation, we add three new usage values to the
  82    list defined in [KrbRev]; one for signing messages, one for
  83    sealing messages, and one for encrypting sequence numbers:
  84
  85    #define KG_USAGE_SEAL 22
  86    #define KG_USAGE_SIGN 23
  87    #define KG_USAGE_SEQ  24
  88
  89 5. Adjustments to Previous Definitions
  90
  91 5.1. Quality of Protection
  92
  93    The GSSAPI specification [GSSAPI] says that a zero QOP value
  94    indicates the "default".  The original specification for the
  95    Kerberos 5 mechanism says that a zero QOP value (or a QOP value
  96    with the appropriate bits clear) means DES encryption.
  97
  98    Rather than continue to force the use of plain DES when the
  99    application doesn't use mechanism-specific QOP values, the better
 100    choice appears to be to redefine the DES QOP value as some non-zero
 101    value, and define a triple-DES value as well.  Then a zero value
 102    continues to imply the default, which would be triple-DES
 103    protection when given a triple-DES session key.
 104
 105    Our values are:
 106
 107    GSS_KRB5_INTEG_C_QOP_HMAC_SHA1        0x0004
 108             /* SHA-1 checksum encrypted with key derivation */
 109
 110    GSS_KRB5_CONF_C_QOP_DES               0x0100
 111             /* plain DES encryption */
 112    GSS_KRB5_CONF_C_QOP_DES3_KD           0x0200
 113             /* triple-DES with key derivation */
 114
 115 \f   Rather than open the question of whether to specify means for
 116    deriving a key of one type given a key of another type, and the
 117    security implications of whether to generate a long key from a
 118    shorter one, our implementation will simply return an error if the
 119    QOP value specified does not correspond to the session key type.
 120
 121    [Implementation note: MIT's code does not implement QoP, and
 122    returns an error for any non-zero QoP value.]
 123
 124 5.2. MIC Sequence Number Encryption
 125
 126    The sequence numbers are encrypted in the context key (as defined
 127    in [GSSAPI-KRB5] -- this will be either the Kerberos session key or
 128    asubkey provided by the context initiator), using whatever
 129    encryption system is designated by the type of that context key.
 130    The IV is formed from the first N bytes of the SGN_CKSUM field,
 131    where N is the number of bytes needed for the IV.  (With all
 132    algorithms described here and in [GSSAPI-KRB5], the checksum is at
 133    least as large as the IV.)
 134
 135 5.3. Message Layout
 136
 137    Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
 138    checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was
 139    specified as being 8 bytes long.  We now change this size to be
 140    "defined by the checksum algorithm", and retroactively amend the
 141    descriptions of all the checksum algorithms described in
 142    [GSSAPI-KRB5] to explicitly specify 8-byte output.  Application
 143    data continues to immediately follow the checksum field in the Wrap
 144    token.
 145
 146    The revised message descriptions are thus:
 147
 148    MIC:
 149
 150    Byte no          Name           Description
 151     0..1           TOK_ID          Identification field.
 152     2..3           SGN_ALG         Integrity algorithm indicator.
 153     4..7           Filler          Contains ff ff ff ff
 154     8..15          SND_SEQ         Sequence number field.
 155     16..s+15       SGN_CKSUM       Checksum of "to-be-signed data",
 156                                    calculated according to algorithm
 157                                    specified in SGN_ALG field.
 158
 159 \f   Wrap:
 160
 161    Byte no          Name           Description
 162     0..1           TOK_ID          Identification field.
 163                                    Tokens emitted by GSS_Wrap() contain
 164                                    the hex value 02 01 in this field.
 165     2..3           SGN_ALG         Checksum algorithm indicator.
 166     4..5           SEAL_ALG        Sealing algorithm indicator.
 167     6..7           Filler          Contains ff ff
 168     8..15          SND_SEQ         Encrypted sequence number field.
 169     16..s+15       SGN_CKSUM       Checksum of plaintext padded data,
 170                                    calculated according to algorithm
 171                                    specified in SGN_ALG field.
 172     s+16..last     Data            encrypted or plaintext padded data
 173
 174    Where "s" indicates the size of the checksum.
 175
 176    As indicated above in section 2, we define the HMAC SHA1 DES3-KD
 177    checksum algorithm to produce a 20-byte output, so encrypted data
 178    begins at byte 36.
 179
 180 6. Backwards Compatibility Considerations
 181
 182    The context initiator SHOULD request of the KDC credentials using
 183    session-key cryptosystem types supported by that implementation; if
 184    the only types returned by the KDC are not supported by the
 185    mechanism implementation, it MUST indicate a failure.  This may
 186    seem obvious, but early implementations of both Kerberos and the
 187    GSSAPI Kerberos mechanism supported only DES keys, so the
 188    cryptosystem compatibility question was easy to overlook.
 189
 190    Under the current mechanism, no negotiation of algorithm types
 191    occurs, so server-side (acceptor) implementations cannot request
 192    that clients not use algorithm types not understood by the server.
 193    However, administration of the server's Kerberos data has to be
 194    done in communication with the KDC, and it is from the KDC that the
 195    client will request credentials.  The KDC could therefore be tasked
 196    with limiting session keys for a given service to types actually
 197    supported by the Kerberos and GSSAPI software on the server.
 198
 199    This does have a drawback for cases where a service principal name
 200    is used both for GSSAPI-based and non-GSSAPI-based communication,
 201    if the GSSAPI implementation does not understand triple-DES but the
 202    Kerberos implementation does.  It means that triple-DES session
 203    keys cannot be issued for that service principal, which keeps the
 204    protection of non-GSSAPI services weaker than necessary.  However,
 205    in the most recent MIT releases thus far, while triple-DES support
 206    has been present, it has required additional work to enable, so it
 207    is not likely to be in use for many services.
 208
 209    It would also be possible to have clients attempt to get single-DES
 210    session keys before trying to get triple-DES session keys, and have
 211    the KDC refuse to issue the single-DES keys only for the most
 212    critical of services, for which single-DES protection is considered
 213    inadequate.  However, that would eliminate the possibility of
 214    connecting with the more secure cryptosystem to any service that
 215    can be accessed with the weaker cryptosystem.
 216
 217 \f   We have chosen to go with the former approach, putting the burden
 218    on the KDC administration and gaining the best protection possible
 219    for GSSAPI services, possibly at the cost of protection of
 220    non-GSSAPI Kerberos services running earlier versions of the
 221    software.
 222
 223 6. Security Considerations
 224
 225    Various tradeoffs arise regarding the mixing of new and old
 226    software, or GSSAPI-based and non-GSSAPI Kerberos authentication.
 227    They are discussed in section 5.
 228
 229 7. References
 230
 231    [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
 232    Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
 233    Associates, Inc., May, 1998.
 234
 235    [GSSAPI] Linn, J., "Generic Security Service Application Program
 236    Interface Version 2, Update 1", RFC 2743, January, 2000.
 237
 238    [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 239    RFC 1964, June, 1996.
 240
 241    [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
 242    Authentication Service (V5)",
 243    draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000.
 244
 245    [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
 246    3", RFC 2026, October, 1996.
 247
 248 8. Author's Address
 249
 250    Kenneth Raeburn
 251    Massachusetts Institute of Technology
 252    77 Massachusetts Avenue
 253    Cambridge, MA 02139
 254
 255 9. Full Copyright Statement
 256
 257    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 258
 259    This document and translations of it may be copied and furnished to
 260    others, and derivative works that comment on or otherwise explain it
 261    or assist in its implementation may be prepared, copied, published
 262    and distributed, in whole or in part, without restriction of any
 263    kind, provided that the above copyright notice and this paragraph
 264    are included on all such copies and derivative works.  However, this
 265    document itself may not be modified in any way, such as by removing
 266    the copyright notice or references to the Internet Society or other
 267    Internet organizations, except as needed for the purpose of
 268    developing Internet standards in which case the procedures for
 269    copyrights defined in the Internet Standards process must be
 270    followed, or as required to translate it into languages other than
 271    English.
 272
 273 \f   The limited permissions granted above are perpetual and will not be
 274    revoked by the Internet Society or its successors or assigns.
 275
 276    This document and the information contained herein is provided on an
 277    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 278    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 279    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 280    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 281    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."