rfc2203.txt

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

Network Working Group                                          M. Eisler
Request for Comments: 2203                                       A. Chiu
Category: Standards Track                                        L. Ling
                                                          September 1997


                   RPCSEC_GSS Protocol Specification

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 memo describes an ONC/RPC security flavor that allows RPC
   protocols to access the Generic Security Services Application
   Programming Interface (referred to henceforth as GSS-API).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  The ONC RPC Message Protocol . . . . . . . . . . . . . . . . . 2
   3.  Flavor Number Assignment . . . . . . . . . . . . . . . . . . . 3
   4.  New auth_stat Values . . . . . . . . . . . . . . . . . . . . . 3
   5.  Elements of the RPCSEC_GSS Security Protocol . . . . . . . . . 3
   5.1.  Version Selection  . . . . . . . . . . . . . . . . . . . . . 5
   5.2.  Context Creation . . . . . . . . . . . . . . . . . . . . . . 5
   5.2.1.  Mechanism and QOP Selection  . . . . . . . . . . . . . . . 5
   5.2.2.  Context Creation Requests  . . . . . . . . . . . . . . . . 6
   5.2.3.  Context Creation Responses . . . . . . . . . . . . . . . . 8
   5.2.3.1.  Context Creation Response - Successful Acceptance  . . . 8
   5.2.3.1.1.  Client Processing of Successful Context Creation
               Responses  . . . . . . . . . . . . . . . . . . . . . . 9
   5.2.3.2.  Context Creation Response - Unsuccessful Cases . . . . . 9
   5.3.  RPC Data Exchange  . . . . . . . . . . . . . . . . . . . .  10
   5.3.1.  RPC Request Header . . . . . . . . . . . . . . . . . . .  10
   5.3.2.  RPC Request Data . . . . . . . . . . . . . . . . . . . .  11
   5.3.2.1.  RPC Request Data - No Data Integrity . . . . . . . . .  11
   5.3.2.2.  RPC Request Data - With Data Integrity . . . . . . . .  11
   5.3.2.3.  RPC Request Data - With Data Privacy . . . . . . . . .  12
   5.3.3.  Server Processing of RPC Data Requests . . . . . . . . .  12
   5.3.3.1.  Context Management . . . . . . . . . . . . . . . . . .  12
   5.3.3.2.  Server Reply - Request Accepted  . . . . . . . . . . .  14
   5.3.3.3.  Server Reply - Request Denied  . . . . . . . . . . . .  15



Eisler, et. al.             Standards Track                     [Page 1]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


   5.3.3.4.  Mapping of GSS-API Errors to Server Responses  . . . .  16
   5.3.3.4.1.  GSS_GetMIC() Failure . . . . . . . . . . . . . . . .  16
   5.3.3.4.2.  GSS_VerifyMIC() Failure  . . . . . . . . . . . . . .  16
   5.3.3.4.3.  GSS_Unwrap() Failure . . . . . . . . . . . . . . . .  16
   5.3.3.4.4.  GSS_Wrap() Failure . . . . . . . . . . . . . . . . .  16
   5.4.  Context Destruction  . . . . . . . . . . . . . . . . . . .  17
   6.  Set of GSS-API Mechanisms  . . . . . . . . . . . . . . . . .  17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
   7.1.  Privacy of Call Header . . . . . . . . . . . . . . . . . .  18
   7.2.  Sequence Number Attacks  . . . . . . . . . . . . . . . . .  18
   7.2.1.  Sequence Numbers Above the Window  . . . . . . . . . . .  18
   7.2.2.  Sequence Numbers Within or Below the Window  . . . . . .  18
   7.3.  Message Stealing Attacks . . . . . . . . . . . . . . . . .  19
   Appendix A. GSS-API Major Status Codes . . . . . . . . . . . . .  20
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   This document describes the protocol used by the RPCSEC_GSS security
   flavor.  Security flavors have been called authentication flavors for
   historical reasons. This memo recognizes that there are two other
   security services besides authentication, integrity, and privacy, and
   so defines a new RPCSEC_GSS security flavor.

   The protocol is described using the XDR language [Srinivasan-xdr].
   The reader is assumed to be familiar with ONC RPC and the security
   flavor mechanism [Srinivasan-rpc].  The reader is also assumed to be
   familiar with the GSS-API framework [Linn].  The RPCSEC_GSS security
   flavor uses GSS-API interfaces to provide security services that are
   independent of the underlying security mechanism.

