ETSI TR 103 617 V1.1.1 (2018-09)

Quantum-Safe Virtual Private Networks

DTR/CYBER-QSC-009

General Information

• Status: Published
• Publication Date: 23-Sep-2018
• Technical Committee: CYBER QSC - Quantum-Safe Cryptography
• Current Stage: 12 - Completion
• Due Date: 11-Oct-2018
• Completion Date: 24-Sep-2018

Standards Content (Sample)

ETSI TR 103 617 V1.1.1 (2018-09)






TECHNICAL REPORT
Quantum-Safe Virtual Private Networks

---------------------- Page: 1 ----------------------
2 ETSI TR 103 617 V1.1.1 (2018-09)



Reference
DTR/CYBER-QSC-009
Keywords
quantum cryptography, security

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2018.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TR 103 617 V1.1.1 (2018-09)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Abbreviations . 9
4 General Virtual Private Network (VPN) requirements . 10
4.1 Background . 10
4.2 Requirements for hybrid use cases . 11
4.3 Direct drop-in requirements . 13
5 Internet Key Exchange (IKE) based requirements . 14
5.1 Background . 14
5.2 Hybrid requirements and solutions . 15
5.2.1 Requirements . 15
5.2.2 Solutions . 15
5.2.2.1 Introduction . 15
5.2.2.2 Establish an IKE connection as usual. 15
5.2.2.3 Add a new IKE_QS_KE phase between the IKE_SA_INIT and IKE_AUTH phases . 16
5.2.2.4 Utilizing the IKE_SA_INIT message . 17
5.2.2.5 Framework of hybrid quantum-safe key exchange . 17
5.3 Direct drop-in requirements . 18
5.4 Quantum-safe pre-shared keys for IKEv2 . 18
6 Transport Layer Security (TLS) based requirements . 20
6.1 Background . 20
6.2 Hybrid requirements and solutions . 22
6.2.1 Requirements . 22
6.2.2 Solutions . 23
6.3 Direct drop-in requirements . 24
7 Media Access Control Security (MACsec) based requirements . 25
7.1 Background . 25
7.2 Hybrid requirements . 26
7.3 Direct drop-in requirements . 27
8 Secure Shell (SSH) based requirements . 27
8.1 Background . 27
8.2 Analysis . 29
8.3 Hybrid requirements . 30
8.4 Direct drop-in requirements . 31
9 Conclusion . 32
Annex A: Experimental Results Related to Message Fragmentation . 33
Annex B: Additional Protocol Impacts . 34
History . 35


ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 103 617 V1.1.1 (2018-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Cyber Security (CYBER).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Recent research in the field of quantum computing has brought about a credible threat to the current state-of-the-art for
protecting electronic information [i.1]. The current data protection mechanisms that typically comprise cryptographic
systems rely on computational hardness as a means to protect sensitive data. This is to say that there are cryptographic
problems that are difficult or impossible to solve using conventional computing.
Because of recent advances in quantum computing, the quantum computer presents a serious challenge to widely used
current cryptographic techniques and assumptions. This is because the quantum computer tends to excel at certain
classes of problems. Among these problem classes are:
1) the integer factorization problem, which is used by the Rivest Shamir Adleman (RSA) cryptographic system;
and
2) the discrete logarithms problem, which is used by Elliptic Curve Cryptography (ECC).
Both RSA and ECC are common public-key cryptographic techniques that are used to secure much of the interchange
of information over the Internet as of 2017. While the integer factorization and discrete logs problems are difficult or
practically impossible to solve using a conventional computer, they become fairly trivial for a quantum computer.
ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 103 617 V1.1.1 (2018-09)
Academia, industry and governments have all made large investments in building a universal quantum computer
powerful enough to break currently used public-key algorithms. Therefore, new solutions based on hard problems that
cannot be efficiently solved by algorithms running on a quantum computer, such as Shor's algorithm, are needed to
secure the existing cryptographic protocols [i.2]. Once the appropriate replacements for currently used cryptographic
primitives are selected, these protocols can be updated. There is nevertheless an immediate harvest and decrypt threat
from a quantum-capable adversary.
The deployment of Virtual Private Networks (VPNs) is a common choice for governments and enterprises to securely
communicate between sites or to connect employees with offices.
Figure 1 describes how the harvest and decrypt attack would work against a VPN session. Each VPN session consists of
two stages:
1) the handshake; and
2) data exchange between the two parties.
During the handshake stage, the peers are authenticated, and the symmetric keys are established. Once that has been
completed, the peers can begin exchanging encrypted data securely.
For example, a secure communication session over a VPN can be harvested and stored today, then decrypted by an
adversary with access to a quantum computer or array of quantum computers at a later date. An adversary with a
quantum computer can then break the key establishment part of the handshake and derive the symmetric keys
negotiated between the peers. These symmetric keys can then be used to decrypt the encrypted data exchanged between
the peers. Any data transmitted today with longer-term confidentiality requirements is already vulnerable [i.2].

