Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-intermediate-07

HI Ben,

thank you for your review.

> Hi all,
> 
> The core mechanisms here seem in good shape.  My main area of
> uncertainty relates to how much analysis, and with what degree of
> formalism, has been applied to the updated IKE_AUTH procedures that are
> supposed to authenticate the intermediate exchange(s).  My comments on
> §3.3.2 have more details, but key questions include how we authenticate
> how many rounds of IKE_INTERMEDIATE were performed, whether using the
> plaintext of the Encrypted payload gives an attacker too much
> flexibility, and whether we want to make any tweaks to "future-proof"
> the construction in case we need some other exchange that occurs prior
> to IKE_AUTH.
> 
> I'd also like to confirm that the current (lack of) Updates:
> relationship between this document and RFC 7296 is correct.  In §3.2, we
> reaffirm that the normal IKE rules for assigning Message IDs apply, so
> "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next
> (if any) and so on".  But in §2.2 of RFC 7296 it is claimed that "the
> first pair of IKE_AUTH messages will have an ID of 1, the second (when
> EAP is used) will be 2, and so on", where we now have competing claims
> about what exchange will get Message ID 1.  I can see a case to be made
> that neither of these statements is intended to be normative, and thus
> that there is no conflict, but wanted to confirm that the WG had
> considered this topic.

Tero has already replied and I agree that we don't need to update RFC 7296 - 
the generic rule from Section 2.2 of RFC 7296 states:

    The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT messages ... 
    and incremented for each subsequent exchange.

and this document doesn't violate it.

> I see the shepherd writeup mentioned some missing articles ('a', 'the',
> etc.).  I took the liberty of making some edits in that space to a local
> copy of the draft, which I will send to the author directly for him to
> incorporate or ignore.

Many thanks for this, really appreciated.

> Section 3.2
> 
>    If the presence of NAT is detected in the IKE_SA_INIT exchange via
>    NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
>    notifications, then the peers MUST switch to port 4500 and send all
>    IKE_INTERMEDIATE exchanges using port 4500.
> 
> I think I see an equivalent requirement in §2.23 of RFC 7296 ("The IKE
> initiator MUST check the NAT_DETECTION_SOURCE_IP or
> NAT_DETECTION_DESTINATION_IP payloads if present, and if they do not
> match the addresses in the outer packet, MUST tunnel all future IKE and
> ESP packets associated with this IKE SA over UDP port 4500."), since the
> IKE_INTERMEDIATE exchanges would fall under "all future IKE packets".
> So, does this need to be written in this was with normative MUST as if
> it is a new requirement?  Or should we rephrase slightly to reaffirm
> that the existing requirement applies in this case?

Good point. Will rephrase.

> Section 3.3.2
> 
>    The requirement to support this behavior makes authentication
>    challenging: it is not appropriate to add on-the-wire content of the
>    IKE_INTERMEDIATE messages into the AUTH payload calculation, because
>    peers generally are unaware in which form other side has received
>    them.  Instead, a more complex scheme is used - authentication is
>    performed by adding content of these messages before their encryption
>    and possible fragmentation, so that data to be authenticated doesn't
>    depend on the form the messages are delivered in.
> 
> The behavior of using the pre-encryption form of the messages in the
> authentication seems to merit some closer inspection, as it opens up an
> avenue for the attacker to modify what bits are authenticated as they
> traverse the network.
> 
> On first look, since the encryption is done using keys negotiated in the
> IKE_SA_INIT exchange, which is itself subject to IKE_AUTH
> authentication, any tampering with the encrypted payloads would require
> tampering with the IKE_SA_INIT exchange (so as to have access to the key
> material needed), which would in turn be detected at time of IKE_AUTH.
> But it would be reassuring to know that some more formal analysis has
> been performed on this scenario.

I'm not aware of any formal analysis (nor did it myself). 
Some analysis and vetting of the current construction was done by Scott Fluhrer and Daniel Van Geest:
https://mailarchive.ietf.org/arch/msg/ipsec/n0QysCUXfgYUddrtWxtiEKvLqh4/

> In a similar vein, it would be good to see some more formal analysis
> that confirms that this construction authenticates the number of
> intermediate exchanges that have occurred.  I am not sure that I could
> sketch an attack that uses such a mismatch, but if we are using a threat
> model where IKE_INTERMEDIATE is used to provide protection against a
> quantum computer that could break the initial IKE_SA_INIT key exchange,
> it seems like we need to be sure to protect against "truncation" attacks
> that cut the quantum-resistant key-exchange out of the authenticated
> transcript.

I agree that formal analysis would be good to have for this situation.

Informally, if we are talking about draft-ietf-ipsecme-ikev2-multiple-ke,
then the SK_p* keys used for calculation of AUTH payload will depend
not only on IKE_SA_INT, but on all subsequent (presumably quantum safe)
key exchanges. And the peers always know how many IKE_INTERMEDIATE
exchanges should take place (as a result of negotiation done in the IKE_SA_INIT).
Of course, an attacker in the middle can play a downgrade attack by
modifying IKE_SA_INT so, that no quantum safe key exchanges are proposed (or accepted),
but in this case the peers will follow local policy - if it allows quantum unsafe
key exchanges to take place, then it cannot be helped.

If we are talking about other applications of IKE_INTERMEDIATE (not concerned
with quantum safe cryptography), then it is possible that an attacker 
equipped with quantum computer to break the authentication, but this is also
true for the current IKEv2 specification, when IKE_INTERMEDIATE is not used.

>    If any IKE_INTERMEDIATE exchange took place, the definition of the
>    blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is
>    modified as follows:
> 
>    InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth
>    ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth
> 
> This sort of construction invites ambiguity if there is ever some other
> future exchange that wants to go between IKE_SA_INIT and IKE_AUTH.  This
> seems like a strong argument in support of the approach this draft
> takes, i.e., make IKE_INTERMEDIATE fully generic, so as to minimize the
> chance of needing such an additional future exchange.  That said, it
> might be possible to slightly improve the future-proofing if we included
> an indicator of what the "next content" after MACedIDFor[IR] is, such as
> the one-octet encoding of the exchange type.  (I think it would have to
> be part of IntAuth_N, not IntAuth itself.)  I don't have a great sense
> for whether the value this adds would be worth the disruption to
> existing implementations, though.

If the WG thinks that it's worth to do this modification, then
we may also consider addressing the following issue,
raised past WGLC by Tobias Brunner:
https://mailarchive.ietf.org/arch/msg/ipsec/8kM6GoPeJwjuoxSH4CL4B75ZJMk/

The WG reaction at that time was that the issue is minor and 
no modification is needed, but _if_ we decide to incorporate
Ben's modification, then we can address this issue too.

And even if we decide to leave it out, some words should be added to 
Security Considerations section anyway, I'll do it.

>    IKE_INTERMEDIATE exchanges took place).  The prf is applied to the
>    the concatenation of two chunks of data: mandatory IntAuth_*_[I/R]_A
>    optionally followed by IntAuth_*_[I/R]_P.  The IntAuth_*_[I/R]_A
>    chunk lasts from the first octet of the IKE Header (not including
>    prepended four octets of zeros, if port 4500 is used) to the last
>    octet of the Encrypted payload header.  The IntAuth_*_[I/R]_P chunk
> 
> I think this would be more precise as "the last octet of the generic
> payload header of the Encrypted payload".  We do go on to say that the
> IV/etc. are not included, but that seems to be in the context of
> computing the _P chunk, and may or may not be saying anything about
> excluding it from the _A calculation.

