rfc1964.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,124 行 · 第 1/4 页

Linn                        Standards Track                     [Page 5]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   flags field of the authenticator checksum.  In response to such a
   request, the context target will reply to the initiator with a token
   containing either a KRB_AP_REP or KRB_ERROR, completing the mutual
   context establishment exchange.

   Relevant KRB_AP_REP syntax is as follows:

   AP-REP ::= [APPLICATION 15] SEQUENCE {
           pvno [0]        INTEGER,        -- represents Kerberos V5
           msg-type [1]    INTEGER,        -- represents KRB_AP_REP
           enc-part [2]    EncryptedData
   }

   EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
           ctime [0]       KerberosTime,
           cusec [1]       INTEGER,
           subkey [2]      EncryptionKey OPTIONAL,
           seq-number [3]  INTEGER OPTIONAL
   }

   The optional seq-number element within the AP-REP's EncAPRepPart
   shall be included.

   The syntax of KRB_ERROR is as follows:

   KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
           pvno[0]         INTEGER,
           msg-type[1]     INTEGER,
           ctime[2]        KerberosTime OPTIONAL,
           cusec[3]        INTEGER OPTIONAL,
           stime[4]        KerberosTime,
           susec[5]        INTEGER,
           error-code[6]   INTEGER,
           crealm[7]       Realm OPTIONAL,
           cname[8]        PrincipalName OPTIONAL,
           realm[9]        Realm, -- Correct realm
           sname[10]       PrincipalName, -- Correct name
           e-text[11]      GeneralString OPTIONAL,
           e-data[12]      OCTET STRING OPTIONAL
   }

   Values to be transferred in the error-code field of a KRB-ERROR
   message are defined in [RFC-1510], not in this specification.








Linn                        Standards Track                     [Page 6]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


1.2. Per-Message and Context Deletion Tokens

   Three classes of tokens are defined in this section: "MIC" tokens,
   emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and consumed
   by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens,
   emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed by
   calls to GSS_Unwrap() (formerly GSS_Unseal()), and context deletion
   tokens, emitted by calls to GSS_Delete_sec_context() and consumed by
   calls to GSS_Process_context_token().  Note: References to GSS-API
   per-message routines in the remainder of this specification will be
   based on those routines' newer recommended names rather than those
   names' predecessors.

   Several variants of cryptographic keys are used in generation and
   processing of per-message tokens:

        (1) context key: uses Kerberos session key (or subkey, if
        present in authenticator emitted by context initiator) directly

        (2) confidentiality key: forms variant of context key by
        exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.

        (3) MD2.5 seed key: forms variant of context key by reversing
        the bytes of the context key (i.e. if the original key is the
        8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
        will be {hh, gg, ff, ee, dd, cc, bb, aa}).

1.2.1. Per-message Tokens - MIC

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:

   Byte no          Name           Description
    0..1           TOK_ID          Identification field.
                                   Tokens emitted by GSS_GetMIC() contain
                                   the hex value 01 01 in this field.
    2..3           SGN_ALG         Integrity algorithm indicator.
                                   00 00 - DES MAC MD5
                                   01 00 - MD2.5
                                   02 00 - DES MAC
    4..7           Filler          Contains ff ff ff ff
    8..15          SND_SEQ         Sequence number field.
    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
                                   calculated according to algorithm
                                   specified in SGN_ALG field.





Linn                        Standards Track                     [Page 7]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   GSS-API tokens must be encapsulated within the higher-level protocol
   by the application; no embedded length field is necessary.

1.2.1.1. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the data field, logically prepended by the first
   8 bytes of the plaintext packet header.  The resulting value binds
   the data to the packet type and signature algorithm identifier
   fields.

   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
   [RFC-1321] hash over the plaintext data, and then computing a DES-CBC
   MAC on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is
   computed per [FIPS-PUB-113], employing the context key and a zero IV.
   The 8-byte result is stored in the SGN_CKSUM field.

   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
   16-byte zero-block, using a zero IV and a key formed by reversing the
   bytes of the context key (i.e. if the original key is the 8-byte
   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
   {hh, gg, ff, ee, dd, cc, bb, aa}).   The resulting 16-byte value is
   logically prepended to the to-be-signed data.  A standard MD5
   checksum is calculated over the combined data, and the first 8 bytes
   of the result are stored in the SGN_CKSUM field.  Note 1: we refer to
   this algorithm informally as "MD2.5" to connote the fact that it uses
   half of the 128 bits generated by MD5; use of only a subset of the
   MD5 bits is intended to protect against the prospect that data could
   be postfixed to an existing message with corresponding modifications
   being made to the checksum.  Note 2: This algorithm is fairly novel
   and has received more limited evaluation than that to which other
   integrity algorithms have been subjected.  An initial, limited
   evaluation indicates that it may be significantly weaker than DES MAC
   MD5.

   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
   plaintext data per [FIPS-PUB-113], employing the context key and a
   zero IV. Padding procedures to accomodate plaintext data lengths
   which may not be integral multiples of 8 bytes are defined in [FIPS-
   PUB-113].  The result is an 8-byte value, which is stored in the
   SGN_CKSUM field.  Support for this algorithm may not be present in
   all implementations.

