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

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Oct 2005 14:11:52 -0700

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: [email-masked]
Date: Wed, 12 Oct 2005 16:07:28 +0300

Earlier today I wrote:

>   "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.

...except that RFC3602 actually does include a sentence saying 
"The default key size is 128 bits". However, it later talks about
negotiating this in IKEv1:

   Since the AES allows variable key lengths, the Key Length attribute
   MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2
   exchange [DOI].

And since the IKEv2 draft also uses the word "require", I think the 
default value mentioned in RFC3602 was intended as a configuration
hint, and does not imply that sending the Key Length attribute
would be optional. 

(More stuff for the IKEv2 clarifications draft, it seems :-)

Best regards,
Pasi