[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 4121

<Kerberos Working Group>                                      Larry Zhu
Internet Draft                                       Karthik Jaganathan
Updates: 1964                                                 Microsoft
Category: Standards Track                                   Sam Hartman
draft-ietf-krb-wg-gssapi-cfx-01.txt                                 MIT
                                                        August 29, 2003
                                             Expires: February 29, 2004

          The Kerberos Version 5 GSS-API Mechanism: Version 2

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of [RFC-2026].

   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

   [RFC-1964] defines protocols, procedures, and conventions to be
   employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in [RFC-2743]) when
   using the Kerberos Version 5 mechanism (as specified in [KRBCLAR]).

   This memo obsoletes [RFC-1964] and proposes changes in response to
   recent developments such as the introduction of Kerberos crypto
   framework.  It is intended that this memo or a subsequent version
   will become the Kerberos Version 5 GSS-API mechanism specification
   on the standards track.

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

   [KCRYPTO] defines a generic framework for describing encryption and
   checksum types to be used with the Kerberos protocol and associated
   protocols.


Zhu              Standards Trace - February 16, 2003                1 
                  Kerberos Version 5 GSS-API      August 2003


   [RFC-1964] describes the GSSAPI mechanism for Kerberos V5.  It
   defines the format of context initiation, per-message and context
   deletion tokens and uses algorithm identifiers for each cryptosystem
   in per message and context deletion tokens.

   The approach taken in this document obviates the need for algorithm
   identifiers.  This is accomplished by using the same encryption and
   checksum algorithms specified by the crypto profile [KCRYPTO] for
   the session key or subkey that is created during context
   negotiation.  Message layouts of the per-message and context
   deletion tokens are therefore revised to remove algorithm indicators
   and also to add extra information to support the generic crypto
   framework [KCRYPTO].

   Tokens transferred between GSS-API peers for security context
   initiation are also described in this document.  The data elements
   exchanged between a GSS-API endpoint implementation and the Kerberos
   KDC are not specific to GSS-API usage and are therefore defined
   within [KRBCLAR] rather than within this specification.

   The new token formats specified in this memo MUST be used with all
   "newer" encryption types [KRBCLAR] and MAY be used with "older"
   encryption types, provided that the initiator and acceptor know,
   from the context establishment, that they can both process these new
   token formats.

   "Newer" encryption types are those which have been specified along
   with or since the new Kerberos cryptosystem specification [KCRYPTO]
   [KRBCLAR].

   Note that in this document, "AES" is used for brevity to refer
   loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96
   as defined in [AES-KRB5].  AES is used as an example of the new
   method defined in this document.

4. Key Derivation for Per-Message and Context Deletion Tokens

   To limit the exposure of a given key, [KCRYPTO] adopted "one-way"
   "entropy-preserving" derived keys, for different purposes or key
   usages, from a base key or protocol key.  This document defines four
   key usage values below for signing and sealing messages:

        Name                         value
      -------------------------------------
       KG-USAGE-ACCEPTOR-SEAL         22
       KG-USAGE-ACCEPTOR-SIGN         23
       KG-USAGE-INITIATOR-SEAL        24
       KG-USAGE-INITIATOR-SIGN        25

   When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
   used as the usage number in the key derivation function for deriving
   keys to be used in MIC and context deletion tokens, and KG-USAGE-
   ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is
   the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage

Zhu              Standards Track - February 16, 2004                2 
                  Kerberos Version 5 GSS-API      August 2003


   number in the key derivation function for MIC and context deletion
   tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens.  Even if
   the Wrap token does not provide for confidentiality the same usage
   values specified above are used.

5. Quality of Protection

   The GSSAPI specification [RFC-2743] provides for Quality of
   Protection (QOP) values that can be used by the application to
   request a certain type of encryption or signing.  A zero QOP value
   is used to indicate the "default" protection; applications which use
   the default QOP are not guaranteed to be portable across
   implementations or even inter-operate with different deployment
   configurations of the same implementation.  Using an algorithm that
   is different from the one for which the key is defined may not be
   appropriate.  Therefore, when the new method in this document is
   used, the QOP value is ignored.

   The encryption and checksum algorithms in per-message and context
   deletion tokens are now implicitly defined by the algorithms
   associated with the session key or subkey.  Algorithms identifiers
   as described in [RFC-1964] are therefore no longer needed and
   removed from the new token headers.

