[IPsec] Alternative Approach for Postquantum Preshared Keys in IKEv2

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 28 November 2019 08:28 UTC

Return-Path: <smyslov.ietf@gmail.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 7F319120048 for <ipsec@ietfa.amsl.com>; Thu, 28 Nov 2019 00:28:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9go73--u8M3M for <ipsec@ietfa.amsl.com>; Thu, 28 Nov 2019 00:28:36 -0800 (PST)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9472120019 for <ipsec@ietf.org>; Thu, 28 Nov 2019 00:28:35 -0800 (PST)
Received: by mail-lj1-x22b.google.com with SMTP id e10so18329032ljj.6 for <ipsec@ietf.org>; Thu, 28 Nov 2019 00:28:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=j+fb7rbObpmBClleSqqpL6RhQ5tIV3fgpOuS//eS0og=; b=sTmSZ5H3oMmpm1PX9q2174yFzU2DVafrClltqUC1daU1xrO8XL29fsZ9PP53PFKjV0 N4XEPiGBF/CSQaroXaUBpMshc6kzFrfL4WdApM+Fy31nfk/e5mD5BO8La127e8XdphMf oDmVUJRvi7qgOFm2NvemLL2keGT0tQ5mlRwFsLiYmg4C4rM2ANYNDwlgxqDImf9F9cMv X0125iSL1nTOQMEO38asOTJlfPm0FC//08HRN2H/5DrLslTJoF7Fql1jj6UOOtILEn6N Ld4mu7pSSOTLXzWsotdD2sjPA5YL+qvn73YFqUtMd/aEwweNGh1w2ZSGCK/hCrRoS/tY 24uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=j+fb7rbObpmBClleSqqpL6RhQ5tIV3fgpOuS//eS0og=; b=SNTAfxYIRtxnl5Jt2j4gGXif9Tl059rC+4LCeU4WY6/ZgXoobaUAiXs6Jrw9Mn/yGj yhYGNYDgVLc6+bmEfKd5GrA7MtgxfdypLbM+GB+Wu/CWbs0AyXbvQqqM5NrE6yWtkiGr uxsiPht7vBpSDAFyGczKqPFnCt+M1fr96sGuA5r9qMGAOgEXj/QpZjZdRhoIfBddNb44 jYfuGx8QWGUbPqDYADMP3bp+JtzKoZy2FgbqLSk+0KofnI1cVt6o0VwhKcGb+tweyC88 qmFfgpIe1mKWVC9sx9A3oIAovg6rNl65Vqa9n+W/Z4+j8d4govQqSadsX3q2Mb6/7FG5 n5Aw==
X-Gm-Message-State: APjAAAUWVvT8wuyFtwsYJoC5q1IIJ2w8k5zgyqSYsTz+3KM/ii7DoEbo 5KynPmbSHppu16j8lMG+A5jnf9mFFgg=
X-Google-Smtp-Source: APXvYqylXfW9yrcV9f513LzWQv3/+7Sqxdryl/83BV2Up91H7ixpeaGQcqIL+zvFuLwMxfIwuPGWQA==
X-Received: by 2002:a2e:84d0:: with SMTP id q16mr22540923ljh.48.1574929713755; Thu, 28 Nov 2019 00:28:33 -0800 (PST)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k25sm8200163ljg.22.2019.11.28.00.28.32 for <ipsec@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Nov 2019 00:28:33 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: IPsecME WG <ipsec@ietf.org>
Date: Thu, 28 Nov 2019 11:28:33 +0300
Message-ID: <036d01d5a5c5$d301f980$7905ec80$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdWlwYYtE8QceRTzSW6790pXFByOkQ==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/vULSdcqqOdOIn7zYDz9HAILPJ80>
Subject: [IPsec] Alternative Approach for Postquantum Preshared Keys in IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Nov 2019 08:28:37 -0000

Hi,

some time ago I've posted a new draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2".
The draft was presented at IETF106:
(https://datatracker.ietf.org/meeting/106/materials/slides-106-ipsecme-an-alternative-approach-for-postquantum-preshared-keys-in-ikev2-00)
But it seemed that few people have read it so far. So, here are some words what is this draft about.

AS you all know we have "Postquantum Preshared Keys for IKEv2" (draft-ietf-ipsecme-qr-ikev2) draft 
that is already in Publication Requested state. This draft defines a mechanism to achieve PQ security
by means of additional Preshared Key (PPK) that is mixed up in IKE SA keys calculation.
This approach is believed to be a temporary solution until new PK KE primitives are standardized.

One of the features of how PPK is used in draft-ietf-ipsecme-qr-ikev2 is that an initial IKE SA,
that is created as result of IKE_SA_INIT+IKE_AUTH is not quantum secure itself. This was
a WG decision to minimize changes to IKEv2. The idea was that if someone needs IKE SA
to be quantum secure, he/she will immediately do a rekey.

The problem is that in the "Group Key Management using IKEv2" (draft-yeung-g-ikev2),
that is just adopted as a WG document, the responder (Group Controller / Key Server)
transfers session keys to the initiator (Group Member) immediately once IKE SA between
them is created. Obviously, keys are sensitive information and they are not protected
by PPK in this case. The workaround suggested in draft-yeung-g-ikev2-16 is to perform
quite long series of exchanges (consuming more resources) to postpone session
keys transfer until the initial SA is rekeyed.

The draft "An Alternative Approach for Postquantum Preshared Keys in IKEv2" proposes
an alternative approach for using PPK by utilizing the IKE_INTERMEDIATE exchange,
in which PPK IDs are exchanged. This allows an initial IKE SA to be secure
against QC, that would substantially simplify G-IKEv2 implementation if PQ security
using PPK is needed.

This alternative approach can also be used in regular IKEv2. Compared
with draft-ietf-ipsecme-qr-ikev2 it has few advantages and a single
drawback - it requires an additional exchange for IKE SA to set up.
However, if IKE_INTERMEDIATE is used for some other (not yet defined)
purposes too, the PPK IDs can be piggybacked and thus having no such penalty
as an extra exchange.

Comments, reviews, opinions are very welcome.
Is it worth to adopt this draft as a WG document?

Regards,
Valery.

> A new version of I-D, draft-smyslov-ipsecme-ikev2-qr-alt-00.txt
> has been successfully submitted by Valery Smyslov and posted to the
> IETF repository.
> 
> Name:		draft-smyslov-ipsecme-ikev2-qr-alt
> Revision:	00
> Title:		An Alternative Approach for Postquantum Preshared Keys in IKEv2
> Document date:	2019-10-17
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-qr-alt-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-qr-alt/
> Htmlized:       https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-qr-alt-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-ikev2-qr-alt
> 
> 
> Abstract:
>    An IKEv2 extension defined in [I-D.ietf-ipsecme-qr-ikev2] allows
>    IPsec traffic to be protected against someone storing VPN
>    communications today and decrypting it later, when (and if) Quantum
>    Computers are available.  However, this protection doesn't cover an
>    initial IKEv2 SA, which might be unacceptable in some scenarios.
>    This specification defines an alternative way get the same protection
>    against Quantum Computers, which allows to extend it on the initial
>    IKEv2 SA.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat