rfc2203.txt

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

   following the verifier.  It is necessary to "overload" the call data
   in this way, rather than pack the GSS-API token into the RPC header,
   because RPC Version 2 restricts the amount of data that can be sent
   in the header.  The opaque body of the credential and verifier fields
   can be each at most 400 octets long, and GSS tokens can be longer
   than 800 octets.








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


   The call data for a context creation request is described by the
   following structure for all creation requests:

      struct rpc_gss_init_arg {
          opaque gss_token<>;
      };

   Here, gss_token is the token returned by the call to  GSS-API's
   GSS_Init_sec_context() routine, opaquely encoded.  The value of this
   field will likely be different in each creation request, if there is
   more than one creation request.  If no token is returned by the call
   to GSS_Init_sec_context(), the context must have been created
   (assuming no errors), and there will not be any more creation
   requests.

   When GSS_Init_sec_context() is called, the parameters
   replay_det_req_flag and sequence_req_flag must be turned off. The
   reasons for this are:

   *    ONC RPC can be used over unreliable transports and provides no
        layer to reliably re-assemble messages. Thus it is possible for
        gaps in message sequencing to occur, as well as out of order
        messages.

   *    RPC servers can be multi-threaded, and thus the order in which
        GSS-API messages are signed or wrapped can be different from the
        order in which the messages are verified or unwrapped, even if
        the requests are sent on reliable transports.

   *    To maximize convenience of implementation, the order in which an
        ONC RPC entity will verify the header and verify/unwrap the body
        of an RPC call or reply is left unspecified.

   The RPCSEC_GSS protocol provides for protection from replay attack,
   yet tolerates out-of-order delivery or processing of messages and
   tolerates dropped requests.















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


5.2.3.  Context Creation Responses

5.2.3.1.  Context Creation Response - Successful Acceptance

   The response to a successful creation request has an MSG_ACCEPTED
   response with a status of SUCCESS.  The results field encodes a
   response with the following structure:

      struct rpc_gss_init_res {
              opaque handle<>;
              unsigned int gss_major;
              unsigned int gss_minor;
              unsigned int seq_window;
              opaque gss_token<>;
      };

   Here, handle is non-NULL opaque data that serves as the context
   identifier. The client must use this value in all subsequent requests
   whether control messages or otherwise).  The gss_major and gss_minor
   fields contain the results of the call to GSS_Accept_sec_context()
   executed by the server.  The values for the gss_major field are
   defined in Appendix A of this document.  The values for the gss_minor
   field are GSS-API mechanism specific and are defined in the
   mechanism's specification.  If gss_major is not one of GSS_S_COMPLETE
   or GSS_S_CONTINUE_NEEDED, the context setup has failed; in this case
   handle and gss_token must be set to NULL by the server.  The value of
   gss_minor is dependent on the value of gss_major and the security
   mechanism used.  The gss_token field contains any token returned by
   the GSS_Accept_sec_context() call executed by the server.  A token
   may be returned for both successful values of gss_major.  If the
   value is GSS_S_COMPLETE, it indicates that the server is not
   expecting any more tokens, and the RPC Data Exchange phase must begin
   on the subsequent request from the client. If the value is
   GSS_S_CONTINUE_NEEDED, the server is expecting another token.  Hence
   the client must send at least one more creation request (with
   gss_proc set to RPCSEC_GSS_CONTINUE_INIT in the request's credential)
   carrying the required token.

   In a successful response, the seq_window field is set to the sequence
   window length supported by the server for this context.  This window
   specifies the maximum number of client requests that may be
   outstanding for this context. The server will accept "seq_window"
   requests at a time, and these may be out of order.  The client may
   use this number to determine the number of threads that can
   simultaneously send requests on this context.






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


   If gss_major is GSS_S_COMPLETE, the verifier's (the verf element in
   the response) flavor field is set to RPCSEC_GSS, and the body field
   set to the checksum of the seq_window (in network order). The QOP
   used for this checksum is 0 (zero), which is the default QOP.  For
   all other values of gss_major, a NULL verifier (AUTH_NONE flavor with
   zero-length opaque data) is used.

5.2.3.1.1.  Client Processing of Successful Context Creation Responses

   If the value of gss_major in the response is GSS_S_CONTINUE_NEEDED,
   then the client, per the GSS-API specification, must invoke
   GSS_Init_sec_context() using the token returned in gss_token in the
   context creation response. The client must then generate a context
   creation request, with gss_proc set to RPCSEC_GSS_CONTINUE_INIT.

   If the value of gss_major in the response is GSS_S_COMPLETE, and if
   the client's previous invocation of GSS_Init_sec_context() returned a
   gss_major value of GSS_S_CONTINUE_NEEDED, then the client, per the
   GSS-API specification, must invoke GSS_Init_sec_context() using the
   token returned in gss_token in the context creation response. If
   GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is
   successfully set up, and the RPC data exchange phase must begin on
   the subsequent request from the client.

