Confusion about delegation

[Greg Hudson]

On 1/31/19 1:32 PM, John Byrne wrote:
> The client_ctx.step() call returns this error: gssapi.raw.misc.GSSError:
> Major (851968): Unspecified GSS failure.  Minor code may provide more
> information, Minor (2529639053): Matching credential not found

This is a bad error message, and we have an open ticket noting the need
to improve it:

  http://krbdev.mit.edu/rt/Ticket/Display.html?id=8586

Because you haven't set the ok_to_auth_as_delegate bit on
HTTP/www.example.com, the KDC issues a non-forwardable service ticket in
the creds.impersonate() step.  The GSSAPI layer stores this as a regular
cred object containing a user -> HTTP/www.example.com service ticket,
not an impersonator cred.  Such a credential can be interrogated for
name attributes to get PAC information (if it came from a KDC supporting
PACs) or to authenticate to the intermediate service itself, but it
can't be used to authenticate to any other service.

When gss_init_sec_context() tries to authenticate with this credential,
it can't find either a client -> target or client -> krbtgt/REALM
credential, so it fails with the uninformative error message.

Release 1.16 added the ability to query a credential for whether it is
an impersonator credential, as noted in the documentation page you
referenced.

> I've made sure that the target_name principal is in the default keytab

Only the target service should have a target_name keytab entry.  Giving
out that keytab to other parties poses a security issue, allowing those
parties to impersonate (in the attacker sense, not the S4U2Proxy sense)
the target service.

> The surprising thing is that if I initialize the context with the other
> name instead (HTTP/www.example.com), then this code works perfectly, and
> authenticates me as 'kerbtestjohn' to www.datastore.com.

I would expect this to authenticate from kerbtestjohn to
HTTP/www.example.com.  How would it authenticate to www.datastore.com if
you didn't ask gss_init_sec_context() to do so?

> Even stranger, if I omit the proxy_creds from the
> SecurityContext, then it also works, using either of the 2 service names.
> So I can impersonate users without the proxy creds!? Shouldn't that be
> rejected?

If you omit proxy_creds, then it should authenticate from whatever
client is in the default ccache (probably HTTP/www.example.com) to the
target service.  It shouldn't authenticate as krbtestjohn.