CAT Working Group                                           K. Raeburn
Internet-draft                                                     MIT
Category:                                                June xx, 2000
Updates: RFC 1964
Document: draft-raeburn-gssapi-krb5-3des-XX.txt

        Triple-DES Support for the Kerberos 5 GSSAPI Mechanism

Status of this Memo
 
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF),
   its areas, and its working groups. Note that other groups may also
   distribute working documents as Internet-Drafts. Internet-Drafts
   are draft documents valid for a maximum of six months and may be
   updated, replaced, or obsoleted by other documents at any time. It
   is inappropriate to use Internet-Drafts as reference material or to
   cite them other than as "work in progress."
     
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
1. Abstract 

   The MIT Kerberos 5 release version 1.2 includes support for
   triple-DES with key derivation [KrbRev].  Recent work by the EFF
   [EFF] has demonstrated the vulnerability of single-DES mechanisms
   to brute-force attacks by sufficiently motivated and well-funded
   parties.

   The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5]
   specifically enumerates encryption and checksum types,
   independently of how such schemes may be used in Kerberos.  In the
   long run, a new Kerberos-based mechanism, which does not require
   separately enumerating for the GSSAPI mechanism each of the various
   encryption types defined by Kerberos, is a better approach.
   Efforts to produce such a specification are under way.

   In the interest of providing increased security in the near term,
   however, MIT is adding support for triple-DES to the existing
   mechanism implementation we ship, as described here.

2. New Algorithm Identifiers

   One new sealing algorithm is defined, for use in WRAP tokens:

   02 00 - DES3-KD

   This algorithm uses triple-DES with key derivation, with a usage
   value KG_USAGE_SEAL.  Padding is still to 8-byte multiples, and the
   IV for encrypting application data is zero.

   One new signing algorithm is defined, for use in MIC, Wrap, and
   Delete tokens:

   04 00 - HMAC SHA1 DES3-KD

   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
   with usage KG_USAGE_SIGN, as (should be described) in [KrbRev].
   [XXX: The current [KrbRev] description refers to out-of-date I-Ds
   from Marc Horowitz.  The text in [KrbRev] may be inadequate to
   produce an interoperable implementation.]

   The checksum size for this algorithm is 20 octets.  See section 4.3
   below for the use of checksum lengths of other than eight bytes.

3. Key Derivation

   For purposes of key derivation, we add three new usage values to the
   list defined in [KrbRev]; one for signing messages, one for
   sealing messages, and one for encrypting sequence numbers:

   #define KG_USAGE_SEAL 22
   #define KG_USAGE_SIGN 23
   #define KG_USAGE_SEQ  24

4. Adjustments to Previous Definitions

4.1. Quality of Protection

   The GSSAPI specification [GSSAPI] says that a zero QOP value
   indicates the "default".  The original specification for the
   Kerberos 5 mechanism says that a zero QOP value (or a QOP value
   with the appropriate bits clear) means DES encryption.

   Rather than continue to force the use of plain DES when the
   application doesn't use mechanism-specific QOP values, the better
   choice appears to be to redefine the DES QOP value as some non-zero
   value, and define a triple-DES value as well.  Then a zero value
   continues to imply the default, which would be triple-DES
   protection when given a triple-DES session key.

   Our values are:

   GSS_KRB5_INTEG_C_QOP_HMAC_SHA1        0x0004
            /* SHA-1 checksum encrypted with key derivation */

   GSS_KRB5_CONF_C_QOP_DES               0x0100
            /* plain DES encryption */
   GSS_KRB5_CONF_C_QOP_DES3_KD           0x0200
            /* triple-DES with key derivation */

   Rather than open the question of whether to specify means for
   deriving a key of one type given a key of another type, and the
   security implications of whether to generate a long key from a
   shorter one, our implementation will simply return an error if the
   QOP value specified does not correspond to the session key type.

   [XXX: Not implemented yet.  Currently an error is reported for all
   non-zero values.  This should be changed before the release, so an
   application can insist on getting no less than triple-DES
   protection.]

4.2. MIC Sequence Number Encryption

   The sequence numbers are encrypted in the context key (as defined
   in [GSSAPI-KRB5] -- this will be either the Kerberos session key or
   asubkey provided by the context initiator), using whatever
   encryption system is designated by the type of that context key.
   The IV is formed from the first N bytes of the SGN_CKSUM field,
   where N is the number of bytes needed for the IV.  (With all
   algorithms described here and in [GSSAPI-KRB5], the checksum is at
   least as large as the IV.)

