As per Relevance of the word overview, we have this rfc below:
Network Working Group J.
Request for Comments: 1509 Digital Equipment
September 1993
Generic Security Service API : C-
Status of this
This RFC 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" for the standardization state and
of this protocol. Distribution of this memo is unlimited
This document specifies C language bindings for the Generic
Service Application Program Interface (GSS-API), which is
at a language-independent conceptual level in other documents
The Generic Security Service Application Programming Interface (GSS
API) provides security services to its callers, and is intended
implementation atop alternative underlying cryptographic mechanisms
Typically, GSS-API callers will be application protocols into
security enhancements are integrated through invocation of
provided by the GSS-API. The GSS-API allows a caller application
authenticate a principal identity associated with a peer application
to delegate rights to a peer, and to apply security services such
confidentiality and integrity on a per-message basis
1.
The Generic Security Service Application Programming Interface [1]
provides security services to calling applications. It allows
communicating application to authenticate the user associated
another application, to delegate rights to another application,
to apply security services such as confidentiality and integrity on
per-message basis
There are four stages to using the GSSAPI
(a) The application acquires a set of credentials with which it
prove its identity to other processes. The application'
credentials vouch for its global identity, which may or may
be related to the local username under which it is running
Wray [Page 1]
RFC 1509 GSSAPI - Overview and C bindings September 1993
(b) A pair of communicating applications establish a joint
context using their credentials. The security context is
pair of GSSAPI data structures that contain shared
information, which is required in order that per-
security services may be provided. As part of
establishment of a security context, the context initiator
authenticated to the responder, and may require that
responder is authenticated in turn. The initiator
optionally give the responder the right to initiate
security contexts. This transfer of rights is
delegation, and is achieved by creating a set of credentials
similar to those used by the originating application, but
may be used by the responder. To establish and maintain
shared information that makes up the security context,
GSSAPI calls will return a token data structure, which is
cryptographically protected opaque data type. The caller
such a GSSAPI routine is responsible for transferring the
to the peer application, which should then pass it to
corresponding GSSAPI routine which will decode it and
the information
(c) Per-message services are invoked to apply either
(i) integrity and data origin authentication,
(ii) confidentiality, integrity and data origin
to application data, which are treated by GSSAPI
arbitrary octet-strings. The application transmitting
message that it wishes to protect will call the
GSSAPI routine (sign or seal) to apply protection,
the appropriate security context, and send the result to
receiving application. The receiver will pass the
data to the corresponding decoding routine (verify or unseal
to remove the protection and validate the data
(d) At the completion of a communications session (which may
across several connections), the peer applications call
routines to delete the security context. Multiple contexts
also be used (either successively or simultaneously) within
single communications association
2. GSSAPI
This section lists the functions performed by each of the
routines and discusses their major parameters, describing how
are to be passed to the routines. The routines are listed in
4-1.
Wray [Page 2]
RFC 1509 GSSAPI - Overview and C bindings September 1993
Figure 4-1 GSSAPI
Routine
gss_acquire_cred Assume a global
gss_release_cred Discard
gss_init_sec_context Initiate a security
with a peer
gss_accept_sec_context Accept a security
initiated by a
gss_process_context_token Process a token on a
context from a
gss_delete_sec_context Discard a security
gss_context_time Determine for how long
context will remain
gss_sign Sign a message;
gss_verify Check signature on a
gss_seal Sign (optionally encrypt)
message;
gss_unseal Verify (optionally decrypt
gss_display_status Convert an API status
to
gss_indicate_mechs Determine
authentication
gss_compare_name Compare two internal-
gss_display_name Convert opaque name to
Wray [Page 3]
RFC 1509 GSSAPI - Overview and C bindings September 1993
gss_import_name Convert a textual name
internal-
gss_release_name Discard an internal-
gss_release_buffer Discard a
gss_release_oid_set Discard a set of
gss_inquire_cred Determine information
a
Individual GSSAPI implementations may augment these routines
providing additional mechanism-specific routines if
functionality is not available from the generic forms.
are encouraged to use the generic routines wherever possible
portability grounds
2.1. Data Types and Calling
The following conventions are used by the GSSAPI
2.1.1. Structured data
Wherever these GSSAPI C-bindings describe structured data,
fields that must be provided by all GSSAPI implementation
documented. Individual implementations may provide
fields, either for internal use within GSSAPI routines, or for use
non-portable applications
2.1.2. Integer
GSSAPI defines the following integer data type
OM_uint32 32-bit unsigned
Where guaranteed minimum bit-count is important, this portable
type is used by the GSSAPI routine definitions. Individual
implementations will include appropriate typedef definitions to
this type onto a built-in data type
2.1.3. String and similar
Many of the GSSAPI routines take arguments and return values
describe contiguous multiple-byte data. All such data is
between the GSSAPI and the caller using the gss_buffer_t data type
Wray [Page 4]
RFC 1509 GSSAPI - Overview and C bindings September 1993
This data type is a pointer to a buffer descriptor, which consists
a length field that contains the total number of bytes in the datum
and a value field which contains a pointer to the actual datum
typedef struct gss_buffer_desc_struct {
size_t length
void *value
} gss_buffer_desc, *gss_buffer_t
Storage for data passed to the application by a GSSAPI routine
the gss_buffer_t conventions is allocated by the GSSAPI routine.
application may free this storage by invoking the gss_release_
routine. Allocation of the gss_buffer_desc object is always
responsibility of the application; Unused gss_buffer_desc
may be initialized to the value GSS_C_EMPTY_BUFFER
2.1.3.1. Opaque data
Certain multiple-word data items are considered opaque data types
the GSSAPI, because their internal structure has no
either to the GSSAPI or to the caller. Examples of such opaque
types are the input_token parameter to gss_init_sec_context (which
opaque to the caller), and the input_message parameter to gss_
(which is opaque to the GSSAPI). Opaque data is passed between
GSSAPI and the application using the gss_buffer_t datatype
2.1.3.2. Character
Certain multiple-word data items may be regarded as simple
Latin-1 character strings. An example of this is
input_name_buffer parameter to gss_import_name. Some GSSAPI
also return character strings. Character strings are passed
the application and the GSSAPI using the gss_buffer_t datatype
defined earlier
2.1.4. Object
Certain GSSAPI procedures take parameters of the type gss_OID,
Object identifier. This is a type containing ISO-defined tree
structured values, and is used by the GSSAPI caller to select
underlying security mechanism. A value of type gss_OID has
following structure
typedef struct gss_OID_desc_struct {
OM_uint32 length
void *elements
} gss_OID_desc, *gss_OID
Wray [Page 5]
RFC 1509 GSSAPI - Overview and C bindings September 1993
The elements field of this structure points to the first byte of
octet string containing the ASN.1 BER encoding of the value of
gss_OID. The length field contains the number of bytes in
value. For example, the gss_OID value corresponding to {iso(1)
identified- oganization(3) icd-ecma(12) member-company(2) dec(1011)
cryptoAlgorithms(7) SPX(5)} meaning SPX (Digital's X.509
authentication mechanism) has a length field of 7 and an
field pointing to seven octets containing the following octal values
53,14,2,207,163,7,5. GSSAPI implementations should provide
gss_OID values to allow callers to request any supported mechanism
although applications are encouraged on portability grounds to
the default mechanism. gss_OID values should also be provided
allow applications to specify particular name types (see
2.1.10). Applications should treat gss_OID_desc values returned
GSSAPI routines as read-only. In particular, the application
not attempt to deallocate them. The gss_OID_desc datatype
equivalent to the X/Open OM_object_identifier datatype [2].
2.1.5. Object Identifier
Certain GSSAPI procedures take parameters of the type gss_OID_set
This type represents one or more object identifiers (section 2.1.4).
A gss_OID_set object has the following structure
typedef struct gss_OID_set_desc_struct {
int count
gss_OID elements
} gss_OID_set_desc, *gss_OID_set
The count field contains the number of OIDs within the set.
elements field is a pointer to an array of gss_OID_desc objects,
of which describes a single OID. gss_OID_set values are used to
the available mechanisms supported by the GSSAPI, to request the
of specific mechanisms, and to indicate which mechanisms a
credential supports. Storage associated with gss_OID_set
returned to the application by the GSSAPI may be deallocated by
gss_release_oid_set routine
2.1.6.
A credential handle is a caller-opaque atomic datum that identifies
GSSAPI credential data structure. It is represented by the caller
opaque type gss_cred_id_t, which may be implemented as either
arithmetic or a pointer type. Credentials describe a principal,
they give their holder the ability to act as that principal.
GSSAPI does not make the actual credentials available
applications; instead the credential handle is used to identify
particular credential, held internally by GSSAPI or
Wray [Page 6]
RFC 1509 GSSAPI - Overview and C bindings September 1993
mechanism. Thus the credential handle contains no security-
information, and requires no special protection by the application
Depending on the implementation, a given credential handle may
to different credentials when presented to the GSSAPI by
callers. Individual GSSAPI implementations should define both
scope of a credential handle and the scope of a credential
(which must be at least as wide as that of a handle).
for credential handle scope include the process that acquired
handle, the acquiring process and its children, or all
sharing some local identification information (e.g., UID). If
handles exist by which a given credential may be reached, the
may delete the credential
Certain routines allow credential handle parameters to be omitted
indicate the use of a default credential. The mechanism by which
default credential is established and its scope should be defined
the individual GSSAPI implementation
2.1.7.
The gss_ctx_id_t data type contains a caller-opaque atomic value
identifies one end of a GSSAPI security context. It may
implemented as either an arithmetic or a pointer type. Depending
the implementation, a given gss_ctx_id_t value may refer to
GSSAPI security contexts when presented to the GSSAPI by
callers. The security context holds state information about each
of a peer communication, including cryptographic state information
Individual GSSAPI implementations should define the scope of
context. Since no way is provided by which a new gss_ctx_id_t
may be obtained for an existing context, the scope of a
should be the same as the scope of a gss_ctx_id_t
2.1.8. Authentication
A token is a caller-opaque type that GSSAPI uses to
synchronization between the context data structures at each end of
GSSAPI security context. The token is a cryptographically
bit-string, generated by the underlying mechanism at one end of
GSSAPI security context for use by the peer mechanism at the
end. Encapsulation (if required) and transfer of the token are
responsibility of the peer applications. A token is passed
the GSSAPI and the application using the gss_buffer_t conventions
2.1.9. Status
One or more status codes are returned by each GSSAPI routine.
distinct sorts of status codes are returned. These are termed
status codes and Mechanism status codes
Wray [Page 7]
RFC 1509 GSSAPI - Overview and C bindings September 1993
2.1.9.1. GSS status
GSSAPI routines return GSS status codes as their OM_uint32
value. These codes indicate errors that are independent of
underlying mechanism used to provide the security service.
errors that can be indicated via a GSS status code are either
API routine errors (errors that are defined in the
specification) or calling errors (errors that are specific to
bindings).
A GSS status code can indicate a single fatal generic API error
the routine and a single calling error. In addition,
status information may be indicated via the setting of bits in
supplementary info field of a GSS status code
These errors are encoded into the 32-bit GSS status code as follows
MSB
|------------------------------------------------------------|
| Calling Error | Routine Error | Supplementary Info |
|------------------------------------------------------------|
Bit 31 24 23 16 15 0
Hence if a GSSAPI routine returns a GSS status code whose upper 16
bits contain a non-zero value, the call failed. If the calling
field is non-zero, the invoking application's call of the routine
erroneous. Calling errors are defined in table 5-1. If the
error field is non-zero, the routine failed for one of the routine
specific reasons listed below in table 5-2. Whether or not the
16 bits indicate a failure or a success, the routine may
additional information by setting bits in the supplementary
field of the status code. The meaning of individual bits is
below in table 5-3.
Table 5-1 Calling
Name Value in
GSS_S_CALL_INACCESSIBLE_READ 1 A required
parameter
not be read
GSS_S_CALL_INACCESSIBLE_WRITE 2 A required
parameter
not be written
GSS_S_CALL_BAD_STRUCTURE 3 A parameter
Wray [Page 8]
RFC 1509 GSSAPI - Overview and C bindings September 1993
Table 5-2 Routine
Name Value in
GSS_S_BAD_MECH 1 An unsupported mechanism
GSS_S_BAD_NAME 2 An invalid name was
GSS_S_BAD_NAMETYPE 3 A supplied name was of
unsupported
GSS_S_BAD_BINDINGS 4 Incorrect channel
were
GSS_S_BAD_STATUS 5 An invalid status code
GSS_S_BAD_SIG 6 A token had an
GSS_S_NO_CRED 7 No credentials were
GSS_S_NO_CONTEXT 8 No context has
GSS_S_DEFECTIVE_TOKEN 9 A token was
GSS_S_DEFECTIVE_CREDENTIAL 10 A credential was
GSS_S_CREDENTIALS_EXPIRED 11 The referenced
have
GSS_S_CONTEXT_EXPIRED 12 The context has
GSS_S_FAILURE 13 Miscellaneous
(see text
Table 5-3 Supplementary Status
Name Bit Number
GSS_S_CONTINUE_NEEDED 0 (LSB) The routine must be
again to complete
function
See routine documentation
detailed description
GSS_S_DUPLICATE_TOKEN 1 The token was a duplicate
an earlier
GSS_S_OLD_TOKEN 2 The token's validity
has
GSS_S_UNSEQ_TOKEN 3 A later token has already
The routine documentation also uses the name GSS_S_COMPLETE, which
a zero value, to indicate an absence of any API errors
supplementary information bits
Wray [Page 9]
RFC 1509 GSSAPI - Overview and C bindings September 1993
All GSS_S_xxx symbols equate to complete OM_uint32 status codes
rather than to bitfield values. For example, the actual value of
symbol GSS_S_BAD_NAMETYPE (value 3 in the routine error field) is 3
<< 16.
The macros GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR()
GSS_SUPPLEMENTARY_INFO() are provided, each of which takes a
status code and removes all but the relevant field. For example,
value obtained by applying GSS_ROUTINE_ERROR to a status code
the calling errors and supplementary info fields, leaving only
routine errors field. The values delivered by these macros may
directly compared with a GSS_S_xxx symbol of the appropriate type
The macro GSS_ERROR() is also provided, which when applied to a
status code returns a non-zero value if the status code indicated
calling or routine error, and a zero value otherwise
A GSSAPI implementation may choose to signal calling errors in
platform-specific manner instead of, or in addition to the
value; routine errors and supplementary info should be returned
routine status values only
2.1.9.2. Mechanism-specific status
GSSAPI routines return a minor_status parameter, which is used
indicate specialized errors from the underlying security mechanism
This parameter may contain a single mechanism-specific error
indicated by a OM_uint32 value
The minor_status parameter will always be set by a GSSAPI routine
even if it returns a calling error or one of the generic API
indicated above as fatal, although other output parameters may
unset in such cases. However, output parameters that are expected
return pointers to storage allocated by a routine must always set
by the routine, even in the event of an error, although in such
the GSSAPI routine may elect to set the returned parameter value
NULL to indicate that no storage was actually allocated. Any
field associated with such pointers (as in a gss_buffer_
structure) should also be set to zero in such cases
The GSS status code GSS_S_FAILURE is used to indicate that
underlying mechanism detected an error for which no specific
status code is defined. The mechanism status code will provide
details about the error
2.1.10.
A name is used to identify a person or entity. GSSAPI
the relationship between a name and the entity claiming the name
Wray [Page 10]
RFC 1509 GSSAPI - Overview and C bindings September 1993
Two distinct representations are defined for names
(a) A printable form, for presentation to a
(b) An internal form, for presentation at the
The syntax of a printable name is defined by the
implementation, and may be dependent on local system configuration
or on individual user preference. The internal form provides
canonical representation of the name that is independent
configuration
A given GSSAPI implementation may support names drawn from
namespaces. In such an implementation, the internal form of the
must include fields that identify the namespace from which the
is drawn. The namespace from which a printable name is drawn
specified by an accompanying object identifier
Routines (gss_import_name and gss_display_name) are provided
convert names between their printable representations and
gss_name_t type. gss_import_name may support multiple syntaxes
each supported namespace, allowing users the freedom to choose
preferred name representation. gss_display_name should use
implementation-chosen preferred syntax for each supported name-type
Comparison of internal-form names is accomplished via
gss_compare_names routine. This removes the need for the
program to understand the syntaxes of the various printable
that a given GSSAPI implementation may support
Storage is allocated by routines that return gss_name_t values.
procedure, gss_release_name, is provided to free storage
with a name
2.1.11. Channel
GSSAPI supports the use of user-specified tags to identify a
context to the peer application. These tags are used to identify
particular communications channel that carries the context.
bindings are communicated to the GSSAPI using the
structure
Wray [Page 11]
RFC 1509 GSSAPI - Overview and C bindings September 1993
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype
gss_buffer_desc initiator_address
OM_uint32 acceptor_addrtype
gss_buffer_desc acceptor_address
gss_buffer_desc application_data
} *gss_channel_bindings_t
The initiator_addrtype and acceptor_addrtype fields denote the
of addresses contained in the initiator_address and acceptor_
buffers. The address type should be one of the following
GSS_C_AF_UNSPEC Unspecified address
GSS_C_AF_LOCAL Host-local address
GSS_C_AF_INET DARPA Internet address
GSS_C_AF_IMPLINK ARPAnet IMP address type (eg IP
GSS_C_AF_PUP pup protocols (eg BSP) address
GSS_C_AF_CHAOS MIT CHAOS protocol address
GSS_C_AF_NS XEROX NS address
GSS_C_AF_NBS nbs address
GSS_C_AF_ECMA ECMA address
GSS_C_AF_DATAKIT datakit protocols address
GSS_C_AF_CCITT CCITT protocols (eg X.25)
GSS_C_AF_SNA IBM SNA address
GSS_C_AF_DECnet DECnet address
GSS_C_AF_DLI Direct data link interface address
GSS_C_AF_LAT LAT address
GSS_C_AF_HYLINK NSC Hyperchannel address
GSS_C_AF_APPLETALK AppleTalk address
GSS_C_AF_BSC BISYNC 2780/3780 address
GSS_C_AF_DSS Distributed system services address
GSS_C_AF_OSI OSI TP4 address
GSS_C_AF_X25 X25
GSS_C_AF_NULLADDR No address
Note that these name address families rather than specific
formats. For address families that contain several
address forms, the initiator_address and acceptor_address fields
contain sufficient information to determine which address form
used. When not otherwise specified, addresses should be specified
network byte-order
Conceptually, the GSSAPI concatenates the initiator_addrtype
initiator_address, acceptor_addrtype, acceptor_address
application_data to form an octet string. The mechanism signs
octet string, and binds the signature to the context
token emitted by gss_init_sec_context. The same bindings
presented by the context acceptor to gss_accept_sec_context, and
Wray [Page 12]
RFC 1509 GSSAPI - Overview and C bindings September 1993
signature is calculated in the same way. The calculated signature
compared with that found in the token, and if the signatures differ
gss_accept_sec_context will return a GSS_S_BAD_BINDINGS error,
the context will not be established. Some mechanisms may include
actual channel binding data in the token (rather than just
signature); applications should therefore not use confidential
as channel-binding components. Individual mechanisms may
additional constraints on addresses and address types that may
in channel bindings. For example, a mechanism may verify that
initiator_address field of the channel bindings presented
gss_init_sec_context contains the correct network address of the
system
2.1.12. Optional
Various parameters are described as optional. This means that
follow a convention whereby a default value may be requested.
following conventions are used for omitted parameters.
conventions apply only to those parameters that are
documented as optional
2.1.12.1. gss_buffer_t
Specify GSS_C_NO_BUFFER as a value. For an input parameter
signifies that default behavior is requested, while for an
parameter it indicates that the information that would be
via the parameter is not required by the application
2.1.12.2. Integer types (input
Individual parameter documentation lists values to be used
indicate default actions
2.1.12.3. Integer types (output
Specify NULL as the value for the pointer
2.1.12.4. Pointer
Specify NULL as the value
2.1.12.5. Object
Specify GSS_C_NULL_OID as the value
2.1.12.6. Object ID
Specify GSS_C_NULL_OID_SET as the value
Wray [Page 13]
RFC 1509 GSSAPI - Overview and C bindings September 1993
2.1.12.7.
Specify GSS_C_NO_CREDENTIAL to use the default credential handle
2.1.12.8. Channel
Specify GSS_C_NO_CHANNEL_BINDINGS to indicate that channel
are not to be used
3. GSSAPI routine
2.1. gss_acquire_
OM_uint32 gss_acquire_cred (
OM_uint32 * minor_status
gss_name_t desired_name
OM_uint32 time_req
gss_OID_set desired_mechs
int cred_usage
gss_cred_id_t * output_cred_handle
gss_OID_set * actual_mechs
OM_int32 * time_rec
Purpose
Allows an application to acquire a handle for a pre-
credential by name. GSSAPI implementations must impose a
access-control policy on callers of this routine to
unauthorized callers from acquiring credentials to which they are
entitled. This routine is not intended to provide a "login to
network" function, as such a function would result in the creation
new credentials rather than merely acquiring a handle to
credentials. Such functions, if required, should be defined
implementation-specific extensions to the API
If credential acquisition is time-consuming for a mechanism,
mechanism may chooses to delay the actual acquisition until
credential is required (e.g., by gss_init_sec_context
gss_accept_sec_context). Such mechanism-specific
decisions should be invisible to the calling application; thus a
of gss_inquire_cred immediately following the call
gss_acquire_cred must return valid credential data, and may
incur the overhead of a deferred credential acquisition
Parameters
desired_name gss_name_t,
Name of principal whose
should be
Wray [Page 14]
RFC 1509 GSSAPI - Overview and C bindings September 1993
time_req integer,
number of seconds that
should remain
desired_mechs Set of Object IDs,
set of underlying security mechanisms
may be used. GSS_C_NULL_OID_SET may be
to obtain an implementation-specific default
cred_usage integer,
GSS_C_BOTH - Credentials may be
either to initiate or
security contexts
GSS_C_INITIATE - Credentials will only
used to initiate
contexts
GSS_C_ACCEPT - Credentials will only be used
accept security contexts
output_cred_handle gss_cred_id_t,
The returned credential handle
actual_mechs Set of Object IDs, modify,
The set of mechanisms for which
credential is valid. Specify
if not required
time_rec Integer, modify,
Actual number of seconds for which
returned credentials will remain valid. If
implementation does not support expiration
credentials, the value GSS_C_INDEFINITE
be returned. Specify NULL if not
minor_status Integer,
Mechanism specific status code
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_BAD_MECH Unavailable mechanism
GSS_S_BAD_NAMETYPE Type contained within desired_name parameter
not
GSS_S_BAD_NAME Value supplied for desired_name parameter
Wray [Page 15]
RFC 1509 GSSAPI - Overview and C bindings September 1993
ill-formed
GSS_S_FAILURE Unspecified failure. The minor_status
contains more detailed
3.2. gss_release_
OM_uint32 gss_release_cred (
OM_uint32 * minor_status
gss_cred_id_t * cred_handle
Purpose
Informs GSSAPI that the specified credential handle is no
required by the process. When all processes have released
credential, it will be deleted
Parameters
cred_handle gss_cred_id_t, modify,
buffer containing opaque
handle. If GSS_C_NO_CREDENTIAL is supplied
the default credential will be
minor_status integer,
Mechanism specific status code
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_NO_CRED Credentials could not be accessed
Wray [Page 16]
RFC 1509 GSSAPI - Overview and C bindings September 1993
3.3. gss_init_sec_
OM_uint32 gss_init_sec_context (
OM_uint32 * minor_status
gss_cred_id_t claimant_cred_handle
gss_ctx_id_t * context_handle
gss_name_t target_name
gss_OID mech_type
int req_flags
int time_req
gss_channel_bindings_
input_chan_bindings
gss_buffer_t input_
gss_OID * actual_mech_type
gss_buffer_t output_token
int * ret_flags
OM_uint32 * time_rec )
Purpose
Initiates the establishment of a security context between
application and a remote peer. Initially, the input_token
should be specified as GSS_C_NO_BUFFER. The routine may return
output_token which should be transferred to the peer application
where the peer application will present it to gss_accept_sec_context
If no token need be sent, gss_init_sec_context will indicate this
setting the length field of the output_token argument to zero.
complete the context establishment, one or more reply tokens may
required from the peer application; if so, gss_init_sec_context
return a status indicating GSS_S_CONTINUE_NEEDED in which case
should be called again when the reply token is received from the
application, passing the token to gss_init_sec_context via
input_token parameters
The values returned via the ret_flags and time_rec parameters are
defined unless the routine returns GSS_S_COMPLETE
Parameters
claimant_cred_handle gss_cred_id_t, read,
handle for credentials claimed.
GSS_C_NO_CREDENTIAL to use
credentials
context_handle gss_ctx_id_t, read/
context handle for new context.
GSS_C_NO_CONTEXT for first call; use
returned by first call in continuation calls
Wray [Page 17]
RFC 1509 GSSAPI - Overview and C bindings September 1993
target_name gss_name_t,
Name of
mech_type OID, read,
Object ID of desired mechanism.
GSS_C_NULL_OID to obtain an
specific
req_flags bit-mask,
Contains four independent flags, each
which requests that the context support
specific service option.
names are provided for each flag, and
symbolic names corresponding to the
flags should be logically-
together to form the bit-mask value.
flags are
GSS_C_DELEG_
True - Delegate credentials to remote
False - Don't
GSS_C_MUTUAL_
True - Request that remote
authenticate
False - Authenticate self to remote
GSS_C_REPLAY_
True - Enable replay detection for
or sealed
False - Don't attempt to
replayed
GSS_C_SEQUENCE_
True - Enable detection of out-of-
signed or sealed
False - Don't attempt to
out-of-sequence
time_req integer,
Desired number of seconds for which
should remain valid. Supply 0 to request
default validity period
input_chan_bindings channel bindings,
Application-specified bindings.
application to securely bind
identification information to the
context
Wray [Page 18]
RFC 1509 GSSAPI - Overview and C bindings September 1993
input_token buffer, opaque, read, optional (see text
Token received from peer application
Supply GSS_C_NO_BUFFER on initial call
actual_mech_type OID,
actual mechanism used
output_token buffer, opaque,
token to be sent to peer application.
the length field of the returned buffer
zero, no token need be sent to the
application
ret_flags bit-mask,
Contains six independent flags, each of
indicates that the context supports a
service option. Symbolic names are
for each flag, and the symbolic
corresponding to the required flags should
logically-ANDed with the ret_flags value to
whether a given option is supported by
context. The flags are
GSS_C_DELEG_
True - Credentials were delegated
the remote
False - No credentials were
GSS_C_MUTUAL_
True - Remote peer has been asked
authenticated
False - Remote peer has not been asked
authenticate
GSS_C_REPLAY_
True - replay of signed or sealed
will be
False - replayed messages will not
GSS_C_SEQUENCE_
True - out-of-sequence signed or
messages will be
False - out-of-sequence messages will
be
GSS_C_CONF_
True - Confidentiality service may
invoked by calling seal
False - No confidentiality service (
seal) available. seal will
message encapsulation, data-
Wray [Page 19]
RFC 1509 GSSAPI - Overview and C bindings September 1993
authentication and
services only
GSS_C_INTEG_
True - Integrity service may be invoked
calling either gss_sign or gss_
routines
False - Per-message integrity
unavailable
time_rec integer, modify,
number of seconds for which the
will remain valid. If the implementation
not support credential expiration, the
GSS_C_INDEFINITE will be returned.
NULL if not required
minor_status integer,
Mechanism specific status code
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_CONTINUE_NEEDED Indicates that a token from the
application is required to complete thecontext,
that gss_init_sec_context must be called again
that token
GSS_S_DEFECTIVE_TOKEN Indicates that consistency checks performed
the input_token
GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency
performed on the credential failed
GSS_S_NO_CRED The supplied credentials were not valid for
initiation, or the credential handle did
reference any credentials
GSS_S_CREDENTIALS_EXPIRED The referenced credentials have
GSS_S_BAD_BINDINGS The input_token contains different
bindings to those specified via
input_chan_bindings
GSS_S_BAD_SIG The input_token contains an invalid signature, or
signature that could not be
Wray [Page 20]
RFC 1509 GSSAPI - Overview and C bindings September 1993
GSS_S_OLD_TOKEN The input_token was too old. This is a fatal
during context
GSS_S_DUPLICATE_TOKEN The input_token is valid, but is a duplicate
a token already processed. This is a fatal
during context establishment
GSS_S_NO_CONTEXT Indicates that the supplied context handle did
refer to a valid
GSS_S_BAD_NAMETYPE The provided target_name parameter contained
invalid or unsupported type of
GSS_S_BAD_NAME The provided target_name parameter was ill-formed
GSS_S_FAILURE Failure. See minor_status for more
3.4. gss_accept_sec_
OM_uint32 gss_accept_sec_context (
OM_uint32 * minor_status
gss_ctx_id_t * context_handle
gss_cred_id_t verifier_cred_handle
gss_buffer_t input_token_
gss_channel_bindings_
input_chan_bindings
gss_name_t * src_name
gss_OID * mech_type
gss_buffer_t output_token
int * ret_flags
OM_uint32 * time_rec
gss_cred_id_t * delegated_cred_handle
Purpose
Allows a remotely initiated security context between the
and a remote peer to be established. The routine may return
output_token which should be transferred to the peer application
where the peer application will present it to gss_init_sec_context
If no token need be sent, gss_accept_sec_context will indicate
by setting the length field of the output_token argument to zero.
complete the context establishment, one or more reply tokens may
required from the peer application; if so, gss_accept_sec_
will return a status flag of GSS_S_CONTINUE_NEEDED, in which case
should be called again when the reply token is received from the
application, passing the token to gss_accept_sec_context via
input_token parameters
Wray [Page 21]
RFC 1509 GSSAPI - Overview and C bindings September 1993
The values returned via the src_name, ret_flags, time_rec,
delegated_cred_handle parameters are not defined unless the
returns GSS_S_COMPLETE
Parameters
context_handle gss_ctx_id_t, read/
context handle for new context.
GSS_C_NO_CONTEXT for first call; use
returned in subsequent calls
verifier_cred_handle gss_cred_id_t, read,
Credential handle claimed by
acceptor
Specify GSS_C_NO_CREDENTIAL to use
credentials. If GSS_C_NO_CREDENTIAL
specified, but the caller has no
credentials established,
implementation-defined default
may be used
input_token_buffer buffer, opaque,
token obtained from remote
input_chan_bindings channel bindings,
Application-specified bindings.
application to securely bind
identification information to the
context
src_name gss_name_t, modify,
Authenticated name of context initiator
After use, this name should be deallocated
passing it to gss_release_name. If not required
specify NULL
mech_type Object ID,
Security mechanism used. The
OID value will be a pointer into
storage, and should be treated as read-
by the caller
output_token buffer, opaque,
Token to be passed to peer application. If
length field of the returned token buffer is 0,
then no token need be passed to the
application
Wray [Page 22]
RFC 1509 GSSAPI - Overview and C bindings September 1993
ret_flags bit-mask,
Contains six independent flags, each
which indicates that the context supports
specific service option. Symbolic names
provided for each flag, and the symbolic
corresponding to the required
should be logically-ANDed with the ret_
value to test whether a given option
supported by the context. The flags are
GSS_C_DELEG_
True - Delegated credentials are
via the delegated_cred_
False - No credentials were
GSS_C_MUTUAL_
True - Remote peer asked for
False - Remote peer did not ask for
GSS_C_REPLAY_
True - replay of signed or sealed
will be
False - replayed messages will not
GSS_C_SEQUENCE_
True - out-of-sequence signed or
messages will be
False - out-of-sequence messages will
be
GSS_C_CONF_
True - Confidentiality service may
invoked by calling seal
False - No confidentiality service (
seal) available. seal
provide message encapsulation
data-origin authentication
integrity services only
GSS_C_INTEG_
True - Integrity service may be
by calling either gss_sign
gss_seal routines
False - Per-message integrity
unavailable
time_rec integer, modify,
number of seconds for which the
will remain valid. Specify NULL if not required
Wray [Page 23]
RFC 1509 GSSAPI - Overview and C bindings September 1993
delegated_cred_
gss_cred_id_t,
credential handle for credentials received
context initiator. Only valid if deleg_flag
ret_flags is true
minor_status integer,
Mechanism specific status code
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_CONTINUE_NEEDED Indicates that a token from the
application is required to complete the context
and that gss_accept_sec_context must be
again with that token
GSS_S_DEFECTIVE_TOKEN Indicates that consistency
performed on the input_token failed
GSS_S_DEFECTIVE_CREDENTIAL Indicates that consistency
performed on the credential failed
GSS_S_NO_CRED The supplied credentials were not valid
context acceptance, or the credential
did not reference any credentials
GSS_S_CREDENTIALS_EXPIRED The referenced credentials
expired
GSS_S_BAD_BINDINGS The input_token contains different
bindings to those specified via
input_chan_bindings parameter
GSS_S_NO_CONTEXT Indicates that the supplied context handle
not refer to a valid context
GSS_S_BAD_SIG The input_token contains an invalid signature
GSS_S_OLD_TOKEN The input_token was too old. This is a
error during context establishment
GSS_S_DUPLICATE_TOKEN The input_token is valid, but is
duplicate of a token already processed.
is a fatal error during context establishment
Wray [Page 24]
RFC 1509 GSSAPI - Overview and C bindings September 1993
GSS_S_FAILURE Failure. See minor_status for more information
3.5. gss_process_context_
OM_uint32 gss_process_context_token (
OM_uint32 * minor_status
gss_ctx_id_t context_handle
gss_buffer_t token_buffer
Purpose
Provides a way to pass a token to the security service. Usually
tokens are associated either with context establishment (when
would be passed to gss_init_sec_context or gss_accept_sec_context)
with per-message security service (when they would be passed
gss_verify or gss_unseal). Occasionally, tokens may be received
other times, and gss_process_context_token allows such tokens to
passed to the underlying security service for processing.
present, such additional tokens may only be generated
gss_delete_sec_context. GSSAPI implementation may use this
to implement deletion of the security context
Parameters
context_handle gss_ctx_id_t,
context handle of context on which token is
be
token_buffer buffer, opaque,
pointer to first byte of token to
minor_status integer,
Implementation specific status code
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_DEFECTIVE_TOKEN Indicates that consistency
performed on the token
GSS_S_FAILURE Failure. See minor_status for more
GSS_S_NO_CONTEXT The context_handle did not refer to a
Wray [Page 25]
RFC 1509 GSSAPI - Overview and C bindings September 1993
3.6. gss_delete_sec_
OM_uint32 gss_delete_sec_context (
OM_uint32 * minor_status
gss_ctx_id_t * context_handle
gss_buffer_t output_token
Purpose
Delete a security context. gss_delete_sec_context will delete
local data structures associated with the specified security context
and generate an output_token, which when passed to the
gss_process_context_token will instruct it to do likewise.
further security services may be obtained using the context
by context_handle
Parameters
minor_status integer,
Mechanism specific status code
context_handle gss_ctx_id_t,
context handle identifying context to delete
output_token buffer, opaque,
token to be sent to remote application
instruct it to also delete the
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_FAILURE Failure, see minor_status for more
GSS_S_NO_CONTEXT No valid context was
3.7. gss_context_
OM_uint32 gss_context_time (
OM_uint32 * minor_status
gss_ctx_id_t context_handle
OM_uint32 * time_rec
Purpose
Determines the number of seconds for which the specified context
remain valid
Wray [Page 26]
RFC 1509 GSSAPI - Overview and C bindings September 1993
Parameters
minor_status integer,
Implementation specific status code
context_handle gss_ctx_id_t,
Identifies the context to be interrogated
time_rec integer,
Number of seconds that the context will
valid. If the context has already expired
zero will be returned
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_CONTEXT_EXPIRED The context has already
GSS_S_CREDENTIALS_EXPIRED The context is recognized,
associated credentials have
GSS_S_NO_CONTEXT The context_handle parameter did not identify
valid
3.8. gss_
OM_uint32 gss_sign (
OM_uint32 * minor_status
gss_ctx_id_t context_handle
int qop_req
gss_buffer_t message_buffer
gss_buffer_t msg_token
Purpose
Generates a cryptographic signature for the supplied message,
places the signature in a token for transfer to the peer application
The qop_req parameter allows a choice between several
algorithms, if supported by the chosen mechanism
Parameters
minor_status integer,
Implementation specific status code
context_handle gss_ctx_id_t,
identifies the context on which the
Wray [Page 27]
RFC 1509 GSSAPI - Overview and C bindings September 1993
will be
qop_req integer, read,
Specifies requested quality of protection
Callers are encouraged, on portability grounds
to accept the default quality of
offered by the chosen mechanism, which may
requested by specifying GSS_C_QOP_DEFAULT
this parameter. If an unsupported
strength is requested, gss_sign will return
major_status of GSS_S_FAILURE
message_buffer buffer, opaque,
message to be
msg_token buffer, opaque,
buffer to receive
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_CONTEXT_EXPIRED The context has already
GSS_S_CREDENTIALS_EXPIRED The context is recognized,
associated credentials have
GSS_S_NO_CONTEXT The context_handle parameter did not identify
valid
GSS_S_FAILURE Failure. See minor_status for more information
3.9. gss_
OM_uint32 gss_verify (
OM_uint32 * minor_status
gss_ctx_id_t context_handle
gss_buffer_t message_buffer
gss_buffer_t token_buffer
int * qop_state
Purpose
Verifies that a cryptographic signature, contained in the
parameter, fits the supplied message. The qop_state parameter
a message recipient to determine the strength of protection that
applied to the message
Wray [Page 28]
RFC 1509 GSSAPI - Overview and C bindings September 1993
Parameters
minor_status integer,
Mechanism specific status code
context_handle gss_ctx_id_t,
identifies the context on which the
message_buffer buffer, opaque,
message to be
token_buffer buffer, opaque,
token associated with
qop_state integer,
quality of protection gained from
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_DEFECTIVE_TOKEN The token failed consistency
GSS_S_BAD_SIG The signature was
GSS_S_DUPLICATE_TOKEN The token was valid, and contained a
signature for the message, but it had
been
GSS_S_OLD_TOKEN The token was valid, and contained a
signature for the message, but it is too
GSS_S_UNSEQ_TOKEN The token was valid, and contained a
signature for the message, but has
verified out of sequence; an earlier token
been signed or sealed by the
application, but not yet been
locally
GSS_S_CONTEXT_EXPIRED The context has already
GSS_S_CREDENTIALS_EXPIRED The context is recognized,
associated credentials have
Wray [Page 29]
RFC 1509 GSSAPI - Overview and C bindings September 1993
GSS_S_NO_CONTEXT The context_handle parameter did not identify
valid
GSS_S_FAILURE Failure. See minor_status for more information
3.10. gss_
OM_uint32 gss_seal (
OM_uint32 * minor_status
gss_ctx_id_t context_handle
int conf_req_flag
int qop_
gss_buffer_t input_message_buffer
int * conf_state
gss_buffer_t output_message_buffer
Purpose
Cryptographically signs and optionally encrypts the
input_message. The output_message contains both the signature
the message. The qop_req parameter allows a choice between
cryptographic algorithms, if supported by the chosen mechanism
Parameters
minor_status integer,
Mechanism specific status code
context_handle gss_ctx_id_t,
identifies the context on which the
will be
conf_req_flag boolean,
True - Both confidentiality and
services are
False - Only integrity service is
qop_req integer, read,
Specifies required quality of protection.
mechanism-specific default may be requested
setting qop_req to GSS_C_QOP_DEFAULT. If
unsupported protection strength is requested
gss_seal will return a major_status
GSS_S_FAILURE
input_message_buffer buffer, opaque,
message to be
Wray [Page 30]
RFC 1509 GSSAPI - Overview and C bindings September 1993
conf_state boolean,
True - Confidentiality, data
authentication and integrity
have been
False - Integrity and data origin services
has been applied
output_message_buffer buffer, opaque,
buffer to receive sealed
Function value
GSS status code
GSS_S_COMPLETE Successful
GSS_S_CONTEXT_EXPIRED The context has already
GSS_S_CREDENTIALS_EXPIRED The context is recognized,
associated credentials have
GSS_S_NO_CONTEXT The context_handle parameter did not identify
valid
GSS_S_FAILURE Failure. See minor_status for more information
3.11. gss_
OM_uint32 gss_unseal (
OM_uint32 * minor_status
gss_ctx_id_t context_handle
gss_buffer_t input_message_buffer
gss_buffer_t output_message_buffer
int * conf_state
int * qop_state
Purpose
Converts a previously sealed message back to a usable form,
the embedded signature. The conf_state parameter indicates
the message was encrypted; the qop_state parameter indicates
strength of protection that was used to provide the
and integrity services
Parameters
minor_status integer,
Mechanism specific status code
Wray [Page 31]
RFC 1509 GSSAPI - Overview and C bindings September 1993
context_handle gss_ctx_id_t,
identifies the context on which the
input_message_buffer buffer, opaque,
sealed
output_message_buffer buffer, opaque,
buffer to receive unsealed
conf_state boolean,
True - Confidentiality and integrity
were
False - Inteegrity service only was
qop_state integer,
quality of protection gained from
Function value
GSS status code
GSS_S_COMPLETE 