Hi Dave, > On Jun 28, 2016, at 2:12 PM, Waltermire, David A. (Fed) > <[email protected]> wrote: > > This has been a good discussion so far. There is work to be done to address > the issues raised. > > Getting back to the call for adoption, I'd like to see feedback on the > following questions to better understand where consensus is on this issue. >
thanks for framing the questions; let me chime in with some specific responses, speaking as a WG member. > 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? Yes; the problem is that IKEv2 does not have the same postquantum security as IKEv1. This is an immediate practical need, because the difference between versions has motivated some users to have a preference for the obsolete version, and on the flip side, users of the current version cannot benefit from postquantum security of preshared keys. > 2) Should we do this work in the IPsecME working group? If not, where? Yes, the problem being addressed is an important one for the IKEv2 standard, and the solution should be broadly available to the IPSec community. > 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? > Yes; that draft is a good starting point. The goal should be to develop an RFC that updates RFC 7383 and specifies how Postquantum Preshared Keys (PPKs) can be used, in a manner that is operationally similar to IKE preshared keys, to achieve postquantum security. The WG should decide whether identity protection is needed, or whether it can be traded for simplicity. Other approaches, such as QKD or using a long stream of shared secret key material obtained from an arbitrary source, should be addressed through separate documents, because they are not needed to address the above problem, and because they do not meet the requirement of operational similarity with current practice. A sequence of key material intended for one-time use is not the same as a PPK, and the logic needed to handle indexing and sequencing should not be imposed on the RFC that addresses the immediate need. Going a little further off topic, with any technology (like QKD or a one-time pad) that is predicated on the idea that computational cryptography cannot be fully trusted, there should be a detailed security analysis of how it is integrated into IPsec/IKE, which shows how to use the technology along with other IPSec mechanisms in a way that is consistent with its security assumptions. In short, the usage of technologies that are only interesting in scenarios that include major advances in cryptanalysis should be specifically crafted to minimize the risk of those advances. No such analysis has yet been put forward. The analysis of key renewal rates in the SECOQC White Paper on Quantum Key Distribution and Cryptography [Section 3.2 of http://www.secoqc.net/downloads/secoqc_crypto_wp.pdf], for instance, neglects to consider the risk of a key collision attack, and does not attempt any formal/provable security framework. The IPSec WG should expect this analysis before any standards a re developed that support these new technologies, and those standards should clearly state what advantages the new technologies have, and in what scenarios they should be used, and what sort of other IPSec algorithms and options are consistent with good security. Please note that I am not objecting to the IPSec WG taking up this work; I am pointing out that there is a lot of work involved, which underscores the importance of dealing with it in a way that is separate from the immediate need of parity between IKE versions. best, David > Regards, > Dave > >> -----Original Message----- >> From: Scott Fluhrer (sfluhrer) [mailto:[email protected]] >> Sent: Friday, June 24, 2016 11:26 AM >> To: [email protected]; David McGrew <[email protected]> >> Cc: Waltermire, David A. (Fed) <[email protected]>; IPsecME WG >> <[email protected]>; Panos Kampanakis (pkampana) <[email protected]> >> Subject: RE: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an >> IPSecME >> WG document >> >> >>> -----Original Message----- >>> From: Paul Wouters [mailto:[email protected]] >>> Sent: Friday, June 24, 2016 9:43 AM >>> To: David McGrew (mcgrew) >>> Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer); >>> Panos Kampanakis (pkampana) >>> Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an >>> IPSecME WG document >>> >>> On Fri, 24 Jun 2016, David McGrew wrote: >>> >>> Hi David, >>> >>>> Because QKD is not a practical system for Internet security. It has >>>> serious >>> security issues/challenges and operational limitations on bitrate, range, >>> and >>> physical media. It requires a point to point optical link, which is >>> typically >>> dedicated fiber, which must be shorter than 60 miles. There are >>> security issues with QKD because it relies on a physical interaction >>> across the line between the encrypter and decrypter, thus giving an >>> attacker the opportunity to perform an attack on the physical process >> anywhere on that >>> line. See for instance Brassard et. al. Security Aspects of Practical >>> Quantum >>> Cryptography, Lydersen et. al., Hacking commercial quantum >>> cryptography systems by tailored bright illumination, or Gerhardt et. >>> al., Full-field implementation of a perfect eavesdropper on a quantum >> cryptography >>> system. Another major security problem is the range limitation; it has >> been >>> proposed to extend the range of QKD by using a chain of trusted >>> repeaters, each connected by a QKD sy stem. These repeaters would >>> greatly increase the attack surface, and require the end user to trust >>> the infrastructure provider(s); in contrast, the Internet community >>> wants end to end encryption, as described in RFC3365 and RFC7624. >>>> >>>> In contrast, QR-IKEv2 can be used to add postquantum security >>>> between >>> any two points on the globe, without requiring dedicated fiber, and >> without >>> requiring physical layer security assumptions. It has *fewer* security >>> assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft >>> relies on the security of symmetric cryptography and the physical >>> layer, whereas QR-IKEv2 relies only on the former. >>> >>> For a postquantum IKEv2 extension, does it matter which underlying >>> mechanism is used to provide the extra bits to mix into the SKEYSEED? >>> >>> I think what is needed is: >>> >>> - A NOTIFY message that signals an identifier of where the extra bits >>> should be taken/generated from. Both endpoints have previous >>> knowledge >>> of what tjos identifier refers to. Be it a hardware device or an >>> offset in a onetime pad, etc, etc. >> >> One possible concern is whether such a notify message would compromise >> the anonymity properties of IKE; if someone in the middle sees the same >> identifier in multiple exchanges, would they be able to conclude that those >> are the same individuals negotiating? If the NOTIFY messages are >> anonymized, how is that done? >> >> Now, it might be that the WG would decide to compromise on such >> anonymization concerns; this would simplify things a lot, however it's very >> much something we need WG agreement on. >> >>> >>> - A specification on how to mix in these extra bits into SKEYSEED generation >>> to gain postquantum security. >> >> The reason we specify modifying the public nonces (rather than doing a more >> fundamental change to the skeyseed computation) was to minimize changes >> to the IKE implementation itself (and in particular, the crypto parts). Is >> there >> a reason why we wouldn't continue with this approach? >> >>> >>> - Any additional counter meassures (such as increased minimum >>> keysizes) >> >> And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as >> the standard IKE versions are fixed to 128 bit keys) >> >>> >>> Do we need to know if these bits came from a QKD link, a QR link, or a >>> mutually shared onetime pad? If not, then these specifics should not >>> go into such an ikev2 extension. >>> >>> Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
