'[IPsec] Alternative Approach for Postquantum Preshared Keys in IKEv2'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [IPsec] Alternative Approach for Postquantum Preshared Keys in IKEv2
From:       "Valery Smyslov" <smyslov.ietf () gmail ! com>
Date:       2019-11-28 8:28:33
Message-ID: 036d01d5a5c5$d301f980$7905ec80$ () gmail ! com
[Download RAW message or body]

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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[prev in list] [next in list] [prev in thread] [next in thread] 