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

[Paul Hoffman <[e-mail]>]

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