5.2.3.2.  Context Creation Response - Unsuccessful Cases

   An MSG_ACCEPTED reply (to a creation request) with an acceptance
   status of other than SUCCESS has a NULL verifier (flavor set to
   AUTH_NONE, and zero length opaque data in the body field), and is
   formulated as usual for different status values.

   An MSG_DENIED reply (to a creation request) is also formulated as
   usual.  Note that MSG_DENIED could be returned because the server's
   RPC implementation does not recognize the RPCSEC_GSS security flavor.
   RFC 1831 does not specify the appropriate reply status in this
   instance, but common implementation practice appears to be to return
   a rejection status of AUTH_ERROR with an auth_stat of
   AUTH_REJECTEDCRED. Even though two new values (RPCSEC_GSS_CREDPROBLEM
   and RPCSEC_GSS_CTXPROBLEM) have been defined for the auth_stat type,
   neither of these two can be returned in responses to context creation
   requests.  The auth_stat new values can be used for responses to
   normal (data) requests.  This is described later.

   MSG_DENIED might also be returned if the RPCSEC_GSS version number in
   the credential is not supported on the server. In that case, the
   server returns a rejection status of AUTH_ERROR, with an auth_stat of

   AUTH_REJECTED_CRED.



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


5.3.  RPC Data Exchange

   The data exchange phase is entered after a context has been
   successfully set up. The format of the data exchanged depends on the
   security service used for the request.  Although clients can change
   the security service and QOP used on a per-request basis, this may
   not be acceptable to all RPC services; some RPC services may "lock"
   the data exchange phase into using the QOP and service used on the
   first data exchange message.  For all three modes of service (no data
   integrity, data integrity, data privacy), the RPC request header has
   the same format.

5.3.1.  RPC Request Header

   The credential has the opaque_auth structure described earlier.  The
   flavor field is set to RPCSEC_GSS.  The credential body is created by
   XDR encoding the rpc_gss_cred_t structure listed earlier into an
   octet stream, and then opaquely encoding this octet stream as the
   body field.

   Values of the fields contained in the rpc_gss_cred_t structure are
   set as follows.  The version field is set to same version value that
   was used to create the context, which within the scope of this memo
   will always be RPCSEC_GSS_VERS_1.  The gss_proc field is set to
   RPCSEC_GSS_DATA.  The service field is set to indicate the desired
   service (one of rpc_gss_svc_none, rpc_gss_svc_integrity, or
   rpc_gss_svc_privacy).  The handle field is set to the context handle
   value received from the RPC server during context creation.  The
   seq_num field can start at any value below MAXSEQ, and must be
   incremented (by one or more) for successive requests.  Use of
   sequence numbers is described in detail when server processing of the
   request is discussed.

   The verifier has the opaque_auth structure described earlier.  The
   flavor field is set to RPCSEC_GSS.  The body field is set as follows.
   The checksum of the RPC header (up to and including the credential)
   is computed using the GSS_GetMIC() call with the desired QOP.  This
   returns the checksum as an opaque octet stream and its length.  This
   is encoded into the body field.  Note that the QOP is not explicitly
   specified anywhere in the request.  It is implicit in the checksum or
   encrypted data.  The same QOP value as is used for the header
   checksum must also be used for the data (for checksumming or
   encrypting), unless the service used for the request is
   rpc_gss_svc_none.







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


5.3.2.  RPC Request Data

5.3.2.1.  RPC Request Data - No Data Integrity

   If the service specified is rpc_gss_svc_none, the data (procedure
   arguments) are not integrity or privacy protected.  They are sent in
   exactly the same way as they would be if the AUTH_NONE flavor were
   used (following the verifier).  Note, however, that since the RPC
   header is integrity protected, the sender will still be authenticated
   in this case.

5.3.2.2.  RPC Request Data - With Data Integrity

   When data integrity is used, the request data is represented as
   follows:

      struct rpc_gss_integ_data {
          opaque databody_integ<>;
          opaque checksum<>;
      };

   The databody_integ field is created as follows.  A structure
   consisting of a sequence number followed by the procedure arguments
   is constructed. This is shown below as the type rpc_gss_data_t:

      struct rpc_gss_data_t {
          unsigned int seq_num;
          proc_req_arg_t arg;
      };

   Here, seq_num must have the same value as in the credential.  The
   type proc_req_arg_t is the procedure specific XDR type describing the
   procedure arguments (and so is not specified here).  The octet stream
   corresponding to the XDR encoded rpc_gss_data_t structure and its
   length are placed in the databody_integ field. Note that because the
   XDR type of databody_integ is opaque, the XDR encoding of
   databody_integ will include an initial four octet length field,
   followed by the XDR encoded octet stream of rpc_gss_data_t.

   The checksum field represents the checksum of the XDR encoded octet
   stream corresponding to the XDR encoded rpc_gss_data_t structure
   (note, this is not the checksum of the databody_integ field).  This
   is obtained using the GSS_GetMIC() call, with the same QOP as was
   used to compute the header checksum (in the verifier). The







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


   GSS_GetMIC() call returns the checksum as an opaque octet stream and
   its length. The checksum field of struct rpc_gss_integ_data has an
   XDR type of opaque. Thus the checksum length from GSS_GetMIC() is
   encoded as a four octet  length field, followed by the checksum,
   padded to a multiple of four octets.

5.3.2.3.  RPC Request Data - With Data Privacy

   When data privacy is used, the request data is represented as
   follows:

      struct rpc_gss_priv_data {
          opaque databody_priv<>
      };

   The databody_priv field is created as follows.  The rpc_gss_data_t
   structure described earlier is constructed again in the same way as
   for the case of data integrity.  Next, the GSS_Wrap() call is invoked
   to encrypt the octet stream corresponding to the rpc_gss_data_t
   structure, using the same value for QOP (argument qop_req to
   GSS_Wrap()) as was used for the header checksum (in the verifier) and
   conf_req_flag (an argument to GSS_Wrap()) of TRUE.  The GSS_Wrap()
   call returns an opaque octet stream (representing the encrypted
   rpc_gss_data_t structure) and its length, and this is encoded as the