6. Token Framing

   Per [RFC-2743], all tokens emitted by the Kerberos V5 GSS-API
   mechanism will have the framing shown below:

      GSS-API DEFINITIONS ::=

      BEGIN

      MechType ::= OBJECT IDENTIFIER
      -- representing Kerberos V5 mechanism

      GSSAPI-Token ::=
      -- option indication (delegation, etc.) indicated within
      -- mechanism-specific token
      [APPLICATION 0] IMPLICIT SEQUENCE {
              thisMech MechType,
              innerToken ANY DEFINED BY thisMech
                 -- contents mechanism-specific
                 -- ASN.1 structure not required
              }
      END

   The innerToken field always starts with a two byte token-identifier
   (TOK_ID).  Here are the TOK_ID values:

         Token                       TOK_ID Value in hex
        -------------------------------------------
         KRB_AP_REQUEST                 01 00
         KRB_AP_REQPLY                  02 00

Zhu              Standards Track - February 16, 2004                3 
                  Kerberos Version 5 GSS-API      August 2003


         KRB_ERROR                      03 00
         [RFC-1964] MIC                 01 01
         [RFC-1964] Wrap                01 02
         [RFC-1964] context deletion    02 01
         MIC                            04 04
         Wrap                           04 05
         context deletion               05 04


7. Context Initialization Tokens

   For context initialization tokens, the body for the innerToken field
   contains a Kerberos V5 message (KRB_AP_REQUEST, KRB_AP_REPLY, or
   KRB_ERROR) as defined in [KRBCLAR].

7.1. Authenticator Checksum

   The authenticator in the KRB_AP_REQ message MUST include the
   optional sequence number and the checksum field.  The checksum field
   is used to convey service flags, channel binding, and optional
   delegation information.  It MUST have a type of 0x8003.  The length
   of the checksum MUST be 24 bytes when delegation is not used.  When
   delegation is used, a TGT with its FORWARDABLE flag set will be
   transferred within the KRB_CRED [KRBCLAR] message.

   The format of the authenticator checksum field is as follows.

      Byte    Name      Description
     -----------------------------------------------------------------
      0..3    Lgth    Number of bytes in Bnd field;
                      Currently contains hex 10 00 00 00
                      (16, represented in little-endian form)
      4..19   Bnd     MD5 hash of channel bindings, taken over all
                      non-null components of bindings, in order
                      of declaration.  Integer fields within channel
                      bindings are represented in little-endian order
                      for the purposes of the MD5 calculation.
      20..23  Flags   Bit vector of context-establishment flags,
                      as defined next. The resulting bit vector is
                      encoded into bytes 20..23 in little-endian form.
      24..25  DlgOpt  The Delegation Option identifier (=1) [optional]
      26..27  Dlgth   The length of the Deleg field [optional]
      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional]

   [we need to get input on how to allow additional data for
   extensions.  Nicolas will post some text for this.  If that is the
   case, do we need to change the checksum type?]

7.1.1. Flags Field

   The checksum flags are used to convey service options or extension
   negotiation information.  The bits in the Flags field are allocated
   as follows (Most significant bit is bit 0):

Zhu              Standards Track - February 16, 2004                4 
                  Kerberos Version 5 GSS-API      August 2003


      Bit         Name          Description
    ----------------------------------------------------
      0..11     Mandatory     Critical extension flags
      12..15    Optional      Non-critical extension flags
      16..31    Standard      Context establishment flags

   An extension or context establishment flag can either be critical or
   non-critical.  When the context initiator desires a particular
   extension or context establishment flag (either critical or non-
   critical) it sets the appropriate checksum flag.  The context
   acceptor MUST ignore unsupported non-critical extensions or flags in
   the initiator's context token (i.e., acceptors MUST NOT return an
   error just because there were unsupported non-critical extensions or
   flags in the initiator's token).  The acceptor MUST return
   GSS_S_UNAVAILABLE [RFC-2743] if there are unsupported critical
   extensions or flags in the initiator's context token.

   The following context establishment flags are defined in [RFC-2744]

        Flag Name                Value
      ---------------------------------
       GSS_C_DELEG_FLAG           1
       GSS_C_MUTUAL_FLAG          2
       GSS_C_REPLAY_FLAG          4
       GSS_C_SEQUENCE_FLAG        8
       GSS_C_CONF_FLAG           16
       GSS_C_INTEG_FLAG          32
       GSS_C_ANON_FLAG           64

   Context establishment flags are exposed to the calling application.
   If the calling application desires a particular service option then
   it requests that option via GSS_Init_sec_context().  An
   implementation that supports a particular extension SHOULD then set
   the appropriate flag in the checksum Flags field.

   All existing context establishment flags are non-critical, and it is
   possible that a new context establishment flag can be added as a
   critical flag.

