Remote Procedure Call (RPC) Security Version 3
updates
- rfc-5403 — RPCSEC_GSS Version 2
Extracted elements (29)
A new reply verifier is needed in RPCSEC_GSSv3 because child and parent handles share the same GSS context and can therefore have the same RPCSEC_GSS sequence numbers. The prior verifier computed a MIC on only the sequence number, enabling man-in-the-middle attacks; the new verifier covers the full RPC reply header including xid, mtype, rpcvers, prog, vers, proc, and cred.
RPCSEC_GSSv3 channel binding differs from v2 in two ways: it reuses existing established context handles rather than providing a new RPC security flavor, and it does not hash the channel-bindings data because there is now general agreement that the secure channel is responsible for producing channel-bindings data of manageable size.
When RPCSEC_GSSv3 contexts are used with NFSv4.1's SSV mechanism, man-in-the-middle attacks described in RFC 5661 Section 2.10.10 are mitigated by the new RPCSEC_GSSv3 reply verifier. However, use of an SSV-backed parent handle in RPCSEC_GSS_CREATE is complicated by SSV context lifetime rules. Servers MUST use RPCSEC_GSS context handles that authenticate the client when protecting callbacks related to state initiated by RPCSEC_GSSv3-protected RPCs.
A successful structured privilege assertion MUST be enumerated in the rcr_assertions field of the rgss3_create_res reply; if the server receives an unrecognized structured privilege assertion, it MUST reject with auth_stat RPCSEC_GSS_UNKNOWN_MESSAGE.
All RPCSEC_GSSv3 implementations MUST implement the new RPCSEC_GSS version number, the new reply verifier, and the new auth_stat values. There is no RPCSEC_GSS_CREATE payload that is REQUIRED; the protocol is feature-driven beyond these mandatory items.
An RPCSEC_GSS_CREATE control procedure carrying a multi-principal authentication payload MUST use rpc_gss_svc_privacy to prevent an attacker from intercepting the message, reassigning the context handle, and stealing the user's identity.
An RPCSEC_GSSv3 child handle MUST NOT be used as the parent handle in an RPCSEC_GSS_CREATE control message.
For multi-principal authentication, the parent handle MUST correspond to a GSS-API security context authenticating the RPC client host, and the inner context handle MUST authenticate the user; the reverse MUST NOT be used.
If a security label itself requires privacy protection, the client MUST use rpc_gss_svc_privacy for the RPCSEC_GSS_CREATE request carrying the label assertion.
If a server receives an RPCSEC_GSS_BIND_CHANNEL operation on an RPCSEC_GSSv3 handle, it MUST return a reply status of MSG_ACCEPTED with an accept_stat of PROC_UNAVAIL; the RPCSEC_GSS_BIND_CHANNEL operation is not supported on version 3 handles.
If the rca_chan_bind_mic field of an RPCSEC_GSS_CREATE message is set, the server MUST verify the client's channel-binding MIC if it supports this feature; on success, the server MUST generate a new MIC of the same channel bindings and place it in rcr_chan_bind_mic.
On successful multi-principal verification, the rgss3_gss_mp_auth field in the rgss3_create_res reply MUST be filled in with the inner RPCSEC_GSSv3 context handle and a MIC computed over the RPC reply header using the GSS-API security context of the inner handle.
RPCSEC_GSSv3 child handles MUST be destroyed upon the destruction of the associated parent handle.
RPCSEC_GSSv3 targets implementing a desired feature MUST also implement the RPCSEC_GSS_LIST operation and MUST return appropriate error auth_stat values for unsupported features in RPCSEC_GSS_CREATE replies.
The client MUST use rpc_gss_svc_integrity or rpc_gss_svc_privacy to protect RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control messages; rpc_gss_svc_none MUST NOT be used.
The client MUST verify the result's rcr_chan_bind_mic by calling GSS_VerifyMIC(); if client-side channel-binding verification fails, the client MUST call RPCSEC_GSS_DESTROY. If the client considers channel binding critical and the server omitted the field, it MUST call RPCSEC_GSS_DESTROY.
The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 3 with version 1 or version 2 of the same target, and vice versa.
The server MUST NOT reject RPCSEC_GSS_CREATE requests containing supported structured privilege assertions even if some assertions are rejected for local policy reasons. If an RPCSEC_GSS_CREATE request contains one or more unsupported structured privilege assertions, the request MUST be rejected with auth_stat RPCSEC_GSS_PRIVILEGE_PROBLEM.
Four new auth_stat enumeration values are defined: RPCSEC_GSS_INNER_CREDPROBLEM (15) for missing inner context user credentials, RPCSEC_GSS_LABEL_PROBLEM (16) for label assertion problems, RPCSEC_GSS_PRIVILEGE_PROBLEM (17) for structured privilege problems, and RPCSEC_GSS_UNKNOWN_MESSAGE (18) for unrecognized structured privilege assertions.
The new RPCSEC_GSSv3 reply verifier computes a GSS-API MIC over: xid, mtype (set to REPLY), rpcvers, prog, vers, proc, and opaque_auth cred — the same fields used in the request verifier except mtype is changed from CALL to REPLY.
The RPCSEC_GSS_CREATE procedure takes rgss3_create_args (optional rca_mp_auth, optional rca_chan_bind_mic, and a sequence of rca_assertions) and returns rgss3_create_res (rcr_handle opaque child context handle, optional rcr_mp_auth, optional rcr_chan_bind_mic, and rcr_assertions).
The RPCSEC_GSS_LIST procedure takes rgss3_list_args (a sequence of rgss3_list_item integers indicating which assertion types to list) and returns a sequence of rgss3_list_item_u unions containing supported LFSs (for LABEL) or supported privilege descriptors (for PRIVS).
Four new values were added to the IANA RPC Authentication Status Numbers registry: RPCSEC_GSS_INNER_CREDPROBLEM (15), RPCSEC_GSS_LABEL_PROBLEM (16), RPCSEC_GSS_PRIVILEGE_PROBLEM (17), and RPCSEC_GSS_UNKNOWN_MESSAGE (18).
IANA created the 'RPCSEC_GSS Structured Privilege Names Registry' maintained under the Standards Action policy. Names are UTF-8 strings of 1–128 characters; the prefixes 'EXPE' and 'PRIV' (and their case permutations) are reserved; the initial entries are copy_to_auth, copy_from_auth, and copy_confirm_auth from RFC 7862.
Client-side assertions carried by RPCSEC_GSSv3 must be evaluated by the server in the context of whether the client and/or user are authenticated, whether multi-principal authentication was used, the client's trust level, permitted assertion ranges, and server-side policy. The security semantics of assertions are application protocol-specific.
RPCSEC_GSSv3 is not a complete solution for labeling: it conveys the labels of actors (subjects) but not the labels of objects. RPC application protocols may require extension to carry object label information.
The rgss3_gss_mp_auth structure carries rgmp_handle (opaque variable-length bytes containing the inner RPCSEC_GSSv3 context handle) and rgmp_rpcheader_mic (opaque variable-length bytes containing a GSS MIC over the RPC header).
The rgss3_label structure carries rl_lfs (an rgss3_lfs with rlf_lfs_id and rlf_pi_id, each 32-bit unsigned integers identifying the Label Format Specifier and Policy Identifier) and rl_label (opaque variable-length bytes containing the MAC subject label).
The rgss3_privs structure carries rp_name (a UTF-8 case-sensitive string array identifying the structured privilege) and rp_privilege (opaque variable-length bytes containing the application-specific privilege data).