rfc2025.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         This algorithm is used to establish a symmetric key for use
         by both the initiator and the target over the established
         context.  The keys used for C-ALG and any keyed I-ALGs (for
         example, DES-MAC) are derived from this context key.  As will
         be seen in Section 3.1, key establishment is done within the
         X.509 authentication exchange and so the resulting shared
         symmetric key is authenticated.

       Examples:

         RSAEncryption OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-1(1) 1        -- imported from [PKCS1] and [RFC-1423]
         }

            In this algorithm (MANDATORY), the context key is generated
            by the initiator, encrypted with the RSA public key of the
            target, and sent to the target.  The target need not respond
            to the initiator for the key to be established.

         id-rsa-key-transport OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 22   -- imported from [X9.44]
         }

            Similar to RSAEncryption, but source authenticating info.
            is also encrypted with the target's RSA public key.



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


        dhKeyAgreement OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-3(3) 1
        }

            In this algorithm, the context key is generated jointly by
            the initiator and the target using the Diffie-Hellman key
            establishment algorithm.  The target must therefore respond
            to the initiator for the key to be established (so this
            K-ALG cannot be used with unilateral authentication in
            SPKM-2 (see Section 3.1)).

2.4 One-Way Function (O-ALG) for Subkey Derivation Algorithm:

       Purpose:

         Having established a context key using the negotiated K-ALG,
         both initiator and target must be able to derive a set of
         subkeys for the various C-ALGs and keyed I-ALGs supported over
         the context.  Let the (ordered) list of agreed C-ALGs be
         numbered consecutively, so that the first algorithm (the
         "default") is numbered "0", the next is numbered "1", and so
         on.  Let the numbering for the (ordered) list of agreed I-ALGs
         be identical.  Finally, let the context key be a binary string
         of arbitrary length "M", subject to the following constraint:
         L <= M <= U  (where the lower limit "L" is the bit length of
         the longest key needed by any agreed C-ALG or keyed I-ALG, and
         the upper limit "U" is the largest bit size which will fit
         within the K-ALG parameters).

         For example, if DES and two-key-triple-DES are the negotiated
         confidentiality algorithms and DES-MAC is the negotiated keyed
         integrity algorithm (note that digital signatures do not use a
         context key), then the context key must be at least 112 bits
         long.  If 512-bit RSAEncryption is the K-ALG in use then the
         originator can randomly generate a context key of any greater
         length up to 424 bits (the longest allowable RSA input
         specified in [PKCS-1]) -- the target can determine the length
         which was chosen by removing the padding bytes during the RSA
         decryption operation.  On the other hand, if dhKeyAgreement is
         the K-ALG in use then the context key is the result of the
         Diffie-Hellman computation (with the exception of the high-
         order byte, which is discarded for security reasons), so that
         its length is that of the Diffie-Hellman modulus, p, minus 8
         bits.






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


         The derivation algorithm for a k-bit subkey is specified as
         follows:

      rightmost_k_bits (OWF(context_key || x || n || s || context_key))

         where

          - "x" is the ASCII character "C" (0x43) if the subkey is
            for a confidentiality algorithm or the ASCII character "I"
            (0x49) if the subkey is for a keyed integrity algorithm;
          - "n" is the number of the algorithm in the appropriate agreed
            list for the context (the ASCII character "0" (0x30), "1"
            (0x31), and so on);
          - "s" is the "stage" of processing -- always the ASCII
            character "0" (0x30), unless "k" is greater than the output
            size of OWF, in which case the OWF is computed repeatedly
            with increasing ASCII values of "stage" (each OWF output
            being concatenated to the end of previous OWF outputs),
            until "k" bits have been generated;
          - "||" is the concatenation operation; and
          - "OWF" is any appropriate One-Way Function.

       Examples:

         MD5 OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549)
           digestAlgorithm(2) 5
         }

           This algorithm is MANDATORY.

         SHA OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 18
         }

         It is recognized that existing hash functions may not satisfy
         all required properties of OWFs.  This is the reason for
         allowing negotiation of the O-ALG OWF during the context
         establishment process (see Section 2.5), since in this way
         future improvements in OWF design can easily be accommodated.
         For example, in some environments a preferred OWF technique
         might be an encryption algorithm which encrypts the input
         specified above using the context_key as the encryption key.







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


