Subject: [IPsec] Proposal for using Implicit IV for IKE

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Nov 2017 10:34:40 +0800

Hi.

So following Daniel’s message in the room, here’s how I think we can make this work.

The IKE header has a “Message ID” field that is a counter. It’s tempting to use this as a counter, same as we use the replay counter in IPsec.  However, as Tero pointed out on Jabber, each such message ID can be used several times:
All responses have the same Message ID as the requests.
The Message ID is one sided.  The n-th request from the original Responder has the same Message ID as the n-th request from the original Initiator.
When a message is fragmented as in RFC 7383, all fragments that are part of the same message are transmitted (and encrypted) with the same Message ID.

Re-using the Message ID makes us re-use the AEAD nonce. Not good.  Fortunately, all the algorithms that the IIV draft mentions require an 8-octet IV while the Message ID is 4-octet.  We can use the 32 “spare” bits to differentiate these messages.  I have two proposals for constructing the 8-octet IV:

Proposal #1:
==========
| 24 zero bits | Flags (8 bits) | Message ID (32 bits)|

And use IIV only for regular Encrypted Payload, not for Encrypted Fragment.  The reasoning is that if you use fragmentation you’ve already solved the message-too-big issue.

The Flags octet includes the I(nitiator) and R(esponse) bits, which differentiate the cases that are not related to fragmentation.

Proposal #2:
==========
| Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits)|

The Fragment Counter is the same as in the RFC 7383 fragment payload, or zero if we are using the regular encrypted payload.

The Flags octet includes the I(nitiator) and R(esponse) bits, which differentiate the cases that are not related to fragmentation.

The Fragment Counter differentiates between different part of the same message.

The Next Payload differentiates between sending a message fragmented and sending it unfragmented.

So in summary, I think it’s doable and can be added to the draft if we have consensus.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Sun, 12 Nov 2017 21:51:18 -0500

> And use IIV only for regular Encrypted Payload, not for Encrypted
    > Fragment. The reasoning is that if you use fragmentation you’ve
    > already solved the message-too-big issue.

    > The Flags octet includes the I(nitiator) and R(esponse) bits, which
    > differentiate the cases that are not related to fragmentation.

    > The Fragment Counter is the same as in the RFC 7383 fragment payload,
    > or zero if we are using the regular encrypted payload.

I think that #2 does a better job.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Schinazi <[email-masked]>
Date: Mon, 13 Nov 2017 11:16:12 +0800

I suspect that there was a typo and Yoav meant to include the flags for proposal 2:

| Next Payload (8 bits) | Flags (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits) |

In that case I do prefer option 2 as it doesn't add much complexity and allows fragmentation.

David

> On Nov 13, 2017, at 10:51, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 13 Nov 2017 06:30:20 +0300

Hi,

there is also an RFC6311, which allows messages

with the MessageID (0) to be sent over the same IKE SA

in case of cluster failover. If the IKE SA is a result of a rekey

(not IKE_SA_INIT), then its first encrypted message

will have MessageID of 0, so if failover happens later,

the MessageID of zero will repeat, breaking the security.

You should consider this case also.

Regards,

Valery.

From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Monday, November 13, 2017 5:35 AM
To: IPsecME WG
Subject: [IPsec] Proposal for using Implicit IV for IKE

Hi.

*	All responses have the same Message ID as the requests.
*	The Message ID is one sided.  The n-th request from the original Responder has the same Message ID as the n-th request from the original Initiator.
*	When a message is fragmented as in RFC 7383, all fragments that are part of the same message are transmitted (and encrypted) with the same Message ID.

Proposal #1:

==========

Proposal #2:

==========

 

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 13 Nov 2017 11:55:22 +0800

Right.  Thanks, David.

> On 13 Nov 2017, at 11:16, David Schinazi <[email-masked]> wrote:
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Nov 2017 22:36:03 +0800

Having re-read RFC 6311, Valery’s right. The synchronization messages in 6311 all have Message ID zero and are encrypted. There do not seem to be any cleartext bits that differentiate one such message from another (which is why the RFC admits that they are replayable).

So I’m kind of stuck.  Support IIV or RFC 6311 but not both?  Drop the whole thing?  Something else that I’m missing?

Yoav

> On 13 Nov 2017, at 11:30, Valery Smyslov <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 15 Nov 2017 04:42:20 +0300

Hi,

I’m a bit nervous since we are trying to find a quick solution

to an apparently not-so-easy problem in a rush time of WGLC.

I think we need more time for that, so we either should 

drop the IIV for IKE and proceed with the current document

for ESP only (and probably creating a new work item – IIV for IKEv2)

or hold on the draft until we found a solution for IKEv2 too.

What about the way how to make IIV work with RFC6311, I can

imaging the following solution. Cluster failover generally occurs

rarely, so we may not worry about the overhead associated

with sending RFC6311 messages. So we can introduce a combine

mode, when some messages have implicit IV and some (e.g.RFC6311 messages) 

have explicit IV. Obviously we need to differentiate between them,

so I presume we need to grab one of reserved bits in IKE header flags

for this purpose. I admit it looks complicated, but I cannot come up

with a simpler solution (except for not using IIV in IKEv2 at all).

Regards,

Valery.

From: Yoav Nir [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2017 5:36 PM
To: Valery Smyslov
Cc: IPsecME WG
Subject: Re: [IPsec] Proposal for using Implicit IV for IKE

Yoav

Hi,

Regards,

Valery.

Hi.

Proposal #1:

==========

Proposal #2:

==========

 

Yoav

---

From: Daniel Migault <[email-masked]>
Date: Tue, 14 Nov 2017 21:10:11 -0500

I am more incline to have IIV for iKEv2 in another document and as such we
request the IANA to set the "IKEv2 Reference" to UNDEFINED.

What about the following text ?

   [RFC8247] recommends the same suites for IKEv2.  However some IKEv2
   extensions such as [RFC6311] or [RFC7383] allow the Message ID to be
   re-used, which is incompatible with the uniqueness property of
   the nonce, and makes these suites highly insecure. As a result, the
suites
   defined is this document does not apply to IKEv2. The IANA is expected
to
   put "UNDEFINED" in the column "IKEv2 Reference" for these transforms.

Yours,
Daniel

On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov <[email-masked]> wrote:

> *From:* Yoav Nir [mailto:[email-masked]]
> *Sent:* Tuesday, November 14, 2017 5:36 PM
> *To:* Valery Smyslov
> *Cc:* IPsecME WG
> *Subject:* Re: [IPsec] Proposal for using Implicit IV for IKE
>
>
>
> Having re-read RFC 6311, Valery’s right. The synchronization messages in
> 6311 all have Message ID zero and are encrypted. There do not seem to be
> any cleartext bits that differentiate one such message from another (which
> is why the RFC admits that they are replayable).
>
>
>
> So I’m kind of stuck.  Support IIV or RFC 6311 but not both?  Drop the
> whole thing?  Something else that I’m missing?
>
>
>
> Yoav
>
>
>
> *From:* IPsec [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Yoav Nir
> *Sent:* Monday, November 13, 2017 5:35 AM
> *To:* IPsecME WG
> *Subject:* [IPsec] Proposal for using Implicit IV for IKE
>
>
>
> Hi.
>
>
>
> The IKE header has a “Message ID” field that is a counter. It’s tempting
> to use this as a counter, same as we use the replay counter in IPsec.
> However, as Tero pointed out on Jabber, each such message ID can be used
> several times:
>
>    - All responses have the same Message ID as the requests.
>    - The Message ID is one sided.  The n-th request from the original
>    Responder has the same Message ID as the n-th request from the original
>    Initiator.
>    - When a message is fragmented as in RFC 7383, all fragments that are
>    part of the same message are transmitted (and encrypted) with the same
>    Message ID.
>
>
>
> Re-using the Message ID makes us re-use the AEAD nonce. Not good.
> Fortunately, all the algorithms that the IIV draft mentions require an
> 8-octet IV while the Message ID is 4-octet.  We can use the 32 “spare” bits
> to differentiate these messages.  I have two proposals for constructing the
> 8-octet IV:
>
>
>
> Proposal #1:
>
> ==========
>
> Fragment.  The reasoning is that if you use fragmentation you’ve already
> solved the message-too-big issue.
>
>
>
> The Fragment Counter is the same as in the RFC 7383 fragment payload, or
> zero if we are using the regular encrypted payload.
>
>
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 15 Nov 2017 05:15:20 +0300

I also think that separate document is a right way to go.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Wednesday, November 15, 2017 5:10 AM
To: Valery Smyslov
Cc: Yoav Nir; IPsecME WG
Subject: Re: [IPsec] Proposal for using Implicit IV for IKE

I am more incline to have IIV for iKEv2 in another document and as such we request the IANA to set the "IKEv2 Reference" to UNDEFINED. 

   [RFC8247] recommends the same suites for IKEv2.  However some IKEv2
   extensions such as [RFC6311] or [RFC7383] allow the Message ID to be
   re-used, which is incompatible with the uniqueness property of
   the nonce, and makes these suites highly insecure. As a result, the suites
   defined is this document does not apply to IKEv2. The IANA is expected to 
   put "UNDEFINED" in the column "IKEv2 Reference" for these transforms.

Yours, 

Daniel

Hi,

Regards,

Valery.

Yoav

Hi,

Regards,

Valery.

Hi.

Proposal #1:

==========

Proposal #2:

==========

 

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Nov 2017 10:30:26 +0800

Hi, Daniel

I think your text is confusing without the suggestion to use Message ID as a nonce. This suggestion is not in the text, it was only in this email thread.

So I think the text should be (new paragraph at the end of IANA Considerations):
   These algorithms should be added with this document as ESP Reference and “Not Allowed” for IKEv2 Reference.

This seems fitting for https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5

A new document will change that.

> On 15 Nov 2017, at 10:10, Daniel Migault <[email-masked]> wrote:
> 
> On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> 
> 
> From: Yoav Nir [mailto:[email-masked] <mailto:[email-masked]>]
> On 13 Nov 2017, at 11:30, Valery Smyslov <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> Hi,
> 
> 
> 
> From: IPsec [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Yoav Nir
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Nov 2017 10:40:20 +0800

Oh, and if you’re updating the draft anyway, you should update the references now that 8221 and 8247 have been published.

Yoav

> On 15 Nov 2017, at 10:30, Yoav Nir <[email-masked]> wrote:
> 
> Hi, Daniel
> 
> This seems fitting for https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 <https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5>
> 
>> On 15 Nov 2017, at 10:10, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 14 Nov 2017 22:47:18 -0500

I agree. I will also make sure the the text make it sure the document is
only on ESP. I believe the confusion --- and the clarification!  came from
citing the IKEv2 recommendations. So I intend to make explicit in the
abstract / intro, we only address ESP.

Yours,
Daniel

On Tue, Nov 14, 2017 at 9:30 PM, Yoav Nir <[email-masked]> wrote:

> Hi, Daniel
>
> I think your text is confusing without the suggestion to use Message ID as
> a nonce. This suggestion is not in the text, it was only in this email
> thread.
>
> This seems fitting for https://www.iana.org/assignments/ikev2-parameters/
> ikev2-parameters.xhtml#ikev2-parameters-5
>

---

From: Daniel Migault <[email-masked]>
Date: Tue, 14 Nov 2017 22:49:43 -0500

This has been updated on my local copy... I was waiting to clarify how we
handle the iKEv2 issue before publishing the update.

On Tue, Nov 14, 2017 at 9:40 PM, Yoav Nir <[email-masked]> wrote:

> Oh, and if you’re updating the draft anyway, you should update the
> references now that 8221 and 8247 have been published.
>
> Yoav
>
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Nov 2017 23:49:39 -0500 (EST)

> for ESP only (and probably creating a new work item – IIV for IKEv2)

Yes please. Split the document.

Paul