Merge branch 'master' into lukeh/acquire-cred-ex-moonshot-integ

[heimdal.git] / doc / standardisation / draft-ietf-krb-wg-gss-crypto-00.txt

Internet-Draft                                                K. Raeburn
Kerberos Working Group                                               MIT
Updates: RFC 1964                                        August 13, 2003
Document: draft-ietf-krb-wg-gss-crypto-00.txt  expires February 13, 2004

                 General Kerberos Cryptosystem Support
                  for the Kerberos 5 GSSAPI Mechanism

Abstract

   This document describes an update to the Kerberos 5 mechanism for
   GSSAPI to allow the use of Kerberos-defined cryptosystems directly in
   GSSAPI messages, without requiring further changes for each new
   encryption or checksum algorithm that complies with the Kerberos
   crypto framework specifications.

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC2026]. 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. Introduction

   Kerberos defines an encryption and checksum framework [KCRYPTO] that
   provides for complete specification and enumeration of cryptosystem
   specifications in a general way, to be used within Kerberos and
   associated protocols.  The GSSAPI Kerberos 5 mechanism definition
   [GSSAPI-KRB5] sets up a framework for enumerating encryption and
   checksum types, independently of how such schemes may be used in
   Kerberos, thus requiring updates for any new encryption or checksum
   algorithm not directly compatible with those already defined.




Raeburn                                                         [Page 1]
\f
INTERNET DRAFT                                               August 2003


   This document describes an update to [GSSAPI-KRB5] to allow the use
   of any Kerberos-defined cryptosystems directly in GSSAPI messages,
   without requiring further changes for each new encryption or checksum
   algorithm that complies with the framework specifications, and
   without making assumptions concerning block sizes or other
   characteristics of the underlying encryption operations.

2. Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

3. New Algorithm Identifiers

   Two new sealing algorithm numbers and one new signing algorithm
   number are defined, for use in MIC, Wrap and Delete tokens.


                 type          name          octet values
                 -----------------------------------------
                 seal   KERBEROS5-ENCRYPT       00 01
                 sign   KERBEROS5-CHECKSUM      00 01
                 sign          NONE             ff ff


   The KERBEROS5-ENCRYPT algorithm encrypts using the Kerberos
   encryption type [KCRYPTO] indicated by the encryption key type (using
   the session key or initiator's subkey, as described in [GSSAPI-
   KRB5]), with a key usage value KG_USAGE_SEAL, defined below.  All
   Kerberos encryption types provide for integrity protection, and
   specify any padding that might be required; neither needs to be done
   at the GSS mechanism level when KERBEROS5-ENCRYPT is used.  When
   KERBEROS5-ENCRYPT is used as the seal algorithm, the sign algorithm
   MUST be NONE.

   The signing algorithm value NONE MUST be used only with a sealing
   algorithm that incorporates integrity protection; currently,
   KERBEROS5-ENCRYPT is the only such sealing algorithm.

   The KERBEROS5-CHECKSUM signing algorithm MAY be used in other cases.
   The contents of the SGN_CKSUM field are determined by computing a
   Kerberos checksum [KCRYPTO], using the session key or subkey, and a
   key usage value of KG_USAGE_SIGN.  The Kerberos checksum algorithm to
   be used is the required-to-implement checksum algorithm associated
   with the encryption key type.  It should be noted that the checksum
   input data in this case is not the same as the "to-be-signed data"
   described in section 1.2.1.1 of [GSSAPI-KRB5]; see below.



Raeburn                                                         [Page 2]
\f
INTERNET DRAFT                                               August 2003


   The encryption or checksum output incorporated in the MIC and Wrap
   tokens is the octet string output from the corresponding operation in
   [KCRYPTO]; it should not be confused with the EncryptedData or
   Checksum object in [KrbClar].

   For purposes of key derivation, we add two new usage values to the
   list defined in [KrbClar]; one for signing messages, and one for
   sealing messages:


                               name        value
                           ----------------------
                           KG_USAGE_SEAL    22
                           KG_USAGE_SIGN    23


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.

   Since the quality of protection cannot be improved without fully
   reauthenticating with a stronger key type, the QOP value is now
   ignored.

