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.