rfc2025.txt

RFC 的详细文档！

Network Working Group                                           C. Adams
Request for Comments: 2025                        Bell-Northern Research
Category: Standards Track                                   October 1996


             The Simple Public-Key GSS-API Mechanism (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.

Abstract

   This specification defines protocols, procedures, and conventions to
   be employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in RFCs 1508 and 1509)
   when using the Simple Public-Key Mechanism.

Background

   Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming
   well-established in many environments, it is important in some
   applications to have a GSS-API mechanism which is based on a public-
   key, rather than a symmetric-key, infrastructure.  The mechanism
   described in this document has been proposed to meet this need and to
   provide the following features.

     1)  The SPKM allows both unilateral and mutual authentication
         to be accomplished without the use of secure timestamps.  This
         enables environments which do not have access to secure time
         to nevertheless have access to secure authentication.

     2)  The SPKM uses Algorithm Identifiers to specify various
         algorithms to be used by the communicating peers.  This allows
         maximum flexibility for a variety of environments, for future
         enhancements, and for alternative algorithms.

     3)  The SPKM allows the option of a true, asymmetric algorithm-
         based, digital signature in the gss_sign() and gss_seal()
         operations (now called gss_getMIC() and gss_wrap() in
         [GSSv2]), rather than an integrity checksum based on a MAC
         computed with a symmetric algorithm (e.g., DES).  For some
         environments, the availability of true digital signatures
         supporting non-repudiation is a necessity.



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


     4)  SPKM data formats and procedures are designed to be as similar
         to those of the Kerberos mechanism as is practical.  This is
         done for ease of implementation in those environments where
         Kerberos has already been implemented.

   For the above reasons, it is felt that the SPKM will offer
   flexibility and functionality, without undue complexity or overhead.

Key Management

   The key management employed in SPKM is intended to be as compatible
   as possible with both X.509 [X.509] and PEM [RFC-1422], since these
   represent large communities of interest and show relative maturity in
   standards.

Acknowledgments

   Much of the material in this document is based on the Kerberos
   Version 5 GSS-API mechanism [KRB5], and is intended to be as
   compatible with it as possible.  This document also owes a great debt
   to Warwick Ford and Paul Van Oorschot of Bell-Northern Research for
   many fruitful discussions, to Kelvin Desplanque for implementation-
   related clarifications, to John Linn of OpenVision Technologies for
   helpful comments, and to Bancroft Scott of OSS for ASN.1 assistance.

1. Overview

   The goal of the Generic Security Service Application Program
   Interface (GSS-API) is stated in the abstract of [RFC-1508] as
   follows:

     "This Generic Security Service Application Program Interface (GSS-
     API) definition provides security services to callers in a generic
     fashion, supportable with a range of underlying mechanisms and
     technologies and hence allowing source-level portability of
     applications to different environments. This specification defines
     GSS-API services and primitives at a level independent of
     underlying mechanism and programming language environment, and is
     to be complemented by other, related specifications:

       - documents defining specific parameter bindings for particular
         language environments;

       - documents defining token formats, protocols, and procedures to
         be implemented in order to realize GSS-API services atop
         particular security mechanisms."





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


   The SPKM is an instance of the latter type of document and is
   therefore termed a "GSS-API Mechanism".  This mechanism provides
   authentication, key establishment, data integrity, and data
   confidentiality in an on-line distributed application environment
   using a public-key infrastructure.  Because it conforms to the
   interface defined by [RFC-1508], SPKM can be used as a drop-in
   replacement by any application which makes use of security services
   through GSS-API calls (for example, any application which already
   uses the Kerberos GSS-API for security).  The use of a public-key
   infrastructure allows digital signatures supporting non-repudiation
   to be employed for message exchanges, and provides other benefits
   such as scalability to large user populations.

   The tokens defined in SPKM are intended to be used by application
   programs according to the GSS API "operational paradigm" (see [RFC-
   1508] for further details):

     The operational paradigm in which GSS-API operates is as follows.
     A typical GSS-API caller is itself a communications protocol [or is
     an application program which uses a communications protocol],
     calling on GSS-API in order to protect its communications with
     authentication, integrity, and/or confidentiality security
     services.  A GSS-API caller accepts tokens provided to it by its
     local GSS-API implementation [i.e., its GSS-API mechanism] and
     transfers the tokens to a peer on a remote system; that peer passes
     the received tokens to its local GSS-API implementation for
     processing.

     This document defines two separate GSS-API mechanisms, SPKM-1 and
     SPKM-2, whose primary difference is that SPKM-2 requires the
     presence of secure timestamps for the purpose of replay detection
     during context establishment and SPKM-1 does not.  This allows
     greater flexibility for applications since secure timestamps cannot
     always be guaranteed to be available in a given environment.

















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


