rfc2847.txt

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

        and instead has RECOMMENDED a 56 bit DES algorithm. Since the
        LIPKEY initiator needs to send a password to the target, and
        since 56 bit DES has been demonstrated as inadequate [EFF],
        LIPKEY needs stronger encryption. Thus, SPKM-3 MUST support this
        algorithm:

           cast5CBC OBJECT IDENTIFIER ::= {
                   iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
                           algorithms(66) 10
           }

           Parameters ::= SEQUENCE {
                   iv OCTET STRING DEFAULT 0, -- Initialization vector
                   keyLength INTEGER          -- Key length, in bits
           }

        The reference for the OID and description of the cast5CBC
        algorithm is [RFC2144]. The keyLength in the Parameters MUST be
        set to 128 bits.

        A triple DES (DES EDE3) algorithm is not a mandatory SPKM-3 C-
        ALG because it is much slower than cast5CBC. One set of
        measurements [Young] on a Pentium Pro 200 megahertz processor
        using the SSLeay code, showed that DES EDE3 performed as high as
        1,646,210 bytes per second, using 1024 byte blocks. The same



Eisler                      Standards Track                     [Page 6]

RFC 2847                         LIPKEY                        June 2000


        test bed yielded performance of 7,147,760 bytes per second for
        cast5CBC, and 22,419,840 bytes per second for RC4. Most TLS
        sessions negotiate the RC4 cipher. Given that LIPKEY is targeted
        at environments similar to that where TLS is deployed, selecting
        a cipher that is over 13 times slower (and over 13 times more
        CPU intensive) than RC4 would severely impede the usefulness of
        LIPKEY.  For performance reasons, RC4 would be the preferred
        mandatory algorithm for SPKM-3. Due to intellectual property
        considerations with RC4 [Schneier], the combination of
        cast5CBC's reasonable performance, and its royalty-free
        licensing terms [RFC2144] make cast5CBC the optimal choice among
        DES EDE3, RC4, and cast5CBC.

   *    Key Establishment Algorithm (K-ALG)

        RFC 2025 lists dhKeyAgreement [PKCS-3] as an apparently optional
        algorithm.  As will be described later, the RSAEncryption key
        establishment algorithm is of no use for a low infrastructure
        security mechanism as defined by this memorandum. Hence, in
        SPKM-3, dhKeyAgreement is a REQUIRED key establishment
        algorithm:

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

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

        RFC 2025 lists MD5 as a mandatory algorithm.  Since MD5 has been
        found to have weaknesses when used as a hash [Dobbertin], id-
        sha1 is a MANDATORY O-ALG in SPKM-3:

           id-sha1 OBJECT IDENTIFIER ::= {
                   iso(1) identified-organization(3) oiw(14)
                   secsig(3) algorithms(2) 26
           }

        The reference for the algorithm OID of id-sha1 is [RFC2437].
        The reference for SHA-1 algorithm corresponding to id-sha1 is
        [FIPS].

2.3.2.  RECOMMENDED Integrity Algorithms (I-ALG)

   md5WithRSAEncryption
        The md5WithRSAEncryption integrity algorithm is listed in
        [RFC2025] as mandatory.  Due to intellectual property
        considerations [RSA-IP], SPKM-3 implementations cannot be



Eisler                      Standards Track                     [Page 7]

RFC 2847                         LIPKEY                        June 2000


        required to implement it. However, given the proliferation of
        certificates using RSA public keys, md5WithRSAEncryption is
        strongly RECOMMENDED. Otherwise, the opportunities for LIPKEY to
        leverage existing public key infrastructure will be limited.

   sha1WithRSAEncryption
        For reasons similar to that for md5WithRSAEncryption,
        sha1WithRSAEncryption is a RECOMMENDED algorithm. The
        sha1WithRSAEncryption algorithm is listed in addition to
        md5WithRSAEncryption due to weaknesses in the MD5 hash algorithm
        [Dobbertin]. The OID for sha1WithRSAEncryption is:

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

        The reference for the algorithm OID and description of
        sha1WithRSAEncryption is [RFC2437].