4.2. Message Layout

   The definitions of the MIC and Wrap tokens in [GSSAPI-KRB5] assumed
   an 8-byte checksum size, and a CBC-mode block cipher with an 8-byte
   block size, without integrity protection.  In the crypto framework
   described in [KCRYPTO], integrity protection is built into the
   encryption operations.  CBC mode is not assumed, and indeed there may
   be no initial vector to supply.  While the operations are performed
   on messages of specific sizes, the underlying cipher may be a stream
   cipher.

   We modify the message definitions such that the portions after the
   first 8 bytes (which specify the token identification and the signing
   and sealing algorithms) are defined by the algorithms chosen.  The
   remaining bytes must convey sequence number and direction
   information, and must protect the integrity of the token id and
   algorithm indicators.  For the DES-based algorithms specified in
   [GSSAPI-KRB5], the definition for the remaining data is backwards
   compatible.



Raeburn                                                         [Page 3]
\f
INTERNET DRAFT                                               August 2003


   The revised message descriptions are thus as follows:


                                MIC token
          Byte #    Name         Description
          -------------------------------------------------------
            0..1    TOK_ID       Identification field (01 01).
            2..3    SGN_ALG      Integrity algorithm indicator.
            4..7    Filler       Contains ff ff ff ff
            8..N                 Dependent on SGN_ALG.

          If SGN_ALG is 0000, 0100, 0200:
            8..15   SND_SEQ      Sequence number/direction
                                 field, encrypted.
           16..23   SGN_CKSUM    Checksum of bytes 0..7 and
                                 application data, as described
                                 in [GSSAPI-KRB5].
          If SGN_ALG is 0001:
            8..15   SND_SEQ      Sequence number/direction
                                 field, NOT encrypted.
           16..N    SGN_CKSUM    Checksum of bytes 0..15 and
                                 application data, with key
                                 usage KG_USAGE_SIGN.


      Suggestions from Microsoft: Moving to 64-bit sequence numbers
      would be better for long sessions with many messages.  Using the
      direction flag to perturb the encryption or integrity protection
      is safer than simply including a flag which a buggy but mostly
      working implementation might fail to check.

      I am considering changing to use 64-bit sequence numbers, and
      omitting the direction flag from the transmitted cleartext data.
      How it would factor into the encrypted Wrap token, I haven't
      figured out yet.

      - Change the key usage values based on the direction?  It's
      suggested in [KCRYPTO], perhaps not strongly enough, that the key
      usage numbers should perturb the key, but DES ignores them,
      although DES shouldn't use this extension.

      - Add a direction flag byte in encrypted data?  Either depends on
      an implementor remembering to add the check.  Adding it to
      checksummed data requires that the implementor get it right.

      - Generate one or two new keys using PRF and random-to-key
      operations, using different keys for each direction?  Pulling the
      DK function out of the simplified profile is probably not a good



Raeburn                                                         [Page 4]
\f
INTERNET DRAFT                                               August 2003


      way to do this.

   The filler bytes are included in the checksum calculation for
   simplicity.  There is no security benefit from including them.

   In the Wrap token, the initial bytes, sequence number and direction
   are incorporated into the data to be encrypted.  In most cases, this
   is likely to be more efficient in terms of space and computing power
   than using unencrypted sequence number and direction fields, adding a
   checksum, and doing the additional work to authenticate that the
   checksum and encrypted data are part of the same message.  (The
   framework in [KCRYPTO] has no support for integrity protection of a
   block of data only some of which is encrypted, except by treating the
   two portions independently and using some additional means to ensure
   that the two parts continue to be associated with one another.)

   The length is also included, as a 4-byte value in network byte order,
   because the decryption operation in the Kerberos crypto framework
   does not recover the exact length of the original input.  Thus,
   messages with application data larger than 4 gigabytes are not
   supported.

      [Q: Should this length be 8 bytes?  ASN.1 wrapper?]


                                Wrap token
       Byte #      Name         Description
       -------------------------------------------------------------
         0..1      TOK_ID       Identification field (02 01).
         2..3      SGN_ALG      Integrity algorithm indicator.
         4..5      SEAL_ALG     Sealing algorithm indicator.
         6..7      Filler       Contains ff ff
         8..last                Dependent on SEAL_ALG and SGN_ALG.

       If SEAL_ALG is 0000:
         8..15     SND_SEQ      Encrypted sequence number field.
        16..23     SGN_CKSUM    Checksum of plaintext padded data,
                                calculated according to algorithm
                                specified in SGN_ALG field.  (RFC
                                1964)
        24..last   Data         Encrypted padded data.

       If SEAL_ALG is 0001 and SGN_ALG is ffff:
         8..last   Data         Encrypted bytes 0..5, 2-byte
                                direction flag, sequence number,
                                4-byte data length, and data.