7.1.2. Channel Binding Information

   In computing the contents of the "Bnd" field, the following detailed
   points apply:

   (1) Each integer field shall be formatted into four bytes, using
   little-endian byte ordering, for purposes of MD5 hash computation.

   (2) All input length fields within gss_buffer_desc [RFC-2744]
   elements of a gss_channel_bindings_struct [RFC-2744], even those
   which are zero-valued, shall be included in the hash calculation;
   the value elements of gss_buffer_desc elements shall be
   dereferenced, and the resulting data shall be included within the
   hash computation, only for the case of gss_buffer_desc elements
   having non-zero length specifiers.

Zhu              Standards Track - February 16, 2004                5 
                  Kerberos Version 5 GSS-API      August 2003



   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
   valid channel bindings structure, the Bnd field shall be set to 16
   zero-valued bytes.

   [Nicolas suggested that the only change that might be needed here
   was the use of SHA1 instead of MD5]

8. Per-Message and Context Deletion Tokens

   The new per-message and context deletion token formats defined in
   this document are designed to accommodate the requirements of newer
   crypto systems.  The token layouts have also been designed to
   facilitate scatter-gather and in-place encryption without incurring
   significant performance penalties for implementations that do not
   allow for either scatter-gather or in-place encryption.

   The design along with the rationale behind it is discussed in detail
   in the following sections.

8.1. Sequence Number and Direction Indicator

   The sequence number for any per-message or context deletion token is
   a 64 bit integer (expressed in big endian order).  One separate flag
   is used as the direction-indicator as described in section 8.2.
   Both the sequence number and the direction-indicator are protected
   by the encryption and checksum procedures as specified in section
   8.4.

8.2. Flags Field

   The Flags field is a one-byte bit vector used to indicate a set of
   attributes.  The meanings of the flags are:

        Bit    Name             Description
       ---------------------------------------------------------------
        0     SentByAcceptor  When set, this flag indicates the sender
                              is the context acceptor.  When not set,
                              it indicates the sender is the context
                              initiator.
        1     Sealed          When set in Wrap tokens, this flag
                              indicates confidentiality is provided
                              for.  It MUST not be set in MIC and
                              context deletion tokens.

   The rest of available bits are reserved for future use.

8.3. EC Field

   The EC (Extra Count) field is a two-byte integer field expressed in
   big endian order.



Zhu              Standards Track - February 16, 2004                6 
                  Kerberos Version 5 GSS-API      August 2003


   In Wrap tokens with confidentiality, the EC field is used to encode
   the size (in bytes) of the random filler, as described in section
   8.4.

   In Wrap tokens without confidentiality, the EC field is used to
   encode the size (in bytes) of the trailing checksum, as described in
   section 8.4.

   When AES is used, the EC field contains the hex value 00 0C in Wrap
   tokens without confidentiality, and 00 00 in Wrap tokens with
   confidentiality.

