Considering: draft-fluhrer-qr-ikev2 For context and a reminder, another draft proposing the use of Quantum Key Distribution (QKD) in IPSec was previously rejected by the group: https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01
The draft under consideration was prompted by an interest in the group in introducing quantum-resistant algorithms to the IKEv2 protocol of the IPSec standard. It makes sense to support the move to QR algorithms but it seems possible that the approach outlined in the current draft will not lead to the best outcome for security or usability. I would propose that the WG take a different approach and not adopt the current draft but instead work towards an alternate draft based around quantum-resistant asymmetric cryptographic functions. Earlier, we had David Waltermire of NIST ask for feedback from the group on the following questions: 1) Previous WG discussions have indicated interest in this problem. Does the working group think that there is a problem here that we need to address? 2) Should we do this work in the IPsecME working group? If not, where? 3) Can we use draft-fluhrer-qr-ikev2 as a starting point for developing a WG solution to this problem? If not, what is a suitable starting point instead? I’d propose answering these as follows: 1) Yes, there is a real threat here as recognized by NIST, NSA, ETSI etc. IKEv2 key exchanges could be recorded now and attacked in future when a quantum computer is available to recover the IPSec session keys. 2) It is completely appropriate for the ipsecme working group to standardize the IPSec protocol modifications and extensions required to provide quantum resistance. The choice of quantum-resistant cryptographic primitives should be decided by the CFRG, NIST, ETSI or other competent body. 3) The Internet Draft Currently under consideration is not the best starting point as it assumes that post-quantum pre-shared keys are the preferred solution for quantum resistance. This is not obviously the case; there are a number of drawbacks with the suggested system: a) PPKs do not provide Perfect Forward Secrecy - given a quantum computer to recover the Diffie-Hellman shared secret, a successful attack on the PPK for one session compromises all other sessions using the same PPK b) The Responder has to scan through a list of PPKs, making an AES/HMAC_SHA256 computation for each, comparing the result against the Indicator sent in the Initiator's payload. Since there is no intrinsic limit to the size of the Responder's PPK list, this is a linear amount of work that could result in potentially unbounded response times. c) An additional round-trip is introduced over and above the normal IKEv2 key negotiation; this will increase the latency of setting up the SA. d) Key distribution for pre-shared-key based cryptosystems can be problematic. A separate PPK will normally be required for each pair of correspondents, so the number of keys can be quadratic, unless group PPKs are used which increases the risk to confidentiality. How will PPKs be generated, will both correspondents contribute entropy to them, or will they be supplied by a trusted third party? A number of quantum-resistant asymmetric public key algorithms have been proposed, e.g. NTRU, NewHope, McEliece, Super-singular isogeny Diffie-Hellman. Some of these have ephemeral keys that will allow for Perfect Forward Secrecy, have security proofs, don't require an additional round-trip, and would bypass the PPK key distribution problem. Without wanting to make a decision between them until they have been properly evaluated, I think the working group should devise a protocol that allows for the use of a quantum-resistant asymmetric algorithm. Mark Mark McFadden Principal Consultant, Internet Infrastructure and Governance InterConnect Communications Mobile: +44 (0) 7792 276 904<tel:+44%207792%20276%20904> Skype: McElmside or +44 (0) 20 7558 8105<tel:+44%2020%207558%208105> Email: markmcfad...@icc-uk.com<mailto:markmcfad...@icc-uk.com> Web: http://www.icc-uk.com<http://www.icc-uk.com/> InterConnect Communications Ltd, Merlin House, Station Road, Chepstow, NP16 5PB, United Kingdom. Registered in England and Wales, company registration no. 1828673. ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. However, InterConnect makes no warranty that this email is virus-free. ________________________________________________________________________
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