4.3. Message Layout

   Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an
   checksum field SGN_CKSUM.  In [GSSAPI-KRB5], this field was
   specified as being 8 bytes long.  We now change this size to be
   "defined by the checksum algorithm", and retroactively amend the
   descriptions of all the checksum algorithms described in
   [GSSAPI-KRB5] to explicitly specify 8-byte output.  Application
   data continues to immediately follow the checksum field in the Wrap
   token.

   The revised message descriptions are thus:

   MIC:

   Byte no          Name           Description
    0..1           TOK_ID          Identification field.
    2..3           SGN_ALG         Integrity algorithm indicator.
    4..7           Filler          Contains ff ff ff ff
    8..15          SND_SEQ         Sequence number field.
    16..s+15       SGN_CKSUM       Checksum of "to-be-signed data",
                                   calculated according to algorithm
                                   specified in SGN_ALG field.

   Wrap:

   Byte no          Name           Description
    0..1           TOK_ID          Identification field.
                                   Tokens emitted by GSS_Wrap() contain
                                   the hex value 02 01 in this field.
    2..3           SGN_ALG         Checksum algorithm indicator.
    4..5           SEAL_ALG        Sealing algorithm indicator.
    6..7           Filler          Contains ff ff
    8..15          SND_SEQ         Encrypted sequence number field.
    16..s+15       SGN_CKSUM       Checksum of plaintext padded data,
                                   calculated according to algorithm
                                   specified in SGN_ALG field.
    s+16..last     Data            encrypted or plaintext padded data

   Where "s" indicates the size of the checksum.

   As indicated above in section 2, we define the HMAC SHA1 DES3-KD
   checksum algorithm to produce a 20-byte output, so encrypted data
   begins at byte 36.

5. Backwards Compatibility Considerations

   The context initiator should request of the KDC credentials using
   session-key cryptosystem types supported by that implementation; if
   the only types returned by the KDC are not supported by the
   mechanism implementation, it should indicate a failure.  This may
   seem obvious, but early implementations of both Kerberos and the
   GSSAPI Kerberos mechanism supported only DES keys, so the
   cryptosystem compatibility question was easy to overlook.

   Under the current mechanism, no negotiation of algorithm types
   occurs, so server-side (acceptor) implementations cannot request
   that clients not use algorithm types not understood by the server.
   However, administration of the server's Kerberos data has to be
   done in communication with the KDC, and it is from the KDC that the
   client will request credentials.  The KDC could therefore be tasked
   with limiting session keys for a given service to types actually
   supported by the Kerberos and GSSAPI software on the server.

   This does have a drawback for cases where a service principal name
   is used both for GSSAPI-based and non-GSSAPI-based communication,
   if the GSSAPI implementation does not understand triple-DES but the
   Kerberos implementation does.  It means that triple-DES session
   keys cannot be issued for that service principal, which keeps the
   protection of non-GSSAPI services weaker than necessary.  However,
   in the most recent MIT releases thus far, while triple-DES support
   has been present, it has required additional work to enable, so it
   should not be in use for many services.

   It would also be possible to have clients attempt to get single-DES
   session keys before trying to get triple-DES session keys, and have
   the KDC refuse to issue the single-DES keys only for the most
   critical of services, for which single-DES protection is considered
   inadequate.  However, that would eliminate the possibility of
   connecting with the more secure cryptosystem to any service that
   can be accessed with the weaker cryptosystem.

   We have chosen to go with the former approach, putting the burden
   on the KDC administration and gaining the best protection possible
   for GSSAPI services, possibly at the cost of protection of
   non-GSSAPI Kerberos services running earlier versions of the
   software.
   [XXX: Actually, we haven't entirely decided and cast it in stone
   yet, it's just what I've implemented; it's easy to change.]

6. Security Considerations

   Various tradeoffs arise regarding the mixing of new and old
   software, or GSSAPI-based and non-GSSAPI Kerberos authentication.
   They are discussed in section 4.

7. References

   [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of
   Encryption Research, Wiretap Politics, and Chip Design", O'Reilly &
   Associates, Inc., May, 1998.

   [GSSAPI] Linn, J., "Generic Security Service Application Program
   Interface Version 2, Update 1", RFC 2743, January, 2000.

   [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
   RFC 1964, June, 1996.

   [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network
   Authentication Service (V5)",
   draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000.

8. Author's Address

   Kenneth Raeburn
   Massachusetts Institute of Technology
   77 Massachusetts Avenue
   Cambridge, MA 02139

9. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this   
   document itself may not be modified in any way, such as by removing   
   the copyright notice or references to the Internet Society or other   
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
