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

[Avinash Duduskar]

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.

Thanks,
Avi