As per Relevance of the word creation, we have this rfc below:
Network Working Group M.
Request for Comments: 2203 A.
Category: Standards Track L.
September 1997
RPCSEC_GSS Protocol
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This memo describes an ONC/RPC security flavor that allows
protocols to access the Generic Security Services
Programming Interface (referred to henceforth as GSS-API).
Table of
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
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.
This document describes the protocol used by the RPCSEC_GSS
flavor. Security flavors have been called authentication flavors
historical reasons. This memo recognizes that there are two
security services besides authentication, integrity, and privacy,
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
flavor mechanism [Srinivasan-rpc]. The reader is also assumed to
familiar with the GSS-API framework [Linn]. The RPCSEC_GSS
flavor uses GSS-API interfaces to provide security services that
independent of the underlying security mechanism
2. The ONC RPC Message
This memo refers to the following XDR types of the ONC RPC protocol
which are described in the document entitled Remote Procedure
Protocol Specification Version 2 [Srinivasan-rpc]:
msg_
reply_
auth_
accept_
reject_
auth_
opaque_
rpc_
call_
reply_
Eisler, et. al. Standards Track [Page 2]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
accepted_
rejected_
3. Flavor Number
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
RPCSEC_GSS requires the addition of two new values to the auth_
enumerated type definition
enum auth_stat {
...
/*
* RPCSEC_GSS
*/
RPCSEC_GSS_CREDPROBLEM = 13,
RPCSEC_GSS_CTXPROBLEM = 14
};
The descriptions of these two new values are defined later in
memo
5. Elements of the RPCSEC_GSS Security
An RPC session based on the RPCSEC_GSS security flavor consists
three phases: context creation, RPC data exchange, and
destruction. In the following discussion, protocol elements
these three phases are described
The following description of the RPCSEC_GSS protocol uses some of
definitions within XDR language description of the RPC protocol
Context creation and destruction use control messages that are
dispatched to service procedures registered by an RPC server.
program and version numbers used in these control messages are
same as the RPC service's program and version numbers. The
number used is NULLPROC (zero). A field in the
information (the gss_proc field which is defined in
rpc_gss_cred_t structure below) specifies whether a message is to
interpreted as a control message or a regular RPC message. If
field is set to RPCSEC_GSS_DATA, no control action is implied;
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
other value, a control action is implied. This is described in
following sections
Just as with normal RPC data exchange messages, the
identifier (the xid field in struct rpc_msg), should be set to
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
* definition of a version negotiation
*
*/
#define RPCSEC_GSS_VERS_1 1
struct rpc_gss_cred_t {
union switch (unsigned int version) { /* version
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
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
RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat
MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat
AUTH_REJECTED_CRED
5.2. Context
Before RPC data is exchanged on a session using the RPCSEC_
flavor, a context must be set up between the client and the server
Context creation may involve zero or more RPC exchanges. The
of exchanges depends on the security mechanism
5.2.1. Mechanism and QOP
There is no facility in the RPCSEC_GSS protocol to negotiate GSS-
mechanism identifiers or QOP values. At minimum, it is expected
implementations of the RPCSEC_GSS protocol provide a means to
* specify mechanism identifiers, QOP values, and RPCSEC_
service values on the client side, and
* enforce mechanism identifiers, QOP values, and RPCSEC_
service values on a per-request basis on the server side
It is necessary that above capabilities exist so that
have the means to conform the required set of required set
<mechanism, QOP, service> tuples (See the section entitled Set
GSS-API Mechanisms). An application may negotiate <mechanism, QOP
service> selection within its protocol or via an out of
protocol. Hence it may be necessary for RPCSEC_GSS implementations
provide programming interfaces for the specification and
of <mechanism, QOP, service>.
Additionally, implementations may depend on negotiation
constructed as pseudo-mechanisms under the GSS-API. Because
schemes are below the GSS-API layer, the RPCSEC_GSS protocol,
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
The first RPC request from the client to the server initiates
creation. Within the RPC message protocol's call_body structure
rpcvers is set to 2. prog and vers are always those for the
being accessed. The proc is always set to NULLPROC (zero).
Within the RPC message protocol's cred structure, flavor is set
RPCSEC_GSS (6). The opaque data of the cred structure (the
field) constituting the credential encodes the rpc_gss_cred_
structure defined previously
The values of the fields contained in the rpc_gss_cred_t
are set as follows. The version field is set to the version of
RPCSEC_GSS protocol the client wants to use. The remainder of
memo documents version RPCSEC_GSS_VERS_1 of RPCSEC_GSS, and so
version field would be set to RPCSEC_GSS_VERS_1. The gss_proc
must be set to RPCSEC_GSS_INIT for the first creation request.
subsequent creation requests, the gss_proc field must be set
RPCSEC_GSS_CONTINUE_INIT. In a creation request, the seq_num
service fields are undefined and both must be ignored by the server
In the first creation request, the handle field is NULL (opaque
of zero length). In subsequent creation requests, handle must
equal to the value returned by the server. The handle field
as the identifier for the context, and will not change for
duration of the context, including responses
RPCSEC_GSS_CONTINUE_INIT
The verifier field in the RPC message header is also described by
opaque_auth structure. All creation requests have the NULL
(AUTH_NONE flavor with zero length opaque data).
Following the verifier are the call data (procedure
parameters). Note that the proc field of the call_body structure
set to NULLPROC, and thus normally there would be zero
following the verifier. However, since there is no RPC data
during a context creation, it is safe to transfer
following the verifier. It is necessary to "overload" the call
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
in the header. The opaque body of the credential and verifier
can be each at most 400 octets long, and GSS tokens can be
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
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'
GSS_Init_sec_context() routine, opaquely encoded. The value of
field will likely be different in each creation request, if there
more than one creation request. If no token is returned by the
to GSS_Init_sec_context(), the context must have been
(assuming no errors), and there will not be any more
requests
When GSS_Init_sec_context() is called, the
replay_det_req_flag and sequence_req_flag must be turned off.
reasons for this are
* ONC RPC can be used over unreliable transports and provides
layer to reliably re-assemble messages. Thus it is possible
gaps in message sequencing to occur, as well as out of
messages
* RPC servers can be multi-threaded, and thus the order in
GSS-API messages are signed or wrapped can be different from
order in which the messages are verified or unwrapped, even
the requests are sent on reliable transports
* To maximize convenience of implementation, the order in which
ONC RPC entity will verify the header and verify/unwrap the
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
tolerates dropped requests
Eisler, et. al. Standards Track [Page 7]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
5.2.3. Context Creation
5.2.3.1. Context Creation Response - Successful
The response to a successful creation request has an MSG_
response with a status of SUCCESS. The results field encodes
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
identifier. The client must use this value in all subsequent
whether control messages or otherwise). The gss_major and gss_
fields contain the results of the call to GSS_Accept_sec_context()
executed by the server. The values for the gss_major field
defined in Appendix A of this document. The values for the gss_
field are GSS-API mechanism specific and are defined in
mechanism's specification. If gss_major is not one of GSS_S_
or GSS_S_CONTINUE_NEEDED, the context setup has failed; in this
handle and gss_token must be set to NULL by the server. The value
gss_minor is dependent on the value of gss_major and the
mechanism used. The gss_token field contains any token returned
the GSS_Accept_sec_context() call executed by the server. A
may be returned for both successful values of gss_major. If
value is GSS_S_COMPLETE, it indicates that the server is
expecting any more tokens, and the RPC Data Exchange phase must
on the subsequent request from the client. If the value
GSS_S_CONTINUE_NEEDED, the server is expecting another token.
the client must send at least one more creation request (
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
window length supported by the server for this context. This
specifies the maximum number of client requests that may
outstanding for this context. The server will accept "seq_window
requests at a time, and these may be out of order. The client
use this number to determine the number of threads that
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
the response) flavor field is set to RPCSEC_GSS, and the body
set to the checksum of the seq_window (in network order). The
used for this checksum is 0 (zero), which is the default QOP.
all other values of gss_major, a NULL verifier (AUTH_NONE flavor
zero-length opaque data) is used
5.2.3.1.1. Client Processing of Successful Context Creation
If the value of gss_major in the response is GSS_S_CONTINUE_NEEDED
then the client, per the GSS-API specification, must
GSS_Init_sec_context() using the token returned in gss_token in
context creation response. The client must then generate a
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
the client's previous invocation of GSS_Init_sec_context() returned
gss_major value of GSS_S_CONTINUE_NEEDED, then the client, per
GSS-API specification, must invoke GSS_Init_sec_context() using
token returned in gss_token in the context creation response.
GSS_Init_sec_context() returns GSS_S_COMPLETE, the context
successfully set up, and the RPC data exchange phase must begin
the subsequent request from the client
5.2.3.2. Context Creation Response - Unsuccessful
An MSG_ACCEPTED reply (to a creation request) with an
status of other than SUCCESS has a NULL verifier (flavor set
AUTH_NONE, and zero length opaque data in the body field), and
formulated as usual for different status values
An MSG_DENIED reply (to a creation request) is also formulated
usual. Note that MSG_DENIED could be returned because the server'
RPC implementation does not recognize the RPCSEC_GSS security flavor
RFC 1831 does not specify the appropriate reply status in
instance, but common implementation practice appears to be to
a rejection status of AUTH_ERROR with an auth_stat
AUTH_REJECTEDCRED. Even though two new values (RPCSEC_GSS_
and RPCSEC_GSS_CTXPROBLEM) have been defined for the auth_stat type
neither of these two can be returned in responses to context
requests. The auth_stat new values can be used for responses
normal (data) requests. This is described later
MSG_DENIED might also be returned if the RPCSEC_GSS version number
the credential is not supported on the server. In that case,
server returns a rejection status of AUTH_ERROR, with an auth_stat
AUTH_REJECTED_CRED
Eisler, et. al. Standards Track [Page 9]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
5.3. RPC Data
The data exchange phase is entered after a context has
successfully set up. The format of the data exchanged depends on
security service used for the request. Although clients can
the security service and QOP used on a per-request basis, this
not be acceptable to all RPC services; some RPC services may "lock
the data exchange phase into using the QOP and service used on
first data exchange message. For all three modes of service (no
integrity, data integrity, data privacy), the RPC request header
the same format
5.3.1. RPC Request
The credential has the opaque_auth structure described earlier.
flavor field is set to RPCSEC_GSS. The credential body is created
XDR encoding the rpc_gss_cred_t structure listed earlier into
octet stream, and then opaquely encoding this octet stream as
body field
Values of the fields contained in the rpc_gss_cred_t structure
set as follows. The version field is set to same version value
was used to create the context, which within the scope of this
will always be RPCSEC_GSS_VERS_1. The gss_proc field is set
RPCSEC_GSS_DATA. The service field is set to indicate the
service (one of rpc_gss_svc_none, rpc_gss_svc_integrity,
rpc_gss_svc_privacy). The handle field is set to the context
value received from the RPC server during context creation.
seq_num field can start at any value below MAXSEQ, and must
incremented (by one or more) for successive requests. Use
sequence numbers is described in detail when server processing of
request is discussed
The verifier has the opaque_auth structure described earlier.
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.
returns the checksum as an opaque octet stream and its length.
is encoded into the body field. Note that the QOP is not
specified anywhere in the request. It is implicit in the checksum
encrypted data. The same QOP value as is used for the
checksum must also be used for the data (for checksumming
encrypting), unless the service used for the request
rpc_gss_svc_none
Eisler, et. al. Standards Track [Page 10]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
5.3.2. RPC Request
5.3.2.1. RPC Request Data - No Data
If the service specified is rpc_gss_svc_none, the data (
arguments) are not integrity or privacy protected. They are sent
exactly the same way as they would be if the AUTH_NONE flavor
used (following the verifier). Note, however, that since the
header is integrity protected, the sender will still be
in this case
5.3.2.2. RPC Request Data - With Data
When data integrity is used, the request data is represented
follows
struct rpc_gss_integ_data {
opaque databody_integ<>;
opaque checksum<>;
};
The databody_integ field is created as follows. A
consisting of a sequence number followed by the procedure
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.
type proc_req_arg_t is the procedure specific XDR type describing
procedure arguments (and so is not specified here). The octet
corresponding to the XDR encoded rpc_gss_data_t structure and
length are placed in the databody_integ field. Note that because
XDR type of databody_integ is opaque, the XDR encoding
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
stream corresponding to the XDR encoded rpc_gss_data_t
(note, this is not the checksum of the databody_integ field).
is obtained using the GSS_GetMIC() call, with the same QOP as
used to compute the header checksum (in the verifier).
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
its length. The checksum field of struct rpc_gss_integ_data has
XDR type of opaque. Thus the checksum length from GSS_GetMIC()
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
When data privacy is used, the request data is represented
follows
struct rpc_gss_priv_data {
opaque databody_priv<>
};
The databody_priv field is created as follows. The rpc_gss_data_
structure described earlier is constructed again in the same way
for the case of data integrity. Next, the GSS_Wrap() call is
to encrypt the octet stream corresponding to the rpc_gss_data_
structure, using the same value for QOP (argument qop_req
GSS_Wrap()) as was used for the header checksum (in the verifier)
conf_req_flag (an argument to GSS_Wrap()) of TRUE. The GSS_Wrap()
call returns an opaque octet stream (representing the
rpc_gss_data_t structure) and its length, and this is encoded as
databody_priv field. Since databody_priv has an XDR type of opaque
the length returned by GSS_Wrap() is encoded as the four
length, followed by the encrypted octet stream (padded to a
of four octets).
5.3.3. Server Processing of RPC Data
5.3.3.1. Context
When a request is received by the server, the following are
to be acceptable
* the version number in the
* the service specified in the
* the context handle specified in the
* the header checksum in the verifier (via GSS_VerifyMIC())
* the sequence number (seq_num) specified in the credential (
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_
for data requests (otherwise, the message will be interpreted as
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
(AND if GSS_VerifyMIC() on the header checksum from the
returns GSS_S_COMPLETE), the window is moved forward to the
sequence number. If the last sequence number seen is N, the
is prepared to receive requests with sequence numbers in the range
through (N - seq_window + 1), both inclusive. If the sequence
received falls below this range, it is silently discarded. If
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
that it has already seen a sequence number within the window,
request is silently discarded. The server should select a seq_
value based on the number requests it expects to
simultaneously. For example, in a threaded implementation seq_
might be equal to the number of server threads. There are no
security issues with selecting a large window. The primary issue
how much space the server is willing to allocate to keep track
requests received within the window
The reason for discarding requests silently is that the server
unable to determine if the duplicate or out of range request was
to a sequencing problem in the client, network, or the
system, or due to some quirk in routing, or a replay attack by
intruder. Discarding the request allows the client to recover
timing out, if indeed the duplication was unintentional or
intended. Note that a consequence of the silent discard is
clients may increment the seq_num by more than one. The effect
this is that the window will move forward more quickly. It is
believed that there is any benefit to doing this
Note that the sequence number algorithm requires that the
increment the sequence number even if it is retrying a request
the same RPC transaction identifier. It is not infrequent
clients to get into a situation where they send two or more
and a slow server sends the reply for the first attempt.
RPCSEC_GSS, each request and reply will have a unique
number. If the client wishes to improve turn around time on the
call, it can cache the RPCSEC_GSS sequence number of each request
sends. Then when it receives a response with a matching
transaction identifier, it can compute the checksum of each
number in the cache to try to match the checksum in the reply'
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
credential. In the case of integrity or privacy, the server
that the QOP value is acceptable, and that it is the same as
used for the header checksum in the verifier. Also, in the case
integrity or privacy, the server will reject the message (with
reply status of MSG_ACCEPTED, and an acceptance status
GARBAGE_ARGS) if the sequence number embedded in the request body
different from the sequence number in the credential
5.3.3.2. Server Reply - Request
An MSG_ACCEPTED reply to a request in the data exchange phase
have the verifier's (the verf element in the response) flavor
set to RPCSEC_GSS, and the body field set to the checksum (the
of GSS_GetMIC()) of the sequence number (in network order) of
corresponding request. The QOP used is the same as the QOP used
the corresponding request
If the status of the reply is not SUCCESS, the rest of the message
formatted as usual
If the status of the message is SUCCESS, the format of the rest
the message depends on the service specified in the
request message. Basically, what follows the verifier in this
are the procedure results, formatted in different ways depending
the requested service
If no data integrity was requested, the procedure results
formatted as for the AUTH_NONE security flavor
If data integrity was requested, the results are encoded in
the same way as the procedure arguments were in the
request. See the section 'RPC Request Data - With Data Integrity.'
The only difference is that the structure representing
procedure's result - proc_res_arg_t - must be substituted in place
the request argument structure proc_req_arg_t. The QOP used for
checksum must be the same as that used for constructing the
verifier
If data privacy was requested, the results are encoded in exactly
same way as the procedure arguments were in the
request. See the section 'RPC Request Data - With Data Privacy.'
QOP used for encryption must be the same as that used
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
An MSG_DENIED reply (to a data request) is formulated as usual.
new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM)
been defined for the auth_stat type. When the reason for denial
the request is a reject_stat of AUTH_ERROR, one of the two
auth_stat values could be returned in addition to the
values. These two new values have special significance from
existing reasons for denial of a request
The server maintains a list of contexts for the clients that
currently in session with it. Normally, a context is destroyed
the client ends the session corresponding to it. However, due
resource constraints, the server may destroy a context
(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
context corresponding to its handle. The server rejects the request
with the reason RPCSEC_GSS_CREDPROBLEM in this case. Upon
this error, the client must refresh the context - that is
reestablish it after destroying the old one - and try the
again. This error is also returned if the context handle
that of a different context that was allocated after the client'
context was destroyed (this will be detected by a failure
verifying the header checksum).
If the GSS_VerifyMIC() call on the header checksum (contained in
verifier) fails to return GSS_S_COMPLETE, the server rejects
request and returns an auth_stat of RPCSEC_GSS_CREDPROBLEM
When the client's sequence number exceeds the maximum the server
allow, the server will reject the request with the
RPCSEC_GSS_CTXPROBLEM. Also, if security credentials become
while in use (due to ticket expiry in the case of the Kerberos V
mechanism, for example), the failures which result cause
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
client must not refresh the context until the problem causing
client request to be denied is rectified
If the version field in the credential does not match the version
RPCSEC_GSS that was used when the context was created,
AUTH_BADCRED value is returned
If there is a problem with the credential, such a bad length,
control procedure, or an illegal service, the appropriate auth_
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
During the data exchange phase, the server may invoke GSS_GetMIC(),
GSS_VerifyMIC(), GSS_Unwrap(), and GSS_Wrap(). If any of
routines fail to return GSS_S_COMPLETE, then various
responses can be returned. The are described as follows for each
the aforementioned four interfaces
5.3.3.4.1. GSS_GetMIC()
When GSS_GetMIC() is called to generate the verifier in the response
a failure results in an RPC response with a reply status
MSG_DENIED, reject status of AUTH_ERROR and an auth status
RPCSEC_GSS_CTXPROBLEM
When GSS_GetMIC() is called to sign the call results (service
rpc_gss_svc_integrity), a failure results in no RPC response
sent. Since ONC RPC server applications will typically control when
response is sent, the failure indication will be returned to
server application and it can take appropriate action (such
logging the error).
5.3.3.4.2. GSS_VerifyMIC()
When GSS_VerifyMIC() is called to verify the verifier in request,
failure results in an RPC response with a reply status of MSG_DENIED
reject status of AUTH_ERROR and an auth status
RPCSEC_GSS_CREDPROBLEM
When GSS_VerifyMIC() is called to verify the call arguments (
is rpc_gss_svc_integrity), a failure results in an RPC response
a reply status of MSG_ACCEPTED, and an acceptance status
GARBAGE_ARGS
5.3.3.4.3. GSS_Unwrap()
When GSS_Unwrap() is called to decrypt the call arguments (service
rpc_gss_svc_privacy), a failure results in an RPC response with
reply status of MSG_ACCEPTED, and an acceptance status
GARBAGE_ARGS
5.3.3.4.4. GSS_Wrap()
When GSS_Wrap() is called to encrypt the call results (service
rpc_gss_svc_privacy), a failure results in no RPC response
sent. Since ONC RPC server applications will typically control when
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
application and it can take appropriate action (such as logging
error).
5.4. Context
When the client is done using the session, it must send a
message informing the server that it no longer requires the context
This message is formulated just like a data request packet, with
following differences: the credential has gss_proc set
RPCSEC_GSS_DESTROY, the procedure specified in the header
NULLPROC, and there are no procedure arguments. The sequence
in the request must be valid, and the header checksum in the
must be valid, for the server to accept the message. The
sends a response as it would to a data request. The client
server must then destroy the context for the session
If the request to destroy the context fails for some reason,
client need not take any special action. The server must be
to deal with situations where clients never inform the server
they no longer are in session and so don't need the server
maintain a context. An LRU mechanism or an aging mechanism should
employed by the server to clean up in such cases
6. Set of GSS-API
RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer,
as such it is inappropriate for the RPCSEC_GSS specification
enumerate a minimum set of required security mechanisms and/
quality of protections
If an application protocol specification references RPCSEC_GSS,
protocol specification must list a mandatory set of { mechanism, QOP
service } triples, such that an implementation cannot
conformance to the protocol specification unless it implements
set of triples. Within each triple, mechanism is a GSS-API
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
RPCSEC_GSS for security, might require that Kerberos V5 with
default QOP using the rpc_gss_svc_integrity service be supported
implementations conforming to the network filing
specification
Eisler, et. al. Standards Track [Page 17]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
7. Security
7.1. Privacy of Call
The reader will note that for the privacy option, only the
arguments and results are encrypted. Information about
application in the form of RPC program number, program
number, and program procedure number is transmitted in the clear
Encrypting these fields in the RPC call header would have changed
size and format of the call header. This would have required
the RPC protocol which was beyond the scope of this proposal.
the encrypted numbers in the credential would have obviated
protocol change, but would have introduced more overloading of
and would have made implementations of RPC more complex. Even if
fields were encrypted somehow, in most cases an attacker
determine the program number and version number by examining
destination address of the request and querying the rpcbind
on the destination host [Srinivasan-bind]. In any case, even by
encrypting the three numbers, RPCSEC_GSS still improves the state
security over what existing RPC services have had
previously. Implementors of new RPC services that are concerned
this risk may opt to design in a "sub-procedure" field that
included in the service specific call arguments
7.2. Sequence Number
7.2.1. Sequence Numbers Above the
An attacker cannot coax the server into raising the sequence
beyond the range the legitimate client is aware of (and thus
a denial of server attack) without constructing an RPC request
will pass the header checksum. If the cost of verifying the
checksum is sufficiently large (depending on the speed of
processor doing the checksum and the cost of checksum algorithm),
is possible to envision a denial of service attack (vandalism, in
form of wasting processing resources) whereby the attacker
requests that are above the window. The simplest method might be
the attacker to monitor the network traffic and then choose
sequence number that is far above the current sequence number.
the attacker can send bogus requests using the above window
number
7.2.2. Sequence Numbers Within or Below the
If the attacker sends requests that are within or below the window
then even if the header checksum is successfully verified, the
will silently discard the requests because the server assumes it
already processed the request. In this case, a server can optimize
Eisler, et. al. Standards Track [Page 18]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
skipping the header checksum verification if the sequence number
below the window, or if it is within the window, not attempt
checksum verification if the sequence number has already been seen
7.3. Message Stealing
This proposal does not address attacks where an attacker can block
steal messages without being detected by the server. To
such protection would be tantamount to assuming a state in the
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
The GSS-API definition [Linn] does not include numerical values
the various GSS-API major status codes. It is expected that this
be addressed in future RFC. Until then, this appendix defines
values for each GSS-API major status code listed in the GSS-
definition. If in the future, the GSS-API definition defines
for the codes that are different than what follows, then
of RPCSEC_GSS will be obliged to map them into the values
below. If in the future, the GSS-API definition defines
status codes not defined below, then the RPCSEC_GSS definition
subsume those additional values
Here are the definitions of each GSS_S_* major status that
implementor of RPCSEC_GSS can expect in the gss_major major field
rpc_gss_init_res. These definitions are not in RPC
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
follows
Most Significant Bit Least Significant
|------------------------------------------------------------|
| 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
with up to one status in the Routine Error field which in turn can
logically ORed with zero or more statuses in the Supplementary
field. If the resulting major status has a non-zero Calling
and/or a non-zero Routine Error, then the applicable GSS-
operation has failed. For purposes of RPCSEC_GSS, this means
the GSS_Accept_sec_context() call executed by the server has failed
If the major status is equal GSS_S_COMPLETE, then this indicates
absence of any Errors or Supplementary Info
The meanings of most of the GSS_S_* status are defined in the GSS-
definition, which the exceptions of
GSS_S_BAD_MIC This code has the same meaning as GSS_S_BAD_SIG
GSS_S_CALL_INACCESSIBLE_
A required input parameter could not be read
GSS_S_CALL_INACCESSIBLE_
A required input parameter could not be written
GSS_S_CALL_BAD_
A parameter was malformed
Eisler, et. al. Standards Track [Page 21]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Much of the protocol was based on the AUTH_GSSAPI security
developed by Open Vision Technologies [Jaspan]. In particular,
acknowledge Barry Jaspan, Marc Horowitz, John Linn, and
McDermott
Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from
Eisler. Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed
Sun Microsystems' implementation of RPCSEC_GSS
Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn,
Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed
specification and gave valuable feedback
Steve Nahm and Kathy Slattery reviewed various drafts of
specification
Much of content of Appendix A was excerpted from John Wray's Work
Progress on GSS-API Version 2 C-bindings
[Eisler] Eisler, M., Schemers, R., and Srinivasan, R
(1996). "Security Mechanism Independence in
RPC," Proceedings of the Sixth Annual
Security Symposium, pp. 51-65.
[Jaspan] Jaspan, B. (1995). "GSS-API Security for
RPC," `95 Proceedings of The Internet
Symposium on Network and Distributed
Security, pp. 144- 151.
[Linn] Linn, J., "Generic Security Service
Program Interface, Version 2", RFC 2078,
1997.
[Srinivasan-bind] Srinivasan, R., "Binding Protocols
ONC RPC Version 2", RFC 1833, August 1995.
[Srinivasan-rpc] Srinivasan, R., "RPC: Remote Procedure
Protocol Specification Version 2", RFC 1831,
August 1995.
[Srinivasan-xdr] Srinivasan, R., "XDR: External
Representation Standard", RFC 1832, August 1995.
Eisler, et. al. Standards Track [Page 22]
RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Authors'
Michael
Sun Microsystems, Inc
M/S UCOS03
2550 Garcia
Mountain View, CA 94043
Phone: +1 (719) 599-9026
EMail: mre@eng.sun.
Alex
Sun Microsystems, Inc
M/S UMPK17-203
2550 Garcia
Mountain View, CA 94043
Phone: +1 (415) 786-6465
EMail: hacker@eng.sun.
Lin
Sun Microsystems, Inc
M/S UMPK17-201
2550 Garcia
Mountain View, CA 94043
Phone: +1 (415) 786-5084
EMail: lling@eng.sun.
Eisler, et. al. Standards Track [Page 23]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
