s4:torture: Adapt KDC canon test to Heimdal upstream changes

[samba.git] / source4 / heimdal / doc / standardisation / draft-ietf-krb-wg-gssapi-cfx-01.txt

<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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f
                  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 \f