Re: [IPsec] IPsec with QKD

Greg Troxel <gdt@ir.bbn.com> Fri, 31 October 2014 11:55 UTC

Return-Path: <gdt@ir.bbn.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69681A8935 for <ipsec@ietfa.amsl.com>; Fri, 31 Oct 2014 04:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEh4936e-NAM for <ipsec@ietfa.amsl.com>; Fri, 31 Oct 2014 04:55:25 -0700 (PDT)
Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577771A8931 for <ipsec@ietf.org>; Fri, 31 Oct 2014 04:55:25 -0700 (PDT)
Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id B8AF8A6E4; Fri, 31 Oct 2014 07:55:24 -0400 (EDT)
From: Greg Troxel <gdt@ir.bbn.com>
To: Paul_Koning@Dell.com
References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com> <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com>
OpenPGP: id=32611E25
X-Hashcash: 1:20:141031:kurosagi@sfc.wide.ad.jp::+4NUd+K2gRCkVG/K:000000000000000000000000000000000000001NFo
X-Hashcash: 1:20:141031:ipsec@ietf.org::FNq1wfM708rjrmQ8:0001hVU
X-Hashcash: 1:20:141031:rdv@sfc.wide.ad.jp::A4Nhb+lnbw5fFdp0:00000000000000000000000000000000000000000003iSZ
X-Hashcash: 1:20:141031:paul_koning@dell.com::YH+OsS3l0je5U9a3:000000000000000000000000000000000000000000aun
X-Hashcash: 1:20:141031:shigeya@wide.ad.jp::Z3sj9krZeXt5YL+Z:00000000000000000000000000000000000000000003Mk8
Date: Fri, 31 Oct 2014 07:55:24 -0400
In-Reply-To: <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com> (Paul Koning's message of "Wed, 29 Oct 2014 15:03:13 +0000")
Message-ID: <rmioasslahf.fsf@fnord.ir.bbn.com>
User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_v86Qc9omas6F5iUDGqxQYtfMtg
X-Mailman-Approved-At: Fri, 31 Oct 2014 09:00:06 -0700
Cc: rdv@sfc.wide.ad.jp, ipsec@ietf.org, kurosagi@sfc.wide.ad.jp, shigeya@wide.ad.jp
Subject: Re: [IPsec] IPsec with QKD
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Oct 2014 11:55:27 -0000

<Paul_Koning@Dell.com> writes:

> I wonder if this should be worded more generically.  This is really
> about an external key agreement mechanism.  QKD is one such mechanism,
> but it isn’t clear to me that the machinery depends on this.
> Suppose, for example, that you distributed copies of one-time pad
> CDROMs to both locations, and used the key ID as offset in the
> one-time-pad data.  This is a completely different key agreement
> scheme but it would seem to fit just as well.  The important point is
> that there is an external source of key material, which has the
> (assumed) property that the key material is known to the two endpoints
> of the IKE exchange, and to no other parties.

I agree that just having an external keying material abstraction makes
sense.   In particular, thinking about it in a larger context is likely
to force clarity on issues of how external keying material is named and
numbered, and how to deal with the possibility that bits which should
match might not.

There are multiple ways to use external material: as OTP, directly as
symmettric keys and by including it in the phase 2 hash.  We implemented
the first and third of these around 2002, and what's been published
about that system is at

  http://dx.doi.org/10.1145/863955.863982