GSS-API Reference
GSS-API Functions provides a table of GSS-API functions.
GSS-API Status Codes discusses status codes returned by GSS-API functions, and provides a list of those status codes.
GSS-API Data Types and Values discusses the various data types used by GSS-API.
Implementation-Specific Features in GSS-API covers features that are unique to the Oracle Solaris implementation of GSS-API.
Kerberos v5 Status Codes lists the status codes that can be returned by the Kerberos v5 mechanism.
This appendix includes the following sections:
Additional GSS-API definitions can be found in the file gssapi.h.
GSS-API Functions
The Oracle Solaris software implements the GSS-API functions. For more information on each function, see its man page. See also Functions From Previous Versions of GSS-API.
- gss_acquire_cred()
Assume a global identity by obtaining a GSS-API credential handle for preexisting credentials
- gss_add_cred()
- gss_inquire_cred()
- gss_inquire_cred_by_mech()
- gss_release_cred()
- gss_init_sec_context()
- gss_accept_sec_context()
- gss_delete_sec_context()
- gss_process_context_token()
Process a token on a security context from a peer application
- gss_context_time()
- gss_inquire_context()
- gss_wrap_size_limit()
- gss_export_sec_context()
- gss_import_sec_context()
- gss_get_mic()
Calculate a cryptographic message integrity code (MIC) for a message
- gss_verify_mic()
Check a MIC against a message to verify integrity of a received message
- gss_wrap()
Attach a MIC to a message, and optionally encrypt the message content
- gss_unwrap()
Verify a message with attached MIC. Decrypt message content if necessary
- gss_import_name()
- gss_display_name()
- gss_compare_name()
- gss_release_name()
- gss_inquire_names_for_mech()
- gss_inquire_mechs_for_name()
- gss_canonicalize_name()
- gss_export_name()
- gss_duplicate_name()
- gss_add_oid_set_member()
- gss_display_status()
- gss_indicate_mechs()
- gss_release_buffer()
- gss_release_oid_set()
- gss_create_empty_oid_set()
- gss_test_oid_set_member()
Functions From Previous Versions of GSS-API
This section explains functions that were included in previous versions of the GSS-API.
Functions for Manipulating OIDs
The Oracle Solaris implementation of GSS-API provides the following functions for convenience and for backward compatibility. However, these functions might not be supported by other implementations of GSS-API.
Although a mechanism's name can be converted from a string to an OID, programmers should use the default GSS-API mechanism if at all possible.
Renamed Functions
The following functions have been supplanted by newer functions. In each case, the new function is the functional equivalent of the older function. Although the old functions are supported, developers should replace these functions with the newer functions whenever possible.
GSS-API Status Codes
Major status codes are encoded in the OM_uint32 as shown in the following figure.
Figure C-1 Major-Status Encoding
If a GSS-API routine returns a GSS status code whose upper 16 bits contain a nonzero value, the call has failed. If the calling error field is nonzero, the application's call of the routine was erroneous. The calling errors are listed in Table C–1. If the routine error field is nonzero, the routine failed because of a routine-specific error, as listed in Table C–2. The bits in the supplementary information field of the status code can be set whether the upper 16 bits indicate a failure or a success. The meaning of individual bits is listed in Table C–3.
GSS-API Major Status Code Values
The following tables list the calling errors that are returned by GSS-API. These errors are specific to a particular language-binding, which is C in this case.
|
The following table lists the GSS-API routine errors, generic errors that are returned by GSS-API functions.
|
The name GSS_S_COMPLETE, which is a zero value, indicates an absence of any API errors or supplementary information bits.
The following table lists the supplementary information values returned by GSS-API functions.
|
For more on status codes, see GSS-API Status Codes.
Displaying Status Codes
The function gss_display_status() translates GSS-API status codes into text format. This format allows the codes to be displayed to a user or put in a text log. gss_display_status() only displays one status code at a time, and some functions can return multiple status conditions. Accordingly, gss_display_status() should be called as part of a loop. When gss_display_status() indicates a non-zero status code, another status code is available for the function to fetch.
Example C-1 Displaying Status Codes with gss_display_status()OM_uint32 message_context;
OM_uint32 status_code;
OM_uint32 maj_status;
OM_uint32 min_status;
gss_buffer_desc status_string;
...
message_context = 0;
do {
maj_status = gss_display_status(
&min_status,
status_code,
GSS_C_GSS_CODE,
GSS_C_NO_OID,
&message_context,
&status_string);
fprintf(stderr, "%.*s\n", \
(int)status_string.length, \
(char *)status_string.value);
gss_release_buffer(&min_status, &status_string,);
} while (message_context != 0);
Status Code Macros
The macros, GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR() and GSS_SUPPLEMENTARY_INFO(), take a GSS status code. These macros remove all information except for the relevant field. For example, the GSS_ROUTINE_ERROR() can be applied to a status code to remove the calling errors and supplementary information fields. This operation leaves the routine errors field only. The values delivered by these macros can be directly compared with a GSS_S_xxx symbol of the appropriate type. The macro GSS_ERROR() returns a non-zero value if a status code indicates a calling or routine error, and a zero value otherwise. All macros that are defined by GSS-API evaluate the arguments exactly once.
GSS-API Data Types and Values
Basic GSS-API Data Types – Shows the definitions of the OM_uint32, gss_buffer_desc, gss_OID_desc, gss_OID_set_desc_struct, and gss_channel_bindings_struct data types.
Name Types – Shows the various name formats recognized by the GSS-API for specifying names.
Address Types for Channel Bindings – Shows the various values that can be used as the initiator_addrtype and acceptor_addrtype fields of the gss_channel_bindings_t structure.
This section describes various types of GSS-API data types and values. Some data types, such as gss_cred_id_t or gss_name_t, are opaque to the user. These data types do not need to be discussed. This section explains the following topics:
Basic GSS-API Data Types
This section describes data types that are used by GSS-API.
OM_uint32
The OM_uint32 is a platform-independent 32–bit unsigned integer.
gss_buffer_desc
The definition of the gss_buffer_desc with the gss_buffer_t pointer takes the following form:
typedef struct gss_buffer_desc_struct {
size_t length;
void *value;
} gss_buffer_desc, *gss_buffer_t;
gss_OID_desc
The definition of the gss_OID_desc with the gss_OID pointer takes the following form:
typedef struct gss_OID_desc_struct {
OM_uint32 length;
void*elements;
} gss_OID_desc, *gss_OID;
gss_OID_set_desc
The definition of the gss_OID_set_desc with the gss_OID_set pointer takes the following form:
typedef struct gss_OID_set_desc_struct {
size_t count;
gss_OID elements;
} gss_OID_set_desc, *gss_OID_set;
gss_channel_bindings_struct
The definition of the gss_channel_bindings_struct structure and the gss_channel_bindings_t pointer has the following form:
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;
Name Types
A name type indicates the format of the associated name. See Names in GSS-API and GSS-API OIDs for more on names and name types. The GSS-API supports the gss_OID name types in the following table.
- GSS_C_NO_NAME
The symbolic name GSS_C_NO_NAME is recommended as a parameter value to indicate that no value is supplied in the transfer of names.
- GSS_C_NO_OID
This value corresponds to a null input value instead of an actual object identifier. Where specified, the value indicates interpretation of an associated name that is based on a mechanism-specific default printable syntax.
- GSS_C_NT_ANONYMOUS
A means to identify anonymous names. This value can be compared with to determine in a mechanism-independent fashion whether a name refers to an anonymous principal.
- GSS_C_NT_EXPORT_NAME
A name that has been exported with the gss_export_name() function.
- GSS_C_NT_HOSTBASED_SERVICE
Used to represent services that are associated with host computers. This name form is constructed using two elements, service and hostname, as follows: service@hostname.
- GSS_C_NT_MACHINE_UID_NAME
Used to indicate a numeric user identifier corresponding to a user on a local system. The interpretation of this value is OS-specific. The gss_import_name() function resolves this UID into a user name, which is then treated as the User Name Form.
- GSS_C_NT_STRING_STRING_UID_NAME
Used to indicate a string of digits that represents the numeric user identifier of a user on a local system. The interpretation of this value is OS-specific. This name type is similar to the Machine UID Form, except that the buffer contains a string that represents the user ID.
- GSS_C_NT_USER_NAME
A named user on a local system. The interpretation of this value is OS-specific. The value takes the form: username.
Address Types for Channel Bindings
The following table shows the possible values for the initiator_addrtype and acceptor_addrtype fields of the gss_channel_bindings_struct structure. These fields indicate the format that a name can take, for example, ARPAnet IMP address or AppleTalk address. Channel bindings are discussed in Using Channel Bindings in GSS-API.
|
Implementation-Specific Features in GSS-API
Some aspects of the GSS-API can differ between implementations of the API. In most cases, differences in implementations have only minimal effect on programs. In all cases, developers can maximize portability by not relying on any behavior that is specific to a given implementation, including the Oracle Solaris implementation.
Oracle Solaris-Specific Functions
The Oracle Solaris implementation does not have customized GSS-API functions.
Human-Readable Name Syntax
Implementations of GSS-API can differ in the printable syntax that corresponds to names. For portability, applications should not compare names that use human-readable, that is, printable, forms. Instead, such applications should use gss_compare_name() to determine whether an internal-format name matches any other name.
The Oracle Solaris implementation of gss_display_name() displays names as follows. If the input_nameargument denotes a user principal, the gss_display_name() returns user_principal@realm as the output_name_buffer and the gss_OID value as the output_name_type. If Kerberos v5 is the underlying mechanism, gss_OID is 1.2.840.11354.1.2.2.
If gss_display_name() receives a name that was created by gss_import_name() with the GSS_C_NO_OID name type, gss_display_name() returns GSS_C_NO_OID in the output_name_type parameter.
Format of Anonymous Names
The gss_display_name() function outputs the string '<anonymous>' to indicate an anonymous GSS-API principal. The name type OID associated with this name is GSS_C_NT_ANONYMOUS. No other valid printable names supported by the Oracle Solaris implementation should be surrounded by angle brackets (<>).
Implementations of Selected Data Types
The following data types have been implemented as pointers, although some implementations might specify these types as arithmetic types: gss_cred_t, gss_ctx_id_t, and gss_name_t.
Deletion of Contexts and Stored Data
When context establishment fails, the Oracle Solaris implementation does not automatically delete partially built contexts. Applications should therefore handle this event by deleting the contexts with gss_delete_sec_context().
The Oracle Solaris implementation automatically releases stored data, such as internal names, through memory management. However, applications should still call appropriate functions, such as gss_release_name(), when data elements are no longer needed.
Protection of Channel-Binding Information
Support for channel bindings varies by mechanism. Both the Diffie-Hellman mechanism and the Kerberos v5 mechanism support channel bindings.
Developers should assume that channel bindings data do not have confidentiality protection. Although the Kerberos v5 mechanism provides this protection, confidentiality for channel-bindings data is not available with the Diffie-Hellman mechanism.
Context Exportation and Interprocess Tokens
The Oracle Solaris implementation detects and rejects attempted multiple imports of the same context.
Types of Credentials Supported
The Oracle Solaris implementation of the GSS-API supports the acquisition of GSS_C_INITIATE, GSS_C_ACCEPT, and GSS_C_BOTH credentials through gss_acquire_cred().
Credential Expiration
The Oracle Solaris implementation of the GSS-API supports credential expiration. Therefore, programmers can use parameters that relate to credential lifetime in functions such as gss_acquire_cred() and gss_add_cred().
Context Expiration
The Oracle Solaris implementation of the GSS-API supports context expiration. Therefore, programmers can use parameters that relate to context lifetime in functions such as gss_init_sec_context() and gss_inquire_context().
Wrap Size Limits and QOP Values
The Oracle Solaris implementation of the GSS-API, as opposed to any underlying mechanism, does not impose a maximum size for messages to be processed by gss_wrap(). Applications can determine the maximum message size with gss_wrap_size_limit().
The Oracle Solaris implementation of the GSS-API detects invalid QOP values when gss_wrap_size_limit() is called.
Use of minor_status Parameter
In the Oracle Solaris implementation of the GSS-API, functions return only mechanism-specific information in the minor_status parameter. Other implementations might include implementation-specific return values as part of the returned minor-status code.
Kerberos v5 Status Codes
Each GSS-API function returns two status codes: a major status code and a minor status code. Major status codes relate to the behavior of GSS-API. For example, if an application attempts to transmit a message after a security context has expired, GSS-API returns a major status code of GSS_S_CONTEXT_EXPIRED. Major status codes are listed in GSS-API Status Codes.
Minor status codes are returned by the underlying security mechanisms supported by a given implementation of GSS-API. Every GSS-API function takes as the first argument a minor_status or minor_stat parameter. An application can examine this parameter when the function returns, successfully or not, to see the status that is returned by the underlying mechanism.
The following tables list the status messages that can be returned by Kerberos v5 in the minor_status argument. For more on GSS-API status codes, see GSS-API Status Codes.
Messages Returned in Kerberos v5 for Status Code 1
The following table lists the minor status messages that are returned in Kerberos v5 for status code 1.
|
Messages Returned in Kerberos v5 for Status Code 2
The following table lists the minor status messages that are returned in Kerberos v5 for status code 2.
|
Messages Returned in Kerberos v5 for Status Code 3
The following table lists the minor status messages that are returned in Kerberos v5 for status code 3.
|
Messages Returned in Kerberos v5 for Status Code 4
The following table lists the minor status messages that are returned in Kerberos v5 for status code 4.
|
Messages Returned in Kerberos v5 for Status Code 5
The following table lists the minor status messages that are returned in Kerberos v5 for status code 5
|
Messages Returned in Kerberos v5 for Status Code 6
The following table lists the minor status messages that are returned in Kerberos v5 for status code 6.
|
Messages Returned in Kerberos v5 for Status Code 7
The following table lists the minor status messages that are returned in Kerberos v5 for status code 7.
|