<no hat> At 12:35 PM +0200 12/4/09, Tero Kivinen wrote: >I would say as we are talking here about the obsoleted IKEv1 protocol, >and these problems have already been solved in the IKEv2, there is no >need to do anything for IKEv1 registries.
Agree. >There is no need to get AES-XCBC PRF to work when protecting IKEv1 >SAs. Agree. > > Proposed change to Roadmap doc: >> >> Add text to Section 5.5 - Pseudo-Random Functions (PRFs): >> >> For each IKEv2 SA, the peers negotiate both a PRF algorithm and an >> integrity-protection algorithm; the former is used to generate keying >> material and other values, and the latter is used to provide protection >> to the IKE SA's traffic. >> >> IKEv1's approach is more complicated. IKEv1 [RFC2409] does not specify >> any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed >> hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function >> to generate keying material and to provide integrity protection for the >> IKE SA. > >Up to this it is fine. > >> If the peers want to use a PRF that is not an HMAC variant (e.g., >> AES-XCBC-PRF-128), they must negotiate both a PRF and a hash function. > >But I would remove all of these, and simply say that: > > Currently there is no PRF functions defined for IKEv1, thus only > PRFs which can be used are the HMAC versions of the unkeyed hash > functions. AES-XCBC-PRF-128 could be defined also in IKEv1, but as > there is no IANA number allocated for it, currently it cannot be > used in IKEv1. Partially agree. I would remove the proposed sentence and add nothing. There is no reason to go into detail about what we don't intend to do. > > If AES-XCBC-PRF-128 is the negotiated PRF, then IKEv1 would use > > AES-XCBC-PRF-128 (not truncated) as a PRF and AES-XCBC-MAC-96 (truncated) > > for integrity-protection. The negotiated hash algorithm would be used > > for example when generating the NAT-D [RFC3947] payloads. If an IKEv1 > > proposal includes a PRF algorithm but not a hash, it must be rejected, > > as specified in [RFC2409]. > >This text above, is something that should be in the RFC specifying the >PRF, not in this document, as it mostly seems to be clarification to >the RFC2409. I do not think this document can add this kind of almost >normative text for any other documents.. Very strongly agree. And the fact that it has not been asked for before now says that even thinking about it is unnecessary. > > NOTE: This solution would require adding an IANA value to the >> iana-ipsec-registry for AES-XCBC-PRF-128 > >If nobody has cared about using AES-XCBC-PRF-128 in protecting the >IKEv1 SA for 6 (or 11) years, I do not think people will start using >it now, thus I suggest we just say it cannot be used. A sentence that says "Therefore PRFs that are not HMACs cannot currently be used" sums up the current state of affairs succinctly --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
