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 09:40, Kampanakis, Panos > <kpanos=40amazon....@dmarc.ietf.org> wrote: > > > This Message Is From an External Sender > This message came from outside the Laboratory. > 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 (if already negotiated) with > IKE_FOLLOWUP_KE which means that your SKEYSEED and SKEYMAT and all other keys > that protect data are quantum-resistant. We do all that because at the time > of IKE_FOLLOWUP_KE we have the full identity of the peer and thus can enforce > the config that says “I expect Peer X to be upgraded and thus must use > ML-KEM”. Note the messages and rekeys etc are already supported in RFC9370, > we are not doing anything exotic. We just use the new configuration flag to > enforce the “use ML-KEM requirement” by using the right messages. I think > this is a simpler approach than introducing a new notification N(MAC more > things) which both peers need to support. > > Feedback from the whole WG is welcome. > > > From: Christopher Patton <cpatton=40cloudflare....@dmarc.ietf.org> > Sent: Tuesday, May 20, 2025 2:36 PM > To: Kampanakis, Panos <kpa...@amazon.com> > Cc: Valery Smyslov <smyslov.i...@gmail.com>; ipsec@ietf.org > Subject: RE: [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. > > > 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 general. However, speaking as a potential > implementer, I believe the solution ought to be a prerequisite for this > draft. The reason is that I think there are extenuating circumstances: The > transition to PQ key exchange is well underway in most of the IETF and > beyond, and I'm worried that the lack of downgrade resilience will hinder > progress for IPSec. > > In particular, if a draft were created that extended IKEv2 to have stronger > downgrade resilience, then I think draft-ietf-ipsecme-ikev2-mlkem ought to > depend on it. > > Such an extension might look like this: The initiator's IKE_INIT_SA message > indicates support for an extension wherein, when selected by the responder, > each host signs/MAC all key exchange messages, including those sent by its > peer. (This seems like it would be necessary for downgrade resilience, though > perhaps not sufficient.) > > We would then make negotiation of ML-KEM in an intermediate exchange > contingent on selection of this downgrade resilience extension. Or perhaps we > could specify something broader? > > Of course, unless marked as mandatory by the initiator, this extension is > itself vulnerable to downgrade attack. This means there would still be a > transition period where most responders don't yet support the extension and > thus some initiators would leave it as optional for a period of time. However > the time horizon for this transition is the same as for the transition to > mandatory-ML-KEM, so I don't think adding it as a dependency costs us any > time. The upside is that we provide downgrade resilience for the broader > ecosystem. > > > It is a great idea to add a discussion in the Sec Considerations section. I > will do that. Please review the text when it is out. > > I'd be happy to! > > > On the specifics, I agree that saying that the responder can choose to go > ML-KEM-as-mandatory won’t always be possible in the migration phase. RFC8784 > addressed this downgrade scenario by introducing a “peer PPK_ID-based > mandatory_or_not PQ PPK flag” configuration. That way, the initiator or > responder know if it is mandatory to use the PPK with the PPK_ID for quantum > resistance. draft-ietf-ipsecme-ikev2-mlkem does not negotiate a separate > identifier which the peers can use to know if ML-KEM is mandatory. So, I > think the most elegant approach is for those worried about such downgrades, > to force a new Child SA creation or rekey or IKE SA rekey by using a > IKE_FOLLOWUP_KE and make use of a mandatory-ML-KEM-peer configuration. > IKE_FOLLOWUP_KE has authenticated peers and thus the responder can enforce a > “mandatory to use ML-KEM for that peer” configuration. Wildcard scenarios > could be used for such identities to prevent large config. > > Thoughts on this solution are welcome. > > IKE_FOLLOWUP_KE is defined in RFC 9370 (Multiple Exchanges), correct? How are > the peers authenticated in these messages? The attacker knows all session > keys at this point, so I imagine they would need something like another AUTH > exchange. > > Best, > Chris P. > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
