Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Cen Jung Tjhai <CJT@post-quantum.com> Thu, 03 August 2017 14:58 UTC

Return-Path: <CJT@post-quantum.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F008C13202F for <ipsec@ietfa.amsl.com>; Thu, 3 Aug 2017 07:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 awki5gJjLp5f for <ipsec@ietfa.amsl.com>; Thu, 3 Aug 2017 07:58:50 -0700 (PDT)
Received: from relay.ezis.com (relay.ezis.com [5.153.73.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4CC13235F for <ipsec@ietf.org>; Thu, 3 Aug 2017 07:58:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.41,316,1498518000"; d="scan'208,217";a="2178023"
Received: from unknown (HELO pqex01.post-quantum.com) ([192.168.142.3]) by ironport.ezis.com with ESMTP; 03 Aug 2017 15:58:49 +0100
Received: from PQEX02.post-quantum.com (192.168.142.18) by PQEX01.post-quantum.com (192.168.142.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 3 Aug 2017 15:58:47 +0100
Received: from PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3]) by PQEX02.post-quantum.com ([fe80::f470:9812:e4eb:5bd3%13]) with mapi id 15.00.1320.000; Thu, 3 Aug 2017 15:58:47 +0100
From: Cen Jung Tjhai <CJT@post-quantum.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] Proposed method to achieve quantum resistant IKEv2
Thread-Index: AQHTDGkCPH5PNqQgTkK9LOvm4SvL2g==
Date: Thu, 03 Aug 2017 14:58:47 +0000
Message-ID: <6721BCD4-D95F-42F1-86B8-400D0F6C1F2F@post-quantum.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.3.255.7]
Content-Type: multipart/alternative; boundary="_000_6721BCD4D95F42F186B8400D0F6C1F2Fpostquantumcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/0ylZ98jbquq-LFrK1sZzs_8Itus>
Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 Aug 2017 14:58:53 -0000

Hi Scott,

>> The other question about your proposed mechanism is how does it work; you just outline
>> a way to exchange ‘quantum resistant’ blobs, and don’t say how those blobs actually work.
>> I’m not talking about the cryptography, I’m talking about the authentication.  For an
>> authentication mechanism to work (for Alice to authenticate to Bob), we must have:
>> - Alice can generate the Blob
>> - Eve cannot generate the Blob
>> - Bob can verify that the Blob was generated properly
>> Saying “postquantum” doesn’t change the underlying problem.  You don’t specify how this
>> works (e.g. what Alice and Bob knows), and why the current authentication mechanisms
>> already in IKE aren’t sufficient

I wonder if there is a confusion there. The text basically proposed a method to do fragmentation of payloads carrying post-quantum public data in IKE_SA_INIT exchange and deal with backward compatibility.

In terms of authentication, those post-quantum blob fragments will need to be signed as per RFC7296. We don’t claim that the authentication is post-quantum. However, we do recognise that future mechanism can be introduced to make the authentication post-quantum, as you point out using post-quantum certificate for example.

Or have I misunderstood you?

Best regards,
CJ