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

[Douglas E. Engert]

With Ubuntu Lucid, and AD 2008 as KDC, a service ticket can
be issued using AES 256, but the PAC server Checksum can be
using RC4.

sshd would then get a "Bad encryption type" message and fail.

This appears to be the situation as outlined in Example 2 in this blog:

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

Using a version of MIT 1.8 of gss-client and gss-server, I can reproduce this
problem on a Solaris 10 system, and indeed the service key enctype is 18 for
  AES 256, and the checksum type is CHECKSUM_TYPE_HMAC_MD5_ARCFOUR
See attached gdb output.

Any ideas on how to fix this for the long term, where AES is used and
a system may want to use the PAC?

For a system like Windows that stores the password and generates keys on
the fly this in not a big deal. For systems where keys are stored
separately this is a big deal, as it means you need to have two keys
to verify the PAC.

In my situation the PAC is not needed, so a circumvention is to
use the NO_AUTH_DATA_REQUIRED bit:  http://support.microsoft.com/kb/832572
or not use AES, or as the blog suggests, if the msDS-SupportedEncryptionTypes
does not include RC4, it might use AES. (I have not tried this, yet
as RC4 is still the common enctype available on all our systems.)

The Solaris 10 provided Kerberos can use AES and does not have this problem,
as I don't think it is checking the PAC...


-- 

  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: cs.txt
Url: http://mailman.mit.edu/pipermail/krbdev/attachments/20100630/978f0025/attachment.txt