Ticket History #8139: SIGNTICKET creation and verification doesn't always use the right key

The KDC code to generate and verify AD-SIGNTICKET checksums uses the
krbtgt_key parameter of handle_authdata(). For AS requests this is
the server key chosen by the KDC to encrypt the issued ticket; for
TGS requests this is the server key which was used to decrypt the
header ticket. Neither key necessarily corresponds to a krbtgt
principal.

Here are some scenarios where this won't work:

* A client makes an AS request for a server principal (not a TGT) and
authenticates to that service. The service makes an S4U2Proxy
request, presenting the client's ticket as an evidence ticket. The
checksum will have been created with the service ticket's key, but
will be verified using the krbtgt key for the service's TGT, so
verification will spuriously fail.

* A service gets a TGT when the krbtgt kvno is 1. The krbtgt key is
then rotated, so the current kvno is 2. A client gets a TGT, then
gets a ticket for the service, then authenticates to the service.
The services makes an S4U2Proxy request presenting the client's
ticket as an evidence ticket. The checksum will have been created
using krbtgt kvno 2, but will be verified using krbtgt kvno 1, so
verification will spuriously fail.

* A service prints a ticket to itself containing AD-SIGNTICKET data,
signed using the service's own key. The service makes a ticket
modification request to the KDC, presenting that ticket in the
header. The KDC will verify the checksum using the service's key,
erroneously succeeding. There is no attack here because a ticket
modification request must result in a ticket to the same service as
the header ticket server, and the KDC won't sign the AD-SIGNEDPATH in
the resulting ticket with the krbtgt key because it never loads the
krbtgt principal. But it still represents a failure of the KDC to
correctly evaluate the significance of the AD-SIGNTICKET checksum.

To behave correctly, the KDC needs to load the local TGT principal
when the AS server or TGS header ticket server principal is not the
local TGT. For verification, the KDC may need to try several
different krbtgt key versions, as there is no kvno in the authdata
element.

Add tests for AD-SIGNTICKET corner cases

Test situations where the previous AD-SIGNTICKET logic would not use
the same key to create and verify the AD-SIGNTICKET data. Also test a
case which forces the new verification logic to try multiple krbtgt
versions.

https://github.com/krb5/krb5/commit/1f2060ee1793f1acea81acefa6a8b1e0da4203ce
Author: Greg Hudson <ghudson@mit.edu>
Commit: 1f2060ee1793f1acea81acefa6a8b1e0da4203ce
Branch: master
src/tests/gssapi/t_s4u.py | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)

Another manifestation of this bug is described in:

http://mailman.mit.edu/pipermail/kerberos/2016-August/021342.html

Briefly, acquire a credential, re-key the TGT with a different first
enctype, acquire a forwarded TGT with the existing credentials, then try to
make a TGS request with the new TGT. Because the authdata in the new TGT
is checksummed with the old TGT key, verify_ad_signedpath_checksum()
receives a bad-enctype error code from krb5_c_verify_checksum() (not a 0
result with valid set to FALSE, as it would get if the checksum were
incorrect but of a valid checksum type for the key). So the whole TGS
operation fails out.