-----Original Message-----
From: Scott Fluhrer (sfluhrer) [mailto:sfluh...@cisco.com]
Sent: Friday, June 24, 2016 11:26 AM
To: p...@nohats.ca; David McGrew <mcg...@cisco.com>
Cc: Waltermire, David A. (Fed) <david.walterm...@nist.gov>; IPsecME WG
<ipsec@ietf.org>; Panos Kampanakis (pkampana) <pkamp...@cisco.com>
Subject: RE: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME
WG document
> -----Original Message-----
> From: Paul Wouters [mailto:p...@nohats.ca]
> 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