Raeburn                                                         [Page 5]
\f
INTERNET DRAFT                                               August 2003


       If SEAL_ALG is ffff, and SGN_ALG is 0000, 0100, 0200:
         8..15     SND_SEQ      Encrypted sequence number field.
        16..23     SGN_CKSUM    Checksum of plaintext padded data,
                                as in RFC 1964.
        24..last   Data         plaintext padded data

       If SEAL_ALG if ffff, and SGN_ALG is 0001:
         8..15     SND_SEQ      Sequence number/direction field,
                                NOT encrypted.
        16..N      SGN_CKSUM    Checksum of bytes 0..15 and
                                application data, with key usage
                                KG_USAGE_SIGN.
       N+1..last   Data         plaintext data


   The direction flag, as in [GSSAPI-KRB5], is made up of bytes
   indicating the party sending the token: 00 for the context initiator,
   or hex FF for the context acceptor.  In the KERBEROS5-ENCRYPT case,
   only two bytes are used, and they replace the fixed filler bytes of
   the token header, which need no protection; this reduces slightly the
   redundancy of the data transmitted.

   The context-deletion token is essentially a MIC token with no user
   data and a different TOK_ID value.  Thus, its modification is
   straightforward.


                          Context deletion token
          Byte #    Name         Description
          -------------------------------------------------------
            0..1    TOK_ID       Identification field (01 02).
            2..3    SGN_ALG      Integrity algorithm indicator.
            4..7    Filler       Contains ff ff ff ff

          If SGN_ALG is 0000, 0100, 0200:
            8..15   SND_SEQ      Sequence number/direction
                                 field, encrypted.
           16..23   SGN_CKSUM    Checksum of bytes 0..7, as
                                 described in [GSSAPI-KRB5].

          If SGN_ALG is 0001:
            8..15   SND_SEQ      Sequence number/direction
                                 field, NOT encrypted.
           16..N    SGN_CKSUM    Checksum of bytes 0..15, with
                                 key usage KG_USAGE_SIGN.






Raeburn                                                         [Page 6]
\f
INTERNET DRAFT                                               August 2003


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 given the task of 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 (for example) AES but the Kerberos implementation
   does.  It means that AES session keys cannot be issued for that
   service principal, which keeps the protection of non-GSSAPI services
   weaker than necessary.

   It would also be possible to have clients attempt to get DES session
   keys before trying to get AES session keys, and have the KDC refuse
   to issue the DES keys only for the most critical of services, for
   which 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 thus recommend 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 sharing service principal
   names with GSSAPI services that have not been updated to support this
   extension.

   [optional:]

   This mechanism extension MUST NOT be used with the DES encryption key
   types described in [KCRYPTO], which ignore the key usage values.






Raeburn                                                         [Page 7]
\f
INTERNET DRAFT                                               August 2003


6. Implementation Note

   At least two implementations have been done of extensions to the RFC
   1964 mechanism for specific non-DES encryption types.  These are not
   standards-track extensions, but implementors may wish to implement
   them as well for compatibility with existing products.  No guidance
   is provided as to when an implementation may wish to use these non-
   standard extensions instead of the extension specified in this
   document.

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

   Remember to check direction flag.  Key usage numbers and direction
   checks?  Considerations depend on the approach taken....

8. Acknowledgements

   Larry Zhu...

9. Normative References

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

   [KCRYPTO]
      draft-ietf-krb-wg-crypto-XX -> RFC xxxx

   [KrbClar]
      draft-ietf-krb-wg-kerberos-clarifications-XX -> RFC xxxx

   [RFC2026]
      RFC 2026 ...

   [RFC2119]
      RFC 2119 ...







Raeburn                                                         [Page 8]
\f
INTERNET DRAFT                                               August 2003


10. Author's Address

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

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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."

Document Change History

Version -XX:

   Split up Abstract and create a real Introduction.  Fix RFC 2026
   reference in Status section.  Added Conventions, Acknowledgements and
   Implementation Note sections.  Updated References with more
   placeholders.  Capitalize some uses of "must" etc.

   Fill in case of Wrap token without integrity protection, using
   KERBEROS5-CHECKSUM for SGN_ALG.  Fix descriptions of which message
   layout is used for which algorithms.




Raeburn                                                         [Page 9]
\f
INTERNET DRAFT                                               August 2003


   Remove discussion of authenticated encryption with additional data.

   Add discussion of 64-bit sequence numbers and data length, and
   alternate handling of the direction flag.


   Version -XX sent in early 2003 to Kerberos working group:

   Initial revision.










































Raeburn                                                        [Page 10]