2.  The ONC RPC Message Protocol

   This memo refers to the following XDR types of the ONC RPC protocol,
   which are described in the document entitled Remote Procedure Call
   Protocol Specification Version 2 [Srinivasan-rpc]:

      msg_type
      reply_stat
      auth_flavor
      accept_stat
      reject_stat
      auth_stat
      opaque_auth
      rpc_msg
      call_body
      reply_body



Eisler, et. al.             Standards Track                     [Page 2]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


      accepted_reply
      rejected_reply

3.  Flavor Number Assignment

   The RPCSEC_GSS security flavor has been assigned the value of 6:

      enum auth_flavor {
          ...
          RPCSEC_GSS = 6      /* RPCSEC_GSS security flavor */
      };

4.  New auth_stat Values

   RPCSEC_GSS requires the addition of two new values to the auth_stat
   enumerated type definition:

      enum auth_stat {
              ...
              /*
               * RPCSEC_GSS errors
               */
              RPCSEC_GSS_CREDPROBLEM = 13,
              RPCSEC_GSS_CTXPROBLEM = 14
      };

   The descriptions of these two new values are defined later in this
   memo.

5.  Elements of the RPCSEC_GSS Security Protocol

   An RPC session based on the RPCSEC_GSS security flavor consists of
   three phases: context creation, RPC data exchange, and context
   destruction.  In the following discussion, protocol elements for
   these three phases are described.

   The following description of the RPCSEC_GSS protocol uses some of the
   definitions within XDR language description of the RPC protocol.

   Context creation and destruction use control messages that are not
   dispatched to service procedures registered by an RPC server.  The
   program and version numbers used in these control messages are the
   same as the RPC service's program and version numbers.  The procedure
   number used is NULLPROC (zero).  A field in the credential
   information (the gss_proc field which is defined in the
   rpc_gss_cred_t structure below) specifies whether a message is to be
   interpreted as a control message or a regular RPC message.  If this
   field is set to RPCSEC_GSS_DATA, no control action is implied; in



Eisler, et. al.             Standards Track                     [Page 3]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


   this case, it is a regular data message.  If this field is set to any
   other value, a control action is implied.  This is described in the
   following sections.

   Just as with normal RPC data exchange messages, the transaction
   identifier (the xid field in struct rpc_msg), should be set to unique
   values on each call for context creation and context destruction.

   The following definitions are used for describing the protocol.

      /* RPCSEC_GSS control procedures */


      enum rpc_gss_proc_t {
              RPCSEC_GSS_DATA = 0,
              RPCSEC_GSS_INIT = 1,
              RPCSEC_GSS_CONTINUE_INIT = 2,
              RPCSEC_GSS_DESTROY = 3
      };

      /* RPCSEC_GSS services */

      enum rpc_gss_service_t {
          /* Note: the enumerated value for 0 is reserved. */
          rpc_gss_svc_none = 1,
          rpc_gss_svc_integrity = 2,
          rpc_gss_svc_privacy = 3
      };

      /* Credential */

      /*
       * Note: version 0 is reserved for possible future
       * definition of a version negotiation protocol
       *
       */
      #define RPCSEC_GSS_VERS_1 1

      struct rpc_gss_cred_t {
          union switch (unsigned int version) { /* version of
                                                      RPCSEC_GSS */
          case RPCSEC_GSS_VERS_1:
              struct {
                  rpc_gss_proc_t gss_proc;  /* control procedure */
                  unsigned int seq_num;   /* sequence number */
                  rpc_gss_service_t service; /* service used */
                  opaque handle<>;       /* context handle */
              } rpc_gss_cred_vers_1_t;



Eisler, et. al.             Standards Track                     [Page 4]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


          }
      };

      /* Maximum sequence number value */

      #define MAXSEQ 0x80000000

