rfc2025.txt

RFC 的详细文档！

   Since the sequence number is used as part of the input to the
   integrity checksum, sequence numbers need not be encrypted, and
   attempts to splice a checksum and sequence number from different
   messages will be detected.  The direction indicator will detect
   tokens which have been maliciously reflected.

3.2.2. Per-message Tokens - Seal / Wrap

   Use of the gss_seal() / 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_seal() / gss_wrap() consists of an integrity header followed by a
   body portion that contains either the plaintext data (if conf-alg =
   NULL) or encrypted data (using the appropriate subkey specified in
   Section 2.4 for one of the agreed C-ALGs for this context).

   The SPKM-WRAP token has the following format:

   SPKM-WRAP ::= SEQUENCE {
           wrap-header       Wrap-Header,
           wrap-body         Wrap-Body
   }

   Wrap-Header ::= SEQUENCE {
           tok-id           INTEGER (513),
                                -- shall contain 0201 (hex)
           context-id       Random-Integer,
           int-alg [0]      AlgorithmIdentifier OPTIONAL,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- field not present = default id.





Adams                       Standards Track                    [Page 22]

RFC 2025                          SPKM                      October 1996


           conf-alg [1]     Conf-Alg OPTIONAL,
                                -- Confidentiality algorithm indicator
                                -- (must be NULL or one of the agreed
                                -- confidentiality algorithms for this
                                -- context).
                                -- field not present = default id.
                                -- NULL = none (no conf. applied).
           snd-seq [2]      SeqNum OPTIONAL
                                -- sequence number field.
   }



   Wrap-Body ::= SEQUENCE {
           int-cksum        BIT STRING,
                                -- Checksum of header and data,
                                -- calculated according to algorithm
                                -- specified in int-alg field.
           data             BIT STRING
                                -- encrypted or plaintext data.
   }

   Conf-Alg ::= CHOICE {
           algId [0]        AlgorithmIdentifier,
           null [1]         NULL
   }


3.2.2.1: Confounding

   As in [KRB5], an 8-byte random confounder is prepended to the data to
   compensate for the fact that an IV of zero is used for encryption.
   The result is referred to as the "confounded" data field.

3.2.2.2. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the plaintext data field, logically prepended by
   the bytes of the plaintext token header (wrap-header).  As with
   gss_sign() / gss_getMIC(), the result binds the data to the entire
   plaintext header, so as to minimize the possibility of malicious
   splicing.

   The examples for md5WithRSA and DES-MAC are exactly as specified in
   3.2.1.1.

   If int-alg specifies md5-DES-CBC and conf-alg specifies anything
   other than DES-CBC, then the checksum is computed according to



Adams                       Standards Track                    [Page 23]

RFC 2025                          SPKM                      October 1996


   3.2.1.1 and the result is stored in int-cksum.  However, if conf-alg
   specifies DES-CBC then the encryption and the integrity are done as
   follows.  An MD5 [RFC-1321] hash is computed over the plaintext data
   (prepended by the header).  This 16-byte value is appended to the
   concatenation of the "confounded" data and 1-8 padding bytes (the
   padding is as specified in [KRB5] for DES-CBC).  The result is then
   CBC encrypted using the DES-CBC subkey (see Section 2.4) and placed
   in the "data" field of Wrap-Body.  The final two blocks of ciphertext
   (i.e., the encrypted MD5 hash) are also placed in the int-cksum field
   of Wrap-Body as the integrity checksum.

   If int-alg specifies sum64-DES-CBC then conf-alg must specify DES-CBC
   (i.e., confidentiality must be requested by the calling application
   or SPKM will return an error).  Encryption and integrity are done in
   a single pass using the DES-CBC subkey as follows.  The sum (modulo
   2**64 - 1) of all plaintext data blocks (prepended by the header) is
   computed.  This 8-byte value is appended to the concatenation of the
   "confounded" data and 1-8 padding bytes (the padding is as specified
   in [KRB5] for DES-CBC).  As above, the result is then CBC encrypted
   and placed in the "data" field of Wrap-Body. The final block of
   ciphertext (i.e., the encrypted sum) is also placed in the int-cksum
   field of Wrap-Body as the integrity checksum.

3.2.2.3 Sequence Number

   Sequence numbers are computed and processed for gss_wrap() exactly as
   specified in 3.2.1.2 and 3.2.1.3.

3.2.2.4: Data Encryption

   The following procedure is followed unless (a) conf-alg is NULL (no
   encryption), or (b) conf-alg is DES-CBC and int-alg is md5-DES-CBC
   (encryption as specified in 3.2.2.2), or (c) int-alg is sum64-DES-CBC
   (encryption as specified in 3.2.2.2):

   The "confounded" data is padded and encrypted according to the
   algorithm specified in the conf-alg field.  The data is encrypted
   using CBC with an IV of zero.  The key used is the appropriate subkey
   derived from the established context key using the subkey derivation
   algorithm described in Section 2.4 (this ensures that the subkey used
   for encryption and the subkey used for a separate, keyed integrity
   algorithm -- for example DES-MAC, but not sum64-DES-CBC -- are
   different).