2. Algorithms

   A number of algorithm types are employed in SPKM.  Each type, along
   with its purpose and a set of specific examples, is described in this
   section.  In order to ensure at least a minimum level of
   interoperability among various implementations of SPKM, one of the
   integrity algorithms is specified as MANDATORY; all remaining
   examples (and any other algorithms) may optionally be supported by a
   given SPKM implementation (note that a GSS-conformant mechanism need
   not support confidentiality).  Making a confidentiality algorithm
   mandatory may preclude exportability of the mechanism implementation;
   this document therefore specifies certain algorithms as RECOMMENDED
   (that is, interoperability will be enhanced if these algorithms are
   included in all SPKM implementations for which exportability is not a
   concern).

2.1 Integrity Algorithm (I-ALG):

         Purpose:

         This algorithm is used to ensure that a message has not been
         altered in any way after being constructed by the legitimate
         sender.  Depending on the algorithm used, the application of
         this algorithm may also provide authenticity and support non-
         repudiation for the message.

       Examples:

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

            This algorithm (MANDATORY) provides data integrity and
            authenticity and supports non-repudiation by computing an
            RSA signature on the MD5 hash of that data.  This is
            essentially equivalent to md5WithRSA {1 3 14 3 2 3},
            which is defined by OIW (the Open Systems Environment
            Implementors' Workshop).

            Note that since this is the only integrity/authenticity
            algorithm specified to be mandatory at this time, for
            interoperability reasons it is also stipulated that
            md5WithRSA be the algorithm used to sign all context
            establishment tokens which are signed rather than MACed --
            see Section 3.1.1 for details.  In future versions of this
            document, alternate or additional algorithms may be
            specified to be mandatory and so this stipulation on the



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


            context establishment tokens may be removed.

         DES-MAC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 10  -- carries length in bits of the MAC as
         }                   -- an INTEGER parameter, constrained to
                             -- multiples of eight from 16 to 64

            This algorithm (RECOMMENDED) provides integrity by computing
            a DES MAC (as specified by [FIPS-113]) on that data.


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

            This algorithm provides data integrity by encrypting, using
            DES CBC, the "confounded" MD5 hash of that data (see Section
            3.2.2.1 for the definition and purpose of confounding).
            This will typically be faster in practice than computing a
            DES MAC unless the input data is extremely short (e.g., a
            few bytes).  Note that without the confounder the strength
            of this integrity mechanism is (at most) equal to the
            strength of DES under a known-plaintext attack.


         sum64-DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) dod(6) internet(1)
            security(5) integrity(3) sum64-DES-CBC(2)
         }

            This algorithm provides data integrity by encrypting, using
            DES CBC, the concatenation of the confounded data and the
            sum of all the input data blocks (the sum computed using
            addition modulo 2**64 - 1).  Thus, in this algorithm,
            encryption is a requirement for the integrity to be secure.

            For comments regarding the security of this integrity
            algorithm, see [Juen84, Davi89].











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


2.2 Confidentiality Algorithm (C-ALG):

       Purpose:

         This symmetric algorithm is used to generate the encrypted
         data for gss_seal() / gss_wrap().

       Example:

         DES-CBC OBJECT IDENTIFIER ::= {
            iso(1) identified-organization(3) oiw(14) secsig(3)
            algorithm(2) 7 -- carries IV (OCTET STRING) as a parameter;
         }                 -- this (optional) parameter is unused in