Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Fri, 1 Jul 2016 00:16:10 +0000

Could multiple identifier aliases be used to provide different ids for the same key? This could help preserve anonymity until all id aliases are exhausted. By providing enough aliases, the same key can be reused multiple times until the aliases run out.

Dave

________________________________
On: 24 June 2016 11:26, "Scott Fluhrer (sfluhrer)" <[email-masked]> wrote:

> -----Original Message-----
> From: Paul Wouters [mailto:[email-masked]]
> 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