| To: | rt@krbdev.mit.edu |
| From: | ghudson@mit.edu |
| Date: | Mon, 02 Nov 2020 11:53:29 -0500 |
| Subject: | Impersonating oneself (with S4U2Self) yields a confusing library error |
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@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.
make testrealm
kvno -U user user
we see the error "kvno: KDC has no support for padata type while getting credentials for user@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.