Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy
updates
- rfc-2743 — Generic Security Service Application Program Interface Version 2, Update 1
- rfc-2744 — Generic Security Service API Version 2 : C-bindings
- rfc-4120 — The Kerberos Network Authentication Service (V5)
- rfc-4121 — The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
Extracted elements (15)
A new flag (deleg_policy_req_flag) is introduced rather than changing deleg_req_flag behavior because existing applications and user expectations depend on the current unconditional delegation behavior. Changing deleg_req_flag to honor OK-AS-DELEGATE would break deployments where KDCs do not set that flag, causing negative user experiences without coordination with administrators.
In hindsight, deleg_req_flag should not have been defined to mean unconditional delegation. Promiscuous delegation reduces overall security by unnecessarily exposing user credentials, including to hosts and services that the user has no reason to trust.
The motivation for this specification is that a central authority (such as a Kerberos KDC setting OK-AS-DELEGATE) is often in a better position than the client application to determine which services should receive delegated credentials, allowing the client to delegate if and only if policy recommends it.
RFC 4120 does not adequately describe the behavior of the OK-AS-DELEGATE flag in a cross-realm environment; RFC 5896 clarifies that all cross-realm TGTs in the traversal path must have OK-AS-DELEGATE set for policy-based delegation to proceed.
If any intermediate cross-realm TGTs do not have the OK-AS-DELEGATE flag set, the Kerberos GSS-API mechanism MUST NOT delegate credentials when deleg_policy_req_flag is set.
If the initiator sets deleg_policy_req_flag, the GSS-API Kerberos mechanism MUST examine the OK-AS-DELEGATE flag in the service ticket and MUST also examine all cross-realm tickets in the traversal from the user's initial TGT to the service ticket.
Mechanisms SHOULD use a trusted and authenticated means of determining delegation policy, and the policy determination MUST NOT be spoofable on the network.
A new input flag, deleg_policy_req_flag, is added to gss_init_sec_context(). When set, delegation SHOULD be performed if recommended by central policy. A corresponding output flag, deleg_policy_state, is set when delegation was both recommended by central policy and successfully performed.
deleg_policy_req_flag and deleg_policy_state apply to the initiator only and their state is never sent over the wire, making them purely local policy controls.
The C binding constant GSS_C_DELEG_POLICY_FLAG is defined with value 32768, representing both deleg_policy_req_flag and deleg_policy_state, analogous to how GSS_C_DELEG_FLAG maps to two flags.
The existing deleg_req_flag behavior is unchanged: when set, the GSS-API mechanism attempts unconditional delegation of user credentials, and on success deleg_state returns TRUE for both initiator and acceptor.
When both deleg_req_flag and deleg_policy_req_flag are set, delegation is attempted unconditionally. deleg_state returns TRUE in both initiator and acceptor on success; deleg_policy_state additionally returns TRUE for the initiator if mechanism-specific policy also recommended delegation.
A client's failure to specify deleg_policy_req_flag can at worst result in NOT delegating credentials, meaning the client does not expand its trust, which is generally safer than the alternative of over-delegation.
deleg_policy_req_flag is not communicated over the wire and therefore does not present a new opportunity for spoofing or downgrading of delegation policy in and of itself.
Delegating the user's TGT is still considered too powerful and dangerous; ideally one would delegate specific service tickets, but this is out of scope for this document.