2.4.  Context Establishment Tokens

   RFC 2025 sets up a context with an initiator first token (REQ-TOKEN),
   a target reply (REP-TI-TOKEN), and finally an initiator second token
   (REP-IT-TOKEN) to reply to the target's reply. Since LIPKEY uses
   SPKM-3 with unilateral authentication, the REP-IT-TOKEN is not used.
   LIPKEY has certain requirements on the contents of the REQ-TOKEN and
   REP-TI-TOKEN, but the syntax of the SPKM-3 tokens is not different
   from RFC 2025's SPKM-1 tokens.

2.4.1.  REQ-TOKEN Content Requirements

2.4.1.1.  algId and req-integrity

   If the SPKM-3 initiator cannot calculate a req-integrity field due to
   the lack of a target certificate, it MUST use the NULL-MAC I-ALG
   described earlier in this memorandum. This will produce a zero length
   bit string in the Integrity field.

2.4.1.2.  Req-contents

   Because RFC 2025 requires that the RSAEncryption K-ALG be present,
   SPKM-1 must be able to map the target (targ-name) to its public key
   certificate, and thus SPKM can use the RSAEncryption algorithm to
   fill in the key-estb-req field.  Because LIPKEY assumes a low
   infrastructure deployment, SPKM-3 MUST be prepared to be unable to
   map the targ-name field of the Req-contents field.  This is a
   contradiction which is resolved by requiring SPKM-3 to support the



Eisler                      Standards Track                     [Page 8]

RFC 2847                         LIPKEY                        June 2000


   dhKeyAgreement algorithm. Note that if an SPKM-3 implementation tries
   to map the target to a certificate, and succeeds, it is free to use
   the RSAEncryption K-ALG algorithm. It is also free to use an algID
   other than NULL-MAC in the REQ-TOKEN type.

2.4.1.2.1.  Options

   SPKM-3 implementations MUST set the target-certif-data-required bit
   to 1 if the only K-ALG in the key-estb-set field of Req-contents is
   dhKeyAgreement. This would normally occur if the SPKM-3
   implementation cannot resolve the target name to a certificate.

2.4.1.2.2.  Conf-Algs

   If the SPKM-3 implementation supports an algorithm weaker than
   cast5CBC, cast5CBC MUST be listed before the weaker algorithm to
   encourage the target to negotiate the stronger algorithm.

2.4.1.2.3.  Intg-Algs

   Because the initiator will be anonymous (at the SPKM-3 level) and
   will not have a certificate for itself, the initiator cannot use an
   integrity algorithm that supports non-repudiation; it must use a MAC
   algorithm. If the SPKM-3 implementation supports an algorithm weaker
   than HMAC-MD5, HMAC-MD5 MUST be listed before the weaker algorithm to
   encourage the target to negotiate the stronger algorithm.

2.4.2.  REP-TI-TOKEN Content Requirements

   With the previously described requirements on REQ-TOKEN, the contents
   of SPKM-3's REP-TI-TOKEN can for the most part be derived from the
   specification in RFC 2025. The exceptions are the algId and rep-ti-
   integ fields.

2.4.2.1.  algId

   The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a
   signature algorithm like id-dsa-with-sha1, md5WithRSAEncryption, or
   sha1WithRSAEncryption.

2.4.2.2.  rep-ti-integ

   If the req-token has an algId of NULL-MAC, then the target MUST
   compute the rep-ti-integ on the concatenation of the req-contents and
   rep-ti-contents.






Eisler                      Standards Track                     [Page 9]

RFC 2847                         LIPKEY                        June 2000


