[krbdev.mit.edu #8958] Impersonating oneself (with S4U2Self) yields a confusing library error

[Greg Hudson via RT]

Mon Nov 02 11:53:29 2020: Request 8958 was acted upon.
 Transaction: Ticket created by ghudson at mit.edu
       Queue: krb5
     Subject: Impersonating oneself (with S4U2Self) yields a confusing library
 error
       Owner: Nobody
  Requestors: ghudson at mit.edu
      Status: new
 Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8958 >


If we run:

make testrealm
kvno -U user user

we see the error "kvno: KDC has no support for padata type while getting
credentials for user at KRBTEST.COM". As we can see in kdc.log, the KDC issued the
ticket, but the client incorrectly deduces that the KDC does not support
S4U2Self, because the same ticket is issued as the KDC would have issued
naturally without processing the S4U2Self padata. The client check is located
in krb5int_process_tgs_reply(), where it conditionally returns
KRB5KDC_ERR_PADATA_TYPE_NOSUPP. This check is described in [MS-SFU] 3.1.5.1.2.

This form of impersonation request should be rare; we only noticed the problem
due to a failing python-gssapi test (
https://github.com/pythongssapi/python-gssapi/issues/220 ). Still, the behavior
doesn't make sense.

Some plausible mitigations:

1. Improve the displayed error by adding an extended message. That wouldn't fix
the bug, and perhaps is not worth the additional code (since a KDC not
supporting S4U2Self is unlikely now and grows less likely with time).

2. Suppress the check if the requested client is the same as the header client.
This is unfortunately easier said than done as the code currently stands, since
krb5int_process_tgs_reply() would have to delve into the padata.

3. Suppress the check if PA_S4U_X509_USER padata is present in the reply. This
isn't comprehensive, as the older variant of S4U2Proxy (PA-FOR-USER) has no
response padata. Notably, current Heimdal only supports that older variant.

4. Detect the edge case before making the request, and return an error. The
risk here is that someone might have a legitimate need to impersonate a set of
clients which includes the requesting server, and we would be needlessly
maintaining an edge case that they have to handle.

5. Detect the edge case before making the request, and make a regular TGS
request instead. The risk here is that some aspect of the S4U2Self processing
might be important.