1.2.1.2. Sequence Number

   Sequence number field: The 8 byte plaintext sequence number field is
   formed from the sender's four-byte sequence number as follows.  If
   the four bytes of the sender's sequence number are named s0, s1, s2



Linn                        Standards Track                     [Page 8]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   and s3 (from least to most significant), the plaintext sequence
   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
   di), where 'di' is the direction-indicator (Hex 0 - sender is the
   context initiator, Hex FF - sender is the context acceptor).  The
   field is then DES-CBC encrypted using the context key and an IV
   formed from the first 8 bytes of the previously calculated SGN_CKSUM
   field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
   sequence number is incremented by one.

   The receiver of the token will first verify the SGN_CKSUM field.  If
   valid, the sequence number field may be decrypted and compared to the
   expected sequence number.  The repetition of the (effectively 1-bit)
   direction indicator within the sequence number field provides
   redundancy so that the receiver may verify that the decryption
   succeeded.

   Since the checksum computation is used as an IV to the sequence
   number decryption, attempts to splice a checksum and sequence number
   from different messages will be detected.  The direction indicator
   will detect packets that have been maliciously reflected.

   The sequence number provides a basis for detection of replayed
   tokens.  Replay detection can be performed using state information
   retained on received sequence numbers, interpreted in conjunction
   with the security context on which they arrive.

   Provision of per-message replay and out-of-sequence detection
   services is optional for implementations of the Kerberos V5 GSS-API
   mechanism.  Further, it is recommended that implementations of the
   Kerberos V5 GSS-API mechanism which offer these services should honor
   a caller's request that the services be disabled on a context.
   Specifically, if replay_det_req_flag is input FALSE, replay_det_state
   should be returned FALSE and the GSS_DUPLICATE_TOKEN and
   GSS_OLD_TOKEN stati should not be indicated as a result of duplicate
   detection when tokens are processed; if sequence_req_flag is input
   FALSE, sequence_state should be returned FALSE and
   GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati should
   not be indicated as a result of out-of-sequence detection when tokens
   are processed.

1.2.2. Per-message Tokens - Wrap

   Use of the GSS_Wrap() call yields a token which encapsulates the
   input user data (optionally encrypted) along with associated
   integrity check quantities. The token emitted by GSS_Wrap() consists
   of an integrity header whose format is identical to that emitted by
   GSS_GetMIC() (except that the TOK_ID field contains the value 02 01),
   followed by a body portion that contains either the plaintext data



Linn                        Standards Track                     [Page 9]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   (if SEAL_ALG = ff ff) or encrypted data for any other supported value
   of SEAL_ALG.  Currently, only SEAL_ALG = 00 00 is supported, and
   means that DES-CBC encryption is being used to protect the data.

   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 hex value 02 01 in this field.
    2..3           SGN_ALG         Checksum algorithm indicator.
                                   00 00 - DES MAC MD5
                                   01 00 - MD2.5
                                   02 00 - DES MAC
    4..5           SEAL_ALG        ff ff - none
                                   00 00 - DES
    6..7           Filler          Contains ff ff
    8..15          SND_SEQ         Encrypted sequence number field.
    16..23         SGN_CKSUM       Checksum of plaintext padded data,
                                   calculated according to algorithm
                                   specified in SGN_ALG field.
    24..last       Data            encrypted or plaintext padded data

   GSS-API tokens must be encapsulated within the higher-level protocol
   by the application; no embedded length field is necessary.

1.2.2.1. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the plaintext padded data field, logically
   prepended by the first 8 bytes of the plaintext packet header.  The
   resulting signature binds the data to the packet type, protocol
   version, and signature algorithm identifier fields.

   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
   hash over the plaintext padded data, and then computing a DES-CBC MAC
   on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is computed
   per [FIPS-PUB-113], employing the context key and a zero IV. The 8-
   byte result is stored in the SGN_CKSUM field.

   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
   16-byte zero-block, using a zero IV and a key formed by reversing the
   bytes of the context key (i.e., if the original key is the 8-byte
   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
   {hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
   logically pre-pended to the "to-be-signed data".  A standard MD5
   checksum is calculated over the combined data, and the first 8 bytes
   of the result are stored in the SGN_CKSUM field.



Linn                        Standards Track                    [Page 10]