Implementing RBCD

[Greg Hudson]

On 3/24/19 2:28 PM, Isaac Boukris wrote:
> There is another issue, if we want to check for sensitivity however.
> To access the PAC we need to decrypt the ticket for-self, and for that
> we need the keytab with long term keys (possibly including other
> enc-types).

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.)

> In GSSAPI, if the ticket for-self was obtained via gss_accept() then
> we should be good, but if it is acquired via gss_impersonate(), it
> seems that at no point we decrypt the ticket, and I was able in fact
> to do constrained-delegation with an initiator TGT only by calling
> gss_impersonate() followed by init_sec_context().

We document that this works (in doc/appdev/gssapi.rst).  t_s4u.c does an
init/accept first; I had always thought this was to exercise more code
paths, but after looking at kvno and at what constrained_delegate() does
with its arguments, I think Luke was concerned about learning the client
name of the decrypted ticket.

> Maybe if gss_impersonate() was called using GSS_C_BOTH
> creds, then we could try to call gss_accept() internally as a shortcut
> and avoid the need of change in the caller application.

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.)

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.

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.

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.