Figure 1: Harvest and Decrypt Attack by a Quantum Adversary
In 2017, quantum safe algorithm candidates were not mature enough to be used on their own. The National Institute of
Standards and Technology (NIST) in the United States of America recommends an approach to address this threat today
[i.13], by performing a quantum safe key establishment in parallel to a classic key establishment, and then merging the
shared secrets before session key generation. In this scenario, if the classic key establishment was performed using a
Federal Information Processing Standardization (FIPS) certified module, the entire system would maintain
FIPS-certification. For greater assurance, two quantum-resistant schemes can be used in parallel to a classic one. These
quantum-resistant schemes need to be based on different hard math problems in case an efficient quantum-based
solution is found during the algorithm evaluation process for one of the problems. It should be noted that this style of
hybrid cryptography is intended as an interim step, to provide protection of existing systems while the algorithm
standardization takes place. Once that standards process is completed, systems are expected to shift to only use quantum
safe algorithms.
Quantum safe algorithms differ noticeably from their classical equivalents. Some candidates have significantly larger
keys, and in the case of key-encapsulation, larger ciphertext. Some candidates have slower key generation and
cryptographic operation times, which impact protocol timing when used in an ephemeral mode for certain applications.
All of these properties have an impact on underlying protocols when quantum safe algorithms are used as a replacement
for classic equivalents. In the case of hybrid key establishment schemes, this impact is even greater since multiple
algorithms are used instead of one.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 103 617 V1.1.1 (2018-09)
The purpose of the present document is to clearly describe the range of protocol requirements necessary to add quantum
resistance to existing or new implementations of VPNs.

ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 103 617 V1.1.1 (2018-09)
1 Scope
The present document explores protocol requirements necessary to add quantum resistance to VPN technologies,
including client, server and architectural considerations. Specifically, requirements around protocols and key
establishment are considered, based on the multitude of systems that are at risk and require security updates before
quantum computers that can attack commercial cryptography are developed.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI White Paper No. 8, ISBN No. 979-10-92620-03-0: "Quantum Safe Cryptography and
Security: An introduction, benefits, enablers and challenges", June 2015.
[i.2] ETSI GR QSC 004 (V1.1.1): "Quantum-Safe Cryptography; Quantum-Safe threat assessment".
[i.3] IETF RFC 4251: "The Secure Shell (SSH) Protocol Architecture".
[i.4] OpenSSH project PROTOCOL file.
NOTE: Available online at http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.
[i.5] IETF RFC 4253: "The Secure Shell (SSH) Transport Layer Protocol".
[i.6] IETF RFC 4252: "The Secure Shell (SSH) Authentication Protocol".
[i.7] IETF RFC 4254: "The Secure Shell (SSH) Connection Protocol".
[i.8] IETF RFC 793: "Transmission Control Protocol".
[i.9] IETF Internet draft: "SSH Agent Protocol draft-miller-ssh-agent-00".
[i.10] IETF RFC 4255: "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints".
[i.11] IETF Internet Draft: "Framework to Integrate Post-quantum Key Exchanges into Internet Key
Exchange Protocol Version 2 (IKEv2)".
NOTE: Available online at https://tools.ietf.org/id/draft-tjhai-ipsecme-hybrid-qske-ikev2-01.txt.
[i.12] IETF Internet Draft: "Quantum-Safe Hybrid (QSH) Key Exchange for Transport Layer Security
(TLS) version 1.3".
NOTE: Available online at https://tools.ietf.org/id/draft-whyte-qsh-tls13-06.txt.
[i.13] NIST Post-Quantum Cryptography FAQs.
NOTE: Available online at https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/faqs.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 103 617 V1.1.1 (2018-09)
[i.14] IETF RFC 4301: "Security Architecture for the Internet Protocol".
[i.15] IETF RFC 7296: "The Internet Key Exchange Protocol Version 2 (IKEv2)".
[i.16] IETF Internet Draft: "Postquantum Pre-shared Keys for IKEv2".
NOTE: Available online at https://www.ietf.org/id/draft-ietf-ipsecme-qr-ikev2-02.txt.
[i.17] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
[i.18] The Viability of Post-Quantum X.509 Certificates.
NOTE: Available online at https://eprint.iacr.org/2018/063.
[i.19] S. Galbraith, C. Petit, B. Shani and Y. Ti: "On The Security of Supersingular Isogeny
Cryptosystems", 2016.
NOTE: Available online at https://eprint.iacr.org/2016/859.pdf.
[i.20] ETSI GR QSC 006 (V1.1.1): "Quantum-Safe Cryptography (QSC); Limits to Quantum Computing
applied to symmetric key sizes".
[i.21] IETF Internet Draft: "Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security
(TLS) version 1.2".
NOTE: Available online at https://datatracker.ietf.org/doc/draft-whyte-qsh-tls12/.
[i.22] IETF Internet Draft: "A Transport Layer Security (TLS) Extension for Establishing An Additional
Secret".
NOTE: Available online at https://datatracker.ietf.org/doc/draft-schanck-tls-additional-keyshare/.
[i.23] "The Double Ratchet Algorithm".
NOTE: Available online at https://www.signal.org/docs/specifications/doubleratchet/.
TM
[i.24] IEEE 802.1AE-2006 : "Local and Metropolitan Area Networks: Media Access Control (MAC)
Security".
TM
[i.25] IEEE 802.1AEbn-2011 : "Local and metropolitan area networks--Media Access Control (MAC)
Security Amendment 1: Galois Counter Mode--Advanced Encryption Standard-- 256 (GCM-AES-
256) Cipher Suite" (Amendment to IEEE Std 802.1AE-2006).
TM
[i.26] IEEE 802.1AEbw-2013 : "Local and metropolitan area networks-Media Access Control (MAC)
Security Amendment 2: Extended Packet Numbering" (Amendment to IEEE Std 802.1AE-2006).
TM
[i.27] IEEE 802.1X-2010 : "Local and metropolitan area networks--Port-Based Network Access
Control".
TM
[i.28] IEEE 802.1Xbx-2014 : "Local and metropolitan area networks -- Port-Based Network Access
Control Amendment 1: MAC Security Key Agreement Protocol (MKA) Extensions" (Amendment
to IEEE Std 802.1X-2010).
TM
[i.29] IEEE 802.1Xck : "Local and Metropolitan Area Networks - Port-Based Network Access Control
Amendment: YANG Data Model". (DRAFT).
NOTE: Available online at https://standards.ieee.org/develop/project/802.1Xck.html.
[i.30] IETF RFC 3394: "Advanced Encryption Standard (AES) Key Wrap Algorithm".
[i.31] IETF RFC 3748: "Extensible Authentication Protocol (EAP)".
[i.32] IETF RFC 5216: "The EAP-TLS Authentication Protocol".
TM
[i.33] IEEE 802.1AR : "Local and metropolitan area networks-Secure Device Identity".
[i.34] IETF RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 103 617 V1.1.1 (2018-09)
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AES Advanced Encryption Standard
AESKW Advanced Encryption Standard Key Wrap
AUTH Authentication
CA Certificate Authority
CAK Connectivity Association Key
CERT Certificates
CKN Connectivity association Key Name
DA Destination Address
DH Diffie-Hellman
EAP Extensible Authentication Protocol
EAPoL Extensible Authentication Protocol over LAN
ECC Elliptic Curve Cryptography
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithms
ETSI European Telecommunications Standards Institute
FIPS Federal Information Processing Standardization
HDR High Data Rate
HTTP HyperText Transfer Protocol
ICK Integrity Check Key
ICV Integrity Check Value
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IKE Internet Key Exchange
IKEv1 Internet Key Exchange version 1
IKEv2 Internet Key Exchange version 2
IP Internet Protocol
IPsec Internet Protocol security
KDF Key Derivation Function
KE Key Exchange
KEK Key Encryption Key
KEM Key Encapsulation Mechanism
KN Key Number
LAN Local Area Network
LHL Leftover Hash Lemma
LWE Learning With Errors
MAC Message Authentication Code
MACsec Media Access Control security
MIs Member Identifiers
MKA Media access control security Key Agreement
MKPDU Media access control security Key agreement Protocol Data Unit
MSK Master Session Key
MTU Maximum Transmission Unit
NATs Network Address Translators
NIST National Institute of Standards and Technology
PKI Public Key Infrastructure
PPK Post-quantum Pre-shared Key
PRF PseudoRandom Function
PSK Pre-Shared Key
QSC Quantum-Safe Cryptography
QSH Quantum Safe Hybrid
QS_SA Quasi Steady - State Approximation
QS_KE Quantum-Safe - Key Exchange
RFC Request For Comments
RSA Rivest Shamir Adleman
RTT Round Trip Time
SA Security Association
SAK Security Association Key
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 103 617 V1.1.1 (2018-09)
SC Secure Channel
SIDH Supersingular Isogeny Diffie–Hellman
SK Secret Key
SNMP Simple Network Management Protocol
SSH Secure Shell
SSHFP Secure Shell key Fingerprint
TCP Transmission Control Protocol
TLP Transport Layer Protocol
TLS Transport Layer Security
US United States (of America)
VPN Virtual Private Network
4 General Virtual Private Network (VPN) requirements
4.1 Background
The primary purpose of a VPN is to provide a secure connection between two end points. While the specific
technologies used to accomplish this can vary widely, the general goals are similar. A VPN then is the technology used
to construct a private network over public channels. Large organizations typically consist of different locations that are
geographically widespread. Each location can have its own Local Area Network (LAN) within which many servers and
client computers interconnect. Nonetheless, it would be necessary to connect LANs of different locations, and some
remote entities, to provide a single network service for the entire organization. Different locations can be connected by
separate, dedicated, and well-protected communication lines. However, as the number of sites increases, and they
become more physically separated, such a solution becomes cost prohibitive. Supporting access to this private network
by remote entities, such as traveling employees, can become infeasible since the number is extremely large and remote
entities can move. VPN allows the use of public networks to connect all these locations and entities as a single private
network.
Often, sensitive data is transmitted over a private network among internal servers, or between an internal server and an
internal client. Therefore, the security of data in transit over a VPN is critical. Since current VPN technologies utilize
public key cryptography extensively for its security, they are vulnerable against quantum attacks.
VPN architectures are often categorized into two connection types: Site-to-site VPN and Remote Access VPN. Because
of the different characteristics of these two types of VPN, the requirements differ.
Site-to-Site VPN
The site-to-site VPN establishes a secure tunnel between the local private networks of two physically separated
locations over public networks, such that the network behaves as if it is a single private network. An outsider of the
VPN can observe the existence of data traffic between the two sites, but cannot see who is connecting with whom, or
read the information in the data traffic. VPN was originally developed for this purpose. In addition, the VPN provides
authentication between the two parties.
The site-to-site VPN connects two sites semi-permanently, therefore, tunnel establishment might not be performed
frequently. Since the tunnel is spanned between only two gateways, flexibility to meet the needs of different
deployments is often preferred over the cost of complexity. Also, it is usually not overly difficult to set up a shared
secret between the two gateways or static self-signed certificates.
Remote Access VPN
The remote access VPN allows a personal device to connect into the organization's private network over the public
network such that the computing resources on this private network become available to the remote device. An outsider
can see the data traffic between the remote device and the gateway but cannot identify which computing resource in the
private network the remote device is connecting to or read or modify the information in the data traffic.
In contrast with site-to-site VPN, tunnel establishments occur very frequently in the remote access VPN. Also, client
(device) authentication is critical for remote access VPN. This is, in part, because when the number of client devices is
large, there is key management required to securely share secrets between the devices and the gateway.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 103 617 V1.1.1 (2018-09)
Underlying Security Protocols and Quantum Vulnerabilities
VPN achieves cryptographic security by the underlying security protocols. These include Internet Protocol Security
(IPSec) and Internet Key Exchange (IKE); Transport Layer Security (TLS); Media Access Control Security (MACsec);
Secure Shell (SSH), and others.
Some VPN protocols are used to establish security between network entities, i.e. at the network layer level, and some
between applications. All protocols accomplish data confidentiality and authentication using symmetric algorithms.
Most protocols accomplish entity authentication and key establishment using public key cryptography, while some rely
on pre-shared secrets. While public key based key establishment algorithms are typically negotiated between peers and
make phased system upgrades possible, the authentication algorithms are not typically negotiated with as much
flexibility since public key certificates contain only one public key type which makes system upgrades difficult.
However, some protocols have introduced more flexibility here such as TLS 1.3 [i.34].
Generally speaking the needs of each protocol listed above are relatively similar at a base level - confidentiality and
authentication - but how those are implemented may be very different depending on the use case. For example, when
TLS is used to establish a VPN between multiple corporate users and the head office, it may require client
authentication while TLS used between a web client and a public web server may only require server authentication.
Some of these specific needs are addressed in the relevant cl
...