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

[Valery Smyslov <[e-mail]>]

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.