rfc2847.txt

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

Network Working Group                                          M. Eisler
Request for Comments: 2847                                       Zambeel
Category: Standards Track                                      June 2000


     LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memorandum describes a method whereby one can use GSS-API
   [RFC2078] to supply a secure channel between a client and server,
   authenticating the client with a password, and a server with a public
   key certificate.  As such, it is analogous to the common low
   infrastructure usage of the Transport Layer Security (TLS) protocol
   [RFC2246].

   The method leverages the existing Simple Public Key Mechanism (SPKM)
   [RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY)
   layered above SPKM.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  LIPKEY's Requirements of SPKM  . . . . . . . . . . . . . . . . 4
   2.1.  Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
   2.2.  Name Type  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.3.  Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5
   2.3.1.  MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 5
   2.3.2.  RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7
   2.4.  Context Establishment Tokens . . . . . . . . . . . . . . . . 8
   2.4.1.  REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 8
   2.4.1.1.  algId and req-integrity  . . . . . . . . . . . . . . . . 8
   2.4.1.2.  Req-contents . . . . . . . . . . . . . . . . . . . . . . 8
   2.4.1.2.1.  Options  . . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.1.2.2.  Conf-Algs  . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.1.2.3.  Intg-Algs  . . . . . . . . . . . . . . . . . . . . . . 9



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


   2.4.2.  REP-TI-TOKEN Content Requirements  . . . . . . . . . . . . 9
   2.4.2.1.  algId  . . . . . . . . . . . . . . . . . . . . . . . . . 9
   2.4.2.2.  rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 9
   2.5.  Quality of Protection (QOP)  . . . . . . . . . . . . . . . .10
   3.  How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . .  11
   3.1.  Tokens . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.  Initiator  . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.2.1.  GSS_Import_name  . . . . . . . . . . . . . . . . . . . .  11
   3.2.2.  GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . .  11
   3.2.3.  GSS_Init_sec_context . . . . . . . . . . . . . . . . . .  12
   3.2.3.1.  LIPKEY Caller Specified anon_req_flag as TRUE  . . . .  12
   3.2.3.2.  LIPKEY Caller Specified anon_req_flag as FALSE . . . .  13
   3.2.4.  Other operations . . . . . . . . . . . . . . . . . . . .  14
   3.3.  Target . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   3.3.1.  GSS_Import_name  . . . . . . . . . . . . . . . . . . . .  14
   3.3.2.  GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . .  14
   3.3.3.  GSS_Accept_sec_context . . . . . . . . . . . . . . . . .  15
   4.  LIPKEY Description . . . . . . . . . . . . . . . . . . . . .  15
   4.1.  Mechanism Type . . . . . . . . . . . . . . . . . . . . . .  15
   4.2.  Name Types . . . . . . . . . . . . . . . . . . . . . . . .  15
   4.3.  Token Formats  . . . . . . . . . . . . . . . . . . . . . .  16
   4.3.1.  Context Tokens . . . . . . . . . . . . . . . . . . . . .  16
   4.3.1.1.  Context Tokens Prior to SPKM-3 Context Establishment .  16
   4.3.1.2.  Post-SPKM-3 Context Establishment Tokens . . . . . . .  16
   4.3.1.2.1.  From LIPKEY Initiator  . . . . . . . . . . . . . . .  17
   4.3.1.2.2.  From LIPKEY Target . . . . . . . . . . . . . . . . .  17
   4.3.2.  Tokens from GSS_GetMIC and GSS_Wrap  . . . . . . . . . .  17
   4.4.  Quality of Protection  . . . . . . . . . . . . . . . . . .  18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
   5.1.  Password Management  . . . . . . . . . . . . . . . . . . .  18
   5.2.  Certification Authorities  . . . . . . . . . . . . . . . .  18
   5.3.  HMAC-MD5 and MD5 Weaknesses  . . . . . . . . . . . . . . .  18
   5.4.  Security of cast5CBC . . . . . . . . . . . . . . . . . . .  18
   References . . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . .  21
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This memorandum describes a new security mechanism under the GSS-API
   called the Low Infrastructure Public Key Mechanism (LIPKEY).  GSS-API
   provides a way for an application protocol to implement
   authentication, integrity, and privacy. TLS is another way. While TLS



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


   is in many ways simpler for an application to incorporate than GSS-
   API, there are situations where GSS-API might be more suitable.
   Certainly this is the case with application protocols that run over
   connectionless protocols. It is also the case with application
   protocols such as ONC RPC [RFC1831] [RFC2203], which have their own
   security architecture, and so do not easily mesh with a protocol like
   TLS that is implemented as a layer that encapsulates the upper layer
   application protocol. GSS-API allows the application protocol to
   encapsulate as much of the application protocol as necessary.

   Despite the flexibility of GSS-API, it compares unfavorably with TLS
   with respect to the perception of the amount of infrastructure
   required to deploy it. The better known GSS-API mechanisms, Kerberos
   V5 [RFC1964] and SPKM require a great deal of infrastructure to set
   up. Compare this to the typical TLS deployment scenario, which
   consists of a client with no public key certificate accessing a
   server with a public key certificate.  The client:

   *    obtains the server's certificate,

   *    verifies that it was signed by a trusted Certification Authority
        (CA),

   *    generates a random session symmetric key,

   *    encrypts the session key with the server's public key, and

   *    sends the encrypted session key to the server.

   At this point, the client and server have a secure channel.  The
   client can then provide a user name and password to the server to
   authenticate the client. For example, when TLS is being used with the
   http protocol, once there is a secure channel, the http server will
   present the client with an html page that prompts for a user name and
   password. This information is then encrypted with the session key and
   sent to the server. The server then authenticates the client.

   Note that the client is not required to have a certificate for itself
   to identify and authenticate it to the server. In addition to a TLS
   implementation, the required security infrastructure includes a
   public key certificate and password database on the server, and a
   list of trusted CAs and their public keys on the client. Most
   operating systems that the http server would run on already have a
   native password database, so the net additional infrastructure is a
   server certificate and CA list. Hence the term "low infrastructure
   security model" to identify this typical TLS deployment scenario.





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


   By using unilateral authentication, and using a mechanism resembling
   the SPKM-1 mechanism type, SPKM can offer many aspects of the
   previously described low infrastructure security model. An
   application that uses GSS-API is certainly free to use GSS-API's
   GSS_Wrap() routine to encrypt a user name and password and send them
   to the server, for it to decrypt and verify.

   Applications often have application protocols associated with them,
   and there might not be any provision in the protocol to specify a
   password.  Layering a thin GSS-API mechanism over a mechanism
   resembling SPKM-1 can mitigate this problem. This can be a useful
   approach to avoid modifying applications that have already bound to
   GSS-API, assuming the applications are not statically bound to
   specific GSS-API mechanisms.  The remainder of this memorandum
   defines the thin mechanism: the Low Infrastructure Public Key
   Mechanism (LIPKEY).