8.4. Encryption and Checksum Operations

   The encryption algorithms defined by the crypto profiles provide for
   integrity protection.  Therefore no separate checksum is needed.

   The result of decryption can be longer than the original plaintext
   [KCRYPTO] and the extra trailing bytes are called "crypto-system
   garbage".  However, given the size of any plaintext data, one can
   always find the next (possibly larger) size so that, when padding
   the to-be-encrypted text to that size, there will be no crypto-
   system garbage added [KCRYPTO].

   In Wrap tokens that provide for confidentiality, the "header" (the
   first 16 bytes of the Wrap token) is appended to the plaintext data
   before encryption.  Random filler is inserted between the plaintext-
   data and the "header", and there SHALL NOT be crypto-system garbage
   added by the decryption operation.  The resulting Wrap token is
   {"header" | encrypt(plaintext-data | random-filler | "header")},
   where encrypt() is the encryption operation (which provides for
   integrity protection) defined in the crypto profile [KCRYPTO].

   [A note from the design team (Sam, Nicolas, Ken, JK and Larry):
   constraints need to be added to kcrypto to keep the header at the
   end of the decrypted data.  Without these constraints, we might have
   the header pre-pended to the front of the data and encode an 8 byte
   length for the plaintext data, which is less efficient.

   Constraints to be added: Given the length of any plaintext data,
   there should always exist the next (possibly larger) size for which,
   when padding the to-be-encrypted data to that size, there will be no
   cryptosystem garbage added, and the number of bytes needed to pad to
   the next size is no larger than 64K.  This is a small addition to
   kcrypto and we will bring it up at the IETF last call for kcrypto]

   In Wrap tokens that do not provide for confidentiality, the checksum
   is calculated over the plaintext data concatenated with the token
   header (the first 16 bytes of the Wrap token).  The resulting Wrap
   token is {"header" | plaintext-data | get_mic(plaintext-data |
   "header")},  where get_mic() is the checksum operation defined in
   the crypto profile [KCRYPTO].


Zhu              Standards Track - February 16, 2004                7 
                  Kerberos Version 5 GSS-API      August 2003


   The parameters for the key and the cipher-state in the encrypt() and
   get_mic() operations have been omitted for brevity.

   The resulting Wrap tokens bind the data to the token header,
   including the sequence number and the directional indicator.

   [With AEAD, Wrap tokens with confidentiality do not need to encrypt
   the header and the overhead can be reduced slightly]

   For MIC tokens, the checksum is first calculated over the token
   header (the first 16 bytes of the MIC token) and then the to-be-
   signed plaintext data.

   For context deletion tokens, the checksum is calculated over the
   token header (the first 16 bytes of the context deletion token).

   When AES is used, the checksum algorithm is HMAC_SHA1_96 and the
   checksum size is 12 bytes.  Data is pre-pended with a 16 byte
   confounder before encryption, and no padding is needed.

