doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc2203.txt b/doc/rfc/rfc2203.txt
new file mode 100644
index 0000000..2f6a8a0
--- /dev/null
+++ b/doc/rfc/rfc2203.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+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
+   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
+   databody_priv field. Since databody_priv has an XDR type of opaque,
+   the length returned by GSS_Wrap() is encoded as the four octet
+   length, followed by the encrypted octet stream (padded to a multiple
+   of four octets).
+
+5.3.3.  Server Processing of RPC Data Requests
+
+5.3.3.1.  Context Management
+
+   When a request is received by the server, the following are verified
+   to be acceptable:
+
+   *    the version number in the credential
+
+   *    the service specified in the credential
+
+   *    the context handle specified in the credential
+
+   *    the header checksum in the verifier (via GSS_VerifyMIC())
+
+   *    the sequence number (seq_num) specified in the credential (more
+        on this follows)
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 12]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   The gss_proc field in the credential must be set to RPCSEC_GSS_DATA
+   for data requests (otherwise, the message will be interpreted as a
+   control message).
+
+   The server maintains a window of "seq_window" sequence numbers,
+   starting with the last sequence number seen and extending backwards.
+   If a sequence number higher than the last number seen is received
+   (AND if GSS_VerifyMIC() on the header checksum from the verifier
+   returns GSS_S_COMPLETE), the window is moved forward to the new
+   sequence number.  If the last sequence number seen is N, the server
+   is prepared to receive requests with sequence numbers in the range N
+   through (N - seq_window + 1), both inclusive.  If the sequence number
+   received falls below this range, it is silently discarded.  If the
+   sequence number is within this range, and the server has not seen it,
+   the request is accepted, and the server turns on a bit to "remember"
+   that this sequence number has been seen.  If the server determines
+   that it has already seen a sequence number within the window, the
+   request is silently discarded. The server should select a seq_window
+   value based on the number requests it expects to process
+   simultaneously. For example, in a threaded implementation seq_window
+   might be equal to the number of server threads. There are no known
+   security issues with selecting a large window. The primary issue is
+   how much space the server is willing to allocate to keep track of
+   requests received within the window.
+
+   The reason for discarding requests silently is that the server is
+   unable to determine if the duplicate or out of range request was due
+   to a sequencing problem in the client, network, or the operating
+   system, or due to some quirk in routing, or a replay attack by an
+   intruder.  Discarding the request allows the client to recover after
+   timing out, if indeed the duplication was unintentional or well
+   intended.  Note that a consequence of the silent discard is that
+   clients may increment the seq_num by more than one. The effect of
+   this is that the window will move forward more quickly. It is not
+   believed that there is any benefit to doing this.
+
+   Note that the sequence number algorithm requires that the client
+   increment the sequence number even if it is retrying a request with
+   the same RPC transaction identifier.  It is not infrequent for
+   clients to get into a situation where they send two or more attempts
+   and a slow server sends the reply for the first attempt. With
+   RPCSEC_GSS, each request and reply will have a unique sequence
+   number. If the client wishes to improve turn around time on the RPC
+   call, it can cache the RPCSEC_GSS sequence number of each request it
+   sends. Then when it receives a response with a matching RPC
+   transaction identifier, it can compute the checksum of each sequence
+   number in the cache to try to match the checksum in the reply's
+   verifier.
+
+
+
+Eisler, et. al.             Standards Track                    [Page 13]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   The data is decoded according to the service specified in the
+   credential.  In the case of integrity or privacy, the server ensures
+   that the QOP value is acceptable, and that it is the same as that
+   used for the header checksum in the verifier.  Also, in the case of
+   integrity or privacy, the server will reject the message (with a
+   reply status of MSG_ACCEPTED, and an acceptance status of
+   GARBAGE_ARGS) if the sequence number embedded in the request body is
+   different from the sequence number in the credential.
+
+5.3.3.2.  Server Reply - Request Accepted
+
+   An MSG_ACCEPTED reply to a request in the data exchange phase will
+   have the verifier's (the verf element in the response) flavor field
+   set to RPCSEC_GSS, and the body field set to the checksum (the output
+   of GSS_GetMIC()) of the sequence number (in network order) of the
+   corresponding request.  The QOP used is the same as the QOP used for
+   the corresponding request.
+
+   If the status of the reply is not SUCCESS, the rest of the message is
+   formatted as usual.
+
+   If the status of the message is SUCCESS, the format of the rest of
+   the message depends on the service specified in the corresponding
+   request message. Basically, what follows the verifier in this case
+   are the procedure results, formatted in different ways depending on
+   the requested service.
+
+   If no data integrity was requested, the procedure results are
+   formatted as for the AUTH_NONE security flavor.
+
+   If data integrity was requested, the results are encoded in exactly
+   the same way as the procedure arguments were in the corresponding
+   request.  See the section 'RPC Request Data - With Data Integrity.'
+   The only difference is that the structure representing the
+   procedure's result - proc_res_arg_t - must be substituted in place of
+   the request argument structure proc_req_arg_t.  The QOP used for the
+   checksum must be the same as that used for constructing the reply
+   verifier.
+
+   If data privacy was requested, the results are encoded in exactly the
+   same way as the procedure arguments were in the corresponding
+   request.  See the section 'RPC Request Data - With Data Privacy.' The
+   QOP used for  encryption must be the same as that used for
+   constructing the reply verifier.
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 14]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+5.3.3.3.  Server Reply - Request Denied
+
+   An MSG_DENIED reply (to a data request) is formulated as usual.  Two
+   new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have
+   been defined for the auth_stat type.  When the reason for denial of
+   the request is a reject_stat of AUTH_ERROR, one of the two new
+   auth_stat values could be returned in addition to the existing
+   values.  These two new values have special significance from the
+   existing reasons for denial of a request.
+
+   The server maintains a list of contexts for the clients that are
+   currently in session with it.  Normally, a context is destroyed when
+   the client ends the session corresponding to it.  However, due to
+   resource constraints, the server may destroy a context prematurely
+   (on an LRU basis, or if the server machine is rebooted, for example).
+   In this case, when a client request comes in, there may not be a
+   context corresponding to its handle. The server rejects the request,
+   with the reason RPCSEC_GSS_CREDPROBLEM in this case.  Upon receiving
+   this error, the client must refresh the context - that is,
+   reestablish it after destroying the old one - and try the request
+   again.  This error is also returned if the context handle matches
+   that of a different context that was allocated after the client's
+   context was destroyed (this will be detected by a failure in
+   verifying the header checksum).
+
+   If the GSS_VerifyMIC() call on the header checksum (contained in the
+   verifier) fails to return GSS_S_COMPLETE, the server rejects the
+   request and returns an auth_stat of RPCSEC_GSS_CREDPROBLEM.
+
+   When the client's sequence number exceeds the maximum the server will
+   allow, the server will reject the request with the reason
+   RPCSEC_GSS_CTXPROBLEM.  Also, if security credentials become stale
+   while in use (due to ticket expiry in the case of the Kerberos V5
+   mechanism, for example), the failures which result cause the
+   RPCSEC_GSS_CTXPROBLEM reason to be returned.  In these cases also,
+   the client must refresh the context, and retry the request.
+
+   For other errors, retrying will not rectify the problem and the
+   client must not refresh the context until the problem causing the
+   client request to be denied is rectified.
+
+   If the version field in the credential does not match the version of
+   RPCSEC_GSS that was used when the context was created, the
+   AUTH_BADCRED value is returned.
+
+   If there is a problem with the credential, such a bad length, illegal
+   control procedure, or an illegal service, the appropriate auth_stat
+   status is AUTH_BADCRED.
+
+
+
+Eisler, et. al.             Standards Track                    [Page 15]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   Other errors can be returned as appropriate.
+
+5.3.3.4.  Mapping of GSS-API Errors to Server Responses
+
+   During the data exchange phase, the server may invoke GSS_GetMIC(),
+   GSS_VerifyMIC(), GSS_Unwrap(), and GSS_Wrap(). If any of these
+   routines fail to return GSS_S_COMPLETE, then various unsuccessful
+   responses can be returned. The are described as follows for each of
+   the aforementioned four interfaces.
+
+5.3.3.4.1.  GSS_GetMIC() Failure
+
+   When GSS_GetMIC() is called to generate the verifier in the response,
+   a failure results in an RPC response with a reply status of
+   MSG_DENIED, reject status of AUTH_ERROR and an auth status of
+   RPCSEC_GSS_CTXPROBLEM.
+
+   When GSS_GetMIC() is called to sign the call results (service is
+   rpc_gss_svc_integrity), a failure results in no RPC response being
+   sent. Since ONC RPC server applications will typically control when a
+   response is sent, the failure indication will be returned to the
+   server application and it can take appropriate action (such as
+   logging the error).
+
+5.3.3.4.2.  GSS_VerifyMIC() Failure
+
+   When GSS_VerifyMIC() is called to verify the verifier in request, a
+   failure results in an RPC response with a reply status of MSG_DENIED,
+   reject status of AUTH_ERROR and an auth status of
+   RPCSEC_GSS_CREDPROBLEM.
+
+   When GSS_VerifyMIC() is called to verify the call arguments (service
+   is rpc_gss_svc_integrity), a failure results in an RPC response with
+   a reply status of MSG_ACCEPTED, and an acceptance status of
+   GARBAGE_ARGS.
+
+5.3.3.4.3.  GSS_Unwrap() Failure
+
+   When GSS_Unwrap() is called to decrypt the call arguments (service is
+   rpc_gss_svc_privacy), a failure results in an RPC response with a
+   reply status of MSG_ACCEPTED, and an acceptance status of
+   GARBAGE_ARGS.
+
+5.3.3.4.4.  GSS_Wrap() Failure
+
+   When GSS_Wrap() is called to encrypt the call results (service is
+   rpc_gss_svc_privacy), a failure results in no RPC response being
+   sent. Since ONC RPC server applications will typically control when a
+
+
+
+Eisler, et. al.             Standards Track                    [Page 16]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   response is sent, the failure indication will be returned to the
+   application and it can take appropriate action (such as logging the
+   error).
+
+5.4.  Context Destruction
+
+   When the client is done using the session, it must send a control
+   message informing the server that it no longer requires the context.
+   This message is formulated just like a data request packet, with the
+   following differences:  the credential has gss_proc set to
+   RPCSEC_GSS_DESTROY, the procedure specified in the header is
+   NULLPROC, and there are no procedure arguments.  The sequence number
+   in the request must be valid, and the header checksum in the verifier
+   must be valid, for the server to accept the message.  The server
+   sends a response as it would to a data request.  The client and
+   server must then destroy the context for the session.
+
+   If the request to destroy the context fails for some reason, the
+   client need not take any special action.  The server must be prepared
+   to deal with situations where clients never inform the server that
+   they no longer are in session and so don't need the server to
+   maintain a context.  An LRU mechanism or an aging mechanism should be
+   employed by the server to clean up in such cases.
+
+6.  Set of GSS-API Mechanisms
+
+   RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and
+   as such it is inappropriate for the RPCSEC_GSS specification to
+   enumerate a minimum set of required security mechanisms and/or
+   quality of protections.
+
+   If an application protocol specification references RPCSEC_GSS, the
+   protocol specification must list a mandatory set of { mechanism, QOP,
+   service } triples, such that an implementation cannot claim
+   conformance to the protocol specification unless it implements the
+   set of triples. Within each triple, mechanism is a GSS-API security
+   mechanism, QOP is a valid quality-of-protection within the mechanism,
+   and service is either rpc_gss_svc_integrity or rpc_gss_svc_privacy.
+
+   For example, a network filing protocol built on RPC that depends on
+   RPCSEC_GSS for security, might require that Kerberos V5 with the
+   default QOP using the rpc_gss_svc_integrity service be supported by
+   implementations conforming to the network filing protocol
+   specification.
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 17]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+7.  Security Considerations
+
+7.1.  Privacy of Call Header
+
+   The reader will note that for the privacy option, only the call
+   arguments and results are encrypted. Information about the
+   application in the form of RPC program number, program version
+   number, and program procedure number is transmitted in the clear.
+   Encrypting these fields in the RPC call header would have changed the
+   size and format of the call header. This would have required revising
+   the RPC protocol which was beyond the scope of this proposal. Storing
+   the encrypted numbers in the credential would have obviated a
+   protocol change, but would have introduced more overloading of fields
+   and would have made implementations of RPC more complex. Even if the
+   fields were encrypted somehow, in most cases an attacker can
+   determine the program number and version number by examining the
+   destination address of the request and querying the rpcbind service
+   on the destination host [Srinivasan-bind].  In any case, even by not
+   encrypting the three numbers, RPCSEC_GSS still improves the state of
+   security over what existing RPC services have had available
+   previously. Implementors of new RPC services that are concerned about
+   this risk may opt to design in a "sub-procedure" field that is
+   included in the service specific call arguments.
+
+7.2.  Sequence Number Attacks
+
+7.2.1.  Sequence Numbers Above the Window
+
+   An attacker cannot coax the server into raising the sequence number
+   beyond the range the legitimate client is aware of (and thus engineer
+   a denial of server attack) without constructing an RPC request that
+   will pass the header checksum. If the cost of verifying the header
+   checksum is sufficiently large (depending on the speed of the
+   processor doing the checksum and the cost of checksum algorithm), it
+   is possible to envision a denial of service attack (vandalism, in the
+   form of wasting processing resources) whereby the attacker sends
+   requests that are above the window. The simplest method might be for
+   the attacker to monitor the network traffic and then choose a
+   sequence number that is far above the current sequence number. Then
+   the attacker can send bogus requests using the above window sequence
+   number.
+
+7.2.2.  Sequence Numbers Within or Below the Window
+
+   If the attacker sends requests that are within or below the window,
+   then even if the header checksum is successfully verified, the server
+   will silently discard the requests because the server assumes it has
+   already processed the request. In this case, a server can optimize by
+
+
+
+Eisler, et. al.             Standards Track                    [Page 18]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   skipping the header checksum verification if the sequence number is
+   below the window, or if it is within the window, not attempt the
+   checksum verification if the sequence number has already been seen.
+
+7.3.  Message Stealing Attacks
+
+   This proposal does not address attacks where an attacker can block or
+   steal messages without being detected by the server. To implement
+   such protection would be tantamount to assuming a state in the RPC
+   service. RPCSEC_GSS does not worsen this situation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 19]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+Appendix A. GSS-API Major Status Codes
+
+   The GSS-API definition [Linn] does not include numerical values for
+   the various GSS-API major status codes. It is expected that this will
+   be addressed in future RFC. Until then, this appendix defines the
+   values for each GSS-API major status code listed in the GSS-API
+   definition.  If in the future, the GSS-API definition defines values
+   for the codes that are different than what follows, then implementors
+   of RPCSEC_GSS will be obliged to map them into the values defined
+   below. If in the future, the GSS-API definition defines additional
+   status codes not defined below, then the RPCSEC_GSS definition will
+   subsume those additional values.
+
+   Here are the definitions of each GSS_S_* major status that the
+   implementor of RPCSEC_GSS can expect in the gss_major major field of
+   rpc_gss_init_res.  These definitions are not in RPC description
+   language form.  The numbers are in base 16 (hexadecimal):
+
+      GSS_S_COMPLETE                  0x00000000
+      GSS_S_CONTINUE_NEEDED           0x00000001
+      GSS_S_DUPLICATE_TOKEN           0x00000002
+      GSS_S_OLD_TOKEN                 0x00000004
+      GSS_S_UNSEQ_TOKEN               0x00000008
+      GSS_S_GAP_TOKEN                 0x00000010
+      GSS_S_BAD_MECH                  0x00010000
+      GSS_S_BAD_NAME                  0x00020000
+      GSS_S_BAD_NAMETYPE              0x00030000
+      GSS_S_BAD_BINDINGS              0x00040000
+      GSS_S_BAD_STATUS                0x00050000
+      GSS_S_BAD_MIC                   0x00060000
+      GSS_S_BAD_SIG                   0x00060000
+      GSS_S_NO_CRED                   0x00070000
+      GSS_S_NO_CONTEXT                0x00080000
+      GSS_S_DEFECTIVE_TOKEN           0x00090000
+      GSS_S_DEFECTIVE_CREDENTIAL      0x000a0000
+      GSS_S_CREDENTIALS_EXPIRED       0x000b0000
+      GSS_S_CONTEXT_EXPIRED           0x000c0000
+      GSS_S_FAILURE                   0x000d0000
+      GSS_S_BAD_QOP                   0x000e0000
+      GSS_S_UNAUTHORIZED              0x000f0000
+      GSS_S_UNAVAILABLE               0x00100000
+      GSS_S_DUPLICATE_ELEMENT         0x00110000
+      GSS_S_NAME_NOT_MN               0x00120000
+      GSS_S_CALL_INACCESSIBLE_READ    0x01000000
+      GSS_S_CALL_INACCESSIBLE_WRITE   0x02000000
+      GSS_S_CALL_BAD_STRUCTURE        0x03000000
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 20]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+   Note that the GSS-API major status is split into three fields as
+   follows:
+
+        Most Significant Bit                     Least Significant Bit
+        |------------------------------------------------------------|
+        | Calling Error | Routine Error  |    Supplementary Info     |
+        |------------------------------------------------------------|
+      Bit 31           24 23            16 15                        0
+
+   Up to one status in the Calling Error field can be logically ORed
+   with up to one status in the Routine Error field which in turn can be
+   logically ORed with zero or more statuses in the Supplementary Info
+   field. If the resulting major status has a non-zero Calling Error
+   and/or a non-zero Routine Error, then the applicable GSS-API
+   operation has failed.  For purposes of RPCSEC_GSS, this means that
+   the GSS_Accept_sec_context() call executed by the server has failed.
+
+   If the major status is equal GSS_S_COMPLETE, then this indicates the
+   absence of any Errors or Supplementary Info.
+
+   The meanings of most of the GSS_S_* status are defined in the GSS-API
+   definition, which the exceptions of:
+
+   GSS_S_BAD_MIC       This code has the same meaning as GSS_S_BAD_SIG.
+
+   GSS_S_CALL_INACCESSIBLE_READ
+                        A required input parameter could not be read.
+
+   GSS_S_CALL_INACCESSIBLE_WRITE
+                        A required input parameter could not be written.
+
+   GSS_S_CALL_BAD_STRUCTURE
+                       A parameter was malformed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 21]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+Acknowledgements
+
+   Much of the protocol was based on the AUTH_GSSAPI security flavor
+   developed by Open Vision Technologies [Jaspan].  In particular, we
+   acknowledge Barry Jaspan, Marc Horowitz, John Linn, and Ellen
+   McDermott.
+
+   Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from Mike
+   Eisler.  Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed to
+   Sun Microsystems' implementation of RPCSEC_GSS.
+
+   Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn, Hilarie
+   Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed the
+   specification and gave valuable feedback.
+
+   Steve Nahm and Kathy Slattery reviewed various drafts of this
+   specification.
+
+   Much of content of Appendix A was excerpted from John Wray's Work in
+   Progress on GSS-API Version 2 C-bindings.
+
+References
+
+   [Eisler]            Eisler, M., Schemers, R., and Srinivasan, R.
+                       (1996).  "Security Mechanism Independence in ONC
+                       RPC," Proceedings of the Sixth Annual USENIX
+                       Security Symposium, pp. 51-65.
+
+   [Jaspan]            Jaspan, B. (1995). "GSS-API Security for ONC
+                       RPC," `95 Proceedings of The Internet Society
+                       Symposium on Network and Distributed System
+                       Security, pp. 144- 151.
+
+   [Linn]              Linn, J., "Generic Security Service Application
+                       Program Interface, Version 2", RFC 2078, January
+                       1997.
+
+   [Srinivasan-bind]   Srinivasan, R., "Binding Protocols for
+                       ONC RPC Version 2", RFC 1833, August 1995.
+
+   [Srinivasan-rpc]    Srinivasan, R., "RPC: Remote Procedure Call
+                       Protocol Specification Version 2", RFC 1831,
+                       August 1995.
+
+   [Srinivasan-xdr]    Srinivasan, R., "XDR: External Data
+                       Representation Standard", RFC 1832, August 1995.
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 22]
+
+RFC 2203           RPCSEC_GSS Protocol Specification      September 1997
+
+
+Authors' Addresses
+
+   Michael Eisler
+   Sun Microsystems, Inc.
+   M/S UCOS03
+   2550 Garcia Avenue
+   Mountain View, CA 94043
+
+   Phone: +1 (719) 599-9026
+   EMail: mre@eng.sun.com
+
+
+   Alex Chiu
+   Sun Microsystems, Inc.
+   M/S UMPK17-203
+   2550 Garcia Avenue
+   Mountain View, CA 94043
+
+   Phone: +1 (415) 786-6465
+   EMail: hacker@eng.sun.com
+
+
+   Lin Ling
+   Sun Microsystems, Inc.
+   M/S UMPK17-201
+   2550 Garcia Avenue
+   Mountain View, CA 94043
+
+   Phone: +1 (415) 786-5084
+   EMail: lling@eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eisler, et. al.             Standards Track                    [Page 23]
+