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

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 10 Jan 2022 15:04:04 -0800

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.

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.

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?

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.

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.

   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.

   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.

   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.

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.)

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.

Thanks,

Ben

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 11 Jan 2022 14:22:53 +0200

> that there is no conflict, but wanted to confirm that the WG had

The text in RFC7296 section 2.2 is not normative, it is example of
what will happen when the normal case. I.e., first exchange will have
message id 0, and second exchange will have message id 1 etc, for
normal use of IKEv2 the first exchange will be IKE_SA_INIT and second
exchange will be IKE_AUTH.

In case IKE_INTERMEDIATE, the first exchange (message id 0) will be
IKE_SA_INIT, and second exchange (message id 1) will be
IKE_INTERMEDIATE. For the G-ikev2 the first exchange (message id 0)
will be IKE_SA_INIT and second exchange (message id 1) will be
GSA_AUTH. For RFC5723 (Resumption) the first exchange (message id 0)
will be IKE_SESSION_RESUMPTION, and second exchange (message id 1)
will be IKE_AUTH.

> that cut the quantum-resistant key-exchange out of the authenticated

Note, that you are here mixing properties from two different
protocols, ikev2 intermediate and ikev2 multiple ke. IKEv2
intermediate is supposed to be used to transport large data between
IKE_SA_INIT and IKE_AUTH. It is not supposed to be quantum resistant
by itself.

Quantum resistant part is provided by the multiple key exchanges.
I.e., every single key exchange run between IKE_SA_INIT and IKE_AUTH
will provide new cryptographic keys to be used for all future
IKE_INTERMEDIATE exchanges and those new keys depends on all previous
key exchanges done.

I.e., when using multiple ke only the first IKE_INTERMEDIATE exchange
uses the diffie-hellman from the IKE_SA_INIT. The end result of the
that IKE_INTERMEDIATE is to generate new cryptographic keys using the
fomula from 3.2.2 of draft-ietf-ipsecme-ikev2-multiple-ke:

               SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)

and

     {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
      SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)

where the SK_d(n-1) is the key derivation key generated by the
previous step, i.e., in this case the Diffie-Hellman of the
IKE_SA_INIT.

So every single multiple key exchange run between the IKE_SA_INIT and
IKE_AUTH will contribute to the final encryption and authentication
keys used for IKE_AUTH.

This protects against attacks where attacker tries to remove any of
the multiple key exchanges from the transcript.

On the other hand IKE_INTERMEDIATE might also be used for use cases
which do not generate keys, for example to transfer some kind of
policy configuration information before IKE_AUTH etc. The
IKE_INTERMEDIATE needs to provide the protection against those
exchanges too, and adding them to the signed data should provide
protection against attackers.

If I remember correct TLS does the same, the final transcript hash is
hash of all messages concatenated together including the handshake
message header, but exlucing record layer headers...
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 11 Jan 2022 17:55:45 +0300

HI Ben,

thank you for your review.

> that there is no conflict, but wanted to confirm that the WG had

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.

> copy of the draft, which I will send to the author directly for him to

Many thanks for this, really appreciated.

> that the existing requirement applies in this case?

Good point. Will rephrase.

> 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/

> that cut the quantum-resistant key-exchange out of the authenticated

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.

> 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.

> 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.

> 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.

> hand, does seem like it would apply in a fairly straightforward manner.)

This is a good point. Will clarify.

> probably worth clarifying.

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

Thank you,
Valery.

> Thanks,
> 
> Ben
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Jan 2022 22:53:17 -0500 (EST)

>> existing implementations, though.

I think this makes sense, and I would be okay with such a change.

> Ben's modification, then we can address this issue too.

I'm not sure this is needed. Implementations will anyway limit the
number of IKE_INTERMEDIATE exchanges they are willing to accept to
some reasonably very low number. Although if others want this, I
won't object.

> Security Considerations section anyway, I'll do it.

That makes sense.

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 12 Jan 2022 15:39:21 -0800

Hi Tero,

> will be IKE_SESSION_RESUMPTION, and second exchange (message id 1)

Thanks for confirming!

> IKE_SA_INIT and IKE_AUTH. It is not supposed to be quantum resistant

Agreed.  This was just an attempt to motivate a sketch of a scenario where
the "truncation attack" might be relevant.
 
> IKE_AUTH will contribute to the final encryption and authentication

Agreed.  But prior to that point, the Nth IKE_INTERMEDIATE exchange can be
attacked if the initial IKE_SA_INIT exchange and all IKE_INTERMEDIATE
exchanges prior to the Nth are compromised in realtime.  (Admittedly a
strong assumption.)

> protection against attackers.

The question I want to probe here focuses more on the non-cryptographic
input to the signature/MAC, as distinct from the actual key used to make the
MacedIDfor* input.  This question remains relevant even if we have some
uses of IKE_INTERMEDIATE other than multiple-ke.  In short, I expect that
we have defense in depth, and one part of that (for multiple-ke) is the
actual key used for the MACedIDFor* MAC.  Is there another part of that
defense in depth that, say, authenticates the Message ID of the AUTH
message?  I think that there are new avenues for attack available if the
attacker is able to cause the initiator and responder to use
InitiatorSignedOctets/ResponderSignedOctets that are of different lengths
on the two parties.  (These are not complete attacks on their own, of
course, due to the defense in depth.)