2.5 Negotiation:

   During context establishment in SPKM, the initiator offers a set of
   possible confidentiality algorithms and a set of possible integrity
   algorithms to the target (note that the term "integrity algorithms"
   includes digital signature algorithms).  The confidentiality
   algorithms selected by the target become ones that may be used for
   C-ALG over the established context, and the integrity algorithms
   selected by the target become ones that may be used for I-ALG over
   the established context (the target "selects" algorithms by
   returning, in the same relative order, the subset of each offered
   list that it supports).  Note that any C-ALG and I-ALG may be used
   for any message over the context and that the first confidentiality
   algorithm and the first integrity algorithm in the agreed sets become
   the default algorithms for that context.

   The agreed confidentiality and integrity algorithms for a specific
   context define the valid values of the Quality of Protection (QOP)
   parameter used in the gss_getMIC() and gss_wrap() calls -- see
   Section 5.2 for further details.  If no response is expected from the
   target (unilateral authentication in SPKM-2) then the algorithms
   offered by the initiator are the ones that may be used over the
   context (if this is unacceptable to the target then a delete token
   must be sent to the initiator so that the context is never
   established).

   Furthermore, in the first context establishment token the initiator
   offers a set of possible K-ALGs, along with the key (or key half)
   corresponding to the first algorithm in the set (its preferred
   algorithm).  If this K-ALG is unacceptable to the target then the
   target must choose one of the other K-ALGs in the set and send this
   choice along with the key (or key half) corresponding to this choice
   in its response (otherwise a delete token must be sent so that the
   context is never established).  If necessary (that is, if the target
   chooses a 2-pass K-ALG such as dhKeyAgreement), the initiator will
   send its key half in a response to the target.

   Finally, in the first context establishment token the initiator
   offers a set of possible O-ALGs (only a single O-ALG if no response
   is expected).  The (single) O-ALG chosen by the target becomes the
   subkey derivation algorithm OWF to be used over the context.

   In future versions of SPKM, other algorithms may be specified for any
   or all of I-ALG, C-ALG, K-ALG, and O-ALG.







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


3. Token Formats

   This section discusses protocol-visible characteristics of the SPKM;
   it defines elements of protocol for interoperability and is
   independent of language bindings per [RFC-1509].

   The SPKM GSS-API mechanism will be identified by an Object Identifier
   representing "SPKM-1" or "SPKM-2", having the value {spkm spkm-1(1)}
   or {spkm spkm-2(2)}, where spkm has the value {iso(1) identified-
   organization(3) dod(6) internet(1) security(5) mechanisms(5)
   spkm(1)}.  SPKM-1 uses random numbers for replay detection during
   context establishment and SPKM-2 uses timestamps (note that for both
   mechanisms, sequence numbers are used to provide replay and out-of-
   sequence detection during the context, if this has been requested by
   the application).

   Tokens transferred between GSS-API peers (for security context
   management and per-message protection purposes) are defined.

3.1. Context Establishment Tokens

   Three classes of tokens are defined in this section:  "Initiator"
   tokens, emitted by calls to gss_init_sec_context() and consumed by
   calls to gss_accept_sec_context(); "Target" tokens, emitted by calls
   to gss_accept_sec_context() and consumed by calls to
   gss_init_sec_context(); and "Error" tokens, potentially emitted by
   calls to gss_init_sec_context() or gss_accept_sec_context(), and
   potentially consumed by calls to gss_init_sec_context() or
   gss_accept_sec_context().

   Per RFC-1508, Appendix B, the initial context establishment token
   will be enclosed within framing as follows:

   InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
           thisMech           MechType,
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "SPKM-1" or "SPKM-2"
           innerContextToken  ANY DEFINED BY thisMech
   }               -- contents mechanism-specific












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


   When thisMech is SPKM-1 or SPKM-2, innerContextToken is defined as
   follows:

      SPKMInnerContextToken ::= CHOICE {
         req    [0] SPKM-REQ,
         rep-ti [1] SPKM-REP-TI,
         rep-it [2] SPKM-REP-IT,
         error  [3] SPKM-ERROR,
         mic    [4] SPKM-MIC,
         wrap   [5] SPKM-WRAP,
         del    [6] SPKM-DEL
      }

   The above GSS-API framing shall be applied to all tokens emitted by
   the SPKM GSS-API mechanism, including SPKM-REP-TI (the response from
   the Target to the Initiator), SPKM-REP-IT (the response from the
   Initiator to the Target), SPKM-ERROR, context-deletion, and per-
   message tokens, not just to the initial token in a context
   establishment exchange.  While not required by RFC-1508, this enables
   implementations to perform enhanced error-checking.  The tag values
   provided in SPKMInnerContextToken ("[0]" through "[6]") specify a
   token-id for each token; similar information is contained in each
   token's tok-id field.  While seemingly redundant, the tag value and
   tok-id actually perform different tasks:  the tag ensures that
   InitialContextToken can be properly decoded; tok-id ensures, among
   other things, that data associated with the per-message tokens is
   cryptographically linked to the intended token type.  Every
   innerContextToken also includes a context-id field; see Section 6 for
   a discussion of both token-id and context-id information and their
   use in an SPKM support function).

   The innerContextToken field of context establishment tokens for the
   SPKM GSS-API mechanism will contain one of the following messages:
   SPKM-REQ; SPKM-REP-TI; SPKM-REP-IT; and SPKM-ERROR.  Furthermore, all
   innerContextTokens are encoded using ASN.1 BER (constrained, in the
   interests of parsing simplicity, to the DER subset defined in
   [X.509], clause 8.7).

   The SPKM context establishment tokens are defined according to
   [X.509] Section 10 and are compatible with [9798].  SPKM-1 (random
   numbers) uses Section 10.3, "Two-way Authentication", when performing
   unilateral authentication of the target to the initiator and uses
   Section 10.4, "Three-way Authentication", when mutual authentication
   is requested by the initiator.  SPKM-2 (timestamps) uses Section
   10.2, "One-way Authentication", when performing unilateral
   authentication of the initiator to the target and uses Section 10.3,
   "Two-way Authentication", when mutual authentication is requested by
   the initiator.