Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism
Extracted elements (20)
In the federated context, an IdP is trusted to make certain statements (e.g., student vs. professor) but not others (e.g., local group membership). Because context determines trust, attributes with different trust contexts need different names. This specification defines distinct attribute names for the federated context to allow applications to distinguish context.
SAML attribute names may not be globally unique—unspecified name formats allow two issuers to choose the same name with different semantics. By including the NameFormat URI as part of the GSS attribute name, the specification ensures that attribute names are disambiguated by their format context.
A service MUST make a policy decision about whether the IdP is permitted to assert a particular attribute and whether the asserted value is acceptable. This policy can be implemented as local configuration, AAA proxy rules, or other deployment-specific mechanisms.
Federated context attribute names MUST NOT be used for attributes issued by a party other than one closely associated with the source of credentials, unless the source of credentials is re-asserting those attributes. Acceptors can assume attributes in the federated context come from the credential source.
GSS_Get_name_attribute MUST only return the federated-saml-assertion attribute with the authenticated output set to true if the mechanism can successfully authenticate the SAML statement. Uses of the GSS-API MUST confirm the attribute is marked authenticated, as some mechanisms may permit an initiator to supply an unauthenticated SAML statement.
If multiple RADIUS attributes with the same name are present in a RADIUS message, a multi-valued GSS-API attribute SHOULD be returned. As an exception, implementations SHOULD concatenate RADIUS attributes (such as EAP-Message or large RFC 6929 attributes) that use multiple attributes to carry more than 253 octets.
If the content of each <saml:AttributeValue> element is a simple text node, the raw and display values of the GSS name attribute MUST be the text content of the element(s), with the raw value encoded as UTF-8. If the value is not simple or is empty, the raw value(s) MUST be a namespace well-formed serialization of the <saml:AttributeValue> element(s) encoded as UTF-8.
In the GSS-EAP mechanism, a SAML assertion carried in an integrity-protected and authenticated AAA protocol SHALL be successfully validated; attributes from that assertion SHALL be returned from GSS_Get_name_attribute with the authenticated output set to true.
The raw value of the federated-saml-nameid GSS name attribute MUST be the well-formed serialization of the <saml:NameID> element encoded as UTF-8. For formats defined in SAML Section 8.3, missing NameQualifier or SPNameQualifier values MUST be populated according to the format's defaulting rules prior to serialization.
The URI indicating the format of the SAML attribute name is not optional and MUST be present in the GSS-API name for SAML attributes.
A SAML assertion from the credential source is exposed as the GSS name attribute 'urn:ietf:params:gss:federated-saml-assertion'. Its value is the assertion carried in the AAA protocol or used for authentication. It is absent if no assertion is present or if the assertion fails local policy.
Each SAML attribute in an assertion SHOULD also be a GSS name attribute, named with three space-separated parts: 'urn:ietf:params:gss:federated-saml-attribute', the NameFormat URI, and the SAML attribute Name. Spaces within URIs are encoded as '%20' and do not separate name parts.
RADIUS attributes received in a GSS-EAP access-accept message are named as 'urn:ietf:params:gss:radius-attribute' followed by a space and the numeric RADIUS attribute name per RFC 6929 Section 2.7. For example, the User-Name attribute (type 1) is named 'urn:ietf:params:gss:radius-attribute 1'; extended type 1 within type 241 is 'urn:ietf:params:gss:radius-attribute 241.1'.
SAML attributes carried in GSS-API names are named with three parts separated by spaces: (1) a URN indicating the context (federated or otherwise), (2) the URI indicating the format of the SAML attribute name (NameFormat), and (3) the SAML attribute name itself. The format URI is not optional.
The <saml:NameID> in the subject of an assertion SHOULD be exposed as a GSS name attribute named with two space-separated parts: 'urn:ietf:params:gss:federated-saml-nameid' followed by the URI for the <saml:NameID> element's Format XML attribute.
A new IANA top-level registry 'Generic Security Service Application Program Interface Parameters' is created, containing a subregistry 'GSS-API URN Parameters'. Registration requires IETF Review or Expert Review. Initial entries map parameter names to URNs of the form 'urn:ietf:params:gss:<paramname>'.
The 'gss' URN sub-namespace is registered in the IETF URN sub-namespace for protocol parameters (RFC 3553). Initial GSS-API URN Parameters registrations are: radius-attribute (Section 5), federated-saml-assertion (Section 6.1), federated-saml-attribute (Section 6.2), and federated-saml-nameid (Section 6.3).
Mechanisms may perform local policy checks on SAML assertions, attributes, and name identifiers. If an application accesses the same SAML assertion through a different path (e.g., via [AAA-SAML]), it may get different results; this is intended, since different paths may apply different policy checks.
The GSS-API mechanism is responsible for authentication and integrity protection of the attributes, but the acceptor application is responsible for deciding whether the credential source is trusted to assert a given attribute and for validating the asserted value. Applications that bypass local policy checks SHOULD perform their own evaluation before relying on the information.
The value of RADIUS attributes exposed as GSS name attributes is the raw octets of the RADIUS packet; integers are in network byte order. The display value SHOULD be a human-readable string if the implementation knows the attribute type.