Subject: [IPsec] Protocol Action: 'Mixing Preshared Keys in IKEv2 for Post-quantum Security' to Proposed Standard (draft-ietf-ipsecme-qr-ikev2-11.txt)

From: The IESG <[email-masked]>
Date: Thu, 16 Jan 2020 14:26:03 -0800

The IESG has approved the following document:
- 'Mixing Preshared Keys in IKEv2 for Post-quantum Security'
  (draft-ietf-ipsecme-qr-ikev2-11.txt) as Proposed Standard

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

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

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

Technical Summary

The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today.  IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available.  It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term.  To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys.

Working Group Summary

The document has been highly reviewed and discussed and presented during multiple meetings and through the mailing list. The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors, to include implementors. In addition to mailing list discussions, the draft has been presented and discussed during the 98 tru 102 IETF meetings. The draft has been supported by the participants in the room on various hums for the specific design decisions made in the document.

Document Quality

The document is supported by implementors, and authors also represent a subset of implementors. Interoperability has been confirmed by at least four independent implementations from Cisco, Apple, libreswan and ELVIS-PLUS. There likely additional implementations that the WG are not aware of at this time.

Personnel

David Waltermire is the document shepherd and Benjamin Kaduk is the responsible AD.

RFC Editor Note

In Section 6, please make the change:

OLD

   exchange immediately.  Instead it waits for more response messages
   retransmitting the request as if no responses were received at all,
   until either the received message contains the USE_PPK or the
   exchange times out (see section 2.4 of [RFC7296] for more details
   about retransmission timers in IKEv2).  If neither of the received
   responses contains USE_PPK, then the exchange is aborted.

NEW

   exchange immediately.  Instead it waits for more response messages,
   retransmitting the request as if no responses were received at all,
   until either the received message contains USE_PPK or the
   exchange times out (see section 2.4 of [RFC7296] for more details
   about retransmission timers in IKEv2).  If none of the received
   responses contain USE_PPK, then the exchange is aborted.