Skip to main content

Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-ikev2-mlkem-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, debcooley1@gmail.com, draft-ietf-ipsecme-ikev2-mlkem@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, rfc-editor@rfc-editor.org, sfluhrer@cisco.com
Subject: Protocol Action: 'Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)' to Proposed Standard (draft-ietf-ipsecme-ikev2-mlkem-05.txt)

The IESG has approved the following document:
- 'Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange
   Protocol Version 2 (IKEv2)'
  (draft-ietf-ipsecme-ikev2-mlkem-05.txt) as Proposed Standard

This document is the product of the IP Security Maintenance and Extensions
Working Group.

The IESG contact persons are Christopher Inacio and Deb Cooley.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/


Ballot Text

Technical Summary

   NIST standardized ML-KEM, a new key encapsulation mechanism, which
   can be used for quantum-resistant key establishment.  This draft
   specifies how to use ML-KEM by itself or as an additional key
   exchange in IKEv2 along with a traditional key exchange.  These
   options allow for negotiating IKE and Child SA keys which are safe
   against cryptographically relevant quantum computers.

Working Group Summary

There was general agreement on this draft.   

Document Quality

   The draft mentioned in the Shepherd's writeup (draft-ietf-ipsecme-downgrade-prevention) has also been submitted to the IESG.

   There is no Yang, no mediatypes, no MIB or anything else that requires validation.

   There was a (late) third party IPR disclosure made, it is on the datatracker page for this draft.

   There exist at least four implementations (Cisco, Palo Alto Networks,
   Strongswan, and Apple). 

Personnel

   The Document Shepherd for this document is Scott Fluhrer. The
   Responsible Area Director is Deb Cooley.

IANA Note

  (Insert IANA Note here or remove section)

RFC Editor Note