2.  LIPKEY's Requirements of SPKM

   SPKM-1 with unilateral authentication is close to the desired low
   infrastructure model described earlier. This section describes some
   additional changes to how SPKM-1 operates in order to realize the low
   infrastructure model.  These changes include some minor changes in
   semantics.  While it would be possible to implement these semantic
   changes within an SPKM-1 implementation (including using the same
   mechanism type Object Identifier (OID) as SPKM-1), the set of changes
   stretch the interpretation of RFC 2025 to the point where
   compatibility would be in danger. A new mechanism type, called SPKM-
   3, is warranted. LIPKEY requires that the SPKM implementation support
   SPKM-3.  SPKM-3 is equivalent to SPKM-1, except as described in the
   remainder of this section.

2.1.  Mechanism Type

   SPKM-3 has a different mechanism type OID from SPKM-1.

   spkm-3 OBJECT IDENTIFIER ::=
      {iso(1)identified-organization(3)dod(6)internet(1)security(5)
      mechanisms(5)spkm(1)spkm-3(3)}

2.2.  Name Type

   RFC 2025 defines no required name types of SPKM. LIPKEY requires that
   the SPKM-3 implementation support all the mechanism independent name
   types in RFC 2078.






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


2.3.  Algorithms

2.3.1.  MANDATORY Algorithms

   RFC 2025 defines various algorithms for integrity, confidentiality,
   key establishment, and subkey derivation.  Except for
   md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG),
   Integrity (I-ALG) and One-Way Functions for Subkey Derivation (O-ALG)
   algorithms listed in RFC 2025 continue to be REQUIRED.

   SPKM is designed to be extensible with regard to new algorithms. In
   order for LIPKEY to work correctly and securely, the following
   algorithms MUST be implemented in SPKM-3:

   *    Integrity algorithms (I-ALG)

      NULL-MAC
           Because the initiator may not have a certificate for itself,
           nor for the target, it is not possible for it to calculate an
           Integrity value in the initiator's REQ-TOKEN that is sent to
           the target. So we define, in ASN.1 [CCITT] syntax, a null I-
           ALG that returns a zero length bit string regardless of the
           input passed to it:

      NULL-MAC OBJECT IDENTIFIER ::=
         {iso(1)identified-organization(3)dod(6)internet(1)security(5)
         integrity(3)NULL-MAC(3)}

      id-dsa-with-sha1
           This is the signature algorithm as defined in Section 7.2.2
           of [RFC2459].  As noted in RFC 2459, the ASN.1 OID used to
           identify this signature algorithm is:

              id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
                      iso(1) member-body(2) us(840) x9-57(10040)
                              x9cm(4) 3
              }

           Note that there is a work-in-progress [PKIX] to obsolete RFC
           2459. However that work-in-progress does not change the
           definition of id-dsa-with-sha1.

      HMAC-MD5
           A consequence of the SPKM-3 initiator not having a
           certificate is that it cannot use a digital signature
           algorithm like md5WithRSAEncryption, id-dsa-with-sha1, or
           sha1WithRSAEncryption once the context is established.
           Instead, a message authentication code (MAC) algorithm is



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


           required. DES-MAC is specified as recommended in [RFC2025].
           Since the security of 56 bit DES has been shown to be
           inadequate [EFF], SPKM-3 needs a stronger MAC. Thus, SPKM-3
           MUST support the HMAC-MD5 algorithm [RFC2104], with this OID:

              HMAC-MD5 OBJECT IDENTIFIER ::= {
                      iso(1) org(3) dod(6) internet(1) security(5)
                              mechanisms(5) ipsec(8) isakmpOakley(1)
                              1
              }

           The reference for the algorithm OID of HMAC-MD5 is [IANA].
           The reference for the HMAC-MD5 algorithm is [RFC2104].

           The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG MAC
           because SHA-1 is about half the speed of MD5 [Young].  A MAC
           based on an encryption algorithm like cast5CBC, DES EDE3, or
           RC4 is not mandatory because MD5 is 31 percent faster than
           the fastest of the three encryption algorithms [Young].

   *    Confidentiality algorithm (C-ALG).

        RFC 2025 does not have a MANDATORY confidentiality algorithm,