rfc2025.txt

中、英文RFC文档大全打包下载完全版 .

           pvno [0]         BIT STRING OPTIONAL, -- prot. version number
           timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
           randTarg         Random-Integer,
           src-name [1]     Name OPTIONAL,
             -- must contain whatever value was supplied in REQ-TOKEN
           targ-name        Name,
           randSrc          Random-Integer,
           rep-data         Context-Data,
           validity [2]     Validity  OPTIONAL,
             -- validity interval for key (used if the target can only
             -- support a shorter context lifetime than was offered in
             -- REQ-TOKEN)
           key-estb-id      AlgorithmIdentifier OPTIONAL,
             -- used if target is changing key estb. algorithm (must be
             -- a member of initiators key-estb-set)
           key-estb-str      BIT STRING OPTIONAL
             -- contains (1) the response to the initiators
             -- key-estb-req (if init. used a 2-pass K-ALG), or (2) the
             -- key-estb-req corresponding to the K-ALG supplied in
             -- above key-estb-id, or (3) the key-estb-req corresponding
             -- to the first K-ALG supplied in initiator's key-estb-id,
             -- if initiator's (OPTIONAL) key-estb-req was not used
             -- (target's key-estb-str must be present in this case).
             -- Established key must satisfy the key length constraints
             -- specified in Section 2.4.
           }






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


   The protocol version number (pvno) parameter is a BIT STRING which
   uses as many bits as necessary to specify a single SPKM protocol
   version offered by the initiator which is supported by the target
   (one bit per protocol version); that is, the target sets exactly one
   bit of pvno.  If none of the versions offered by the initiator are
   supported by the target, a delete token must be returned so that the
   context is never established.  If the initiator's pvno has only one
   bit set and the target happens to support this protocol version, then
   this version is used over the context and the pvno parameter of REP-
   TOKEN can be omitted.  Finally, if the initiator and target do have
   one or more versions in common but the version of the REQ-TOKEN
   received is not supported by the target, a REP-TOKEN must be sent
   with a desired version bit set in pvno (and dummy values used for all
   subsequent token fields).  The initiator can then respond with a new
   REQ-TOKEN of the proper version (essentially starting context
   establishment anew).

3.1.3. Context Establishment Tokens - Initiator (second token)

   Relevant SPKM-REP-IT syntax is as follows:

   SPKM-REP-IT ::= SEQUENCE {
           responseToken    REP-IT-TOKEN,
           algId            AlgorithmIdentifier,
           rep-it-integ     Integrity  -- "token" is REP-IT-TOKEN
   }

   REP-IT-TOKEN ::= SEQUENCE {
           tok-id           INTEGER (768), -- shall contain 0300 (hex)
           context-id       Random-Integer,
           randSrc          Random-Integer,
           randTarg         Random-Integer,
           targ-name        Name,  -- the targ-name specified in REP-TI
           src-name         Name OPTIONAL,
             -- must contain whatever value was supplied in REQ-TOKEN
           key-estb-rep     BIT STRING OPTIONAL
                 -- contains the response to targets key-estb-str
                 -- (if target selected a 2-pass K-ALG)
           }

3.1.4. Error Token

   The syntax of SPKM-ERROR is as follows:

   SPKM-ERROR ::= SEQUENCE {
           error-token      ERROR-TOKEN,
           algId            AlgorithmIdentifier,
           integrity        Integrity  -- "token" is ERROR-TOKEN



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


   }

   ERROR-TOKRN ::=   SEQUENCE {
           tok-id           INTEGER (1024), -- shall contain 0400 (hex)
           context-id       Random-Integer
           }

   The SPKM-ERROR token is used only during the context establishment
   process.  If an SPKM-REQ or SPKM-REP-TI token is received in error,
   the receiving function (either gss_init_sec_context() or
   gss_accept_sec_context()) will generate an SPKM-ERROR token to be
   sent to the peer (if the peer is still in the context establishment
   process) and will return GSS_S_CONTINUE_NEEDED.  If, on the other
   hand, no context establishment response is expected from the peer
   (i.e., the peer has completed context establishment), the function
   will return the appropriate major status code (e.g., GSS_S_BAD_SIG)
   along with a minor status of GSS_SPKM_S_SG_CONTEXT_ESTB_ABORT and all
   context-relevant information will be deleted.  The output token will
   not be an SPKM-ERROR token but will instead be an SPKM-DEL token
   which will be processed by the peer's gss_process_context_token().

   If gss_init_sec_context() receives an error token (whether valid or
   invalid), it will regenerate SPKM-REQ as its output token and return
   a major status code of GSS_S_CONTINUE_NEEDED.  (Note that if the
   peer's gss_accept_sec_context() receives SPKM-REQ token when it is
   expecting a SPKM-REP-IT token, it will ignore SPKM-REQ and return a
   zero-length output token with a major status of
   GSS_S_CONTINUE_NEEDED.)

   Similarly, if gss_accept_sec_context() receives an error token
   (whether valid or invalid), it will regenerate SPKM-REP-TI as its
   output token and return a major status code of GSS_S_CONTINUE_NEEDED.

   md5WithRsa is currently stipulated for the signing of context
   establishment tokens.  Discrepancies involving modulus bitlength can
   be resolved through judicious use of the SPKM-ERROR token.  The
   context initiator signs REQ-TOKEN using the strongest RSA it supports
   (e.g., 1024 bits).  If the target is unable to verify signatures of
   this length, it sends SPKM-ERROR signed with the strongest RSA that
   it supports (e.g. 512).

   At the completion of this exchange, both sides know what RSA
   bitlength the other supports, since the size of the signature is
   equal to the size of the modulus.  Further exchanges can be made
   (using successively smaller supported bitlengths) until either an
   agreement is reached or context establishment is aborted because no
   agreement is possible.




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


