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

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

 

<Network Working Group>                                       Larry Zhu 
Internet Draft                                       Karthik Jaganathan 
Updates: 1964                                                 Microsoft 
Category: Standards Track                                   Sam Hartman 
draft-ietf-krb-wg-gssapi-cfx-02.txt                                 MIT 
                                                     September 29, 2003 
                                                Expires: March 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. 
    
Abstract 
    
   This memo defines protocols, procedures, and conventions to be 
   employed by peers implementing the Generic Security Service 
   Application Program Interface (GSS-API as specified in [RFC-2743]) 
   when using the Kerberos Version 5 mechanism (as specified in 
   [KRBCLAR]). 
    
   [RFC-1964] is updated and incremental changes are proposed in 
   response to recent developments such as the introduction of Kerberos 
   crypto framework [KCRYPTO].  These changes support the inclusion of 
   new cryptosystems based on crypto profiles [KCRYPTO], by defining 
   new per-message and context-deletion tokens along with their 
   encryption and checksum algorithms.   
    
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]. 
    
1. Introduction 
    

  
Zhu                         Internet Draft                           1 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
   [KCRYPTO] defines a generic framework for describing encryption and 
   checksum types to be used with the Kerberos protocol and associated 
   protocols. 
    
   [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.  
   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], 
   as defined in section 3.1.3 of [KRBCLAR]. 
    
   Note that in this document, the term "little endian order" is used 
   for brevity to refer to the least-significant-byte-first encoding, 
   while the term "big endian order" is for the most-significant-byte-
   first encoding. 
    
2. 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 
          

Zhu                         Internet Draft                           2 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
   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 
   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. 
    
   During context initiation, the acceptor MAY assert a subkey, and if 
   so, subsequent messages MUST use this subkey as the protocol key and 
   these messages MUST be flagged as "AcceptorSubkey" as described in 
   section 4.2.2. 
    
3. Quality of Protection 
 
   The GSS-API specification [RFC-2743] provides for Quality of 
   Protection (QOP) values that can be used by applications 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. 
 
4. Definitions and Token Formats 
    
   This section provides terms and definitions, as well as descriptions 
   for tokens specific to the Kerberos Version 5 GSS-API mechanism. 
    
4.1. Initial Context Tokens 
    
   Per [RFC-2743], all context initiation 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 

Zhu                         Internet Draft                           3 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
         [APPLICATION 0] IMPLICIT SEQUENCE { 
                 thisMech MechType, 
                 innerToken ANY DEFINED BY thisMech 
                    -- contents mechanism-specific 
                    -- ASN.1 structure not required 
                 } 
    
         END 
    
   The innerToken field starts with a two-byte token-identifier 
   (TOK_ID) expressed in big endian order, followed by a Kerberos 
   message.   
    
   Here are the TOK_ID values used in the initial tokens: 
    
         Token               TOK_ID Value in Hex  
        ----------------------------------------- 
         KRB_AP_REQUEST        01 00 
         KRB_AP_REPLY          02 00 
         KRB_ERROR             03 00 
             
   Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 
   are defined in [KRBCLAR].   
    
   If an unknown token ID is received in the first context token, the 
   receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the 
   returned output token MUST contain a KRB_ERROR message with the 
   error code KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 
    
4.1.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 bindings, 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 ticket-granting ticket will be transferred in 
   a KRB_CRED message.  The ticket SHOULD have its forwardable flag 
   set.  The KRB_CRED message MUST be encrypted in the session key of 
   the ticket used to authenticate the context. 
    
   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 value 10 00 00 00 (16, represented in little- 
                      endian order) 
      4..19   Bnd     Channel binding information, as describe in  
                      section 4.1.1.2. 
      20..23  Flags   Four-byte context-establishment flags in little- 
                      endian order as described in section 4.1.1.1.  
      24..25  DlgOpt  The Delegation Option identifier (=1) [optional] 
      26..27  Dlgth   The length of the Deleg field [optional] 


Zhu                         Internet Draft                           4 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
      28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional] 
 
