Subject: #25 [**] prf (section 8)

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Thu, 10 Feb 2005 16:14:43 +0900

At Fri, 28 Jan 2005 21:19:39 -0500 (EST),
Sam Hartman <[email-masked]> wrote:
> 
> Section 6.1:
> 
>    o    IKE Quick Mode (phase 2) uses the hash algorithm used in main
>         mode (phase 1) to generate the keying material. KINK MUST use
>         the hashing algorithm specified in the session ticket's etype.
> 
> [**] This checksum may not be deterministic and is probably not
> appropriate for use in setting up a key.  A PRF is provided, although
> depending on how the hash is used the PRF may or may not be a suitable
> replacement.  There has been significant discussion within krb-wg on
> when the PRF is appropriate and when it is not.  This discussion
> centered around key determination in pkinit.

IKE requires the very PRF to generate IPsec keys, so using PRFs
provided by kcrypto is appropriate here.
kcrypto also says "The PRF output string should be suitable for use
in key generation,..."

Does anyone object to using the kcrypto PRF?

-- 
KAMADA Ken'ichi <[email-masked]>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Feb 2005 20:10:25 -0500

>>>>> "KAMADA" == KAMADA Ken'ichi <[email-masked]> writes:

    KAMADA> IKE requires the very PRF to generate IPsec keys, so using
    KAMADA> PRFs provided by kcrypto is appropriate here.  kcrypto
    KAMADA> also says "The PRF output string should be suitable for
    KAMADA> use in key generation,..."

The kcrypto PNRF is certainly usable for generating keys; that's its
point.  The working group was concerned about the PRF for kcrypto
mainly because they needed to take a DH output and get a random bit
string.  The kcrypto PRF requires a key.

The only problem I can see with using the kcrypto PRF in kink is
details of the PFS if Kink ends up supporting PFS.  If you don't ever
run into a situation where you want to use the PRF but there is no
appropriate key to feed into it, then everything is fine.

--Sam

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Fri, 18 Feb 2005 12:55:46 +0900

At Thu, 17 Feb 2005 20:10:25 -0500,
> appropriate key to feed into it, then everything is fine.

I'm now clear on the issue you raised.
On that regard, KINK uses a DH output in the octet-string of the PRF.
The protocol-key of the PRF is always a key provided in the AP
exchange, so I think there is no situation you concerns.

I skimmed the recent ietf-krb-wg ML and found some issues discussed.
I think KINK has no problem with them.

1. PRF needs a key as its input.
	In KINK, there is a key even when taking PFS.
	(as described above)

2. Is kcrypto PRF cryptographically strong?
	This is kcrypto issue, and the answer seems to be "yes"
	according to the ietf-krb-wg ML.

3. The output size of PRF is not the same with the key (nor the seed).
	Yes, it is the way of PRF and KINK doesn't have any
	problem with it.