Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: David Waltermire <firstname.lastname@example.org>, The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Protocol Action: 'Mixing Preshared Keys in IKEv2 for Post-quantum Security' to Proposed Standard (draft-ietf-ipsecme-qr-ikev2-11.txt) 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.