4.1.1.1. Checksum Flags Field 
    
   The checksum "Flags" field is used to convey service options or 
   extension negotiation information.  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() [RFC-2743].  An 
   implementation that supports a particular option or extension SHOULD 
   then set the appropriate flag in the checksum Flags field.   
    
   The receiver MUST ignore unknown checksum flags. 
    
4.1.1.2. Channel Binding Information 
 
   Channel bindings are user-specified tags to identify a given context 
   to the peer application.  These tags are intended to be used to 
   identify the particular communications channel that carries the 
   context. 
    
   When using C language bindings, channel bindings are communicated to 
   the GSS-API using the following structure [RFC-2744]: 
 
      typedef struct gss_channel_bindings_struct { 
         OM_uint32       initiator_addrtype; 
         gss_buffer_desc initiator_address; 
         OM_uint32       acceptor_addrtype; 
         gss_buffer_desc acceptor_address; 
         gss_buffer_desc application_data; 
      } *gss_channel_bindings_t; 
    
   The member fields and constants used for different address types are 
   defined in [RFC-2744]. 
    
   The "Bnd" field contains the 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. 
    
   In computing the contents of the Bnd field, the following detailed 
   points apply:  


Zhu                         Internet Draft                           5 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
    
   (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 elements of a 
   gss_channel_bindings_struct 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.  
    
   (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 
   valid channel binding structure, the Bnd field shall be set to 16 
   zero-valued bytes.  
 
4.2. Per-Message and Context Deletion Tokens 
    
   Three classes of tokens are defined in this section:  "MIC" tokens, 
   emitted by calls to GSS_GetMIC() and consumed by calls to 
   GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 
   consumed by calls to GSS_Unwrap(), and context deletion tokens, 
   emitted by calls to GSS_Delete_sec_context() and consumed by calls 
   to GSS_Process_context_token(). 
    
   The new per-message and context deletion tokens introduced here do 
   not include the pseudo ASN.1 header used by the initial context 
   tokens.  These new tokens are designed to be used with newer crypto 
   systems that can, for example, have variable-size checksums.   
    
4.2.1. Sequence Number and Direction Indicator 
 
   To distinguish intentionally-repeated messages from maliciously-
   replayed ones, per-message and context deletion tokens contain a 
   sequence number field, which is a 64 bit integer expressed in big 
   endian order.  One separate bit is used as the direction-indicator 
   in the Flags field as described in section 4.2.2, thus preventing an 
   adversary from sending back the same message in the reverse 
   direction and having it accepted.  Both the sequence number and the 
   direction-indicator are protected by the encryption and checksum 
   procedures specified in section 4.2.4.  
    
   After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's 
   sequence numbers are incremented by one. 
 
4.2.2. Flags Field 
 
   The "Flags" field is a one-byte integer used to indicate a set of 
   attributes.  The meanings of bits in this field (the least 
   significant bit is bit 0) are as follows: 
    
        Bit    Name             Description 
       --------------------------------------------------------------- 
        0   SentByAcceptor    When set, this flag indicates the sender  
                              is the context acceptor.  When not set, 


Zhu                         Internet Draft                           6 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
                              it indicates the sender is the context  
                              initiator. 
        1   Sealed            When set in Wrap tokens, this flag  
                              indicates confidentiality is provided  
                              for.  It SHALL NOT be set in MIC and  
                              context deletion tokens. 
        2   AcceptorSubkey    A subkey asserted by the context acceptor 
                              is used to protect the message. 
    
   The rest of available bits are reserved for future use and MUST be 
   cleared.  The receiver MUST ignore unknown flags. 
    
4.2.3. EC Field 
 
   The "EC" (Extra Count) field is a two-byte integer field expressed 
   in big endian order.   
    
   In Wrap tokens with confidentiality, the EC field is used to encode 
   the number of bytes in the filler, as described in section 4.2.4. 
    
   In Wrap tokens without confidentiality, the EC field is used to 
   encode the number of bytes in the trailing checksum, as described in 
   section 4.2.4.   
 
4.2.4. Encryption and Checksum Operations 
    
   The encryption algorithms defined by the crypto profiles provide for 
   integrity protection [KCRYPTO].  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 first 16 bytes 
   of the Wrap token (the "header") are appended to the plaintext data 
   before encryption.  Filler bytes can be inserted between the 
   plaintext-data and the "header", and the values and size of the 
   filler octets are chosen by implementations, such that there is no 
   crypto-system garbage present after the decryption.  The resulting 
   Wrap token is {"header" | encrypt(plaintext-data | filler | 
   "header")}, where encrypt() is the encryption operation (which 
   provides for integrity protection) defined in the crypto profile 
   [KCRYPTO], and the RRC field in the to-be-encrypted header contains 
   the hex value 00 00.   
           
   In Wrap tokens that do not provide for confidentiality, the checksum 
   is calculated first over the plaintext data, and then the first 16 
   bytes of the Wrap token (the "header").  Both the EC field and the 
   RRC field in the token header are filled with zeroes for the purpose 
   of calculating the checksum.  The resulting Wrap token is {"header" 


Zhu                         Internet Draft                           7 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
   | plaintext-data | get_mic(plaintext-data | "header")},  where 
   get_mic() is the checksum operation defined in the crypto profile 
   [KCRYPTO].  
    
   The parameters for the key and the cipher-state in the encrypt() and 
   get_mic() operations have been omitted for brevity.   
        
   For MIC tokens, the checksum is first calculated over the first 16 
   bytes of the MIC token and then the to-be-signed plaintext data.   
   
   The resulting Wrap and MIC tokens bind the data to the token header, 
   including the sequence number and the directional indicator.  
   
   For context deletion tokens, the checksum is calculated over the 
   first 16 bytes of the token message. 
   
4.2.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. 
 
4.2.6. Message Layouts 
    
   Per-message and context deletion token messages start with a two-
   byte token identifier (TOK_ID) field, expressed in big endian order. 
   These tokens are defined separately in subsequent sub-sections. 
    
4.2.6.1. MIC Tokens 
    
   Use of the GSS_GetMIC() call yields a token, separate from the user  
   data being protected, which can be used to verify the integrity of  
   that data as received.  The token has the following format: 
    

Zhu                         Internet Draft                           8 \f
                 Kerberos Version 5 GSS-API      September 2003 
 

      Byte no     Name       Description 
      -----------------------------------------------------------------  
       0..1     TOK_ID     Identification field.  Tokens emitted by  
                           GSS_GetMIC() contain the hex value 04 04  
                           expressed in big endian order in this field. 
       2        Flags      Attributes field, as described in section  
                           4.2.2. 
       3..7     Filler     Contains five bytes of hex value FF. 
       8..15    SND_SEQ    Sequence number field in clear text,  
                           expressed 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. 
    
4.2.6.2. Wrap Tokens 
    
   Use of the GSS_Wrap() call yields a token, which consists of a 
   descriptive header, followed by a body portion that contains either 
   the input user data in plaintext concatenated with the checksum, or 
   the input user data encrypted.  The GSS_Wrap() token has the 
   following format: 
    
      Byte no     Name       Description 
      --------------------------------------------------------------- 
       0..1     TOK_ID     Identification field.  Tokens emitted by  
                           GSS_Wrap() contain the the hex value 05 04                 
                           expressed in big endian order in this field. 
       2        Flags      Attributes field, as described in section  
                           4.2.2. 
       3        Filler     Contains the hex value FF. 
       4..5     EC         Contains the "extra count" field, in big  
                           endian order as described in section 4.2.3. 
       6..7     RRC        Contains the "right rotation count" in big  
                           endian order, as described in section 4.2.5. 
       8..15    SND_SEQ    Sequence number field in clear text, 
                           expressed in big endian order. 
       16..last Data       Encrypted data for Wrap tokens with  
                           confidentiality, or plaintext data followed  
                           by the checksum for Wrap tokens without  
                           confidentiality, as described in section  
                           4.2.4, where the encryption or checksum 
                           algorithm is defined by the crypto profile  
                           for the session key or subkey. 
                                   
4.2.6.3. Context Deletion Tokens        
    
   The token emitted by GSS_Delete_sec_context() is based on the packet 
   format for tokens emitted by GSS_GetMIC().  The context-deletion 
   token has the following format: 
    

Zhu                         Internet Draft                           9 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
      Byte no     Name       Description 
      ----------------------------------------------------------------- 
       0..1     TOK_ID     Identification field.  Tokens emitted by  
                           GSS_Delete_sec_context() contain the hex  
                           value 04 05 expressed in big endian order in  
                           this field. 
       2        Flags      Attributes field, as described in section  
                           4.2.2. 
       3..7     Filler     Contains five bytes of hex value FF. 
       8..15    SND_SEQ    Sequence number field in clear text,  
                           expressed 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. 
                                 
5. 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]. 
    
5.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.  
    
5.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" */ 


Zhu                         Internet Draft                          10 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
      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 
              /* "Credential usage type is unknown" */ 
      GSS_KRB5_S_G_UNKNOWN_QOP 
              /* "Unknown quality of protection specified" */ 
    
5.1.2. Kerberos-specific-codes 
    
      GSS_KRB5_S_KG_CCACHE_NOMATCH  
              /* "Client principal in credentials does not match   
                 specified name" */ 
      GSS_KRB5_S_KG_KEYTAB_NOMATCH 
              /* "No key available for specified service principal" */ 
      GSS_KRB5_S_KG_TGT_MISSING 
              /* "No Kerberos ticket-granting ticket available" */ 
      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" */ 
 
5.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. 
 
6. 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 [RFC-1964] 
   when the key type corresponds to "older" enctypes.  An alternative 
   approach might be to retry sending the message with the sign or seal 
   algorithm explicitly defined as in [RFC-1964].  However this would 
   require either the use of a mechanism such as [RFC-2478] to securely 
   negotiate the method or the use out of band mechanism to choose 
   appropriate mechanism.  For this reason, it is RECOMMENDED that the 
   new token formats defined in this document SHOULD be used only if 
   both peers are known to support the new mechanism during context 
   negotiation, for example, either because of the use of "new" 
   enctypes or because of the use of Kerberos Version 5 extensions. 

 
Zhu                         Internet Draft                          11 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
7. Security Considerations 
    
   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 [AES-KRB5] 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.  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. 
    
8. Acknowledgments 
   
  The authors wish to acknowledge the contributions from the following 
  individuals:  
 
  Ken Raeburn and Nicolas Williams corrected many of our errors in the 
  use of generic profiles and were instrumental in the creation of this 
  draft.  
   
  The text for security considerations was contributed by Ken Raeburn. 
   
  Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 
  namely the encoding of the RRC field.   
   
  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, and Kevin Damour also provided 
  valuable inputs on this draft. 
   
  Jeffrey Hutzelman provided comments on channel bindings and suggested 
  many editorial changes. 
 
  This document retains some of the text of RFC-1964 in relevant 
  sections. 

Zhu                         Internet Draft                          12 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
   
9. References 
    
9.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. 
    
   [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. 
    
   [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
   raeburn-krb-rijndael-krb-05.txt, June 2003.  Work in progress.  
    
   [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 
   Negotiation Mechanism", RFC 2478, December 1998. 
 
9.2. Informative References 
 
   [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 
   Developer Network (MSDN), April 2003. 
    
10. 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 
 
Zhu                         Internet Draft                          13 \f
                 Kerberos Version 5 GSS-API      September 2003 
 
 
   Sam Hartman 
   Massachusetts Institute of Technology 
   77 Massachusetts Avenue 
   Cambridge, MA 02139 - USA 
   Email: hartmans@MIT.EDU 
    
    















































Zhu                         Internet Draft                          14 \f
                 Kerberos Version 5 GSS-API      September 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. 
    
   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. 
    

























Zhu                         Internet Draft                          15 \f