Subject: [IPsec] Martin Duke's No Objection on draft-ietf-ipsecme-ikev2-intermediate-09: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 02 Mar 2022 12:17:15 -0800

Martin Duke has entered the following ballot position for
draft-ietf-ipsecme-ikev2-intermediate-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(3.2) "Implementations MUST verify that Message IDs in the IKE_INTERMEDIATE
messages [increment by 1]". Or what? In any case, isn't this fully enforced by
the WINDOW_SIZE parameter in Sec 2.3 of RFC 7296? That is, if WINDOW_SIZE == 1,
any message that doesn't increment by 1 will simply be ignored. If WINDOW_SIZE
> 1, receiving an increment > 1 is in fact legal (due to packet loss) but the
window will not advance until all IDs are received?

(5) The security considerations hint at it with all the DoS talk, but it would
be valuable to place some limits on the kind of information that can be
contained in IKE_INTERMEDIATE and how it is processed. The document doesn't
appear to explicitly restrict these messages to overflow from IKE_SA_INIT
messages, so if an extension sends e.g. user data in these what are the
implications? I'd suggest that applications not process such data until AUTH
exchange is complete.

While I am not particularly happy with solely using the WINDOW_SIZE mechanism
to regulate the amount of data in flight, IMO that is an issue with RFC 7296
and not this document.

---

From: Valery Smyslov <[email-masked]>
Date: Thu, 3 Mar 2022 00:26:30 +0300

Hi Martin,

thank you for your comments.

> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/

Your understanding is correct. These requirements are in RFC 7296
and may look redundant in this document. While it is not a good
practice to repeat requirements from another document, 
it is done here for the purpose of bringing readers' attention
to them, because for this particular exchange they are crucial 
for security. The way IKE_INTERMEDIATE exchanges 
are authenticated implies that chunks of data fed into the prf
be in the order these exchanges took place. 

Scott Fluhrer suggested to reinforce the requirement to check 
Message ID in the draft (quoting his private e-mail with his permission):

"... we need to be careful about Message ID handling; what we want to prevent is an attacker resending 
a previous encrypted IKE Intermediate message, and confusing things (which plausibly could happen 
if there were a large number of IKE intermediate exchanges, and the sides don't track all the message IDs 
that they've seen already).  I would suggest that the draft state that the responder MUST verify that 
the message IDs received are increasing (or is that inferable from the IKE RFC?)."

So, while it is basically repetition of what RFC 7296 says, it was decided
to reiterate these requirement due to their importance for security.

> implications? I'd suggest that applications not process such data until AUTH

This document defines only the IKE_INTERMEDIATE exchange itself.
It is expected that other documents will define its application
and the types of data it contains.

That said, I agree that IKE_INTERMEDIATE must only be used 
in those cases, when the data transferred needs to be processed 
before (or in) IKE_AUTH. So, it's not for transferring user data 
(and I hope no specification will use it for this purpose).

I can add something like this:

  It is expected that the IKE_INTERMEDIATE exchange will 
  only be used for transferring data that is needed to establish IKE SA
  and not for data that can be send later when this SA is established.

Is it OK?

> to regulate the amount of data in flight, IMO that is an issue with RFC 7296

Indeed.

Thank you!

Regards,
Valery.

---

From: Martin Duke <[email-masked]>
Date: Wed, 2 Mar 2022 14:09:07 -0800

For the proposed text, I would prefer something normative but if you think
that's unwise I'll accept your proposal.

Otherwise, your responses look great!

Thanks!

On Wed, Mar 2, 2022 at 1:26 PM Valery Smyslov <[email-masked]> wrote:

> > messages [increment by 1]". Or what? In any case, isn't this fully
> enforced
> > by

---

From: Valery Smyslov <[email-masked]>
Date: Thu, 3 Mar 2022 09:40:24 +0300

Hi Martin,

For the proposed text, I would prefer something normative but if you think that's unwise I'll accept your proposal.

          As Murray noticed, we can’t use normative language against future specifications :-)

          I combined text resulted from Lars’ comment and from yours into a list as follows

          (at the end of Introduction section):

                                                    ... It is expected that separate

   specifications will define for which purposes and how the

   IKE_INTERMEDIATE exchange is used in IKEv2.  Some considerations must

   be taken into account when designing such specifications.

   o  The IKE_INTERMEDIATE exchange is not intended for bulk transfer.

      This document doesn't set a hard cap on the amount of data that

      can be safely transferred using this mechanism, as it depends on

      its application.  But it is anticipated that in most cases the

      amount of data will be limited to tens of Kbytes (few hundred

      Kbytes in extreme cases), which is believed to cause no network

      problems (see [RFC6928] as an example of experiments with sending

      similar amounts of data in the first TCP flight).  See also

      Section 5 for the discussion of possible DoS attack vectors when

      amount of data sent in IKE_INTERMEDIATE is too large.

   o  It is expected that the IKE_INTERMEDIATE exchange will only be

      used for transferring data that is needed to establish IKE SA and

      not for data that can be send later when this SA is established.

          I think both wordings impose some recommendations/restrictions on using

          this exchange and thus it’s a good idea to put them together. Is it OK?

          Thanks!

          Regards,

          Valery.

Thanks!

Hi Martin,

Is it OK?

Indeed.

Thank you!

Regards,
Valery.

---

From: Martin Duke <[email-masked]>
Date: Thu, 3 Mar 2022 09:41:14 -0800

Looks good to me.