3.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_init_sec_context(), gss_accept_sec_context(),
   or gss_delete_sec_context() and consumed by calls to
   gss_process_context_token().

3.2.1. Per-message Tokens - Sign / MIC

   Use of the gss_sign() / 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 and the data may be
   sent separately by the sending application and it is the receiving
   application's responsibility to associate the received data with the
   received token.

   The SPKM-MIC token has the following format:

   SPKM-MIC ::= SEQUENCE {
           mic-header       Mic-Header,
           int-cksum        BIT STRING
                                -- Checksum over header and data,
                                -- calculated according to algorithm
                                -- specified in int-alg field.
   }

   Mic-Header ::= SEQUENCE {
           tok-id           INTEGER (257),
                                -- shall contain 0101 (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.
   }

   SeqNum ::= SEQUENCE {
           num      INTEGER, -- the sequence number itself
           dir-ind  BOOLEAN  -- a direction indicator
   }






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


3.2.1.1. Checksum

   Checksum calculation procedure (common to all algorithms -- note that
   for SPKM the term "checksum" includes digital signatures as well as
   hashes and MACs): Checksums are calculated over the data field,
   logically prepended by the bytes of the plaintext token header (mic-
   header).  The result binds the data to the entire plaintext header,
   so as to minimize the possibility of malicious splicing.

   For example, if the int-alg specifies the md5WithRSA algorithm, then
   the checksum is formed by computing an MD5 [RFC-1321] hash over the
   plaintext data (prepended by the header), and then computing an RSA
   signature [PKCS1] on the 16-byte MD5 result.  The signature is
   computed using the RSA private key retrieved from the credentials
   structure and the result (whose length is implied by the "modulus"
   parameter in the private key) is stored in the int-cksum field.

   If the int-alg specifies a keyed hashing algorithm (for example,
   DES-MAC or md5-DES-CBC), then the key to be used is the appropriate
   subkey derived from the context key (see Section 2.4).  Again, the
   result (whose length is implied by int-alg) is stored in the int-
   cksum field.

3.2.1.2. Sequence Number

   It is assumed that the underlying transport layers (of whatever
   protocol stack is being used by the application) will provide
   adequate communications reliability (that is, non-malicious loss,
   re-ordering, etc., of data packets will be handled correctly).
   Therefore, sequence numbers are used in SPKM purely for security, as
   opposed to reliability, reasons (that is, to avoid malicious loss,
   replay, or re-ordering of SPKM tokens) -- it is therefore recommended
   that applications request sequencing and replay detection over all
   contexts.  Note that sequence numbers are used so that there is no
   requirement for secure timestamps in the message tokens.  The
   initiator's initial sequence number for the current context may be
   explicitly given in the Context-Data field of SPKM-REQ and the
   target's initial sequence number may be explicitly given in the
   Context-Data field of SPKM-REP-TI; if either of these is not given
   then the default value of 00 is to be used.

   Sequence number field: The sequence number field is formed from the
   sender's four-byte sequence number and a Boolean direction-indicator
   (FALSE - sender is the context initiator, TRUE - sender is the
   context acceptor).  After constructing a gss_sign/getMIC() or
   gss_seal/wrap() token, the sender's seq. number is incremented by 1.





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


3.2.1.3. Sequence Number Processing

   The receiver of the token will verify the sequence number field by
   comparing the sequence number with the expected sequence number and
   the direction indicator with the expected direction indicator.  If
   the sequence number in the token is higher than the expected number,
   then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is
   returned.  If the token sequence number is lower than the expected
   number, then the expected sequence number is not adjusted and
   GSS_S_DUPLICATE_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_OLD_TOKEN is
   returned, whichever is appropriate.  If the direction indicator is
   wrong, then the expected sequence number is not adjusted and
   GSS_S_UNSEQ_TOKEN is returned.

   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.