Subject: Re: pkinit-20 checksum problem

From: Ken Raeburn <[email-masked]>
Date: Tue, 19 Oct 2004 20:04:32 -0400

As I agreed with Jeff to do, I've submitted a draft that specifies an
unkeyed sha1 checksum type, assigns checksum type number 14 to it, and
releases checksum type number 10 for future assignment.  (Though I
think the releasing of a number is totally unsupported by the IANA
guidelines we put together...maybe it'll just have to be "reserved"?)

Working on it, I found myself thinking that maybe it's the wrong
direction.

Any general use of Kerberos checksums must indicate the key and key
usage value to be used.  Put another way, the "unkeyed" algorithms
*do* have key and key-usage input parameters, they're just ignored.
And, to be picky, the key-usage value could still be incorporated into
a Kerberos checksum that ignores the supplied key, and I think it
would still have to be considered "unkeyed".

An explicitly unkeyed use like in PKINIT is an attempt to borrow a
data type from Kerberos to wrap up a message digest and an algorithm
identifier together, with no real relationship to checksums as used in
Kerberos.

I wonder, then, if perhaps PKAuthenticator, buried inside a CMS
SignedData field, should have two fields using existing CMS types:

    paDigestType  [3] DigestAlgorithmIdentifier,
    paDigest      [4] Digest

(RFC 2630 doesn't seem to include a message type with a digest but
omitting the message itself.)

This seem more suited to the intended use and the CMS-oriented context
than the Kerberos types, and the SHA-1 algorithm identifier is already
in RFC 2630.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Wed, 20 Oct 2004 10:09:54 -0400

I tend to agree with Ken that pkinit should not be using a Kerberos
checksum for the pkauthenticator.  I tend to agree with Ken and Jeff
that adding hash functions to kcrypto would be a bad idea.  Note I
believe this is true both in the current kcrypto and in any future
revision we do in the short term.

I also agree with Larry that it is too late in the game to fix pkinit
or at least I hope pkinit is close enough that it is too late to fix.
Let's agree that if we can get all the issues in pkinit resolved by
some deadline that is very close--say end of year--that we will wave
our hands vaguely and accept that at least for now pkinit uses a
Kerberos checksum even though it makes no sense to do so.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 20 Oct 2004 10:56:22 -0500

> Kerberos checksum even though it makes no sense to do so.

Worse hacks have been done before.  This is not an entirely terrible
hack -- we'd be pretending that the simplified kcrypto profiles export a
"checksum" function that is suitable for use in randomstring2key() so we
can be "compliant" with a recent BCP.  In all cases such a checksum
function is available (except in the des-cbc-crc case, which we may
happily ignore as aes-cts-sha-1 is REQUIRED).

Remind me again though, why we can't build a randomstring2key() on
string2key(base64()) or why we can't build a dhkey2key() using the
kcrypto prf() as a building block?  (In the case of the former we'd not
be following the BCP, but is that so bad?  In the case of the latter I
think, but don't know for sure, that such a thing can be constructed
such that it is secure even if we assume structure in dh secret but also
enough overall entropy.)

Nico
--