Subject: RE: Diffie-Hellman key derivation for PKINIT

From: Medvinsky Alexander-MGI1174 <[email-masked]>
Date: Thu, 23 Oct 2003 11:13:48 -0700

The recommended approach with Diffie-Hellman is to include the whole Diffie-Hellman shared secret in the key derivation (the way that IPsec, TLS, etc. perform key derivation).  There is also RFC 2631 that defines key derivation for CMS which also takes as input the whole Diffie-Hellman shared secret.

I thought that the key derivation function DR(Key, Constant) in the crypto draft can take a variable-length (base) key, but it appears that the DR() function is based on a block cipher that has specific key length.

So maybe PKINIT could use the "pseudo-random function" you defined in the crypto draft to take the whole Diffie-Hellman shared secret as input and output the "base key" that goes into the DR(Key, Constant) function for key derivation?  The crypto draft defines:

pseudo-random function    tmp1 = H(octet-string)
                          tmp2 = truncate tmp1 to multiple of m
                          PRF = E(protocol-key, tmp2, initial-cipher-state)

The protocol-key could be the first part of the Diffie-Hellman secret with parity bits inserted using random-to-key function.  The "octet-string" would be the rest of the Diffie-Hellman secret.  The output of the pseudo-random function would be the "base key" that goes into DR(Key, Constant) (or directly into random-to-key function if key derivation is the identity for some crypto systems).

Sasha.

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 3:21 AM
To: Medvinsky Alexander-MGI1174
Cc: [email-masked]; [email-masked]
Subject: Re: Diffie-Hellman key derivation for PKINIT

Medvinsky Alexander-MGI1174 <[email-masked]> writes:
> This was my action item from the KRB WG interim meeting.  Here are my
> exact proposed changes to the PKINIT draft for Diffie-Hellman key
> derivation:

My notes from the interim meeting were pretty vague in this area.
Please pardon me if I've forgotten some of the issues we discussed.

> Section 3.1.1.
> -------------------
> OLD TEXT: 
>     In the case of Diffie-Hellman, the key is produced from the agreed
>     bit string as follows:
>
>         * Truncate the bit string to the required length.
>         * Apply the specific cryptosystem's random-to-key function.

Reasonable.

>     Appropriate key constraints for each valid cryptosystem are given
>     in RFC 1510bis.

Not sure what this was about; any such constraints on keys should be
dealt with by the random-to-key function.

> NEW TEXT:
>     In the case of Diffie-Hellman, when a crypto system is selected
> with key derivation (as defined by [crypto draft reference]),

Why do you want to distinguish cases where the key derivation step is
the identity function from cases where it is not?

>    the base
> key used in the key derivation is the agreed bit string that is the
> result of the Diffie-Hellman key agreement.  (Key derivation function

No, random-to-key is the right way to generate the key.  Your proposed
wording means that for triple-DES, we would chop the bit string down
to 192 bits and use it as the key.  That'll get the parity bits wrong
almost all the time.

> defined by [crypto draft reference] generates keys of an appropriate
> size for the selected etype or checksum type, regardless of the size
> of the base key.)

The base key is used to encrypt a value computed using n-fold on the
key usage value plus an additional octet.  It has to be the correct
size, and it has to be in the correct format.  Use random-to-key to
generate it.

>     [crypto draft reference] also defines crypto systems where the key
> derivation function is replaced by an identity operation.  In those
> cases, the bit string generated from the Diffie-Hellman key agreement
> must be truncated to the size that is required by that specific crypto
> system.  The random-to-key function for the specific crypto system is
> then applied to the truncated shared bit string, in order to produce
> the final key for that crypto system.

This is okay, except that it shouldn't be specific to cases where the
identity function is used.

> In addition to these proposed changes to the PKINIT draft, PacketCable
> implementations currently use DES3-CBC-MD5 etype that was at one time
> defined in the Kerberos revisions draft (although the definition was
> not fully specified).  Since the crypto draft already contains legacy
> etypes and checksum types that use identity function for key
> derivation, is it possible to add back in the DES3-CBC-MD5 etype with
> maybe language that it is a legacy crypto system and a strong
> recommendation to use the 3DES etype with key derivation?  The same
> question applies to the RSA-MD5-DES3 checksum type that at one time
> was defined in Kerberos revisions.

I'd rather not add more cryptosystems to the document, unless we're
going to be promoting their use in general implementations.  RC4 isn't
going in, either, and it's probably closer to having a complete
specification.  Adding more to the crypto draft would pull it back to
the working group, delay its publication further, and delay the
documents depending on it.  There's no reason they can't be published
in separate documents.

Ken

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 23 Oct 2003 18:54:51 -0400

Medvinsky Alexander-MGI1174 <[email-masked]> writes:

> The recommended approach with Diffie-Hellman is to include the whole
> Diffie-Hellman shared secret in the key derivation (the way that
> IPsec, TLS, etc. perform key derivation).  There is also RFC 2631 that
> defines key derivation for CMS which also takes as input the whole
> Diffie-Hellman shared secret.

Hm, yes.  You could hash the bit string, as Joel suggested, possibly
multiple times if more bits are required than the output of one run of
the hash function.  Or you could use n-fold, which can generate larger
as well as smaller output, though the entropy mixing is weaker.

Something like PBKDF2 would do a good job, and would be present in a
Kerberos AES implementation that accepts passwords anyways.  It may
seem like overkill, but if we set the iteration count at 1, the salt
string as empty, the pass phrase as the Diffie-Hellman bit string and
the PRF as a SHA-1 HMAC, it becomes relatively simple:

	F (X, n) = HMAC-SHA1 (key=X, text=n as 4 octets MSB-first)

	T_1 = F (DH, 1) (= HMAC-SHA1 (key=DH, text=00 00 00 01))
	T_2 = F (DH, 2)
	...
	T_l = F (DH, l)

	tmp = T_1 || T_2 || ... || T_l<0..n>
        key = random-to-key (tmp)

If the needed bits are no more than 160, it's a single HMAC.  For
AES-256 or 3DES, it's two HMACs.

The DH bit string can be of arbitrary length (though if it's too long,
the HMAC spec says it gets hashed first), and large amounts of
random-to-key data can be generated.

> So maybe PKINIT could use the "pseudo-random function" you defined in
> the crypto draft to take the whole Diffie-Hellman shared secret as
> input and output the "base key" that goes into the DR(Key, Constant)
> function for key derivation?  The crypto draft defines:
>
> The protocol-key could be the first part of the Diffie-Hellman secret
> with parity bits inserted using random-to-key function.  The

The PRF is going to be dependent on good key generation, so if
truncation isn't good enough for the base key, I don't know if it
would be good enough for such an intermediate key either.

> "octet-string" would be the rest of the Diffie-Hellman secret.  The
> output of the pseudo-random function would be the "base key" that goes
> into DR(Key, Constant) (or directly into random-to-key function if key
> derivation is the identity for some crypto systems).

And still you want to distinguish these two kinds of cryptosystems?
Why?

Ken