ctdb-server: Clean up connection tracking functions

[samba4-gss.git] / third_party / heimdal / doc / standardisation / draft-raeburn-krb-gssapi-krb5-3des-01.txt

Kerberos Working Group                                        K. Raeburn
Category: Informational                                              MIT
Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt    November 24, 2000


         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 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 probably a better approach.  Various people have
   expressed interest in designing one, but the work has not yet been
   completed.

   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.  So,
   in the interest of providing increased security in the near term, MIT
   is adding support for triple-DES to the existing mechanism
   implementation we ship, as an interim measure.








Raeburn                                                         [Page 1]
\f
INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000


2. New Algorithm Identifiers

   One new sealing algorithm is defined, for use in Wrap tokens.


   +--------------------------------------------------------------------+
   |          name                                octet values          |
   +--------------------------------------------------------------------+
   |         DES3-KD                                 02 00              |
   +--------------------------------------------------------------------+

   This algorithm uses triple-DES with key derivation, with a usage
   value KG_USAGE_SEAL.  (Unlike the EncryptedData definition in
   [KrbRev], no integrity protection is needed, so this is "raw" triple-
   DES, with no checksum attached to the encrypted data.)  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.


   +--------------------------------------------------------------------+
   |             name                               octet values        |
   +--------------------------------------------------------------------+
   |       HMAC SHA1 DES3-KD                           04 00            |
   +--------------------------------------------------------------------+

   This algorithm generates an HMAC using SHA-1 and a derived DES3 key
   with usage KG_USAGE_SIGN, as described in [KrbRev].

   [N.B.: The current [KrbRev] description refers to expired 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.














Raeburn                                                         [Page 2]
\f
INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000


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:


   +--------------------------------------------------------------------+
   |             name                                    value          |
   +--------------------------------------------------------------------+
   |         KG_USAGE_SEAL                                22            |
   |         KG_USAGE_SIGN                                23            |
   |         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 forcing the use of plain DES when the application doesn't
   use mechanism-specific QOP values, we redefine the explicit DES QOP
   value as a 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:

   +--------------------------------------------------------------------+
   |             name                  value      meaning               |
   +--------------------------------------------------------------------+
   | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1    0x0004     SHA-1 HMAC, using     |
   |                                              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 attempt to specify a generic mechanism for deriving a key
   of one type given a key of another type, and evaluate the security
   implications of using a short key to generate a longer key to satisfy
   the requested quality of protection, our implementation will simply



Raeburn                                                         [Page 3]
\f
INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000


   return an error if the nonzero QOP value specified does not
   correspond to the session key type.

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 token:

   Byte #             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.













Raeburn                                                         [Page 4]
\f
INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000


   Wrap token:

   Byte #           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 (e.g., the
   service key) 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 (most
   notably the "host" service key), 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



Raeburn                                                         [Page 5]
\f
INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000


   principal, which keeps the protection of non-GSSAPI services weaker
   than necessary.

   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.

   For MIT's 1.2 release, we chose 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
   weaker protection of non-GSSAPI Kerberos services running earlier
   versions of the software.

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 5.

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-06.txt, July 4, 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.




Raeburn                                                         [Page 6]
\f
INTERNET DRAFT       Triple-DES for GSSAPI Kerberos        November 2000


   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."

10. Document Change History

>From -00 to -01:

   Converted master to GNU troff and tbl, rewriting tables in the
   process.

   Specify informational category only.  Modify some text to emphasize
   that this document intends to describe MIT's extensions.

   Point out that while EncryptedData for 3des-kd includes a checksum,
   DES3-KD GSS encryption does not.

   Shorten backwards-compatibility descriptions a little.

   Submit to Kerberos working group rather than CAT.











Raeburn                                                         [Page 7]
\f