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
