[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-23 Thread Wang Guilin
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-22 Thread Tero Kivinen
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Jun Hu (Nokia)
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] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Kampanakis, Panos
; 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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Jun Hu (Nokia)
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Daniel Van Geest
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Valery Smyslov
..@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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Jun Hu (Nokia)
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Daniel Van Geest
.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,

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-21 Thread Jun Hu (Nokia)
, 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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-19 Thread Wang Guilin
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:

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-11 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-11 Thread Valery Smyslov
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-

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-10 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-10 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-07-09 Thread Christopher Patton
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 &

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-06-26 Thread Valery Smyslov
@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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-28 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-23 Thread Paul Wouters
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-23 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-23 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-23 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-22 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-22 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-21 Thread Michael Richardson
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.

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-21 Thread Michael Richardson
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-21 Thread Kampanakis, Panos
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-21 Thread Michael Richardson
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-21 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-21 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-21 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-20 Thread Kampanakis, Panos
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-20 Thread Kampanakis, Panos
) 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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-20 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-20 Thread Kampanakis, Panos
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-20 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-20 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-20 Thread Valery Smyslov
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-19 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-19 Thread Christopher Patton
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

[IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00

2025-05-18 Thread Valery Smyslov
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