Extended Generic Security Service Mechanism Inquiry APIs
Extracted elements (22)
GSS-API applications have historically hardcoded mechanism OIDs because no API existed to query mechanism properties. This document introduces mechanism attributes to allow programmatic mechanism selection without hardcoding OIDs.
Individual mechanism attribute types are modeled as OIDs and reuse existing 'OID' and 'OID set' data types to simplify the interfaces. This avoids introducing new data types while leveraging the existing GSS-API type system.
Mechanism attributes may be added at any time, both to the known set and to existing mechanisms' attribute sets. The 'critical_mech_attrs' parameter in GSS_Indicate_mechs_by_attrs() and known_mech_attrs output in GSS_Inquire_attrs_for_mech() address the problem of applications not knowing whether implementations understand newly-added attributes.
There is a bug in the C bindings of GSS-APIv2u1 (RFC 2744) where the C 'const' attribute is misapplied to pointer typedefs, declaring the pointer as const rather than the pointed-to object. New typedefs (gss_const_OID, gss_const_OID_set, etc.) are defined in this document to fix this.
All future GSS-API mechanism specifications MUST list the set of GSS-API mechanism attributes associated with them.
GSS_C_MA_DEPRECATED mechanisms MUST NOT be used as a default mechanism, and GSS_C_MA_NOT_DFLT_MECH mechanisms MUST NOT be used as a default mechanism.
The namespace of programming-language symbols beginning with GSS_C_MA_* is reserved for allocation by IETF Consensus. IANA allocated a base OID arc (1.3.6.1.5.5.13) and registered all GSS_C_MA_* values described in Section 3.2.
A new major status code GSS_S_BAD_MECH_ATTR is defined with routine error number 19 (shifted left by GSS_C_ROUTINE_ERROR_OFFSET), returned by GSS_Display_mech_attr() when the specified mechanism attribute OID is unknown to the implementation.
GSS_C_MA_DEPRECATED (arc 7) indicates a mechanism MUST NOT be used as a default mechanism. GSS_C_MA_NOT_DFLT_MECH (arc 8) indicates a mechanism MUST NOT be used as default regardless of deprecation status.
GSS_C_MA_ITOK_FRAMED (arc 9) indicates that a mechanism's initial context tokens are properly framed per Section 3.1 of RFC 2743. GSS_C_MA_AUTH_INIT (arc 10) and GSS_C_MA_AUTH_TARG (arc 11) indicate support for initiator-to-acceptor and acceptor-to-initiator authentication respectively.
GSS_C_MA_MECH_CONCRETE (arc 1) indicates a mechanism is neither a pseudo-mechanism nor a composite mechanism. GSS_C_MA_MECH_PSEUDO (arc 2) indicates a pseudo-mechanism. GSS_C_MA_MECH_COMPOSITE (arc 3) is reserved for stackable pseudo-mechanisms.
GSS_C_MA_PFS (arc 25) indicates support for Perfect Forward Security. GSS_C_MA_CBINDINGS (arc 24) indicates support for channel bindings. GSS_C_MA_CTX_TRANS (arc 27) indicates support for security context export/import.
GSS_Display_mech_attr() takes a mechanism attribute OID and returns three outputs: name (the GSS_C_MA_* symbol name), short_desc (brief description), and long_desc (longer description). Output buffers must be released via GSS_Release_buffer().
GSS_Indicate_mechs_by_attrs() takes three OID set inputs: desired_mech_attrs (mechanisms MUST offer), except_mech_attrs (mechanisms MUST NOT offer), and critical_mech_attrs (mechanisms MUST understand). It returns the set of matching mechanism OIDs.
GSS_Inquire_attrs_for_mech() takes a mechanism OID and returns two OID sets: mech_attrs (attributes the mechanism supports) and known_mech_attrs (attributes the mechanism implementation knows about, whether or not supported).
Mechanism attributes are modeled as OIDs, reusing the existing 'OID' and 'OID set' data types. An open namespace for mechanism attributes is defined under arc <1.3.6.1.5.5.13>.
Security protection attributes include GSS_C_MA_INTEG_PROT (arc 17) for per-message integrity, GSS_C_MA_CONF_PROT (arc 18) for confidentiality, GSS_C_MA_MIC (arc 19) for MIC tokens, GSS_C_MA_WRAP (arc 20) for WRAP tokens, GSS_C_MA_REPLAY_DET (arc 22) for replay detection, and GSS_C_MA_OOS_DET (arc 23) for out-of-sequence detection.
The Kerberos V mechanism (RFC 1964) supports GSS_C_MA_MECH_CONCRETE, GSS_C_MA_ITOK_FRAMED, GSS_C_MA_AUTH_INIT, GSS_C_MA_AUTH_TARG, GSS_C_MA_DELEG_CRED, GSS_C_MA_INTEG_PROT, GSS_C_MA_CONF_PROT, GSS_C_MA_MIC, GSS_C_MA_WRAP, GSS_C_MA_PROT_READY, GSS_C_MA_REPLAY_DET, GSS_C_MA_OOS_DET, GSS_C_MA_CBINDINGS, and optionally GSS_C_MA_CTX_TRANS.
The SPNEGO mechanism (RFC 4178) provides only GSS_C_MA_MECH_NEGO and GSS_C_MA_ITOK_FRAMED attributes, reflecting its role as a pure negotiation pseudo-mechanism.
IANA registered the GSS_C_MA_* mechanism attribute OIDs under arc 1.3.6.1.5.5.13. Arcs 1-27 are assigned to the known mechanism attributes listed in Table 1; arcs 28 and above are reserved for future allocation by IETF Consensus.
Application developers must understand that mechanism attributes may be added at any time to both the known attribute set and existing mechanisms' supported attributes. Applications must identify which attributes are critical and use the criticality features of the new APIs accordingly.
The ability to programmatically inquire about specific mechanism properties should improve security by reducing hardcoding of mechanism OIDs and allowing applications to select mechanisms based on verified security properties. The semantics of each mechanism attribute may include a security component.