Fwd: [krbdev.mit.edu #4975] Checksum type 14 undefined

Marcus Watts mdw at umich.edu
Thu Dec 7 17:18:57 EST 2006

Tom Yu <tlyu at MIT.EDU> writes:
> To: "Kevin Coffman" <kwc at citi.umich.edu>
> Subject: Re: Fwd: [krbdev.mit.edu #4975] Checksum type 14 undefined
> From: Tom Yu <tlyu at MIT.EDU>
> Date: Thu, 07 Dec 2006 16:34:33 -0500
> Message-ID: <ldvhcw7tmom.fsf at cathode-dark-space.mit.edu>
> Lines: 15
> Cc: "krbdev at mit.edu" <krbdev at MIT.EDU>
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> Sender: krbdev-bounces at MIT.EDU
> Errors-To: krbdev-bounces at MIT.EDU
> >>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:
> Kevin> If the Windows 2003 KDC returns a pkinit reply with a checksum rather
> Kevin> than the insecure nonce, it uses checksum type 14.  This type is defined
> Kevin> in RFC3961, but not in the current code.  I'm assuming that
> Kevin> Vista/Longhorn will also use this checksum type.
> Kevin> If we hack the pkinit code to use checksum type 9 when we get back 14,
> Kevin> it works.  I do not know if a simple alias of type 9 is the correct answer.
> Does anyone depend on cksum type 9 being unkeyed SHA1?  I'm not sure
> whether RFC 3961's assignment precedes the use in our implementation
> or not.
> ---Tom

I've got code that knows 9 is unkeyed SHA1 with key usage 0x99,
but doesn't actually use it for anything.  I wound up using
CKSUMTYPE_RSA_MD5==7 because sha1 support didn't seem to be standardized
enough across implementations to be a dependable feature.
For instance, Heimdal apparently has CKSUMTYPE_RSA_MD5_DES3 == 9,
and uses CKSUMTYPE_SHA1 == 14.  shishi didn't have an unkeyed sha-1
type at all.
					-Marcus Watts

More information about the krbdev mailing list