3.2.3. Context deletion token

   The token emitted by gss_delete_sec_context() is based on the format
   for tokens emitted by gss_sign() / gss_getMIC().



Adams                       Standards Track                    [Page 24]

RFC 2025                          SPKM                      October 1996


   The SPKM-DEL token has the following format:

   SPKM-DEL ::= SEQUENCE {
           del-header       Del-Header,
           int-cksum        BIT STRING
                                -- Checksum of header, calculated
                                -- according to algorithm specified
                                -- in int-alg field.
   }

   Del-Header ::= SEQUENCE {
           tok-id           INTEGER (769),
                                -- shall contain 0301 (hex)
           context-id       Random-Integer,
           int-alg [0]      AlgorithmIdentifier OPTIONAL,
                                -- Integrity algorithm indicator (must
                                -- be one of the agreed integrity
                                -- algorithms for this context).
                                -- field not present = default id.
           snd-seq [1]      SeqNum OPTIONAL
                                -- sequence number field.
   }

   The field snd-seq will be calculated as for tokens emitted by
   gss_sign() / gss_getMIC().  The field int-cksum will be calculated as
   for tokens emitted by gss_sign() / gss_getMIC(), except that the
   user-data component of the checksum data will be a zero-length
   string.

   If a valid delete token is received, then the SPKM implementation
   will delete the context and gss_process_context_token() will return a
   major status of GSS_S_COMPLETE and a minor status of
   GSS_SPKM_S_SG_CONTEXT_DELETED.  If, on the other hand, the delete
   token is invalid, the context will not be deleted and
   gss_process_context_token() will return the appropriate major status
   (GSS_S_BAD_SIG, for example) and a minor status of
   GSS_SPKM_S_SG_BAD_DELETE_TOKEN_RECD.  The application may wish to
   take some action at this point to check the context status (such as
   sending a sealed/wrapped test message to its peer and waiting for a
   sealed/wrapped response).

4. Name Types and Object Identifiers

   No mandatory name forms have yet been defined for SPKM.  This section
   is for further study.






Adams                       Standards Track                    [Page 25]

RFC 2025                          SPKM                      October 1996


4.1. Optional Name Forms

   This section discusses name forms which may optionally be supported
   by implementations of the SPKM GSS-API mechanism.  It is recognized
   that OS-specific functions outside GSS-API are likely to exist in
   order to perform translations among these forms, and that GSS-API
   implementations supporting these forms may themselves be layered atop
   such OS-specific functions.  Inclusion of this support within GSS-API
   implementations is intended as a convenience to applications.

4.1.1. User Name Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) user_name(1)}.  The recommended symbolic name for this
   type is "GSS_SPKM_NT_USER_NAME".

   This name type is used to indicate a named user on a local system.
   Its interpretation is OS-specific.  This name form is constructed as:

      username

4.1.2. Machine UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) machine_uid_name(2)}.  The recommended symbolic name for
   this type is "GSS_SPKM_NT_MACHINE_UID_NAME".

   This name type is used to indicate a numeric user identifier
   corresponding to a user on a local system.  Its interpretation is
   OS-specific.  The gss_buffer_desc representing a name of this type
   should contain a locally-significant uid_t, represented in host byte
   order.  The gss_import_name() operation resolves this uid into a
   username, which is then treated as the User Name Form.

4.1.3. String UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) string_uid_name(3)}.  The recommended symbolic name for
   this type is "GSS_SPKM_NT_STRING_UID_NAME".

   This name type is used to indicate a string of digits representing
   the numeric user identifier of a user on a local system.  Its
   interpretation is OS-specific. This name type is similar to the
   Machine UID Form, except that the buffer contains a string
   representing the uid_t.



Adams                       Standards Track                    [Page 26]

RFC 2025                          SPKM                      October 1996


5. Parameter Definitions

   This section defines parameter values used by the SPKM GSS-API
   mechanism.  It defines interface elements in support of portability.

5.1. Minor Status Codes

   This section recommends common symbolic names for minor_status values
   to be returned by the SPKM GSS-API mechanism.  Use of these
   definitions will enable independent implementors 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 must 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.

5.1.1. Non-SPKM-specific codes (Minor Status Code MSB, bit 31, SET)

5.1.1.1. GSS-Related codes (Minor Status Code bit 30 SET)

   GSS_S_G_VALIDATE_FAILED
       /* "Validation error" */
   GSS_S_G_BUFFER_ALLOC
       /* "Couldn't allocate gss_buffer_t data" */
   GSS_S_G_BAD_MSG_CTX
       /* "Message context invalid" */
   GSS_S_G_WRONG_SIZE
       /* "Buffer is the wro