Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
updates
- rfc-4462 — Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
Extracted elements (27)
Only SHA-256 and SHA-512 are used for DH groups, following the practice of RFC 8268. For NIST elliptic curves, the same curve-to-hash pairing as RFC 5656 is adopted for consistency.
SHA-1 has known security concerns (RFC 6194) and MODP groups with fewer than 2048 bits are deprecated per NIST SP 800-131A. This document replaces SHA-1-based GSS key exchange methods with SHA-2 variants and larger DH groups to address these weaknesses.
This document updates RFC 4462 by adding new key exchange methods and deprecating the SHA-1-based methods (gss-group1-sha1-*, gss-group14-sha1-*, gss-gex-sha1-*). Implementations wishing to interoperate with legacy peers may still need to support the deprecated methods.
After GSS context establishment (GSS_S_COMPLETE), both parties must verify that mutual_state and integ_avail are both 'true'; if not, the key exchange MUST fail.
Deprecated algorithms gss-group1-sha1-*, gss-group14-sha1-*, and gss-gex-sha1-* SHOULD NOT be used due to small key lengths and vulnerability to brute-force attacks.
For NIST curves, public keys MUST use the uncompressed point representation and MUST be converted using the algorithm in Section 2.3.4 of SEC1v2. If conversion fails or the compressed representation is used, the key exchange MUST fail.
If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or any other GSS-API call returns other than GSS_S_COMPLETE, the key exchange MUST fail.
If the client does not support or intend to use gssapi-keyex user authentication, anon_req_flag SHOULD be set to 'true'. Otherwise, it MAY be set to 'true' if the client wishes to hide its identity.
If the client receives SSH_MSG_KEXGSS_CONTINUE after GSS_Init_sec_context() has returned GSS_S_COMPLETE, or receives SSH_MSG_KEXGSS_COMPLETE without GSS_S_COMPLETE from GSS_Init_sec_context(), the key exchange MUST fail.
Implementations MUST check whether the computed Diffie-Hellman shared secret for X25519 or X448 is the all-zero value and abort if so, as described in Section 6 of RFC 7748.
Implementations MUST compute X25519 and X448 functions using the algorithms described in RFC 7748.
replay_det_req_flag and sequence_req_flag SHOULD be set to 'false' since the key exchange exchanges only a single message token once the context is established.
The client MUST include its public key with the first message sent to the server. If the server receives more than one key or none at all, the key exchange MUST fail.
The client MUST set mutual_req_flag and integ_req_flag to 'true' when calling GSS_Init_sec_context(). deleg_req_flag MAY be set to 'true' to request credential delegation.
The exchange hash H SHOULD be kept secret.
The SSH_MSG_KEXGSS_HOSTKEY message is OPTIONAL. If the 'null' host key algorithm from RFC 4462 Section 5 is used, this message MUST NOT be sent.
Five new ECDH key exchange method families are defined: gss-nistp256-sha256-* (SHOULD), gss-nistp384-sha384-* (MAY), gss-nistp521-sha512-* (MAY), gss-curve25519-sha256-* (SHOULD), and gss-curve448-sha512-* (MAY), covering NIST P-curves and RFC 7748 curves.
Five new finite-field DH key exchange method families are defined: gss-group14-sha256-* (SHOULD), gss-group15-sha512-* (MAY), gss-group16-sha512-* (SHOULD), gss-group17-sha512-* (MAY), and gss-group18-sha512-* (MAY), covering 2048- through 8192-bit MODP groups from RFC 3526.
Key exchange method names are formed by concatenating the family name prefix with the base64 encoding of the MD5 hash of the ASN.1 DER encoding of the GSS-API mechanism's OID, following the naming convention of RFC 4462.
IANA has updated the SSH Protocol Parameters 'Key Exchange Method Names' registry to add thirteen new method name prefixes (gss-group14-sha256-* through gss-curve448-sha512-*) and to reference RFC 8732 for the three deprecated SHA-1 entries.
The ECDH mechanisms closely follow RFC 5656; all original security considerations from RFC 4462 and RFC 5656 apply to the new elliptic curve DH methods.
The new finite-field DH mechanisms are identical to RFC 4462 except for the use of SHA-2 and larger DH groups; all original RFC 4462 security considerations continue to apply.
When deleg_req_flag is set, extra care must be taken to verify that the GSS-API acceptor matches the intended target. Some implementations (e.g., Kerberos krb5 libraries) use insecure DNS resolution to canonicalize target names, making them vulnerable to DNS spoofing that could cause silent credential delegation to an attacker.
ECDH GSS key exchange: Client generates ephemeral key pair and calls GSS_Init_sec_context(), sends SSH_MSG_KEXGSS_INIT. Server may send SSH_MSG_KEXGSS_HOSTKEY. The loop exchanges SSH_MSG_KEXGSS_CONTINUE tokens until context is established. Server then generates its key pair, computes shared secret and hash H, calls GSS_GetMIC(H), and sends SSH_MSG_KEXGSS_COMPLETE. Client verifies key, computes shared secret and H, calls GSS_VerifyMIC.
SSH_MSG_KEXGSS_COMPLETE carries: byte (message type), string (Q_S, server's ephemeral public key octet string), string (mic_token, MIC of H), boolean (TRUE if output_token follows), and optionally string (output_token from GSS_Accept_sec_context()).
SSH_MSG_KEXGSS_INIT carries: byte (message type), string (output_token from GSS_Init_sec_context()), string (Q_C, client's ephemeral public key octet string).
The exchange hash H is computed as: hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K), where all string fields are length-prefixed and K is an mpint. If no SSH_MSG_KEXGSS_HOSTKEY was sent, K_S is the empty string.