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

From: [email-masked]
Date: Wed, 12 Oct 2005 15:47:54 +0300

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 12 Oct 2005 16:47:56 +0300

> the "key length" attribute is not included in the SA payloads.

I was about the send the same comment earlier, but noticed that the
Key Lenght attribute is defined to be used with Encryption algorithm,
not with PRFs, so there is not really specified way to tell what is
the PRF key lenght (i.e. the key length is taken from the actual
keying material fed to the PRF). 

> PRF_AES128_CBC always uses 128-bit AES internally (even with 3664bis).

That text in the IKEv2 has always confused me, is it so that for
example ENCR_CAST or ENCR_BLOWFISH cannot be used with any other key
length than the default, or is it so that key length is not needed if
it is default, but it can be given?

The text says that only algorithms defined that accept attributes are
AES, so that would indicate BLOWFISH or CAST cannot use Key length
attribute. I think the original text should have said that only
algorithms that REQUIRE key lengths attributes are the AES based,
others can use it but it is not required.
-- 
[email-masked]