A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML)
Extracted elements (27)
Channel binding is set to 'n' (not supported) because channel-binding data cannot be integrity protected by the SAML negotiation itself. In theory it could be inserted into the SAML flow and verified by the server, but this is currently not supported in SAML.
The mechanism reuses the SAML 2.0 Web Browser SSO profile to the maximum extent and does not establish a separate authentication, integrity, or confidentiality layer, relying instead on TLS. This design means the IdP requires no changes; only the RP (SASL server) and client need modification.
When used as a GSS-API mechanism, the GS2 header on the client's first message and channel-binding data are excluded, and the initial context token header (RFC 2743, Section 3.1) is prefixed to the client's first authentication message.
The SASL server must implement a SAML Relying Party and correlate its SASL session with the SAML authentication result by matching the ID of the SAML authentication request it issued with the one received in the SAML authentication statement.
This specification is appropriate only when a browser instance is available. When no browser is available, SAML profiles that do not require a browser (such as the Enhanced Client or Proxy profile) may be used, but those are out of scope for this document.
Applications using the GSS-API mechanism MUST match the TLS server's identity with the target name per RFC 6125; the client uses the negotiated targ_name as the reference identifier matched against the DNS-ID of the server's certificate, and MUST reject the connection on mismatch.
Clients and servers MUST treat the IdP-Identifier as a domain name slot. They SHOULD support internationalized domain names (IDNs), and if they do, all labels MUST be A-labels or NR-LDH labels.
If internationalized labels are used in the IdP-Identifier, they MUST be converted from U-labels to A-labels using Punycode encoding prior to sending them to the SASL server.
In the gs2-header, the 'gs2-nonstd-flag' MUST NOT be present, and the 'gs2-cb-flag' MUST be set to 'n' because channel-binding data cannot be integrity protected by the SAML negotiation.
SAML20 GSS-API security contexts MUST have the mutual_state flag (GSS_C_MUTUAL_FLAG) set to TRUE. SAML does not support credential delegation; therefore, security contexts MUST have the deleg_state flag (GSS_C_DELEG_FLAG) set to FALSE.
Should the client support Internationalized Resource Identifiers (IRIs), it MUST first map the IRI to a URI before transmitting it to the server, as defined in Section 3.1 of RFC 3987.
The SAML mechanism MUST only be used over channels protected by TLS or over similar integrity-protected and authenticated channels, because it transports information that should not be controlled by an attacker.
The SASL client MUST construct a URL from the authentication request URI received from the server and transmit it to the IdP via an HTTP GET over a server-authenticated TLS channel.
The SASL outcome (message 8) SHALL be used to set state in the server and SHALL be reported to the SASL client as described in RFC 4422, Section 3.6.
When TLS is used, the client MUST successfully validate the server's certificate per RFC 5280 and RFC 6125.
The IdP is aware of each RP that a user authenticates to; the protocol does not hide this information. IdPs can track user access to services using RPs, which SASL server implementers should be aware of.
For GSS-API principal name types, SAML supports GSS_C_NT_HOSTBASED_SERVICE for acceptors and only GSS_C_NT_USER_NAME for initiators. GSS_C_NT_USER_NAME is the default name type; there are no SAML-specific name syntaxes.
The GSS-API mechanism OID for SAML is 1.3.6.1.5.5.17; its DER encoding is 0x2b 0x06 0x01 0x05 0x05 0x11. The SAML mechanism does not support per-message tokens or the GSS_Pseudo_random() function.
The SASL mechanism name is 'SAML20'. It is client-first, capable of transferring an authorization identity via the gs2-header, and does not offer a security layer. The exchange consists of four messages: initial-response, authentication-request URI, fixed '=' response, and SASL outcome.
IANA assigned OID 1.3.6.1.5.5.17 for the SAML GSS-API mechanism in the SMI Security for Mechanism Codes sub-registry (prefix iso.org.dod.internet.security.mechanisms, 1.3.6.1.5.5).
IANA registered the SASL mechanism profile 'SAML20' with intended usage COMMON. The mechanism is defined in this document (RFC 6595).
Collusion between RPs is possible when the same user identifier is shared across multiple RPs. SAML's targeted identity feature mitigates this by allowing the IdP to supply RP-specific opaque identifiers instead of the real user identifier.
The server is responsible for binding SAML subject identifiers to authorization identities, and only specific trusted IdPs should be allowed. This trust establishment between RPs and IdPs is a required operational step.
This mechanism is vulnerable to man-in-the-middle and tunneling attacks unless a client always verifies the server's identity before proceeding with authentication. TLS with server authentication is the typical mitigation.
The SAML SASL authentication flow has eight steps: (1) server advertises SAML20, (2) client sends initial-response with gs2-header and IdP domain, (3) server sends authentication request URI, (4) client sends '=', (5-6) out-of-band SAML flow between client and IdP, (7) IdP sends authentication statement to server out-of-band, (8) server sends SASL outcome to client.
The authentication request (server to client, message 3) is a URI encoded per RFC 3986 using the SAML 2.0 HTTP Redirect Binding (Section 3.4 of the SAML bindings spec), with the SAML AuthnRequest as a parameter.
The initial response from the client is defined as 'initial-response = gs2-header IdP-Identifier', where IdP-Identifier is a domain name identifying the user's Identity Provider.