IETF Logo Mail Archive

Re: [IPsec] IPsec with QKD

<Paul_Koning@Dell.com> Wed, 29 October 2014 15:03 UTC

Return-Path: <Paul_Koning@dell.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 4EDC61A0390 for <ipsec@ietfa.amsl.com>; Wed, 29 Oct 2014 08:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 7MpH6f2DlbS7 for <ipsec@ietfa.amsl.com>; Wed, 29 Oct 2014 08:03:34 -0700 (PDT)
Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617301A036F for <ipsec@ietf.org>; Wed, 29 Oct 2014 08:03:16 -0700 (PDT)
DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version:Return-Path; b=TMga62rdhnUV3JJJvV8ReTLzva0R3hFdNn2krcX0O6bQeMob+6ESmgDf n+JFGjY91PmA7EiTsLbzTcmhD82jakZV0+msfSE2vg+QZQOe4iTOBzCGf sc2vt9iLKM3Oii1DUkY6mV31GUw0vklMZKAZGgSE7hjSp1w8EHohgNC/Z g=;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1414594996; x=1446130996; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=9nDpHr5YMWaLp6mvnzhzhaX7cuF3P/Vsccfe+iAN7rk=; b=NEc3rm7+hNNfNr0pwIbZHWeSdJx1Qn8ad5p0IIFgrCW/Rwd0LcPp7NCx OVuplBvYZvYH+QusX47cOz5unLktJtst2c4Ft95Qw6REPqVpk8b0Ue/3q yhZKNMJqs1JfMVLMCUuYXM0CAgOFKKtaj3CO1Dwv1/tDTjQmgmJsrWbuY k=;
X-LoopCount0: from 10.170.28.40
X-IronPort-AV: E=Sophos;i="5.04,810,1406610000"; d="scan'208,217";a="715237266"
From: Paul_Koning@Dell.com
To: rdv@sfc.wide.ad.jp
Thread-Topic: [IPsec] IPsec with QKD
Thread-Index: AQHP8hGnxyUwrEBowkSdbjGMq89vjJxEyhQAgAK4ggA=
Date: Wed, 29 Oct 2014 15:03:13 +0000
Message-ID: <264EF2D3-F00F-4D3C-9576-D61879AE9D44@dell.com>
References: <9FA67F6A-A730-46FC-925E-F16A1B686D73@sfc.wide.ad.jp> <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com>
In-Reply-To: <7134F6D8-587F-4EBA-8E23-C088D8F1EA25@dell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.177.90.69]
Content-Type: multipart/alternative; boundary="_000_264EF2D3F00F4D3C9576D61879AE9D44dellcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/54GIAZkdYPLp08LJMRODIJcJE1U
Cc: 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: Wed, 29 Oct 2014 15:03:42 -0000

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.

paul


On Oct 27, 2014, at 2:13 PM, Rodney Van Meter <rdv@sfc.wide.ad.jp<mailto:rdv@sfc.wide.ad.jp>> wrote:

...
* We have just uploaded an -01 of the I-D we wrote, incorporating feedback from several people, including Sean Turner, Sheila Frankel and Alan Mink.
  http://datatracker.ietf.org/doc/draft-nagayama-ipsecme-ipsec-with-qkd/?include_text=1

v2.23.0 | Report a Bug | By Email