rfc2203.txt

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

   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