Subject: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jan 2009 00:45:55 +0200

Tero:

Here is the new version suggested replacement text [to sec. 3.14]: 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.

Pasi:

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

Email secured by Check Point

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

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 28 Jan 2009 11:41:17 -0500

Is it the intention of this text to discourage using the "final ciphertext 
block of the previous [sent] message" for all modes, including CBC?  While 
the original ikev2bis text was a little ambiguous, it seemed to apply this 
statement only to "modes other than CBC," whereas this replacement text 
more clearly applies it to all modes.

I expect that many implementations are currently using the final 
ciphertext block as the next IV for CBC, especially as this practice is 
required for IKEv1 (IVs are implicit) and sanctioned by RFC 4306 for 
IKEv2.  If this statement is in fact intended to apply to CBC, is there a 
reference we could cite in justification?  [MODES] lists "two recommended 
methods" for generating an IV, but it does not itself proscribe the use of 
the final ciphertext block for CBC.  In fact, the use of the final 
ciphertext block is consistent with how CBC operates within a given 
message.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Yaron Sheffer <[email-masked]>
To:
IPsecme WG <[email-masked]>
Date:
01/27/2009 06:55 PM
Subject:
[IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE     SA

Tero: 
Here is the new version suggested replacement text [to sec. 3.14]: 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. 
Pasi: 
Looks good to me! (We also need to update couple sentences earlier in 
ikev2bis, Section 3.14, to match this, though.)

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 28 Jan 2009 11:52:47 -0500

On Wed, 28 Jan 2009 11:41:17 -0500
Scott C Moonen <[email-masked]> wrote:

> [MODES] lists "two
> recommended methods" for generating an IV, but it does not itself
> proscribe the use of the final ciphertext block for CBC.  In fact,
> the use of the final ciphertext block is consistent with how CBC
> operates within a given message.
> 

There are attacks on CBC if you can predict the previous block of
ciphertext -- or, of course, the IV.  They don't apply within a single
message, but when you use the last block as the IV for the next packet
the enemy has time to play.  (All this came up on the mailing list a
few years ago, though it would take me a while to dig up the messages.)

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Scott Fluhrer" <[email-masked]>
Date: Wed, 28 Jan 2009 15:47:04 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Steven M. Bellovin
> Sent: Wednesday, January 28, 2009 11:53 AM
> To: Scott C Moonen
> Cc: IPsecme WG; [email-masked]
> Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in 
> IKEv2 to protect IKE SA
> 
> > proscribe the use of the final ciphertext block for CBC.  
> In fact, the 
> > use of the final ciphertext block is consistent with how 
> CBC operates 
> > within a given message.
> > 
> 
> There are attacks on CBC if you can predict the previous 
> block of ciphertext -- or, of course, the IV.  They don't 
> apply within a single message, but when you use the last 
> block as the IV for the next packet the enemy has time to 
> play.  (All this came up on the mailing list a few years ago, 
> though it would take me a while to dig up the messages.)

Found it: http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html (and
following messages in the thread)

See also http://www.samivaarala.com/publications/espiv/index.html where they
actually performed the attack (in a test setting)

-- 
scott

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 28 Jan 2009 16:48:11 -0500

> actually performed the attack (in a test setting)

Thanks, Scott, that is interesting.  IKEv2 is a different story than ESP, 
however, since there is really very little external influence on the 
messages exchanged.  Assuming that this wording change for IKEv2 is 
deliberate and is related to these ESP citations, has anyone actually 
sketched out a hypothetical attack vector for IKEv2?

From:
"Scott Fluhrer" <[email-masked]>
To:
"'Steven M. Bellovin'" <[email-masked]>, Scott C 
Moonen/Raleigh/IBM@IBMUS
Cc:
"'IPsecme WG'" <[email-masked]>, <[email-masked]>
Date:
01/28/2009 03:47 PM
Subject:
RE: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA

> though it would take me a while to dig up the messages.)

Found it: http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html 
(and
following messages in the thread)

See also http://www.samivaarala.com/publications/espiv/index.html where 
they
actually performed the attack (in a test setting)

-- 
scott

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 28 Jan 2009 16:54:33 -0500

On Wed, 28 Jan 2009 16:48:11 -0500
Scott C Moonen <[email-masked]> wrote:

> Scott Fluhrer writes:
> > Found it:
> > http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html 
> (and
> Thanks, Scott, that is interesting.  IKEv2 is a different story than
> ESP, however, since there is really very little external influence on
> the messages exchanged.  Assuming that this wording change for IKEv2
> is deliberate and is related to these ESP citations, has anyone
> actually sketched out a hypothetical attack vector for IKEv2?
> 
I'd rather turn it around.  Given that we know there's a weakness in
this general area, is there any reason not to avoid it?  Is there a
real cost to using good IVs?

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jan 2009 10:19:47 +0200

> real cost to using good IVs?

There's a tradition of treating random bits as a scarce resource, and requiring as little of them as possible. That's probably because revealing too many random bits on the network may lead to attacks on your PRNG.

You could also use a counter for the IV, but then you still get the predictability.

I still like the idea of using the PRNG to generate good IVs, but it does have some drawbacks.

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 29 Jan 2009 08:20:07 -0500

> real cost to using good IVs?

Inertia is the reason I'm thinking of.  I agree with your sentiment in 
principle, but the draft doesn't exist in a vacuum.  I suspect many 
implementations took the easy route and did it the way they were used to 
doing it in IKEv1, and which RFC 4306 explicitly allowed for IKEv2.  These 
implementations are non-compliant with the draft's MUST out of the 
starting gate.

From:
"Steven M. Bellovin" <[email-masked]>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
"Scott Fluhrer" <[email-masked]>, "'IPsecme WG'" <[email-masked]>, 
[email-masked]
Date:
01/28/2009 04:54 PM
Subject:
Re: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA

                                 --Steve Bellovin, 
http://www.cs.columbia.edu/~smb

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Jan 2009 16:39:11 +0200

> implementations are non-compliant with the draft's MUST out of the 

The change is intentional, the original -00 text applied the "new
unpredictable IV for every message" for all modes. The #68 changes
that to say that unpredictable IV is only needed for CBC mode and for
all other modes the document specifying the mode does need to specify
the IV format and generation etc.

Using final ciphertext block of previous message is dangerous, and I
do not want to see us waiting for someone to create attack before we
take actions against that.

Creating unpredictable IVs isn't too expensive (for example I think
you can just take counter and encrypt it with some random key, or just
use PRNG), they do not need to be really random, just unpredictable.

We are already doing other protocol changes too, so adding new MUST to
fix a security hole is something we must do at the same time.
Especially as it will not really affect interoperability, as
recipients MUST still accept any IVs the other non-complient old
versions generated (i.e. the final ciphertext block of previous
message). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 29 Jan 2009 17:00:10 +0200

I agree with Tero.

        Yaron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tero Kivinen
> Sent: Thursday, January 29, 2009 16:39
> To: Scott C Moonen
> Cc: 'IPsecme WG'; [email-masked]; Scott Fluhrer; Steven M.
> Bellovin
> Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to
> protect IKE SA
>
> Scott C Moonen writes:
> > Steven Bellovin writes:
> Scanned by Check Point Total Security Gateway.
>
> Scanned by Check Point Total Security Gateway.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Jan 2009 11:18:41 -0500

I agree with Tero here.

The cost of generating an IV is relatively small.  As he noted, one 
can use a counter as plaintext input and encrypt that value in block 
mode to yield an IV. This approach has been vetted for a long time 
and I believe NIST publications have recommended it.

A recipient ought not be confused by this, in the IKEv2 context. 
Packets may arrive out of order and and thus every packet needs to 
carry its own IV. It would be inappropriate for a recipient to try to 
hold onto the last ciphertext block from a prior IKE packet to use it 
as an IV, given the need for an explicit IV.

Steve

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 29 Jan 2009 14:11:25 -0500

On Thu, 29 Jan 2009 11:18:41 -0500

> and I believe NIST publications have recommended it.
Right.  Leaving aside the mythology that we need a true-random value
for anything (insisting on trying to get one can actually be harmful),
all we need here is unpredictability.  And the notion that randomness
is in short supply dates back a dozen years or so in the IPsec group;
technology has changed and we can reexamine it.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 29 Jan 2009 11:36:27 -0800 (PST)

Hi Scott,

> implementations are non-compliant with the draft's MUST out of the

  But that's all goodness. It will force implementations to do the Right
Thing.

  All that's needed is a random function. Something whose output is
indistinguishable from random, even given knowledge of the input. A
truncated hash is a candidate (see Bellare and Rogaway's "Random Oracles
are Practical: A Paradigm for Designing Efficient Protocols" for a good
discussion). A PRNG can get a seed that is repeatedly hashed with a
counter, and the hash output is truncated to create the IV.

  Dan.