Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA

From: <[email-masked]>
Date: Tue, 14 Oct 2008 13:32:56 +0300

Tero Kivinen wrote:
> Responder takes IV field from the packet a generates the real IV given
> to the AES CTR by concatenating nonce (which is from keying material
> generated by IKEv2), IV field, and block number (0). Responder does
> not care how the IV was generated, and it does not need to care.
> Responder will be interoperable with the other end regardless how the
> initiator generates IVs. 

Note that RFC 4306 specifies that the IV length is equal to the block
length of the underlying encryption algorithm. This doesn't work for
CTR mode, so there's no way RFC 4306 and use of CTR mode in IKEv2 are
compatible.

(We could, of course, change this text in IKEv2bis...)

Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Oct 2008 15:39:34 +0300

> CTR mode, so there's no way RFC 4306 and use of CTR mode in IKEv2 are

AES (the underlying encryption algorithm) has block size of 128 bits,
and IV length to be used with CTR mode is defined in the section 3.1
in the RFC3686. I do not see any way anybody could use any other IV
length than the one defined in the RFC3686 which also matches the
"block length of the underlying encryption algorithm".

I do not really see any reason why this does not work with CTR mode
too, especially as it is using "underlying encryption algorithm"
instead of refering the block size requiremetns of the selected mode
and algorithm to be used.

> (We could, of course, change this text in IKEv2bis...)

As there is no newer RFCs or drafts to specify how to use counter mode
algorithms, and I do not really consider the text in RFC4306 to forbid
CTR mode ciphers, and RFC3686 do fill up the gaps in the RFC4306 by
specifying the IV length and the IV generation rules.

We should most likely change the IKEv2bis text from:
----------------------------------------------------------------------
   o  Initialization Vector - Optional block of bits that is required
      to allow encrption algorithm to produce a unique stream
      independent from other streams produced by same key. The length
      and generation depends on the encryption algorithm and mode it
      is used in. For CBC modes the initialization vector is    a
      randomly chosen value whose length is equal to the block length
      of the underlying encryption algorithm. Recipients MUST accept
      any value.  Senders SHOULD either pick this value
      pseudo-randomly and independently for each message or use the
      final ciphertext block of the previous message sent.  Senders 
      MUST NOT use the same value for each message, use a sequence of
      values with low hamming distance (e.g., a sequence number), or use
      ciphertext from a received message. For other modes the IV
      format and processing is specified in the document specifying
      the encryption algorithm and mode.
----------------------------------------------------------------------

I.e. change add some generic text to really tell what IV is (I copied
that mostly from wikipedia), and then tell that the rest of the text
is for CBC mode, and other modes do tell how the IV is used in the
corresponding documents. The RFC3686 do tell IV length and how it is
generated.

Hmm.. found another problem in the RFC4306. The ENCR_AES_CTR has wrong
reference. It is refering to the RFC3664 (The AES-XCBC-PRF-128
Algorithm for the Internet Key Exchange Protocol (IKE)), instead of
the RFC3686 (Using Advanced Encryption Standard (AES) Counter Mode
With IPsec Encapsulating Security Payload (ESP)). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Thu, 16 Oct 2008 13:13:54 +0300

Tero Kivinen wrote:

> > Note that RFC 4306 specifies that the IV length is equal to the
> > block length of the underlying encryption algorithm. This doesn't
> > work for CTR mode, so there's no way RFC 4306 and use of CTR mode
> > in IKEv2 are compatible.
> 

No, it does *not* match -- the block size is 128 bits (16 octets),
while the IV length in Section 3.1 of RFC 3686 is 8 octets.

> specifying the IV length and the IV generation rules.

The problem is that RFC 4306 also specifies the IV length and IV
generation rules -- and those don't match RFC 3686.

> corresponding documents. The RFC3686 do tell IV length and how it is

BTW, note that ikev2bis has updated this text (in particular, the text
about using the final ciphertext block of the previous is just wrong,
shown to be insecure in practise, and explicitly forbidden in the NIST
spec of CBC mode).

If we want to add support for CTR mode in this document (which isn't
all that clear -- if someone really needs this, it could be a separate
document like RFC 5282), we could prephrase this, of course...

> With IPsec Encapsulating Security Payload (ESP)). 

Already fixed in ikev2bis almost a year ago :-)

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 16 Oct 2008 17:37:29 +0300

> while the IV length in Section 3.1 of RFC 3686 is 8 octets.

True. 

But this is exactly same situation we have with AES-GCM (IV = 8 bytes,
block size is 16 bytes). Does that mean that we cannot use AES-GCM
regardless that we have rfc5282 as RFC 4306 mandates the IV to be same
as block length?

