RPCSEC_GSS Version 2
updated by
- rfc-7861 — Remote Procedure Call (RPC) Security Version 3
updates
- rfc-2203 — RPCSEC_GSS Protocol Specification
Extracted elements (22)
A one-way hash of channel bindings is used in rbcmia_bind_chan_hash rather than the raw channel bindings because some channel bindings (e.g., those composed of public keys) can be relatively large, imposing a space management burden on implementations.
Channel bindings support is added at the RPCSEC_GSS protocol layer rather than relying on native GSS mechanism channel bindings because, as RFC 2743 Section 1.1.6 notes, not all GSS mechanism implementations support channel bindings. This approach makes the feature available regardless of the underlying GSS mechanism's capabilities.
Protecting the RPCSEC_GSS version number within RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT tokens was considered as a MITM mitigation but rejected: it does not fully prevent the attack (merely moves MIC guessing to the INIT message), and including the version number in GSS tokens would require changing GSS or the GSS mechanism itself.
The primary motivation for channel bindings is to securely exploit hardware-assisted encryption at lower protocol layers (e.g., IPsec), allowing RPCSEC_GSS-layer MICs and privacy overhead to be eliminated when the channel already provides equivalent protection.
RPCSEC_GSSv2 is fully backward-compatible with RPCSEC_GSSv1; all RPCSEC_GSSv1 functionality is supported by RPCSEC_GSSv2. Version negotiation is implicit: the initiator sets rgc_version to RPCSEC_GSS_VERS_2, and a non-recognizing target returns an RPC error per RFC 2203 Section 5.1.
An initiator MUST NOT use an RPCSEC_GSS handle returned by a version 2 target with a version 1 instance of that same target, and MUST NOT use a handle returned by version 1 with a version 2 target.
Each time a target fails to verify the MIC of an RPCSEC_GSS_BIND_CHANNEL request, it SHOULD significantly reduce the lifetime of the underlying GSS context (e.g., by 50% per failure) to limit the window for a MITM brute-force attack.
RPCSEC_GSSv2 targets MUST support rpc_gss_svc_channel_prot. This service is only valid when RPCSEC_GSSv2 is in use, an RPCSEC_GSS_BIND_CHANNEL has completed successfully, and the secure channel still exists.
Targets MUST support the RPCSEC_GSS_BIND_CHANNEL procedure. The NULL RPC procedure MUST be used when issuing RPCSEC_GSS_BIND_CHANNEL requests, the same as for RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT.
The target SHOULD require a stronger MIC for RPCSEC_GSS_BIND_CHANNEL than for RPCSEC_GSS_DATA requests. If HMACs are used and N DATA requests are expected before context expiry, the HMAC for BIND_CHANNEL SHOULD be log2(N) bits longer than normal.
The target SHOULD stop allowing RPCSEC_GSS_DATA requests with rpc_gss_svc_channel_prot protection once the GSS context expires, even though such requests do not construct new GSS tokens.
To ensure interoperability, RPCSEC_GSSv2 implementations SHOULD NOT transfer tokens that use native GSS channel bindings (as defined in RFC 2743 Section 1.1.6) between initiator and target.
When the target returns RGSS2_BIND_CHAN_HASH_NOTSUPP, the rbcr_oid_list field MUST contain one or more OID elements identifying hash algorithms the target supports.
RPCSEC_GSSv2 adds two new enumerated values: rpc_gss_svc_channel_prot = 4 in rpc_gss_service_t and RPCSEC_GSS_BIND_CHANNEL = 4 in rpc_gss_proc_t. The version constant RPCSEC_GSS_VERS_2 = 2 is also introduced; both RPCSEC_GSS_VERS_1 and RPCSEC_GSS_VERS_2 share the same credential body type rpc_gss_cred_vers_1_t.
The rpc_gss_svc_channel_prot service eliminates per-request MICs: verifiers on both request and reply have flavor AUTH_NONE with zero-length contents. Non-NULL RPCSEC_GSS credentials are still used to identify the sending principal, with the service field set to rpc_gss_svc_channel_prot.
The RPCSEC_GSS_BIND_CHANNEL procedure performs a mutual channel-binding proof: the initiator sends a GSS MIC over the channel's shared information hash; the target verifies it and returns its own MIC, achieving simultaneous mutual authentication and proof of shared channel knowledge.
The RPCSEC_GSS_BIND_CHANNEL reply verifier is the XDR encoding of rgss2_bind_chan_verf_res, containing: rbcvr_res (a rgss2_bind_chan_res union with status RGSS2_BIND_CHAN_OK, RGSS2_BIND_CHAN_PREF_NOTSUPP, or RGSS2_BIND_CHAN_HASH_NOTSUPP) and rbcvr_mic (GSS_GetMIC over rgss2_bind_chan_MIC_in_res).
A MITM can intercept an RPCSEC_GSSv1 RPCSEC_GSS_INIT message, upgrade the version number to 2 toward a v2 target, then attempt to construct a valid RPCSEC_GSS_BIND_CHANNEL by reusing MICs from subsequent DATA requests, eventually gaining the ability to send unauthenticated channel-protected requests.
With channel bindings, a single forged GSS MIC allows an attacker to inject bogus requests for the lifetime of the channel, compared to RPCSEC_GSSv1 where a forged MIC enables only a single bogus request. This significantly raises the security requirement for the MIC algorithm used by the GSS mechanism.
rgss2_bind_chan_MIC_in_res encodes three fields: rbcmr_seq_num (unsigned int matching the RPCSEC_GSS credential seq_num), rbcmr_bind_chan_hash (one-way hash of the channel bindings including prefix), and rbcmr_res (copy of rbcvr_res). This structure is the input to GSS_GetMIC for the reply verifier's rbcvr_mic field.
The rpc_gss_cred_vers_1_t structure encodes: gss_proc (rpc_gss_proc_t), seq_num (unsigned int), service (rpc_gss_service_t), and handle (variable-length opaque). This structure is used for both version 1 and version 2 credentials, with rgc_version in the outer union selecting the version.
The RPCSEC_GSS_BIND_CHANNEL request verifier is the XDR encoding of rgss2_bind_chan_verf_args, containing: rbcva_chan_bind_prefix (channel binding prefix string up to but excluding the colon), rbcva_chan_bind_oid_hash (ASN.1 OID of the hash algorithm), and rbcva_chan_mic (GSS_GetMIC output over the RPC header concatenated with the XDR-encoded rbcmia_bind_chan_hash).