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
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.