[krbdev.mit.edu #8033] Need better diagnostics for S4U2Proxy impersonator name mismatch

[Greg Hudson via RT]

An intermediate service can perform S4U2Proxy by acquiring a GSS_C_BOTH 
acceptor credential, receiving a service ticket with 
gss_accept_sec_context, and then calling gss_init_sec_context with the 
resulting delegated credential.  gss_accept_sec_context creates the 
delegated credential by copying the intermediate service's ccache into a 
MEMORY ccache and adding the service ticket.

When the service ticket is accepted in gss_accept_sec_context, it is 
decrypted by treating each eligible keytab key in turn; the name of the 
matching key is then placed in ticket->server because that field is not 
trustworthy on the wire (nothing protects it) and it might be an alias 
anyway.

If the client name in the ccache does not match this name, the 
application gets back a GSS_S_FAILURE/KRB5_CC_NOTFOUND error from 
gss_init_sec_context with no extended message.  This error originates 
from krb5_cc_retrieve_cred as called by 
init_sec_context.c:get_credentials.

We can detect this problem earlier, in accept_sec_context, although it is 
not clear whether it is appropriate to fail out at that point.  It is 
likely that we can make S4U2Proxy work if the mismatch occurs because the 
keytab and ccache used two different names for the same principal (due to 
case mismatch or an alias).  If we cannot make it work, we should 
generate a more helpful diagnostic.

http://mailman.mit.edu/pipermail/kerberos/2014-October/020301.html is an 
example of this coming up in practice.  It has come up at least once 
before as well.