On 1 July 2005 the IESG received a request from Paul Hoffman to consider publication of draft-hoffman-rfc3664bis-03 as a standards-track RFC. Updates were made based on IETF Last Call comments, the -04 version of the document was discussed during the telechat of 1 September 2005. The document was approved, and it is now in the RFC Editor queue. On 29 September 2005, Paul Hoffman asked the IESG to rescind approval of the document due to an implementation issue that was discovered at the IKEv2 bake-off. A summary of the problem is: In IKEv2 section 2.14 on generating keying material, it says: "If the negotiated prf takes a fixed length key and the lengths of Ni and Nr do not add up to that length, half the bits must come from Ni and half from Nr, taking the first bits of each." In section 2.15 on authentication, it says: "If the negotiated prf takes a fixed size key, the shared secret MUST be of that fixed size." In draft-hoffman-rfc3664bis-04 section 1.1 says: "This document specifies the same algorithm as RFC 3664 except that the restriction on keys having to be exactly 128 bits from [AES-XCBC-MAC] is removed. Implementations of RFC 3664 will have the same bits-on-the-wire results as this algorithm; the only difference is that keys that were not equal in length to 128 bits will no longer be rejected, but instead will be made 128 bits. The problem is that changing from fixed-key-size to variable-key-size changes the bits output from generating keying material. Because the nonces must each be at least 128 bits (from IKEv2 section 2.10), the lengths will never add up to the key length unless the key is 256 or longer. A new version of draft-hoffman-rfc3664bis has been posted that attempts to solve the problem. This new version will be the subject of a separate IETF Last Call and IESG action. Accordingly, the IESG agreed to rescind approval to publish draft-hoffman-rfc3664bis-04 as a standards-track RFC. This decision requires that the following action by the RFC Editor: Please remove draft-hoffman-rfc3664bis-04.txt from the RFC Editor queue and discontinue processing of the document. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