I myself think that if the algorithm specific RFC (RFC 5282 for
AES-GCM and RFC 3686 for AES-CTR) specifies some other IV processing
rules those are used even when the RFC 4306 says that the iv length is
equal the block length of the underlying encryption algorithm. 

> generation rules -- and those don't match RFC 3686.

Thats why I think we need to change those rules to apply only to CBC
modes defined in the RFC4306 (or the bis) and for other algorithms you
use the rules specified in those documents.

> shown to be insecure in practise, and explicitly forbidden in the NIST

So I can see it has, but it still has the text which forbids using any
other mode than where the IV length is same as block length. This
removes AES-GCM, AES-CCM and AES-CTR for example. I think we should
remove the text saying the IV length is same as block length, and
refer to the algorithm sepecific IV length specifications and use that
text for only CBC modes.

> document like RFC 5282), we could prephrase this, of course...

We do have that already. It is the RFC 3686. It is specifically writen
so it can be used with both IKEv1 and IKEv2 (i.e. using the KEYMAT
term to match both IKEv1 and IKEv2 specifications), and it does
specify the IV length and other things needed.

Note, that RFC 5282 does have about same text as RFC 3686. I do not
really see any real difference there. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Fri, 24 Oct 2008 11:41:13 +0300

> equal the block length of the underlying encryption algorithm. 

Note that AES-GCM was already specified in RFC 4106; RFC 5282 updates
the necessary parts of RFC 4306 so that 4106 can actually be used.

We couldn't just use RFC 4106 without RFC 5282; for similar reasons,
we can't use RFC 3686 as-is, but need to slightly update RFC 4306
text on this point (either in IKEv2bis or in a separate draft).
If you're suggesting doing it in IKEv2bis (sounds like a reasonable
idea to me), please send text :)

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 24 Oct 2008 15:07:01 +0300

> the necessary parts of RFC 4306 so that 4106 can actually be used.

Yes, that was needed as RFC4306 defined specific format for the
encrypted payload, including the integrity checksum data field which
is not present when using combined mode ciphers, and most imporantly
RFC 5282 also specified what is the contents of the AAD. Those are not
defined in the RFC4306 so thats why we did need RFC5282.

> We couldn't just use RFC 4106 without RFC 5282; for similar reasons,

We could not use RFC4106 as it only specied how to use combined modes
with ESPv3, and it did specify completely different things to put to
the AAD for the IKEv2.

RFC 4106 specified that AAD contains SPI and sequence number. RFC 5282
specifies that AAD contains IKEv2 header, unencrypted IKE payloads and
the payload header of the encrypted payloads.

The need for the RFC5282 was not because the combined modes use
different IV lengths, and it was not really because they do not have
the integrity checksum data field at all (we could consider combined
mode ciphers to have ICV field length of 0). It was needed to specify
how to construct AAD.

AES-CTR does not have that problem, as it still uses the exactly same
normal integrity algorithms that are used also for CBC modes.

> text on this point (either in IKEv2bis or in a separate draft).

On the other hand RFC3686 do specify everything that is needed for the
IKEv2 so that the AES-CTR cipher can be used to protect IKEv2 SA. The
only thing that is slightly inconsistent is that the RFC4306 tells how
IV field is used for CBC modes, which is not exactly same that what is
used for the AES-CTR. But on the other hand the RFC3686 do have the
replacement text for that telling what is the lenght of the IV field
and how it is constructed.

It cannot say that this text is supposed to replace RFC4306 section
3.14 IV description as there was no need to make forward reference to
the RFC4306 from that document, but the text in RFC3686 is written
based on the IKEv2 drafts available at that time, and it was supposed
to be enough to allow AES-CTR mode to be used in IKEv2.

We seem to have missed text in RFC4306 to explain that the IV text is
only for CBC modes, and for other ciphers use the text from the
document specifying them, but the RFC3686 do have the text specifying
things anyways.

> idea to me), please send text :)

Here is the new version suggested replacement text:
----------------------------------------------------------------------
   o  Initialization Vector - For CBC mode ciphers the length of the
      initialization vector (IV) is equal to the block length of the
      underlying encryption algorithm. Senders MUST select a new
      unpredictable IV for every message; recipients MUST accept any
      value. The reader is encouraged to consult [MODES] for advice on
      IV generation. In particular, using the final ciphertext block
      of the previous message is not considered unpredictable. For
      other modes than CBC the IV format and processing is specified
      in the document specifying the encryption algorithm and mode.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Mon, 27 Oct 2008 14:20:06 +0200

> Here is the new version suggested replacement text:

Looks good to me! (We also need to update couple sentences earlier
in ikev2bis, Section 3.14, to match this, though.)

Best regards,
Pasi