Generic Security Service Application Programming Interface (GSS-API) Naming Extensions
Extracted elements (24)
All name attributes are treated as locally critical: the mechanism(s) must understand them. This is required because name attributes necessarily have semantics the mechanism must act upon (including transporting application-specific attributes to peers), even though there is no protocol provision guaranteeing that remote peers understand any given attribute.
Attributes that have different naming contexts (trust model, encoding, credential issuer role) MUST have different attribute names so applications can distinguish them. This means there is no single attribute name for a concept like 'email address'; multiple attribute names exist for the same basic information depending on context.
Local attributes are introduced to allow GSS-API implementations to consolidate policy knowledge (e.g., which certification authorities are trusted for PKINIT) and re-encode mechanism-specific attributes into a single canonical form. This trades interoperability for usability by requiring knowledge of the local implementation but reduces per-application policy logic.
Name attribute values are made available in canonical network encodings (rather than language- or platform-specific types) to facilitate construction of portable Access Control Lists. A separate display function (GSS_Display_name_ext) is provided for applications needing local representations.
The C-bindings rely on the gss_buffer_set_t type and associated functions (gss_create_empty_buffer_set, gss_add_buffer_set_member, gss_release_buffer_set) from GFD.024, and on const types from RFC 5587. Only the specific sections cited (GFD.024 §2.5/§6 and RFC 5587 §3.4.6 Figure 1) are normatively required; other changes those documents specify to existing GSS-API behavior are not required.
A mechanism MUST always prefix raw name attributes it passes through with a prefix that reflects the context of the attribute, in order to prevent ambiguities that could arise if a mechanism blindly passes through an attribute name it does not understand.
Any implementation of SET OF OCTET STRING used by this specification MUST preserve order, as GSS_Get_name_attribute() and GSS_Set_name_attribute() rely on order preservation for multi-valued attributes.
Attribute names MUST support multiple components. If there is more than one component, the more significant components define the semantics of the less significant components.
Deletion of negative authenticated attributes from NAME objects MUST NOT be allowed; such attempts must result in GSS_S_UNAUTHORIZED.
In the C-binding of GSS_Get_name_attribute(), the 'more' parameter MUST be initialized to -1 on the first call. The authenticated and complete flags MUST NOT change between multiple calls iterating over values for the same attribute.
The 'complete' flag in GSS_Get_name_attribute() and GSS_Set_name_attribute() SHOULD NOT be used in federated cases where several peers may hold some of the attributes about a name, as it may be highly dangerous in that context.
When GSS_Set_name_attribute() is called on a non-MN and succeeds even though no mechanisms understand the attribute, subsequent credential acquisition (GSS_Acquire_cred/GSS_Add_cred) MUST fail for mechanisms that do not understand the set attributes.
Attribute names are represented as OCTET STRING values. If an attribute name contains a space (ASCII 0x20), the first space separates the primary (most significant) component ('prefix') from the remainder. If the primary component contains ':' (ASCII 0x3a), it is treated as a URI; otherwise, the attribute is a local attribute.
GSS_Display_name_ext() displays a given GSS name using a caller-specified name type OID. The function may fail (GSS_S_UNAVAILABLE) if the name cannot be displayed using that syntax, since mappings between name syntaxes may be inexact or lossy.
GSS_Export_name_composite() exports a token that preserves name attribute information (including authenticated/complete flags) and can be re-imported with GSS_Import_name() using GSS_C_NT_COMPOSITE_EXPORT (OID 1.3.6.1.5.6.6). This is intended for inter-process communication.
GSS_Get_name_attribute() returns the values (both network encoding and display form) of a named attribute on a GSS name object, along with 'authenticated' (boolean: sourced from trusted peer credential) and 'complete' (boolean: represents the full set of values) flags.
GSS_Inquire_name() returns the set of attribute names associated with a GSS name object, and indicates whether the name is a Mechanism Name (MN) and, if so, which mechanism it belongs to. The attrs output is a SET OF OCTET STRING (gss_buffer_set_t in C).
GSS_Set_name_attribute() sets one or more values for a named attribute on a GSS name object. In the C-binding, one call per value is required; to replace all values, GSS_Delete_name_attribute() must be called first.
IANA registered OID value 6 ('gss-composite-export', absolute OID 1.3.6.1.5.6.6) in 'SMI Security for Name System Designators Codes (nametypes)' for the GSS_C_NT_COMPOSITE_EXPORT name type defined by this document.
This document creates a namespace of GSS-API name attributes identified by URIs. No single allocation authority is required. Future deployment experience may indicate the need for an IANA registry of URNs for IETF-defined attribute names, but no registry is established here.
Asserted (non-authenticated) attributes MUST NOT be used for security-sensitive purposes such as authorization decisions, because asserted attributes may be controlled directly by the peer. Only authenticated attributes — those with a secure association to a trusted credential source — are appropriate for such uses.
'Authenticated' means only that a trusted third party (not the peer itself) asserted the attribute; it does not imply any semantic claim about the attribute's accuracy is true. Additional semantics are always the result of applying local policy. For example, a 'mail' attribute may be authenticated via signed SAML yet still be user-modifiable in some deployments.
When the underlying security mechanism does not provide a permanent unique identity (e.g., anonymous Kerberos), GSS-API naming extensions may be used to supply a permanent unique identity attribute — globally unique, namespace-unique, or a 'directed' identifier unique per acceptor identity — using constructs such as SAML persistent NameID.
All tokens produced by GSS_Export_name_composite() MUST start with a two-octet token ID of hex 04 02 in network byte order. The remainder of the token format is implementation-defined (for IPC use only).