RE: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please review

[[e-mail]]

The text should also say that for the purpose of algorithm
negotiation, this PRF has a fixed key length.  In other words,
the "key length" attribute is not included in the SA payloads.

BTW, there's text in IKEv2 -17 that has this wrong. Section 3.3.5
says that

   "The only algorithms defined in this document that accept
   attributes are the AES based encryption, integrity, and
   pseudo-random functions, which require a single attribute
   specifying key width."

Only ENCR_AES_CBC and ENCR_AES_CTR accept different key lengths; 
and since there's no specified default key length, the key length
attribute MUST be included.

But AUTH_AES_XCBC_96 [RFC3566] always uses 128-bit keys, and
PRF_AES128_CBC always uses 128-bit AES internally (even with 3664bis).

Best regards,
Pasi

> -----Original Message-----
> From: Paul Hoffman
> Sent: 07 October, 2005 00:12
> To: IPsec WG
> Subject: [Ipsec] Important changes in draft-hoffman-rfc3664bis; please
review
> 
> Greetings again. At the IKEv2 bakeoff, a significant problem was 
> found with draft-hoffman-rfc3664bis, which has already been put in 
> the RFC Editor's queue. It would have been nice if this had been 
> noticed before we all agreed that the document was sound, but there 
> is still time to make a technical change to fix this.
> 
> 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.
> rfc3664bis 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.
> 
> Because of this, I have issued a new version of 
> draft-hoffman-rfc3664bis (-05, to be specific), that attempts to 
> solve the problem by adding the following two paragraphs to section 
> 1.1:
> 
> -----
>     IKEv2 [IKEv2] uses PRFs for multiple purposes, most notably for
>     generating keying material and authentication of the IKE_SA.  The
>     IKEv2 specification differentiates between PRFs with 
>     fixed key sizes and those with variable key sizes.
> 
>     When using the PRF described in this document with IKEv2, the
>     PRF is considered to be fixed-length for generating keying
>     material but variable-length for authentication.  That is, when
>     generating keying material, "half the bits must come from Ni and
>     half from Nr, taking the first bits of each" as described in
>     IKEv2 section 2.14, but when authenticating with shared secrets
>     (IKEv2 section 2.16), the shared secret does not have to be 128
>     bits long.  This somewhat tortured logic allows IKEv2
>     implementations that use the fixed-length-key semantics from RFC
>     3664 to interoperate with implementations that use the
>     variable-length-key semantics of this document.
> -----
> 
> I have also asked Russ Housley to take the previous draft off the RFC 
> Editor's queue and, if there is general agreement on this change, put 
> the revised draft back into the queue.
> 
> All IKEv2 implementers: please read the whole document carefully 
> (again, I hope), particularly looking at these two paragraphs, and 
> comment on whether this fixes the problems stated. Thanks!
> 
> --Paul Hoffman, Director
> --VPN Consortium

_______________________________________________
Ipsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipsec