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

[Martin Duke <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Martin,
>
> thank you for your comments.
>
> > 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?
>
> 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.
>
> > (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.
>
> 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?
>
> > 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.
>
> Indeed.
>
> Thank you!
>
> Regards,
> Valery.
>
>