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
- [IPsec] IPsec with QKD Rodney Van Meter
- [IPsec] IPsec with QKD Rodney Van Meter
- Re: [IPsec] IPsec with QKD Rodney Van Meter
- Re: [IPsec] IPsec with QKD Paul_Koning
- Re: [IPsec] IPsec with QKD Rodney Van Meter
- Re: [IPsec] IPsec with QKD Paul_Koning
- Re: [IPsec] IPsec with QKD Rodney Van Meter
- Re: [IPsec] IPsec with QKD Rodney Van Meter
- Re: [IPsec] IPsec with QKD Greg Troxel
- Re: [IPsec] IPsec with QKD Tony Putman
- Re: [IPsec] IPsec with QKD Rodney Van Meter
- Re: [IPsec] IPsec with QKD Tony Putman
- Re: [IPsec] IPsec with QKD Paul_Koning