Subject: Key reuse and the PRF in draft-ietf-krb-wg-crypto-xx

From: [email-masked] (Sam Hartman)
Date: Mon, 26 Jul 2004 17:52:48 -0400 (EDT)

The Kerberos crypto framework introduces a PRF to be used in various
key setup operations for things like pkinit and DH authentication.
The PRF is not ever used by the crypto draft itself nor by the base
Kerberos specification.  However it seems that the PRF will be needed
by several protocols under discussion in the Kerberos working group.
That's why it was added.

Modern Kerberos crypto systems try to take a base protocol key and
derive usage-specific keys from this protocol key.  That way, the key
used to encrypt some object will not be the same key used to encrypt
objects of a different type.

The specification of the prf in section 5.3 of
draft-ietf-krb-wg-crypto uses the raw protocol key not some derived
key:

			  PRF = E(protocol-key, tmp2,
			  initial-cipher-state)

This is clearly a valid prf.  However, it exposes ciphertexts
encrypted directly in the protocol key.  It's probably OK to do so
provided that the protocol keys used with the prf are only used for
key derivation.

But this seems like sloppy cryptographic practice.  It's also
incredibly easy to fix at a specification level:

			  PRF = E(dk(protocol-key, prfconstant), tmp2,
			  initial-cipher-state)

prfconstant is some constant that meets the constraints discussed in
section 5.1 and that we decide on.

I think we have reasonably high confidence that no current protocols
are using this prf yet and that no one has deployed an implementation
of the prf.

I think Ken and I would like to see this changed made.  It would of
course require IESG approval.  The down side of making the change is
that if someone has deployed the current version of the PRF then we
make things complicated for them.  If someone outside the IETF has
written a protocol specification that depends on the old PRF, then we
make things inconvenient for everyone because anyone wanting to
implement that protocol specification would have to code both versions
of the prf.

I'd like feedback from the working group on whether this change is
worth making.  I'd also like to ask Russ how importan he believes
fixing direct use of protocol keys is in this instance.

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 27 Jul 2004 10:23:09 -0400

>are using this prf yet and that no one has deployed an implementation

Just as a FYI ... the hardware-preauth draft specifics the use of the
prf for non-DES/3DES enctypes, but AFAIK no one has deployed this yet.

--Ken

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Jul 2004 11:04:06 -0400

>>>>> "Ken" == Ken Hornstein <[email-masked]> writes:

    >> I think we have reasonably high confidence that no current
    >> protocols are using this prf yet and that no one has deployed
    >> an implementation of the prf.

    Ken> Just as a FYI ... the hardware-preauth draft specifics the
    Ken> use of the prf for non-DES/3DES enctypes, but AFAIK no one
    Ken> has deployed this yet.

O, cool, I knew you were going to do that but had no idea you had ever
gotten around to implementing.

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 27 Jul 2004 11:09:29 -0400

>gotten around to implementing.

It's been on my list to implement, but I haven't done so just yet.  So
it shouldn't matter if the prf changes.

--Ken