Frankel, Sheila E. writes: > This is an initial attempt to resolve Issue #113. We would > appreciate comments/suggestions/alternate approaches. > > #113: Use of AES-XCBC in IKE > > Currently, the Req levels are SHOULD for IKEv1 (based on RFC4109) > and optional for IKEv2. The Req levels for AES-XCBC-PRF are SHOULD > (based on RFC4109) and SHOULD+ for IKEv2 (RFC4307) > > This leaves us with 2 questions: > 1) If there is no IANA value for AES-XCBC in IKEv1, how can RFC4109 > recommend (SHOULD) its use? > 2) If AES-XCBC and AES-XCBC-PRF can be used in IKEv1, what should > be proposed? What should you propose if you want AES-XCBC for both > a PRF and an integrity-protection algorithm in IKEv1?
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. As nobody has yet to noticed that there is no number of AES-XCBC PRF for IKEv1, I assume nobody has implemented it. If it has not been implemented, then I do not think vendors will add implementation of it to the obsoleted IKEv1 protocol, thus there will never be implementations for it. Usually the hash/mac functions used to protect IKEv1 SA do not matter that much to users, they only care what algorithms are used in the IPsec SAs. Currently AES-XCBC-MAC-96 can be used in those contexts fine both in IKEv1 and IKEv2, thus there is no problem there. There is no need to get AES-XCBC PRF to work when protecting IKEv1 SAs. > 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. > 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.. > 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
