Re: [IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE
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
[IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE
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
[IPsec] Suggested solution to Roadmap Issue #113: Use of AES-XCBC in IKE
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? 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. 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. 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]. NOTE: This solution would require adding an IANA value to the iana-ipsec-registry for AES-XCBC-PRF-128 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
