RFC: add a 'policy' value to GSSAPIDelegateCredentials (OK-AS-DELEGATE)

[Alexander Bokovoy]

On to, 09 heinäkuuta 2026, Avinash Duduskar wrote:
> Hi,
> 
> GSSAPIDelegateCredentials forwards the user's TGT to any host the
> client authenticates to. Kerberos has the OK-AS-DELEGATE ticket flag
> (RFC 4120) so a realm can mark which services are trusted to receive
> delegated credentials, and GSS-API exposes it through
> GSS_C_DELEG_POLICY_FLAG (RFC 5896), which for the Kerberos mechanism
> requests delegation only when the service ticket carries
> OK-AS-DELEGATE.
> 
> In the client today, ssh_gssapi_init_ctx() in gss-genr.c always sets
> GSS_C_DELEG_FLAG when delegation is enabled, so ssh requests
> delegation unconditionally and ignores the realm policy.
> 
> I'd like to add a third value to the ssh_config client option, making
> it no / yes / policy. Under policy the client requests
> GSS_C_DELEG_POLICY_FLAG instead of GSS_C_DELEG_FLAG (RFC 5896 defines
> both flags together as unconditional delegation, so policy sets the
> policy flag alone). The core change is one flag choice in
> ssh_gssapi_init_ctx() and an #ifdef for GSS_C_DELEG_POLICY_FLAG,
> which is not defined on every GSSAPI implementation. Client side
> only; sshd and the monitor are unchanged, including sshd's new
> same named accept side option. Existing yes/no semantics and the
> default are untouched; policy is strictly opt-in.
> 
> Where the macro is missing at build time, policy would degrade to
> requesting no delegation (or reject at parse; no strong preference);
> a library that predates RFC 5896 ignores the unknown bit, which is
> also no delegation. Under policy no build or library combination
> delegates unconditionally. Since non-delegation becomes a normal
> outcome under policy, the patch would check ret_flags after the
> final gss_init_sec_context() and log at verbose whether credentials
> were delegated.
> 
> MIT and Heimdal both have enforce_ok_as_delegate in krb5.conf, but
> that knob is [libdefaults] only: it demotes GSS_C_DELEG_FLAG for
> every GSSAPI application, not just ssh, and it demotes even a
> deliberate yes, so delegating unconditionally to one legacy host
> while policy-gating everywhere else is not expressible with the
> existing knobs. Both manpages document the alternative: without the
> knob, the ticket flag is "only enforced when an application
> specifically requests enforcement". ssh cannot make that request
> today; the policy value is that request, made per destination with
> Host and Match, where ssh already keeps this kind of trust decision
> (ForwardAgent). curl has shipped the same tri-state for years
> (--delegation none/policy/always).
> 
> I found no prior proposal to honor OK-AS-DELEGATE and no mention of
> GSS_C_DELEG_POLICY_FLAG in the openssh-unix-dev archives or on
> bugzilla.mindrot.org.
> 
> Before writing a patch: is this something you would consider, and
> would you rather extend GSSAPIDelegateCredentials or add a separate
> keyword? I will go with whichever fits.

Unconditional delegation is typically blocked in Active Directory
environments between trusted forests already. It is also not secure in
itself, so following a KDC-derived policy would be a tiny bit better.
Since this is purely a client side feature, I'd say adding a tristate is
fine.

-- 
/ Alexander Bokovoy