Kampanakis, Panos <kpanos=40amazon....@dmarc.ietf.org> 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 (if already negotiated)
> with IKE_FOLLOWUP_KE which means that your SKEYSEED and SKEYMAT and all
The initiator must know that it's going to do this, so it SHOULD avoid keying
the child SA. If it's keyed, it might get used, and I think we'd want to
avoid that.
> 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
After a CRQC, doesn't this mean that an active on-path attacker (meddler in
the middle) also has this information...
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
