MIME-Version: 1.0
References: 
 <PH3PPFA3FE8A23FE4F3833C4C5FECEC2DDFC125A@PH3PPFA3FE8A23F.namprd11.prod.outlook.com>
 <CAG2Zi23b7OuK5SX2f2HWUbDonXXzL82U_Ts+eWd9iug9zeYDAQ@mail.gmail.com>
 <BYAPR08MB5288E9023D9D5882B65A48609525A@BYAPR08MB5288.namprd08.prod.outlook.com>
 <0a9801dc0123$755e9c10$601bd430$@gmail.com>
 <BYAPR08MB5288FFE647A50107717DF1E29524A@BYAPR08MB5288.namprd08.prod.outlook.com>
 <19890.1753898456@obiwan.sandelman.ca>
 <BYAPR08MB5288F727F36D69271D2BAE7E9524A@BYAPR08MB5288.namprd08.prod.outlook.com>
 <BYAPR08MB5288EB06FFCD8BAE1F40C15D9524A@BYAPR08MB5288.namprd08.prod.outlook.com>
 <CAG2Zi21_Ak++pmmMt4NivfTMU7ChZEwSwPVn9qC6Y2VQ3U5qVg@mail.gmail.com>
 <BYAPR08MB52881DE7CE105FD5854BE01A9524A@BYAPR08MB5288.namprd08.prod.outlook.com>
In-Reply-To: 
 <BYAPR08MB52881DE7CE105FD5854BE01A9524A@BYAPR08MB5288.namprd08.prod.outlook.com>
From: Christopher Patton <cpatton@cloudflare.com>
Date: Thu, 31 Jul 2025 08:39:14 -0400
Message-ID: 
 <CAG2Zi22kbWBDq1CejN93a89OO2-VgZJ7P7bvzW_xayoDPT_dWw@mail.gmail.com>
To: "Jun Hu (Nokia)" <jun.hu@nokia.com>
Content-Type: multipart/alternative; boundary="00000000000080c723063b38ee24"
Message-ID-Hash: IPTWGFRSZEJMOY5N2PMGSEC64PPLE4CZ
CC: Michael Richardson <mcr+ietf@sandelman.ca>,
 Valery Smyslov <smyslov.ietf@gmail.com>,
 "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, ipsec <ipsec@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BIPsec=5D_Re=3A_draft-smyslov-ipsecme-ikev2-downgrade-prevention?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ipsec/NrOhC8pHldOUj-0DeHt7l7-v_20>

--00000000000080c723063b38ee24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Jun,


> Ok, the attack with this procedure could work, however from Y point of
> view it is talking with A instead of X, so if there are additional action=
s
> on Y tied to peer=E2=80=99s ID, for example if Y install some firewall/AC=
L rules
> based on IDi, and only X is allowed to access some backend service via th=
e
> installed firewall/ACL rule, this attack won=E2=80=99t get around that.
>

Very true, but before Y figures out it is talking to the wrong peer, X
might reveal sensitive information about itself to the adversary that it
would have only wanted to reveal to Y.

