The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism
obsoletes
- rfc-2222 — Simple Authentication and Security Layer (SASL)
Extracted elements (21)
The authentication sequence has known limitations: it lacks channel bindings and does not minimize the number of round-trips. These limitations are acknowledged, and the SASL WG was working on a separate document to address them.
The specification requires clients to request integrity from GSS_Init_sec_context (upgrading from RFC 2222/RFC 2078 behavior) so that the security layer negotiation can be wrapped with GSS_Wrap, satisfying RFC 4422's requirement that security layer negotiation be integrity-protected.
RFC 2222 implementations will not work with GSS-API implementations that require integ_req_flag to be true. No RFC 1964 or RFC 4121 implementations requiring integ_req_flag=true are known to exist.
A server MUST NOT advertise support for the 'GSSAPI' SASL mechanism unless it has acceptor credential for the Kerberos V5 GSS-API mechanism.
Clients MUST use GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names unless they have a priori knowledge that the server supports alternate name types.
If the client will be requesting a security layer providing confidentiality protection, it MUST supply a conf_req_flag of TRUE to GSS_Init_sec_context.
Servers SHOULD use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred for GSS_C_NO_NAME and the Kerberos V5 GSS-API mechanism OID as the preferred approach for acceptor credentials.
The maximum size field in the client's response MUST be 0 if the client does not support any security layer.
The server SHOULD verify that the negotiated GSS-API mechanism is indeed Kerberos V5 by examining the mech_type parameter returned from GSS_Accept_sec_context.
Upon successful context establishment, if the negotiated GSS-API mechanism is not Kerberos V5 (i.e., mech_type differs), SASL authentication MUST be aborted.
When calling GSS_Init_sec_context, the client MUST pass the integ_req_flag of TRUE to ensure integrity protection is requested.
When decoding received data with GSS_Unwrap, a major_status other than GSS_S_COMPLETE MUST be treated as a fatal error.
When the server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL, it SHOULD verify via GSS_Inquire_context that the client's target_name matches the expected service principal in either GSS_C_NT_HOSTBASED_SERVICE or GSS_KRB5_NT_PRINCIPAL_NAME format.
The SASL mechanism name for the Kerberos V5 GSS-API mechanism is 'GSSAPI'. Despite the generic name, it is specifically tied to Kerberos V5 and the GSS-API Kerberos V5 mechanism (RFC 4121).
Three security layer bit-masks are defined: 1 = no security layer; 2 = integrity protection (GSS_Wrap with conf_flag=FALSE); 4 = confidentiality protection (GSS_Wrap with conf_flag=TRUE). Undefined bits must be negotiated off.
IANA updated the existing 'GSSAPI' SASL mechanism registration to reference RFC 4752. The registration specifies: family=NO, intended usage=COMMON, [email protected], and notes the mechanism is specific to the Kerberos V5 GSS-API mechanism.
The channel bindings parameter to GSS_Init_sec_context and GSS_Accept_sec_context is required to be NULL, disallowing GSS-API channel bindings. This is a known limitation; channel binding support is deferred to a future GSS-API family of SASL mechanisms.
When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service, to avoid DNS-based spoofing attacks.
The GSSAPI SASL authentication exchange proceeds: (1) client sends initial GSS token; (2) client and server exchange GSS_S_CONTINUE_NEEDED tokens until context established; (3) server sends GSS_Wrap'd 4-octet security layer offer; (4) client sends GSS_Wrap'd security layer selection plus authorization identity; (5) server verifies and authentication is complete.
The client's security layer negotiation response is: first octet = selected security layer bit-mask, octets 2–4 = maximum output_message size client can receive (network byte order, MUST be 0 if no security layer), remaining octets = UTF-8 encoded authorization identity (not NUL-terminated).
The server's security layer negotiation message is 4 octets: the first octet is a bit-mask of supported security layers, and octets 2–4 are the maximum output_token size the server can receive in network byte order.