8.5. RRC Field

   The RRC (Right Rotation Count) field in Wrap tokens is added to
   allow the data to be encrypted in-place by existing [SSPI]
   applications that do not provide an additional buffer for the
   trailer (the cipher text after the in-place-encrypted data) in
   addition to the buffer for the header (the cipher text before the
   in-place-encrypted data).  The resulting Wrap token in the previous
   section, excluding the first 16 bytes of the token header, is
   rotated to the right by "RRC" bytes.  The net result is that "RRC"
   bytes of trailing octets are moved toward the header.  Consider the
   following as an example of this rotation operation: Assume that the
   RRC value is 3 and the token before the rotation is {"header" | aa |
   bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be
   {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb
   | cc |...| hh} is used to indicate the byte sequence.

   The RRC field is expressed as a two-byte integer in big endian
   order.

   The rotation count value is chosen by the sender based on
   implementation details, and the receiver MUST be able to interpret
   all possible rotation count values.

8.6. Message Layout for Per-message and Context Deletion Tokens

   The new message layouts are as follows.

   MIC Token:

      Byte no           Name           Description
       0..1            TOK_ID       Identification field.
                                    Tokens emitted by GSS_GetMIC()
                                    contain the hex value 04 04 in

Zhu              Standards Track - February 16, 2004                8 
                  Kerberos Version 5 GSS-API      August 2003


                                    this field.
       2               Flags        Attributes field, as described in
                                    Section 8.2.
       3..7            Filler       Contains 5 bytes of hex value FF.
       8..15           SND_SEQ      Sequence number field in
                                    cleartext, in big endian order.
       16..last        SGN_CKSUM    Checksum of byte 0..15 and the
                                    "to-be-signed" data, where the
                                    checksum algorithm is defined by
                                    the crypto profile for the
                                    session key or subkey.


   The Filler field is included in the checksum calculation for
   simplicity.  This is common to both MIC and context deletion token
   checksum calculations.

   Wrap Token:

      Byte no           Name           Description
       0..1            TOK_ID       Identification field.
                                    Tokens emitted by GSS_Wrap()
                                    contain the hex value 05 04
                                    in this field.
       2               Flags        Attributes field, as described in
                                    Section 8.2.
       3               Filler       Contains the hex value FF.
       4..5            EC           Contains the "extra count" field,
                                    in big endian order as described in
                                    section 8.3.
       6..7            RRC          Contains the "right rotation
                                    count" in big endian order, as
                                    described in section 8.5.
       8..15           SND_SEQ      Sequence number field in
                                    cleartext, in big endian order.
       16..last        Data         Encrypted data or (plaintext data +
                                    checksum), as described in section
                                    8.4, where the encryption or
                                    checksum algorithm is defined by
                                    the crypto profile for the session
                                    key or subkey.


   Context Deletion Token:

      Byte no          Name             Description
       0..1           TOK_ID        Identification field.
                                    Tokens emitted by
                                    GSS_Delete_sec_context() contain
                                    the hex value 04 05 in this
                                    field.
       2              Flags         Attributes field, as described in
                                    Section 8.2.

Zhu              Standards Track - February 16, 2004                9 
                  Kerberos Version 5 GSS-API      August 2003


       3..7           Filler        Contains 5 bytes of hex value FF.
       8..15          SND_SEQ       Sequence number field in
                                    cleartext, in big endian order.
       16..N          SGN_CKSUM     Checksum of byte 0..15, where the
                                    checksum algorithm is defined by
                                    the crypto profile for the
                                    session key or subkey.


9. Parameter Definitions

   This section defines parameter values used by the Kerberos V5 GSS-
   API mechanism. It defines interface elements in support of
   portability, and assumes use of C language bindings per [RFC-2744].

9.1. Minor Status Codes

   This section recommends common symbolic names for minor_status
   values to be returned by the Kerberos V5 GSS-API mechanism.  Use of
   these definitions will enable independent implementers to enhance
   application portability across different implementations of the
   mechanism defined in this specification.  (In all cases,
   implementations of GSS_Display_status() will enable callers to
   convert minor_status indicators to text representations.)  Each
   implementation should make available, through include files or other
   means, a facility to translate these symbolic names into the
   concrete values which a particular GSS-API implementation uses to
   represent the minor_status values specified in this section.

   It is recognized that this list may grow over time, and that the
   need for additional minor_status codes specific to particular
   implementations may arise.  It is recommended, however, that
   implementations should return a minor_status value as defined on a
   mechanism-wide basis within this section when that code is
   accurately representative of reportable status rather than using a
   separate, implementation-defined code.

9.1.1. Non-Kerberos-specific codes

      GSS_KRB5_S_G_BAD_SERVICE_NAME
              /* "No @ in SERVICE-NAME name string" */
      GSS_KRB5_S_G_BAD_STRING_UID
              /* "STRING-UID-NAME contains nondigits" */
      GSS_KRB5_S_G_NOUSER
              /* "UID does not resolve to username" */
      GSS_KRB5_S_G_VALIDATE_FAILED
              /* "Validation error" */
      GSS_KRB5_S_G_BUFFER_ALLOC
              /* "Couldn't allocate gss_buffer_t data" */
      GSS_KRB5_S_G_BAD_MSG_CTX
              /* "Message context invalid" */
      GSS_KRB5_S_G_WRONG_SIZE
              /* "Buffer is the wrong size" */
      GSS_KRB5_S_G_BAD_USAGE

Zhu              Standards Track - February 16, 2004               10 
                  Kerberos Version 5 GSS-API      August 2003


              /* "Credential usage type is unknown" */
      GSS_KRB5_S_G_UNKNOWN_QOP
              /* "Unknown quality of protection specified" */

9.1.2. Kerberos-specific-codes

      GSS_KRB5_S_KG_CCACHE_NOMATCH
              /* "Principal in credential cache does not match desired
                 name" */
      GSS_KRB5_S_KG_KEYTAB_NOMATCH
              /* "No principal in keytab matches desired name" */
      GSS_KRB5_S_KG_TGT_MISSING
              /* "Credential cache has no TGT" */
      GSS_KRB5_S_KG_NO_SUBKEY
              /* "Authenticator has no subkey" */
      GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
              /* "Context is already fully established" */
      GSS_KRB5_S_KG_BAD_SIGN_TYPE
              /* "Unknown signature type in token" */
      GSS_KRB5_S_KG_BAD_LENGTH
              /* "Invalid field length in token" */
      GSS_KRB5_S_KG_CTX_INCOMPLETE
              /* "Attempt to use incomplete security context" */

9.2. Buffer Sizes

   All implementations of this specification shall be capable of
   accepting buffers of at least 16K bytes as input to GSS_GetMIC(),
   GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
   the output_token generated by GSS_Wrap() for a 16K byte input buffer
   as input to GSS_Unwrap().  Support for larger buffer sizes is
   optional but recommended.

10. Backwards Compatibility Considerations

   The new token formats defined in this document will only be
   recognized by new implementations.  To address this, implementations
   can always use the explicit sign or seal algorithm in [GSSAPI-KRB5]
   when the key type corresponds to "older" algorithms.  An alternative
   approach might be to retry sending the message with the sign or seal
   algorithm explicitly defined as in [GSSAPI-KRB5].  However this
   would require the use of a mechanism such as [RFC-2478] to securely
   negotiate the algorithm or the use out of band mechanism to choose
   appropriate algorithms.  For this reason, it is RECOMMENDED that the
   new token formats defined in this document can be used only if both
   peers are known during context negotiation to support the new
   mechanism (either because of the use of "new" enctypes or because of
   the use of Kerberos V extensions).

11. Security Considerations

   It is possible that the KDC returns a session-key type that is not
   supported by the GSSAPI implementation (either on the client and the
   server). In this case the implementation MUST not try to use the key

Zhu              Standards Track - February 16, 2004               11 
                  Kerberos Version 5 GSS-API      August 2003


   with a supported cryptosystem. This will ensure that no security
   weaknesses arise due to the use of an inappropriate key with an
   encryption algorithm.

   In addition the security problem described in [3DES] arising from
   the use of a service implementation with a GSSAPI mechanism
   supporting only DES and a Kerberos mechanism supporting both DES and
   Triple DES is actually a more generic one.  It arises whenever the
   GSSAPI implementation does not support a stronger cryptosystem
   supported by the Kerberos mechanism.  KDC administrators desiring to
   limit the session key types to support interoperability with such
   GSSAPI implementations should carefully weigh the reduction in
   protection offered by such mechanisms against the benefits of
   interoperability.


12. Acknowledgments

  The authors wish to acknowledge the contributions from the following
  individuals:

  Ken Raeburn and Nicolas Willams corrected many of our errors in the
  use of generic profiles and were instrumental in the creation of this
  draft.

  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea.

  Sam Hartman and Nicolas Williams recommended the replacing our
  earlier key derivation function for directional keys with different
  key usage numbers for each direction as well as retaining the
  directional bit for maximum compatibility.

  Paul Leach provided numerous suggestions and comments.

  Scott Field, Richard Ward, Dan Simon also provided valuable inputs on
  this draft.

13. References

13.1. Normative References

   [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
   3", BCP 9, RFC 2026, October 1996.

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [AES] National Institute of Standards and Technology, U.S.
   Department of Commerce, "Advanced Encryption Standard", Federal
   Information Processing Standards Publication 197, Washington, DC,
   November 2001.



Zhu              Standards Track - February 16, 2004               12 
                  Kerberos Version 5 GSS-API      August 2003


   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress.

   [3DES] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI
   Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT
   distribution, June 2000.

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

   [RFC-2744] Wray, J., "Generic Security Service API Version 2 : C-
   bindings", RFC 2744, January 2000.

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

   [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
   Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003.  Work in
   progress.

   [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,
   Raeburn, K., "The Kerveros Network Authentication Service (V5)",
   draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002.
   Work in progress.

   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API
   Negotiation Mechanism.", RFC 2478, December 1998.

13.2. Informative References

   [SSPI] Leach, P., Security Service Provider Interface, MSDN, April
   2003

14. Author's Address

   Larry Zhu
   One Microsoft Way
   Redmond, WA 98052 - USA
   EMail: LZhu@microsoft.com

   Karthik Jaganathan
   One Microsoft Way
   Redmond, WA 98052 - USA
   EMail: karthikj@microsoft.com

   Sam Hartman
   Massachusetts Institute of Technology
   77 Massachusetts Avenue
   Cambridge, MA 02139 - USA
   Email: hartmans@MIT.EDU


Zhu              Standards Track - February 16, 2004               13 
                  Kerberos Version 5 GSS-API      August 2003



Full Copyright Statement

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
































Zhu              Standards Track - February 16, 2004               14


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/