> message header, but exlucing record layer headers...

Yes, the TLS transcript hashes all messages concatenated together, but in
TLS there's a clear "end" signal in the Finished message (and the pretty
static handshake structure).  Any new messages added to the handshake by
extensions are explicitly negotiated, and that negotiation itself is
protected by the transcript hash.  Here, we just have "the usual stuff,
followed by one or more IntAuth_N chunks", with no clear "end" marker.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 12 Jan 2022 16:17:59 -0800

Hi Valery,

Trimming as appropriate...

> https://mailarchive.ietf.org/arch/msg/ipsec/n0QysCUXfgYUddrtWxtiEKvLqh4/

Thanks for the link!  Yoav, could you update the shepherd writeup to
mention this thread?

> key exchanges to take place, then it cannot be helped.

Just to confirm: the peers negotiate how many additional KEs to run, which
is expected to also be the number of IKE_INTERMEDIATE exchanges, but could
be smaller if IKE_INTERMEDIATE is also used for some other
(as-yet-undefined) purpose in the same association.

> true for the current IKEv2 specification, when IKE_INTERMEDIATE is not used.

To reiterate on my reply to Tero, I'm thinking about the robustness of the
system overall -- e.g., if we assume a highly capable attacker that can do
many things we don't currently believe possible, like break DH and find
certain types of hash collision, do we have a mechanism in place to ensure
that the initiator and responder use transcripts of the same length?
The point is not that we expect an attacker with such capabilities to
appear, but rather to consider various aspects of the negotiation and
confirm that we have a specific mechanism in the AUTH construction that
protects that aspect of the negotiation.

> Ben's modification, then we can address this issue too.

My instinct is to retain the current construction, but I don't remember
enough about previous times that this class of construction has come up to
be able to give a good reasoning for why.  (I don't even remember if this
type of thing came up in TLS, or SAAG, or elsewhere.)  Perhaps there was
some concern about some intermediate step being flawed or attacked so as to
bias the distribution of that intermediate value, thereby weakening the
authentication of the previous iterations, but I really don't remember for
sure.

> Security Considerations section anyway, I'll do it.

Sounds good.

> look more friendly, it'll be great.

My suggestion would just be to add a new sentence (before "The
IntAuth_*_[I/R]_A chunk lasts from [...]"): "The IntAuth_*_[I/R]_A chunk
covers the data that is the AAD input to AEAD algorithms protecting the
Encrypted Payload, and the IntAuth_*_[I/R]_P chunk covers the plaintext
input to such algorithms.  It's not great writing, but it will probably get
the job done.

Thanks,

Ben

---

From: Valery Smyslov <[email-masked]>
Date: Thu, 13 Jan 2022 16:41:07 +0300

Hi Ben,

> Trimming as appropriate...

Further trimming...

> (as-yet-undefined) purpose in the same association.

Yes, exactly. 

> protects that aspect of the negotiation.

It is expected, that peers will negotiate new extensions which make use of IKE_INTERMEDIATE,
so in general they will know how many the IKE_INTERMEDIATE exchanges would take place.
However, I'd rather leave some flexibility here. See for example
draft-smyslov-ipsecme-ikev2-qr-alt, where using IKE_INTERMEDIATE
is optional on the Initiator's discretion.

We can modify the calculation as you suggested in reply to Tero
by appending MessageID of IKE_AUTH exchange at the IntAuth:

IntAuth =  IntAuth_1 [| IntAuth_2 [| IntAuth_3 ... ]] | MID_IKE_AUTH

Do you think it is enough?

> authentication of the previous iterations, but I really don't remember for

Should we ask cryptographers to review it?

> input to such algorithms.  It's not great writing, but it will probably get

This is not accurate wording. First, although AEAD algorithms are in fashion now,
the IntAuth_*_* construction doesn't rely on them, so it's not correct in my opinion
to mention AAD here. Yes, IntAuth_*_[I/R]_A covers what AAD for AEAD is,
but if non-AEAD algorithm is used, then AAD is undefined, but IntAuth_*_[I/R]_A
still have the same scope. And second, IntAuth_*_[I/R]_P is not equal
to the plaintext for AEAD, since the plaintext would also include Padding
and Pad Length fields which are excluded from IntAuth_*_[I/R]_P.

How about:

The IntAuth_*_[I/R]_A chunk covers the data that would be the AAD input to AEAD algorithms 
should they be used for protecting the Encrypted Payload (regardless of whether they are actually used), 
and the IntAuth_*_[I/R]_P chunk covers the plaintext input to such algorithms stripped of
the Padding and the Pad Length fields.

Does this text helps or only adds confusion?

Regards,
Valery.