Some aspects of the GSS-API can differ between implementations of theAPI. In most cases, differences in implementations have only minimal effecton programs. In all cases, developers can maximize portability by not relyingon 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 correspondsto names. For portability, applications should not compare names that usehuman-readable, that is, printable, forms. Instead, such applications should usegss_compare_name() to determine whether an internal-formatname matches any other name.
The Oracle Solaris implementationofgss_display_name() displays names as follows. If theinput_nameargument denotes a user principal, thegss_display_name() returns user_principal@realm as theoutput_name_buffer and the gss_OID valueas theoutput_name_type. If Kerberos v5 is theunderlying mechanism, gss_OID is1.2.840.11354.1.2.2.
Ifgss_display_name() receives a name that was createdbygss_import_name() with the GSS_C_NO_OID nametype,gss_display_name() returns GSS_C_NO_OID intheoutput_name_type parameter.
Thegss_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 implementationshould be surrounded by angle brackets (<>).
The following data types have been implemented as pointers, althoughsome 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 notautomatically delete partially built contexts. Applications should thereforehandle this event by deleting the contexts withgss_delete_sec_context().
The Oracle Solaris implementation automatically releases stored data, such as internal names,through memory management. However, applications should still call appropriatefunctions, such asgss_release_name(), when data elementsare no longer needed.
Support for channel bindings varies by mechanism. Both the Diffie-Hellmanmechanism and the Kerberos v5 mechanism support channel bindings.
Developers should assume that channel bindings data do not have confidentialityprotection. Although the Kerberos v5 mechanism provides this protection, confidentialityfor channel-bindings data is not available with the Diffie-Hellman mechanism.
The Oracle Solaris implementation detects and rejects attempted multiple imports of the samecontext.
The Oracle Solaris implementation of the GSS-API supports the acquisition of GSS_C_INITIATE, GSS_C_ACCEPT, and GSS_C_BOTH credentials throughgss_acquire_cred().
The Oracle Solaris implementation of the GSS-API supports credential expiration. Therefore, programmerscan use parameters that relate to credential lifetime in functions such asgss_acquire_cred() andgss_add_cred().
The Oracle Solaris implementation of the GSS-API supports context expiration. Therefore, programmerscan use parameters that relate to context lifetime in functions such asgss_init_sec_context() andgss_inquire_context().
The Oracle Solaris implementation of the GSS-API, as opposed to any underlying mechanism, does not impose amaximum size for messages to be processed bygss_wrap().Applications can determine the maximum message size withgss_wrap_size_limit().
The Oracle Solaris implementation of the GSS-API detects invalid QOP values whengss_wrap_size_limit() is called.
In the Oracle Solaris implementation of the GSS-API, functions return only mechanism-specificinformation in theminor_status parameter. Otherimplementations might include implementation-specific return values as partof the returned minor-status code.