2.5.  Quality of Protection (QOP)

   The SPKM-3 initiator and target negotiate the set of algorithms they
   mutually support, using the procedure defined in Section 5.2 of RFC
   2025. If a QOP of zero is specified, then the initiator and target
   will use the first C-ALG (privacy), and I-ALG (integrity) algorithms
   negotiated.

   SPKM breaks the QOP into several fields, as reproduced here from
   Section 5.2 of RFC 2025:

       Confidentiality                    Integrity
       31 (MSB)                        16 15                 (LSB) 0
      -------------------------------|-------------------------------
      | TS(5) | U(3) | IA(4) | MA(4) | TS(5) | U(3) | IA(4) | MA(4) |
      -------------------------------|-------------------------------

   The MA subfields enumerate mechanism-defined algorithms. Since this
   memorandum introduces a new mechanism, SPKM-3, within the SPKM
   family, it is appropriate to add algorithms to the MA subfields of
   the respective Confidentiality and Integrity fields.

   The complete set of Confidentiality MA algorithms is thus:

      0001 (1) = DES-CBC
      0010 (2) = cast5CBC

   Where "0001" and "0010" are in base 2.  An SPKM peer that negotiates
   a confidentiality MA algorithm value of "0010" MUST use a 128 bit
   key, i.e. set the keyLength values in the cast5CBC Parameters to 128
   bits.

   The complete set of Integrity MA algorithms is thus:

      0001 (1) = md5WithRSAEncryption
      0010 (2) = DES-MAC
      0011 (3) = id-dsa-with-sha1
      0100 (4) = HMAC-MD5
      0101 (5) = sha1WithRSAEncryption

   Where "0001" through "0101" are in base 2.

   Adding support for cast5CBC, id-dsa-with-sha1, HMAC-MD5, and
   sha1WithRSAEncryption in the above manner to SPKM-1 and SPKM-2 does
   not impair SPKM-1 and SPKM-2 backward compatibility because, as noted
   previously, SPKM negotiates algorithms. An older SPKM-1 or SPKM-2
   that does not recognize MA values for cast5CBC, id-dsa-with-sha1,
   HMAC-MD5, or sha1WithRSAEncryption will not select them.



Eisler                      Standards Track                    [Page 10]

RFC 2847                         LIPKEY                        June 2000


3.  How LIPKEY Uses SPKM

3.1.  Tokens

   LIPKEY will invoke SPKM-3 to produce SPKM tokens. Since the mechanism
   that the application uses is LIPKEY, LIPKEY will wrap some of the
   SPKM-3 tokens with LIPKEY prefixes. The exact definition of the
   tokens is described later in this memorandum.

3.2.  Initiator

3.2.1.  GSS_Import_name

   The initiator uses GSS_Import_name to import the target's name,
   typically, but not necessarily, using the GSS_C_NT_HOSTBASED_SERVICE
   name type.  Ultimately, the output of GSS_Import_name will apply to
   an SPKM-3 mechanism type because a LIPKEY target is an SPKM-3 target.

3.2.2.  GSS_Acquire_cred

   The initiator calls GSS_Acquire_cred. The credentials that are
   acquired are LIPKEY credentials, a user name and password. How the
   user name and password is acquired is dependent upon the operating
   environment. A application that invokes GSS_Acquire_cred() while the
   application's user has a graphical user interface running might
   trigger the appearance of a pop up window that prompts for the
   information. A application embedded into the operating system, such
   as an NFS [Sandberg] client implemented as a native file system might
   broadcast a message to the user's terminals telling him to invoke a
   command that prompts for the information.

   Because the credentials will not be used until GSS_Init_sec_context
   is called, the LIPKEY implementation will need to safeguard the
   credentials. If this is a problem, the implementation may instead
   defer actual acquisition of the user name and password until
   GSS_init_sec_context is ready to send the user name and password to
   the target. In that event, the output_cred_handle argument of
   GSS_Acquire_cred would simply be a reference that mapped to the
   principal corresponding to the desired_name argument. A subsequent
   GSS_Init_sec_context call would consider the mapping of
   claimant_cred_handle to principal when it acquires the user name and
   password. For example, the aforementioned pop up window might fill in
   the user name portion of the dialog with a default value that maps to
   the principal referred to in claimant_cred_handle.







Eisler                      Standards Track                    [Page 11]