5.1.  Version Selection

   This document defines just one protocol version (RPCSEC_GSS_VERS_1).
   The client should assume that the server supports RPCSEC_GSS_VERS_1
   and issue a Context Creation message (as described in the section
   RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
   MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
   AUTH_REJECTED_CRED.

5.2.  Context Creation

   Before RPC data is exchanged on a session using the RPCSEC_GSS
   flavor, a context must be set up between the client and the server.
   Context creation may involve zero or more RPC exchanges.  The number
   of exchanges depends on the security mechanism.

5.2.1.  Mechanism and QOP Selection

   There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API
   mechanism identifiers or QOP values. At minimum, it is expected that
   implementations of the RPCSEC_GSS protocol provide a means to:

   *    specify mechanism identifiers, QOP values, and RPCSEC_GSS
        service values on the client side, and to

   *    enforce mechanism identifiers, QOP values, and RPCSEC_GSS
        service values on a per-request basis on the server side.

   It is necessary that above capabilities exist so that applications
   have the means to conform the required set of required set of
   <mechanism, QOP, service> tuples (See the section entitled Set of
   GSS-API Mechanisms).  An application may negotiate <mechanism, QOP,
   service> selection within its protocol or via an out of band
   protocol. Hence it may be necessary for RPCSEC_GSS implementations to
   provide programming interfaces for the specification and enforcement
   of <mechanism, QOP, service>.

   Additionally, implementations may depend on negotiation schemes
   constructed as pseudo-mechanisms under the GSS-API.  Because such
   schemes are below the GSS-API layer, the RPCSEC_GSS protocol, as
   specified in this document, can make use of them.



Eisler, et. al.             Standards Track                     [Page 5]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


5.2.2.  Context Creation Requests

   The first RPC request from the client to the server initiates context
   creation.  Within the RPC message protocol's call_body structure,
   rpcvers is set to 2. prog and vers are always those for the service
   being accessed.  The proc is always set to NULLPROC (zero).

   Within the RPC message protocol's cred structure, flavor is set to
   RPCSEC_GSS (6).  The opaque data of the cred structure (the body
   field) constituting the credential encodes the rpc_gss_cred_t
   structure defined previously.

   The values of the fields contained in the rpc_gss_cred_t structure
   are set as follows.  The version field is set to the version of the
   RPCSEC_GSS protocol the client wants to use.  The remainder of this
   memo documents version RPCSEC_GSS_VERS_1 of RPCSEC_GSS, and so the
   version field would be set to RPCSEC_GSS_VERS_1.  The gss_proc field
   must be set to RPCSEC_GSS_INIT for the first creation request.  In
   subsequent creation requests, the gss_proc field must be set to
   RPCSEC_GSS_CONTINUE_INIT.  In a creation request, the seq_num and
   service fields are undefined and both must be ignored by the server.
   In the first creation request, the handle field is NULL (opaque data
   of zero length).  In subsequent creation requests, handle must be
   equal to the value returned by the server.  The handle field serves
   as the identifier for the context, and will not change for the
   duration of the context, including responses to
   RPCSEC_GSS_CONTINUE_INIT.

   The verifier field in the RPC message header is also described by the
   opaque_auth structure.  All creation requests have the NULL verifier
   (AUTH_NONE flavor with zero length opaque data).

   Following the verifier are the call data (procedure specific
   parameters).  Note that the proc field of the call_body structure is
   set to NULLPROC, and thus normally there would be zero octets
   following the verifier.  However, since there is no RPC data exchange
   during a context creation, it is safe to transfer information