Implementing RBCD

[Isaac Boukris]

On Tue, Mar 26, 2019 at 5:46 PM Greg Hudson <ghudson at mit.edu> wrote:
>
> Right, this is tricky, because we are used to being able to do
> S4U2Self->S4U2Proxy with only a ccache containing the intermediate
> service's TGT.  (Interestingly, kvno -P requires a keytab argument,
> which it uses to get the client name.  I'm not sure this is necessary,
> since the client learns the name during S4U2Self and reports it to the
> caller.)

Technically, kvno also needs the keytab because
krb5_get_credentials_for_proxy() expects the ticket to be already
decrypted in order to check the forwardable flag and (perhaps it was
designed for accept() flow).
If we end up not requiring the forwardable flag, then we can relax
this expectation and subsequently remove the requirement for a keytab
in kvno (though we may still want to know if it was forwardable in
case we want to conditionally check rbcd support in s4u2proxy reply's
encrypted padata as suggested).

> I think the simplest answer is to remove the forwardable check and
> always generate proxy credentials, letting the KDC decide if the
> evidence ticket is valid.  That way unmodified applications will work
> with RBKCD.  (Applications have to be prepared for the possibility that
> S4U2Proxy fails, since there are permissions on who can
> constrained-delegate to what targets.  So adding a case where S4U2Proxy
> fails because the evidence ticket isn't valid shouldn't break anything.)

Yea, in a way it even simplifies caller's expectations. It is also the
simplest to implement, so I'll start with this.

> It seems potentially useful to make gss_impersonate() decrypt the ticket
> if impersonator_cred_handle is GSS_C_BOTH, if only to set name
> attributes based on the ticket's authorization data.  This could be done
> with init/accept as you suggest, or with
> krb5_server_decrypt_ticket_keytab().  At that point we have enough
> information to definitively determine whether the ticket is valid for
> S4U2Proxy.

I see the point in setting name attributes in gss_impersonate(), and
saving the application the need for an extra init/accept, but if we
relax forwardable requirements then I would prefer to defer this,
along with PAC decoding to later, as a separate task.

> If impersonator_cred_handle is GSS_C_INITIATE, we could still try to
> decrypt the ticket using the default keytab, and be prepared for
> failure.  I can't decide whether this would violate the principle of
> least surprise.

I thought that GSS_C_ACCEPT would be needed to access default keytab,
same as we require GSS_C_INITIATE in gss_accept() in order to access
the ccache when we need to create proxy credentials. But I'm not clear
on these concepts.

> At any rate, if we can't decrypt the ticket internally, I think the
> right answer is to assume that the ticket is valid for S4U2Proxy, since
> just looking at the forwardable flag isn't sufficient any more.

Same here. I don't get what security purpose it serves for the
intermediate service to check for client sensitivity, since the KDC
who'd decode the second ticket can and must check it anyway. If
anything I think this check better fits later on, when the proxy
accepts the final ticket (we could add that too).