Subject: RE: pkinit and dh->key

From: Medvinsky Alexander-MGI1174 <[email-masked]>
Date: Fri, 23 Jan 2004 19:07:31 -0800

Sorry for the delay on my action item.  I believe that I am clear on what Sam Hartman is proposing:

	1) Take the first N bytes of the Diffie-Hellman secret, where N is the "key generation seed length" parameter for a particular etype.
	2) Generate a protocol key from the seed using random-to-key function for that etype.
	3) Generate encryption/checksum keys from the protocol key using a key derivation function for that etype.  The only key usage I found that applies to PKINIT is 3 (AS-REP encrypted part).

I don't have a problem with this approach, but I am not sure that the working group has reached consensus on it.  Joel previously commented that in order to get better entropy the whole Diffie-Hellman secret should be used during key derivation, as is done by some other standards.

Ken Raeburn suggested that in order to hash the whole DH secret, the PBKDF2 key derivation function could be used, as it is defined by PKCS#5.  This function has the following parameters: PBKDF2 (password, salt, iteration-count, desired output length).  As Ken proposed, it appears that the salt is not needed here (can be set to empty string) and iteration-count can be 1.  

PBKDF2 is calculated as concatenation of HMAC-SHA1(password, 00000001) || HMAC-SHA1(password, 00000002) ... Until there are enough bits generated.  The result is truncated to the desired output length.  One issue with this approach is that it would require the use of the HMAC-SHA1 function regardless of which etype had been selected.

So an alternative approach for PKINIT DH key derivation would be:

	1) Compute PBKDF2(DH-secret, "", 1, N), where N is again the "key generation seed length".
	2) Generate a protocol key by applying random-to-key function to the result of step 1.
	3) Generate encryption/checksum keys from the protocol key using a key derivation function for that etype.

I understand that Sam Hartman strongly prefers approach #1.  Does anyone still object to that approach?

Sasha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Thursday, January 08, 2004 5:18 PM
To: [email-masked]
Subject: Re: pkinit and dh->key

On Thursday, January 08, 2004 15:54:31 -0500 Sam Hartman <[email-masked]> 
wrote:

> We're approaching the point at which we wanted to have a final pkinit 
> draft.  I think the issue of how to handle getting from a DH value to 
> a key is still open.  What do we need to do to close that issue?

That was not on my open issues list, but it is now.  My open-issues list 
currently looks something like this:

OPEN ISSUES:
-- specify subjectAltName for user cert
   [tlyu, jaltman, editor; update at ietf58 meeting]

-- refactoring preauth
   [Sam Hartman; status update at ietf58 meeting]

-- Confirm alignment with kcrypto
   [Sasha Medvinsky; commented on list; ping again 19-Nov-2003]

-- Confirm alignment with kerberos-clarifications
   [Nico Williams; 20-Dec-2003]

-- How to transform DH shared secret into a key
   [???]

-- Update PA types
   [Cliff Neuman + editor; last]

CLOSED ISSUES:
++ REMOVE use of raw public keys [editor]
++ REMOVE name transformation [editor]
++ REMOVE principal name as trusted-CA [editor] Internationalization of 
++ strings [Jeff Altman] Extensibility [Jeff Hutzelman]
++ Confirm alignment with CMS [Todd Stecher/Microsoft]
++ initial flag issue [initial flag SET for pkinit; confirmed on list]
++ transited CA's AUTH-DATA [bcn, Nico Williams]
++ OCSP and optional revocation information [JK]
++ Security of cached DH values and use of a nonce [JK]