krb5-1.8 fails to verify MS PAC Checksum when AES 256 is used causing sshd to fail

[Douglas E. Engert]

On 7/1/2010 9:25 AM, Luke Howard wrote:
> See attached, untested patch. This could be optimised by mapping the checksum type to an enctype (is there API for this?) and then calling krb5_kt_get_entry() rather than enumerating the keytab, but we still need to enumerate the keytab if server == NULL to handle aliases.
>

Thanks for the quick response of a patch. I applied the patch to 1.8 for testing
with some changes to replace the "for" with an if and while loop. See attached patch
with some additional debuging output added.

With the AD account entry attribute msDS-SupportedEncryptionTypes = 4 (RC4 only)
The first verify works.

With  msDS-SupportedEncryptionTypes = 16 (AES256) The first verify fails
as expected, and the keytab is searched, and each key is tried. But
the RC4 key (23) gets a KRB5KRB_AP_ERR_BAD_INTEGRITY as the compare
of the computed and supplied checksums don't match.

I know the keytab keys match AD as the keys work with ssh gssapi when the PAC
is not checked.

So there is still something going on here.

Looking at [MS-KILE] v20100601 and the [MS-PAC] v20100601 The KDC should be
not be using the -138 checksum type if only AES keys are listed as being supported.



Reading the blog again:
http://blogs.msdn.com/b/openspecification/archive/2010/01/01/verifying-the-server-signature-in-kerberos-privilege-account-certificate.aspx

It says:
> Per HMAC RFC 2104 (referenced by RFC 4757), B=64 bytes is used for the padding
> for both MD5 and SHA1. The key can be of any length up to B, the block length of
> the hash function. Since the AES256 key length is 256 bits (32 bytes), the key
> material will not be truncated but appended with 32 bytes of zeroes; for AES128
> the padding would have been 48 bytes of zeros.

So this sounds like it using the padded AES key, and not an RC4 key as would
be expected if the checksum type = -138.  Or am I reading this wrong?

Attached is the updated patch with debugging for pac.c, and some more
output showing the test the modified patch.

Any one from Microsoft on the list wish to comment?



> -- Luke
>
>
>
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: updated.pac.patch.txt
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20100701/b8de4770/attachment.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gdb.pac.txt
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20100701/b8de4770/attachment-0001.txt