Subject: Re: pkinit-20 checksum problem

From: Ken Raeburn <[email-masked]>
Date: Sun, 07 Nov 2004 21:54:03 -0500

Sam and I were talking about the checksum use in PKINIT the other day.
He suggested that in a future update to PKINIT that might actually
allow for some kind of negotiation of the checksum type, we could do
the specification of the checksum type differently, for example with
OIDs as I was suggesting.

All that would be required for now would be to specify (1) the
checksum field is marked as OPTIONAL in the ASN.1, and (2) the spec
should say that in the current rev of the protocol a KDC getting a
message with the checksum field missing must return a certain error
message.  In the next rev, an OID field can be added and the client
could perhaps be allowed to omit the current checksum field.  (With
some compatibility concerns obviously.)  The ASN.1 message containing
the checksum field already has an extension marker.

And, actually, we could probably go one step further, and say that for
the current rev of the protocol, SHA-1 is used, and the checksum type
number is filled in with 10, and then drop the SHA-1 unkeyed kcrypto
checksum type stuff, just keep the number reserved, kind of like the
way 0x8003 is reserved but not defined with a kcrypto profile.

The upshot of this right now would be (1) minor tweaks to the current
draft, (2) no changes to the protocol, (3) dropping my sha1 draft.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 10 Nov 2004 00:19:02 -0500

Some of us at IETF talked about this a little after lunch, and came up 
with the following proposal:

Section 3.2.1:

Change the paChecksum field of PKAuthenticator to an OCTET STRING.  
(Not discussed: Should it be OPTIONAL?  My guess would be yes, but then 
language has to be added to 3.2.2 saying that if the paChecksum field 
is omitted, the server must return a specific error.)

Section 3.2.3, KDC reply key derivation:

Change step 3 to drop "h" parameter to octetstring2key and explicitly 
invoke sha1; delete the last sentence.  Delete steps 4 and 5.  Renumber 
step 6 to 4, and drop the "H" argument to octetstring2key.

This puts off the hash algorithm negotiation to a future revision.
Unless we want to push forward on the negotiation and work out 
everything we need to incorporate, this time around....

Ken

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 12 Nov 2004 09:24:27 -0500

I am in favor of this proposal.

Ken Raeburn wrote:

> Change the paChecksum field of PKAuthenticator to an OCTET STRING.  (Not 
> discussed: Should it be OPTIONAL?  My guess would be yes, but then 
> language has to be added to 3.2.2 saying that if the paChecksum field is 
> omitted, the server must return a specific error.)

I belive the field should be optional and we must define an error
in case it is omitted.

> everything we need to incorporate, this time around....

I see no reason why we need to address the specific negotiation method
at this time.  We just need to ensure we place an extension marker at 
the appropriate location in the ASN.1.

Jeffrey Altman