rfc2025.txt

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

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


   The implication of the previous paragraph is that for SPKM-2
   unilateral authentication no negotiation of K-ALG can be done (the
   target either accepts the K-ALG and context key given by the
   initiator or disallows the context).  For SPKM-2 mutual or SPKM-1
   unilateral authentication some negotiation is possible, but the
   target can only choose among the one-pass K-ALGs offered by the
   initiator (or disallow the context).  Alternatively, the initiator
   can request that the target generate and transmit the context key.
   For SPKM-1 mutual authentication the target can choose any one- or
   two-pass K-ALG offered by the initiator and, again, can be requested
   to generate and transmit the context key.

   It is envisioned that typical use of SPKM-1 or SPKM-2 will involve
   mutual authentication.  Although unilateral authentication is
   available for both mechanisms, its use is not generally recommended.

3.1.1. Context Establishment Tokens - Initiator (first token)

   In order to accomplish context establishment, it may be necessary
   that both the initiator and the target have access to the other
   partys public-key certificate(s).  In some environments the initiator
   may choose to acquire all certificates and send the relevant ones to
   the target in the first token.  In other environments the initiator
   may request that the target send certificate data in its response
   token, or each side may individually obtain the certificate data it
   needs.  In any case, however, the SPKM implementation must have the
   ability to obtain certificates which correspond to a supplied Name.
   The actual mechanism to be used to achieve this is a local
   implementation matter and is therefore outside the scope of this
   specification.


   Relevant SPKM-REQ syntax is as follows (note that imports from other
   documents are given in Appendix A):

   SPKM-REQ ::= SEQUENCE {
           requestToken      REQ-TOKEN,
           certif-data [0]   CertificationData OPTIONAL,
           auth-data [1]     AuthorizationData OPTIONAL
              -- see [RFC-1510] for a discussion of auth-data
   }

   CertificationData ::= SEQUENCE {
           certificationPath [0]          CertificationPath OPTIONAL,
           certificateRevocationList [1]  CertificateList OPTIONAL
   }  -- at least one of the above shall be present





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


   CertificationPath ::= SEQUENCE {
           userKeyId [0]         OCTET STRING OPTIONAL,
              -- identifier for user's public key
           userCertif [1]        Certificate OPTIONAL,
              -- certificate containing user's public key
           verifKeyId [2]        OCTET STRING OPTIONAL,
              -- identifier for user's public verification key
           userVerifCertif [3]   Certificate OPTIONAL,
              -- certificate containing user's public verification key
           theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL
   }          -- certification path from target to source

   Having separate verification fields allows different key pairs
   (possibly corresponding to different algorithms) to be used for
   encryption/decryption and signing/verification.  Presence of [0] or
   [1] and absence of [2] and [3] implies that the same key pair is to
   be used for enc/dec and verif/signing (note that this practice is not
   typically recommended).  Presence of [2] or [3] implies that a
   separate key pair is to be used for verif/signing, and so [0] or [1]
   must also be present.  Presence of [4] implies that at least one of
   [0], [1], [2], and [3] must also be present.

      REQ-TOKEN ::= SEQUENCE {
              req-contents     Req-contents,
              algId            AlgorithmIdentifier,
              req-integrity    Integrity  -- "token" is Req-contents
      }

      Integrity ::= BIT STRING
        -- If corresponding algId specifies a signing algorithm,
        -- "Integrity" holds the result of applying the signing procedure
        -- specified in algId to the BER-encoded octet string which results
        -- from applying the hashing procedure (also specified in algId) to
        -- the DER-encoded octets of "token".
        -- Alternatively, if corresponding algId specifies a MACing
        -- algorithm, "Integrity" holds the result of applying the MACing
        -- procedure specified in algId to the DER-encoded octets of
        -- "token" (note that for MAC, algId must be one of the integrity
        -- algorithms offered by the initiator with the appropriate subkey
        -- derived from the context key (see Section 2.4) used as the key
        -- input)

   It is envisioned that typical use of the Integrity field for each of
   REQ-TOKEN, REP-TI-TOKEN, and REP-IT-TOKEN will be a true digital
   signature, providing unilateral or mutual authentication along with
   replay protection, as required.  However, there are situations in
   which the MAC choice will be appropriate.  One example is the case in
   which the initiator wishes to remain anonymous (so that the first, or



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


   first and third, token(s) will be MACed and the second token will be
   signed).  Another example is the case in which a previously
   authenticated, established, and cached context is being re-
   established at some later time (here all exchanged tokens will be
   MACed).

   The primary advantage of the MAC choice is that it reduces processing
   overhead for cases in which either authentication is not required
   (e.g., anonymity) or authentication is established by some other
   means (e.g., ability to form the correct MAC on a "fresh" token in
   context re-establishment).

   Req-contents ::= SEQUENCE {
           tok-id           INTEGER (256),    -- shall contain 0100(hex)
           context-id       Random-Integer,   -- see Section 6.3
           pvno             BIT STRING,       -- protocol version number
           timestamp        UTCTime OPTIONAL, -- mandatory for SPKM-2
           randSrc          Random-Integer,
           targ-name        Name,
           src-name [0]     Name OPTIONAL,
              -- must be supplied unless originator is "anonymous"
           req-data         Context-Data,
           validity [1]     Validity OPTIONAL,
              -- validity interval for key (may be used in the
              -- computation of security context lifetime)
           key-estb-set     Key-Estb-Algs,
              -- specifies set of key establishment algorithms
           key-estb-req      BIT STRING OPTIONAL,
              -- key estb. parameter corresponding to first K-ALG in set
              -- (not used if initiator is unable or unwilling to
              -- generate and securely transmit key material to target).
              -- Established key must satisfy the key length constraints
              -- specified in Section 2.4.
           key-src-bind      OCTET STRING OPTIONAL
              -- Used to bind the source name to the symmetric key.
              -- This field must be present for the case of SPKM-2
              -- unilateral authen. if the K-ALG in use does not provide
              -- such a binding (but is optional for all other cases).
              -- The octet string holds the result of applying the
              -- mandatory hashing procedure MD5 (in MANDATORY I-ALG;
              -- see Section 2.1) as follows:  MD5(src || context_key),
              -- where "src" is the DER-encoded octets of src-name,
              -- "context-key" is the symmetric key (i.e., the
              -- unprotected version of what is transmitted in
              -- key-estb-req), and "||" is the concatenation operation.
           }





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


   -- The protocol version number (pvno) parameter is a BIT STRING which
   -- uses as many bits as necessary to specify all the SPKM protocol
   -- versions supported by the initiator (one bit per protocol
   -- version).  The protocol specified by this document is version 0.
   -- Bit 0 of pvno is therefore set if this version is supported;
   -- similarly, bit 1 is set if version 1 (if defined in the future) is
   -- supported, and so on.  Note that for unilateral authentication
   -- using SPKM-2, no response token is expected during context
   -- establishment, so no protocol negotiation can take place; in this
   -- case, the initiator must set exactly one bit of pvno.  The version
   -- of REQ-TOKEN must correspond to the highest bit set in pvno.
   -- The "validity" parameter above is the only way within SPKM for
   -- the initiator to transmit desired context lifetime to the target.
   -- Since it cannot be guaranteed that the initiator and target have
   -- synchronized time, the span of time specified by "validity" is to
   -- be taken as definitive (rather than the actual times given in this
   -- parameter).

   Random-Integer ::= BIT STRING

   -- Each SPKM implementation is responsible for generating a "fresh"
   -- random number for the purpose of context establishment; that is,
   -- one which (with high probability) has not been used previously.
   -- There are no cryptographic requirements on this random number
   -- (i.e., it need not be unpredictable, it simply needs to be fresh).

   Context-Data ::= SEQUENCE {
           channelId       ChannelId OPTIONAL, -- channel bindings
           seq-number      INTEGER OPTIONAL,   -- sequence number
           options         Options,
           conf-alg        Conf-Algs,          -- confidentiality. algs.
           intg-alg        Intg-Algs,          -- integrity algorithm
           owf-alg         OWF-Algs            -- for subkey derivation
   }

   ChannelId ::= OCTET STRING

   Options ::= BIT STRING {
           delegation-state (0),
           mutual-state (1),
           replay-det-state (2), -- used for replay det. during context
           sequence-state (3),   -- used for sequencing during context
           conf-avail (4),
           integ-avail (5),
           target-certif-data-required (6)
                                 -- used to request targ's certif. data
   }




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


   Conf-Algs ::= CHOICE {
           algs [0]        SEQUENCE OF AlgorithmIdentifier,
           null [1]        NULL
            -- used when conf. is not available over context
   } -- for C-ALG (see Section 5.2 for discussion of QOP)

   Intg-Algs ::= SEQUENCE OF AlgorithmIdentifier
       -- for I-ALG (see Section 5.2 for discussion of QOP)

   OWF-Algs ::= SEQUENCE OF AlgorithmIdentifier
       -- Contains exactly one algorithm in REQ-TOKEN for SPKM-2
       -- unilateral, and contains at least one algorithm otherwise.
       -- Always contains exactly one algorithm in REP-TOKEN.

   Key-Estb-Algs ::= SEQUENCE OF AlgorithmIdentifier
       -- to allow negotiation of K-ALG

   A context establishment sequence based on the SPKM will perform
   unilateral authentication if the mutual-req bit is not set in the
   application's call to gss_init_sec_context().  SPKM-2 accomplishes
   this using only SPKM-REQ (thereby authenticating the initiator to the
   target), while SPKM-1 accomplishes this using both SPKM-REQ and
   SPKM-REP-TI (thereby authenticating the target to the initiator).

   Applications requiring authentication of both peers (initiator as
   well as target) must request mutual authentication, resulting in
   "mutual-state" being set within SPKM-REQ Options.  In response to
   such a request, the context target will reply to the initiator with
   an SPKM-REP-TI token.  If mechanism SPKM-2 has been chosen, this
   completes the (timestamp-based) mutual authentication context
   establishment exchange.  If mechanism SPKM-1 has been chosen and
   SPKM-REP-TI is sent, the initiator will then reply to the target with
   an SPKM-REP-IT token, completing the (random-number-based) mutual
   authentication context establishment exchange.

   Other bits in the Options field of Context-Data are explained in
   RFC-1508, with the exception of target-certif-data-required, which
   the initiator sets to TRUE to request that the target return its
   certification data in the SPKM-REP-TI token.  For unilateral
   authentication in SPKM-2 (in which no SPKM-REP-TI token is
   constructed), this option bit is ignored by both initiator and
   target.









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


3.1.2. Context Establishment Tokens - Target

   SPKM-REP-TI ::= SEQUENCE {
           responseToken    REP-TI-TOKEN,
           certif-data      CertificationData OPTIONAL
             -- included if target-certif-data-required option was
             -- set to TRUE in SPKM-REQ
   }


   REP-TI-TOKEN ::= SEQUENCE {
           rep-ti-contents Rep-ti-contents,
           algId           AlgorithmIdentifier,
           rep-ti-integ    Integrity  -- "token" is Rep-ti-contents
   }

   Rep-ti-contents ::= SEQUENCE {
           tok-id           INTEGER (512),   -- shall contain 0200 (hex)
           context-id       Random-Integer,  -- see Section 6.3