[15954] in Kerberos_V5_Development
Re: krb5-1.8 fails to verify MS PAC Checksum when AES 256 is used
daemon@ATHENA.MIT.EDU (Tom Yu)
Thu Jul 1 16:58:56 2010
To: "Douglas E. Engert" <deengert@anl.gov>
From: Tom Yu <tlyu@mit.edu>
Date: Thu, 01 Jul 2010 16:58:50 -0400
In-Reply-To: <4C2CFA81.5090804@anl.gov> (Douglas E. Engert's message of "Thu,
01 Jul 2010 15:28:49 -0500")
Message-ID: <ldvvd8yx6k5.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
"Douglas E. Engert" <deengert@anl.gov> writes:
> 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.
Didn't Richard Silverman recently see something like this behavior?
I think we haven't been able to track it down yet.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
