Subject: Diffie-Hellman key derivation for PKINIT

From: Medvinsky Alexander-MGI1174 <[email-masked]>
Date: Wed, 22 Oct 2003 22:55:19 -0700

Brian,

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:

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.

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

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

    [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.

Section 3.2.1
-------------------
OLD TEXT that is to be deleted:
    If cached parameters are used, the client and the KDC MUST perform
    key derivation (for the appropriate cryptosystem) on the
    resulting encryption key, as specified in RFC 1510bis.

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.

Sasha.

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 23 Oct 2003 06:21:15 -0400

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.

Reasonable.

>     Appropriate key constraints for each valid cryptosystem are given

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: "Joel N. Weber II" <[email-masked]>
Date: Thu, 23 Oct 2003 14:33:27 -0400

>	   * Truncate the bit string to the required length.

As I've said previously, I'm concerned about whether there may be
security problems with this.  Every existing widely deployed, well
analyzed protocol I know of hashes the entire bit string; certainly
SSHv2 does, and I'm pretty sure TLS and IPsec use a hash rather than
truncation as well.

If nobody can cite a source in which a cryptographer says that the
hashing is unnecessary and truncation is perfectly secure, then I
think we ought to imitate the existing, widely-deployed, well-analyzed
protocols.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 13:18:13 -0500

>>>>> "Joel" == Joel N Weber <[email-masked]> writes:

    >> * Truncate the bit string to the required length.
    Joel> As I've said previously, I'm concerned about whether there
    Joel> may be security problems with this.  Every existing widely
    Joel> deployed, well analyzed protocol I know of hashes the entire
    Joel> bit string; certainly SSHv2 does, and I'm pretty sure TLS
    Joel> and IPsec use a hash rather than truncation as well.

This comment is not appropriate in this context.  It seems that your
concern is with the crypto draft, not with how it is used in this
instance.  If you believe you have a security concern against that
draft, you should bring it to the IESG as that draft has already
concluded both the working group last call and the IETF last call.

I don't believe your proposed change is a good idea because it
involves depending on a specific hash rather than just on the crypto
system.