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]>