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

"KAMADA Ken'ichi" <[email protected]> Fri, 18 Feb 2005 12:55:46 +0900
Newsgroups gmane.ietf.kink
Message-ID <20050218125546RO%[email protected]>
At Thu, 17 Feb 2005 20:10:25 -0500,
Sam Hartman <[email protected]> wrote:
> 
>     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.

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.

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