The IV is not included, as with all AEAD algorithms defined for use with IKEv2 so far.
I'll add clarifications as you suggested.

>    is present if the Encrypted payload is not empty.  It consists of the
> 
> (editorial) I'd recommend including some keyword to provide a mnemonic
> for the _A and _P suffixes for these intermediate values.

The initial idea behind _A and _P was _A[AD] and _P[AYLOAD].
The _A chunk scope is equal to AAD for AEAD algorithms 
and the _P scope is just a content of Encrypted Payload
before encryption. But then it was figured out that the lines
with formulas become too long and don't fit into RFC text format
limitations. So, the names were truncated in favor of formulas readability.
If you have good suggestions how to make these values
look more friendly, it'll be great.

> Section 3.4
> 
>    DoS attack.  See Section 2.21.1 and 2.21.2 of [RFC7296] describe how
>    errors are handled in initial IKEv2 exchanges, these considerations
>    are also applied to the IKE_INTERMEDIATE exchange.
> 
> While the translation of the IKE_SA_INIT error handling to
> IKE_INTERMEDIATE seems pretty straightforward, I wonder if we want to
> say a little more about how the IKE_AUTH error handling applies.  In
> particular, I'm not sure if the portions about sending an
> AUTHENTICATION_FAILED notification will ever apply.  (The handling of
> messages that contain an unsupported critical payload, on the other
> hand, does seem like it would apply in a fairly straightforward manner.)

This is a good point. Will clarify.

> Section 5
> 
> Do we think there's a risk of IKE_INTERMEDIATE being used as a DoS
> vector by way of causing a peer to retain a lot of state prior to
> authentication?  Perhaps that is more appropriate for the other
> specifications that consume IKE_INTERMEDIATE.
> 
>    attacker to mount Denial-of-Service attack.  Moreover, if in this
>    situation the negotiated prf was not secure against preimage attack
>    with known key, then the attacker could forge the IKE_INTERMEDIATE
> 
> I think this would need to be a second-preimage attack, right?  It's
> probably worth clarifying.

Yes, a second-preimage attack was meant. Fixed.

Thank you,
Valery.

> Thanks,
> 
> Ben
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec