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.
The Oracle Solaris implementation does not have customized GSS-API functions.
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.
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 (<>).
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.
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.
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.
The Oracle Solaris implementation detects and rejects attempted multiple imports of the same context.
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().
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().
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().
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.
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.