ailto:ipsec@ietf.org>>
时 间:2025-07-22 15:27:30
主 题:[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
Jun Hu \(Nokia\) writes:
> ● Sure, downgrade attack also works for hybrid if initial DH is weak, but
> you could use ML-KEM as the initial DH (I understand concern of hav
Jun Hu \(Nokia\) writes:
> ● Sure, downgrade attack also works for hybrid if initial DH is weak, but
> you could use ML-KEM as the initial DH (I understand concern of having
> large IKE_SA_INIT packet, but it could work in network support large mtu)
> ● In hub-and-spoke case, gateway ha
deployments
From: Daniel Van Geest
Sent: Monday, July 21, 2025 4:05 PM
To: Jun Hu (Nokia) ; Valery Smyslov ;
'Christopher Patton'
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION: This is an external email. Please be very ca
; ipsec@ietf.org
Subject: [EXTERNAL] [IPsec] Re: Binding properties of
draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
Clarifying question
Jun Hu,
*another approach is like you mentioned, there is IPsec implementation
> could abort negotiation base on local policy config once learned peer’s
> IKEv2 ID*
>
I'm a little concerned about leaning on this, as the attack might involve a
peer other than the victim. Concretely, the attacker m
Clarifying question: How exactly would it work to disable weak KEs for peers
that support strong KE? The peer doesn't identify itself until the IKE_AUTH
exchange, at which point the sequence of KEs has already been negotiated and
executed. Is it possible to abort due to insufficient KE paramete
oudflare....@dmarc.ietf.org>>
Sent: Wednesday, May 28, 2025 11:47 PM
To: ipsec@ietf.org<mailto:ipsec@ietf.org>
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
Hi all,
I appreciate the productive discussion here! I've asked the chairs for
Clarifying question: How exactly would it work to disable weak KEs for
peers that support strong KE? The peer doesn't identify itself until the
IKE_AUTH exchange, at which point the sequence of KEs has already been
negotiated and executed. Is it possible to abort due to insufficient KE
parameters a
..@cloudflare.com>
Cc: ipsec@ietf.org <mailto:ipsec@ietf.org>
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additio
t: Thursday, July 10, 2025 8:20 PM
To: 'Christopher Patton' <mailto:cpat...@cloudflare.com>
Cc: ipsec@ietf.org<mailto:ipsec@ietf.org>
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION: This is an external email. Please be very carefu
.com>
Cc: ipsec@ietf.org<mailto:ipsec@ietf.org>
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
HI Chris,
, with assumption that at least one side knows the capability
of both peers
From: Valery Smyslov
Sent: Thursday, July 10, 2025 8:20 PM
To: 'Christopher Patton'
Cc: ipsec@ietf.org
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION: This is an exte
itely different, as
AUTH data are different, even the key used is the same.
Guilin
发件人:Valery Smyslov mailto:smyslov.i...@gmail.com>>
收件人:'Christopher Patton' mailto:cpat...@cloudflare.com>>
抄 送:ipsec mailto:ipsec@ietf.org>>
时 间:2025-07-11 09:52:51
主 题:[IPsec] Re:
Valery,
> Got it. In that case, why append NonceRData to InitiatorSignedOctets? Are
> these octets not already contained in RealMessage1 | RealMessage2? (Same
> question for ResponderSignedOctets.)
>
>
>
> This is an interesting point, thank you for bringing it. My
> initial idea was to
Hi Chris,
First, I understand the intent of the extension to be to have each party sign
the entire transcript of the IKE_SA_INIT exchange. Is that what's happening
here? I ask because I'm not precisely sure what parts of the transcript are
specified here:
https://www.ietf.org/archive/id/draft-
Valery,
On Thu, Jul 10, 2025 at 8:20 AM Valery Smyslov
wrote:
> HI Chris,
>
>
>
> thank you for your review. Please, see inline.
>
>
>
> Hi Valery,
>
>
>
> Thanks so much for the quick turnaround! The draft is nicely written, and
> I'm happy that it addresses the broader problem.
>
>
>
> I just
tracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-downgrade-prevention/
From: Christopher Patton mailto:40cloudflare@dmarc.ietf.org> >
Sent: Wednesday, May 28, 2025 11:47 PM
To: ipsec@ietf.org <mailto:ipsec@ietf.org>
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem
tension aimed to address
> the problem.
>
>
>
> Regards,
>
> Valery.
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-downgrade-prevention/
>
>
>
>
>
> *From:* Christopher Patton
> *Sent:* Wednesday, May 28, 2025 11:47 PM
&
@ietf.org
Subject: [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
Hi all,
I appreciate the productive discussion here! I've asked the chairs for time at
IETF 123 to discuss if/how to address this problem.
Chris P.
On Mon, May 19, 2025 at 2:39 PM Christopher Patton mailto
Hi all,
I appreciate the productive discussion here! I've asked the chairs for time
at IETF 123 to discuss if/how to address this problem.
Chris P.
On Mon, May 19, 2025 at 2:39 PM Christopher Patton
wrote:
> Digging into this a little deeper, I believe the downgrade attack
> described in Secti
On Wed, 21 May 2025, Michael Richardson wrote:
We added an IKEv1 Notify to say that an end-point supported IKEv2.
That implementation failed to take into account that Vendor IDs were
not actually payloads that were part of the signature, and so was
completely ineffective :)
Paul
Impersonation is not interesting here. The goal of attacker is to downgrade
secure connection
between peers so that it can break ECDH and read their communication. So, this
is an active attack,
but the goal is eavesdropping.
Consider initiator I has some sensitive information to send to respond
HI Valery,
We thought about this mode, but decided it didn't make sense. It would seem
to allow the malicious initiator E to impersonate responder R to initiator
I. No quantum computer needed! Do you think there's any chance that
deployments do this in practice?
Chris P.
On Fri, May 23, 2025 at
Hi Chris,
IKEv2 allows peers to use different PSKs for authentication initiator and
responder (but both peers must have both these PSKs).
So, _theoretically_ it is not unrealistic that each peer uses a separate PSK to
authenticate itself,
and one of these PSKs is compromised, while the other is
Hi all,
A quick follow-up here: This attack doesn't seem to work for the
authentication mode in which the initiator and responder MAC their outbound
messages with a PSK. The responder IKE_AUTH message would be MAC'ed by the
PSK shared with initiator E, not initiator I. Thus initiator I would abort
Hi Chris,
My idea is that responder can hash the received IKE_SA_INIT message
(actually, do a negotiated prf with some fixed or known key, since
hash is not negotiated in IKEv2) and include the result into the
response IKE_SA_INIT using some new status notification.
Respond
We added an IKEv1 Notify to say that an end-point supported IKEv2.
That was our defense (really: detection) of downgrade attacks.
I remember trying to debug something years ago where it looked like there was
a downgrade attack occuring... I never did quite figure out if that was real,
or a bug.
Valery Smyslov wrote:
> While I agree that these prerequisites are not unrealistic, I
> think that by Q-day (the day we believe the CRQC exists) all hosts must
> be already switched to the mode when PQ algorithms are mandatory, with
> no exception for “old” systems. And b
Christopher Patton ; Valery Smyslov
; ipsec@ietf.org
Subject: RE: [EXTERNAL] [IPsec] Re: Binding properties of
draft-ietf-ipsecme-ikev2-mlkem-00
Kampanakis, Panos wrote:
> I fleshed out the details of this approach a bit in
>
https://github.com/csosto-pk/pq-mlkem-ikev2/issues/5#issuec
Kampanakis, Panos wrote:
> I fleshed out the details of this approach a bit in
>
https://github.com/csosto-pk/pq-mlkem-ikev2/issues/5#issuecomment-2896485221
> Basically you don’t do IKE_INTERMEDIATE at all, you do all classical
> and immediately rekey the SA and the Child SA (i
Hi Valery,
>While I agree that these prerequisites are not unrealistic, I
> think that by Q-day (the day we believe the CRQC exists) all hosts must be
>
>already switched to the mode when PQ algorithms are mandatory,
> with no exception for “old” systems. And before this day the
typo (see below)
From: Valery Smyslov
Sent: Wednesday, May 21, 2025 10:51 AM
To: 'Christopher Patton'
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00
Hi Chris,
[snipped]
It seems to me that both of these prerequisites are realistic:
1. Wh
Hi Chris,
[snipped]
It seems to me that both of these prerequisites are realistic:
1. When deploying a new protocol feature like this, in my experience there is
usually a period of time where graceful fallback is an operational requirement.
In particular, an ECDH+ML-KEM initiator may still
lov
; ipsec@ietf.org
Subject: RE: [EXTERNAL] [EXT] [IPsec] Re: Binding properties of
draft-ietf-ipsecme-ikev2-mlkem-00
Why would you trust “full identity” that’s been authenticated by Classic means?
—
Regards,
Uri
Secure Resilient Systems and Technologies
MIT Lincoln Laboratory
On May 21, 2025, at
) which both
peers need to support.
Feedback from the whole WG is welcome.
From: Christopher Patton
Sent: Tuesday, May 20, 2025 2:36 PM
To: Kampanakis, Panos
Cc: Valery Smyslov ; ipsec@ietf.org
Subject: RE: [EXTERNAL] [IPsec] Re: Binding properties of
draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION
Hi Panos,
Regardless, it is a valid point. I think it is out of scope to address this
> in the draft as I consider it a general IKEv2 issue which the WG can tackle
> in separate work.
>
I agree the problem is not specific to draft-ietf-ipsecme-ikev2-mlkem and
that the ideal solution is more gener
be used for such
identities to prevent large config.
Thoughts on this solution are welcome.
From: Christopher Patton
Sent: Tuesday, May 20, 2025 11:07 AM
To: Valery Smyslov
Cc: ipsec@ietf.org
Subject: [EXTERNAL] [IPsec] Re: Binding properties of
draft-ietf-ipsecme-ikev2-mlkem-00
CAUTION
Hi Valery, thanks for the quick reply!
> I assume that SK_I and SK_E are long-term shared secrets used
> for authentication?
>
> Just to clarify, because in RFC 7296 those secrets are called
> PSKs, while SK_* are session keys.
>
Correct, I mean PSK.
> This looks like combi
Hi Chris,
Hi Valery,
I think the property I'm describing is slightly different, but the difference
may not matter for most purposes.
I hope so.
By "binding to the protocol context" I mean, at the point at which SKEYSEED(1)
is derived, the initiator and responder only derive the s
Hi Chris,
Digging into this a little deeper, I believe the downgrade attack described in
Section 5.2.1 of [1] is relevant here.
Suppose I have broken ECDH and want to impersonate some responder R to some
initiator I. I don't have access to I's MAC key SK_I, but I do have access to
another in
Digging into this a little deeper, I believe the downgrade attack described
in Section 5.2.1 of [1] is relevant here.
Suppose I have broken ECDH and want to impersonate some responder R to some
initiator I. I don't have access to I's MAC key SK_I, but I do have access
to another initiator E's MAC
Hi Valery,
I think the property I'm describing is slightly different, but the
difference may not matter for most purposes.
By "binding to the protocol context" I mean, at the point at which
SKEYSEED(1) is derived, the initiator and responder only derive the same
SKEYSEED(1) if they have a consist
Hi Chris,
Hi all,
I'm reviewing draft-ietf-ipsecme-ikev2-mlkem-00 [1] and had a few questions
about its hybrid security. Forgive me if this concern has already been raised
and addressed, as I'm new to this mailing list. I briefly searched the archive
and didn't find a related thread.
Suppo
43 matches
Mail list logo