Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family
updated by
- rfc-9266 — Channel Bindings for TLS 1.3
Extracted elements (25)
GS2 does not support SASL security layers (confidentiality/integrity of application data after authentication) because SASL applications typically run over TLS, making security layers redundant; channel binding to the TLS channel is the recommended replacement.
GS2 was created because GS1 (the original GSS-API->SASL bridge, RFC 4752) was not round-trip optimized and did not support channel binding. GS2 fixes both deficiencies and also serves as the bridge for newer mechanisms such as SCRAM.
SHA-1 is used only to derive SASL mechanism names from GSS-API OIDs; no traditional cryptographic collision-resistance property is required — only that truncated outputs are distinct for practical input values. GS2 itself uses no other cryptographic algorithm and is otherwise as algorithm-agile as the underlying GSS-API mechanisms.
The SASL 'GSSAPI' mechanism (RFC 4752) for Kerberos V5 is not wire-compatible with Kerberos V5 used as a GS2 mechanism. If one side supports only 'GSSAPI' and the other only GS2, mechanism negotiation will fail.
Authentication MUST NOT succeed if GSS_Init/Accept_sec_context returns anything other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, if the GS2 header does not match the ABNF, or if authorization of the client principal to the requested authzid fails.
GSS-API mechanisms that negotiate other mechanisms (such as SPNEGO, RFC 4178) MUST NOT be used with GS2. SASL client implementations MUST NOT choose the SPNEGO mechanism under any circumstances, due to both interoperability and security problems with double negotiation.
If a server supports Kerberos V5 via GS2, it SHOULD also support Kerberos V5 through the 'GSSAPI' mechanism to avoid interoperability problems with older clients. If the application requires SASL security layers, it MUST use the 'GSSAPI' mechanism instead of GS2-KRB5.
If GSS_Inquire_SASLname_for_mech() fails and the GS2 implementation cannot map the OID to a SASL mechanism name by other means, the GS2 implementation MUST NOT use the given GSS-API mechanism.
If the client's gs2-cb-flag was 'y' and the server did advertise channel binding support (via the PLUS variant), the server MUST fail authentication. If the flag was 'p' and the server does not support the indicated channel binding type, the server MUST fail authentication.
If the client supports channel binding and the server does not appear to (no -PLUS name advertised), the client MUST NOT use an 'n' gs2-cb-flag. Clients that support mechanism negotiation and channel binding MUST use 'p' when the server offers the PLUS variant.
Servers that support channel binding SHOULD advertise both the non-PLUS and PLUS variants of each GS2 mechanism name. If a server would never succeed with the non-PLUS variant due to policy, it MUST advertise only the PLUS variant.
The GSS-API mutual_req_flag MUST be set. Clients MUST verify that the corresponding ret_flag is set when the context is fully established; if not, authentication MUST fail. Per-message req_flags SHOULD NOT be set since GS2 does not use per-message tokens.
The initial GSS-API context token header (RFC 2743, Section 3.1) MUST be removed by the client before prefixing the GS2 header. The server MUST recompute and restore it before passing the token to GSS_Accept_sec_context, except when the gs2-nonstd-flag is present.
The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 0, and the corresponding address fields MUST be the empty string. The application-data field MUST be set to the gs2-header (excluding the gs2-nonstd-flag part) concatenated with the channel binding data when 'p' is used.
'tls-unique' (RFC 5929) is the default channel binding type for application protocols that do not specify their own. Servers MUST implement 'tls-unique' if they implement any channel binding; clients SHOULD implement it. Both SHOULD choose the highest-layer/innermost end-to-end TLS channel.
Each GSS-API mechanism exposed via GS2 has two SASL mechanism names: the base name (server does not support channel binding) and the base name suffixed with '-PLUS' (server does support channel binding). The '-PLUS' suffix is the sole signal for channel binding capability.
For GSS-API mechanisms without a pre-assigned SASL name, the GS2 SASL name is 'GS2-' concatenated with the Base32 (uppercase, RFC 4648) encoding of the first 55 bits of the SHA-1 hash of the ASN.1 DER encoding (including tag and length) of the mechanism OID.
IANA registered SASL mechanism family 'GS2-*' per RFC 4422. All SASL mechanism names starting with 'GS2-' are reserved for mechanisms conforming to RFC 5801. GS2 mechanism names MUST NOT end in '-PLUS' except as a version of another name simply suffixed with '-PLUS'.
The grandfathered SASL mechanism names 'GS2-KRB5' and 'GS2-KRB5-PLUS' are assigned to the Kerberos V5 GSS-API mechanism (RFC 1964, RFC 4121) for use via GS2. The names 'SPNEGO' and 'SPNEGO-PLUS' are assigned to the SPNEGO GSS-API mechanism but MUST NOT be used.
Authentication failure due to channel binding failure may indicate an attempted MITM attack, but detection is heuristic because a real attacker would more likely close the connection or simulate a network partition rather than let authentication fail.
Because GS2 does not support security layers, it is strongly RECOMMENDED that channel binding to a secure external channel be used. Successful channel binding eliminates MITM attacks, provided the external channel and its channel binding data are secure.
GS2 does not protect against downgrade attacks on channel binding types; negotiation of channel binding type was intentionally left out of scope. Passive attackers may recover channel binding data if neither the external channel nor the GSS-API mechanism provides confidentiality protection for it.
When constructing input_name_string for GSS_Import_name with GSS_C_NT_HOSTBASED_SERVICE, the client SHOULD NOT canonicalize the server's FQDN using an insecure directory service such as DNS without DNSSEC, to prevent name substitution attacks.
The gs2-authzid field is encoded as UTF-8 with NUL forbidden; commas MUST be escaped as '=2C' and equals signs MUST be escaped as '=3D'. NUL is forbidden per RFC 4422 Section 3.4.1.
The GS2 header prepended to the initial GSS-API context token has the ABNF form: gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ",". The gs2-cb-flag is one of 'p=<cb-name>' (used channel binding), 'n' (no CB support), or 'y' (supports CB, thinks server does not).