In general, I don't think we should count on whatever application we build
on top of IPsec to save us. When we build these applications, we reasonably
assume IPsec provides a secure channel between the endpoints. This attack
would seem to invalidate that assumption, since (1) the peers have not
actually authenticated one another (X believes it's talking to Y, but Y
believes it's talking to A) and (2) the adversary can decrypt all packets
exchanged between the endpoints. We could try to shove in some
post-handshake authentication, but that just pushes the problem to the
application. I think it's better to fix IPsec itself rather than rely on
ad-hoc, per-application defenses.



> And beside configure properly, another mitigation against this attack
> without introducing new protocol changes is just Y mandate use of PPK
> (RFC8784).
>

I have two thoughts here.

First, I imagine that mandating the use of a PPK isn't going to be viable
for all deployment scenarios. Otherwise, I don't know that there would be
any point in supporting digital signatures for authentication in IKEv2. If
you can distribute a PPK, then you can also distribute a MAC key.

Second, RFC8784 does indeed provide some protection here, but the attack
would still invalidate forward secrecy. That is, if an attacker ever learns
the PPK used in the handshake, it would then be able to decrypt the
traffic. RFC8784 only provides forward secrecy if the PPK is combined with
a fresh, strong key exchange, but the attack downgrades the key exchange to
one the attacker can break.

This second point is a bit more subtle, but it reveals something
fundamental about authenticated key exchange in general: the possibility of
downgrade attacks implies that whatever security property we think we're
getting from the protocol might not actually hold -- whether it's forward
secrecy or something else that our application needs.

Best,
Chris P.

--00000000000080c723063b38ee24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Jun,</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>





<div lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt">Ok, the attack with t=
his procedure could work, however from Y point of view it is talking with A=
 instead of X, so if there are additional actions on Y tied to peer=E2=80=
=99s ID, for example if Y install some firewall/ACL
 rules based on IDi, and only X is allowed to access some backend service v=
ia the installed firewall/ACL rule, this attack won=E2=80=99t get around th=
at.</span></p></div></div></div></blockquote><div><br></div><div>Very true,=
 but before Y figures out it is talking to the wrong peer, X might reveal s=
ensitive information about itself to the adversary that it would have only =
wanted to reveal to Y.</div><div><br></div><div>In general, I don&#39;t thi=
nk we should count on whatever application we build on top of IPsec to save=
 us. When we build these applications, we reasonably assume IPsec provides =
a secure channel between the endpoints. This attack would seem to invalidat=
e that assumption, since=C2=A0(1) the peers have not actually authenticated=
 one another (X believes it&#39;s talking to Y, but Y believes it&#39;s tal=
king to A) and (2) the adversary=C2=A0can decrypt all packets exchanged bet=
ween the endpoints. We could try to shove in some post-handshake authentica=
tion, but that just pushes the problem to the application. I think it&#39;s=
 better to fix IPsec itself rather than rely on ad-hoc, per-application def=
enses.</div><div>=C2=A0</div><div>=C2=A0<span style=3D"font-size:11pt">=C2=
=A0</span>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v><div lang=3D"EN-US"><div><p class=3D"MsoNormal"><span style=3D"font-size:=
11pt"><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11pt">And beside configure =
properly, another mitigation against this attack without introducing new pr=
otocol changes is just Y mandate use of PPK (RFC8784).</span></p></div></di=
v></div></blockquote></div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">I have two thoughts here.</div><div class=3D"gmail_quote">=
<br></div><div class=3D"gmail_quote">First, I imagine that mandating the us=
e of a PPK isn&#39;t going to be viable for all deployment scenarios. Other=
wise, I don&#39;t know that there would be any point in supporting digital =
signatures for authentication in IKEv2. If you can distribute a PPK, then y=
ou can also distribute a MAC key.</div><div class=3D"gmail_quote"><br></div=
><div class=3D"gmail_quote">Second, RFC8784 does indeed provide some protec=
tion here, but the attack would still invalidate forward secrecy. That is, =
if an attacker ever learns the PPK used in the handshake, it would then be =
able to decrypt the traffic. RFC8784 only provides forward secrecy if the P=
PK is combined with a fresh, strong key exchange, but the attack downgrades=
 the key exchange to one the attacker can break.</div><div class=3D"gmail_q=
uote"><br></div><div class=3D"gmail_quote">This second point is a bit more =
subtle, but it reveals something fundamental about authenticated key exchan=
ge in general: the possibility of downgrade attacks implies that whatever s=
ecurity property we think we&#39;re getting from the protocol might not act=
ually hold -- whether it&#39;s forward secrecy or something else that our a=
pplication needs.</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">Best,</div><div class=3D"gmail_quote">Chris P.</div><div class=
=3D"gmail_quote"><br></div></div>
</div>

--00000000000080c723063b38ee24--