Network Working Group CJ. Tjhai
Internet-Draft Post-Quantum
Intended status: Standards Track T. Heider
Expires: May 5, 2021 genua GmbH
V. Smyslov
ELVIS-PLUS
November 1, 2020
Beyond 64KB Limit of IKEv2 Payload
draft-tjhai-ikev2-beyond-64k-limit-00
Abstract
The maximum Internet Key Exchange Version 2 (IKEv2) payload size is
limited to 64KB. This makes IKEv2 not usable for conservative post-
quantum cryptosystem whose public-key is larger than 64KB. This
document describes the mechanisms and considerations to exchange such
large key-establishment data in IKEv2.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 5, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Tjhai, et al. Expires May 5, 2021 [Page 1]
Internet-Draft Beyond 64KB November 2020
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Fragmentation of Large Payload . . . . . . . . . . . . . . . 4
2.1. Hash and URL . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Key Exchange Payload . . . . . . . . . . . . . . . . 4
2.1.2. Certificate Payload . . . . . . . . . . . . . . . . . 5
2.2. Payload Fragmentation . . . . . . . . . . . . . . . . . . 5
2.2.1. Bulk Transfer and Confirmation . . . . . . . . . . . 6
2.2.2. Incremental Transfer and Confirmation . . . . . . . . 7
3. Operational Considerations . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Our digital communications are secured by public-key cryptography
algorithms that relies on computational hardness assumptions such as
the difficulty in factoring large integers or that of finding the
discrete logarithm on an elliptic curve group or finite-field.
Recent advances in quantum computing, however, have caused some
concerns on the security of these assumptions. It is conjectured
that these hard computational problems can be solved in polynomial
time when sufficiently large quantum computers become available. The
concerns have prompted the National Institute of Standards and
Technology (NIST) to initiate a process to standardize one or more
public-key algorithms that are quantum-resistant. This family of
algorithms is known as post-quantum or quantum-resistant
cryptographic algorithms.
It would be ideal if these cryptographic algorithms can be drop-in
replacements to the classical algorithms we currently use.
Unfortunately, almost all of the post-quantum cryptography algorithms
have either public-key, ciphertext or signature size that is many
times larger than their classical counterparts. One of the issues
that this will cause, in particular for UDP-based protocols such as
IPsec, is fragmentation of packets at IP layer. In the context of
IPsec/IKEv2 post-quantum key exchange, the fragmentation issue can be
addressed by sending the post-quantum exchange data in
IKE_INTERMEDIATE [I-D.ietf-ipsecme-ikev2-intermediate], which is the
Tjhai, et al. Expires May 5, 2021 [Page 2]
Internet-Draft Beyond 64KB November 2020
intermediary state between IKE_SA_INIT and IKE_AUTH. This is the
approach taken in [I-D.ietf-ipsecme-ikev2-multiple-ke] whereby a
classical and one or more post-quantum key exchanges are combined in
order to establish security associations that are quantum-resistant.
Because all public-key cryptography algorithms rely on computational
hardness assumptions, the confidence of a cryptographic algorithm is
an important consideration. An algorithm that has been well-studied
and field-tested is better trusted than newer ones. Unfortunately,
the confidence of post-quantum cryptographic algorithms is relatively
low. All of the algorithms submitted to NIST post-quantum
standardization are based on new computational hardness assumptions
and despite being conjectured to be resistant to quantum computer
attacks, they have not been well cryptanalyzed compared to the
classical counterparts. An exception to this is the Goppa-code based
McEliece cryptosystem [McEliece] which has withstood years of
cryptanalysis since 1978 and still remains unbroken. It is not
surprising that a more efficient and CCA secure version of McEliece
cryptosystem, Classic McEliece [CM], is selected as one of the
finalists in NIST post-quantum standardization. Furthermore, this
cryptosystem has also been recommended for long-term confidentiality
protection of data, see [BSI].
While there is interest in using McEliece cryptosystem, in particular
for information that needs to remain secure for a long time, there is
a challenge in integrating it with IKEv2 [RFC7296]. One
characteristic of McElieces cryptosystem is the very asymmetric size
of its ciphertext and public-key. While its ciphertext is the
smallest compared to all other post-quantum key-establishment
algorithms submitted to NIST, the size of its public-key, however, is
the largest. The smallest public-key size of Classic McEliece is
255KB. This presents a problem if one were to use Classic McEliece
for key-establishment with IKEv2, as the maximum payload size
supported by IKEv2 is limited to 64KB. This document describes a
mechanism to support IKEv2 key-exchange with key size larger than
64KB, building on the works in [I-D.ietf-ipsecme-ikev2-multiple-ke]
and [I-D.ietf-ipsecme-ikev2-intermediate].
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document assumes familiarity with IKEv2 concept described in
[RFC7296].
Tjhai, et al. Expires May 5, 2021 [Page 3]
Internet-Draft Beyond 64KB November 2020
2. Fragmentation of Large Payload
A method to extend IKEv2 that allows quantum-resistant shared secret
to be derived from at least one post-quantum key-establishment
algorithm is proposed in [I-D.ietf-ipsecme-ikev2-multiple-ke]. Each
post-quantum key-establishment data is transported using an
IKE_INTERMEDIATE message, which appears following an IKE_SA_INIT
exchange. This is necessary because most post-quantum key-
establishment data are larger than 1KB and therefore are likely to be
dropped by firewalls and network middleboxes if they are sent in the
IKE_SA_INIT message over a UDP channel. IKEv2 has a mechanism to
handle IP-level fragmentation [RFC7383], but it is only available to
messages sent after the IKE_SA_INIT exchange. As such, it is
necessary to send these post-quantum key-establishment payloads in
IKE_INTERMEDIATE so that it can benefit from the IKEv2 message
fragmentation mechanism.
IKEv2 message fragmentation [RFC7383] allows a big payload to be
broken up into a number of smaller UDP datagrams. However, this
mechanism can only be used to fragment payloads up to 64KB in size.
For larger messages, different mechanisms are required and two of
which are discussed below.
2.1. Hash and URL
[RFC7296] defines a mechanism whereby an authentication payload such
as a certificate can be encoded using a hash value and a URL. A peer
utilizes HTTP_CERT_LOOKUP_SUPPORTED Notify payload to indicate that
X.509 certificates are not transported in-band, instead the other
peer shall fetch the certificates from the given URL and verify its
integrity from the hash value. In this way, the peer needs to send
20 octets plus a variable length URL only over the wire, instead of a
few kilobytes of payload, which is useful in the event IKEv2 message
fragmentation is not available.
Large public keys can be transported by reusing the same technique
and this can be done in two ways, as described below.
2.1.1. Key Exchange Payload
The Key Exchange Data field of IKEv2 Key Exchange Payload contains a
single format, which is a blob that is only meaningful to the
specified key exchange method. In order to support hash and URL
data, an encoding format needs to be specified on the header.
Tjhai, et al. Expires May 5, 2021 [Page 4]
Internet-Draft Beyond 64KB November 2020
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C|F| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Exchange Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The reserved bit-field F above specifies the encoding format. If it
is 0, the Key Exchange Data is a blob as specified in RFC7296. On
the other hand if it is 1, the Key Exchange Data is in the form of
hash and URL format, whereby the hash value is the SHA3-256 digest
[FIPS-202] of the replaced value truncated to 20 octets and the URL
value is a variable length URL (in either http or https schema) that
resolves to the DER-encoded of the replaced value itself.
Because the hash and URL value is transported in a Key Exchange
Payload, it is possible to support the use-case of a single post-
quantum key-establishment with large public-key. This payload will
be sent as part of IKE_SA_INIT exchange and it will not require
IKE_INTERMEDIATE exchanges.
2.1.2. Certificate Payload
An alternative is to re-purpose Certificate Payload to carry the hash
and URL value of the post-quantum key-establishment data. At the
time of writing, the IANA registry defines two hash and URL encoding
values, namely X.509 certificate and X.509 certificate bundle. In
order to use this payload, a new encoding value for key establishment
data will be required.
Because a Certificate Payload is part of IKE_AUTH message, unlike the
previous approach, the hash and URL value of the key-establishment
data shall be transported via IKE_INTERMEDIATE message. As such, it
will not be able to support a single post-quantum key-establishment
with a large public-key case. Furthermore, it is semantically
incorrect to repurpose Certificate Payload, which is intended to
carry authentication data, to transport key-establishment data.
2.2. Payload Fragmentation
As mentioned earlier, IKEv2 support for fragmentation as specified in
[RFC7383] allows IKE messages up to 64KB to be broken down into
smaller fragments. While the size of IKE payloads is constrained to
Tjhai, et al. Expires May 5, 2021 [Page 5]
Internet-Draft Beyond 64KB November 2020
a 16-bit field, an IKE message itself has a 32-bit length field and
therefore, in order to support payloads larger than 64KB limit, a
fragmentation needs to be carried out at an upper level. In this
case, the large key-establishment data is first fragmented into a
number of payload fragments that are no bigger than 64KB and each of
which is subjected to further fragmentation using IKEv2 standard
message fragmentation when transported in IKE_INTERMEDIATE messages.
There are two possible ways to perform large payload fragmentation,
as discussed below.
2.2.1. Bulk Transfer and Confirmation
The large key-establishment payload is first split into a sequence of
Key Exchange payload chunks where each share the same value of Key
Exchange Method value and has no more than 64KB in size. This
sequence of payload chunks is encrypted and is treated as an
Encrypted and Authenticated payload as per Section 3.14 of [RFC7296],
which is then sent over an IKE_INTERMEDIATE message.
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi1, Ni,
N(IKEV2_FRAGMENTATION_SUPPORTED)*,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1, KEr1, Nr,
N(IKEV2_FRAGMENTATION_SUPPORTED)*,
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
HDR, SK{KEi2.1, KEi2.2, KEi2.3, ...} --->
<--- HDR, SK{KEr2, ...}
*: optional
While the IKE header (HDR) has a 32-bit field to denote the length of
its message, that for Encrypted payload header (SK) is capped at
16-bit, which is not long enough. As a consequence, the payload
length field of the Encrypted Payload SHALL be set to 0. Because the
Encrypted payload is always the last payload in an IKE message, it is
possible to compute the encrypted IKE payload length instead of
relying on the information in its payload length field.
When IKEv2 standard message fragmentation is used, each of the Key
Exchange payload chunk is subjected to further fragmentation as per
[RFC7383].
Tjhai, et al. Expires May 5, 2021 [Page 6]
Internet-Draft Beyond 64KB November 2020
2.2.2. Incremental Transfer and Confirmation
As stated in Section 4 of [RFC7383], if any single fragment is lost,
the receiving peer will not be able to reassemble the original large
key-establishment payload. The above bulk transfer is susceptible to
this issue. There is another way to transfer these payload chunks
that is less susceptible to this, but at the cost of higher latency.
Instead of transferring in a bulk, each Key Exchange payload chunk
must be acknowledged prior to sending the subsequent chunk. As
before, the large key-establishment payload is split over several Key
Exchange payload chunks where each of them share the same Key
Exchange Method value. Each chunk is then sent to the peer using the
IKE_INTERMEDIATE message, and each one must be acknowledged by the
receiving peer before the subsequent chunk can be sent.
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi1, Ni,
N(IKEV2_FRAGMENTATION_SUPPORTED)*,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1, KEr1, Nr,
N(IKEV2_FRAGMENTATION_SUPPORTED)*,
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
HDR, SK{KEi2.1, ...} --->
<--- HDR, SK{}
HDR, SK{KEi2.2, ...} --->
<--- HDR, SK{}
HDR, SK{KEi2.3, ...} --->
<--- HDR, SK{KEr2, ...}
HDR, SK{} --->
*: optional
In order to support key-encapsulation mechanism, the receiving peer
has to wait until the entire chunks are received before it can
respond with its own Key Exchange payload, which may not be large.
While the description above focuses on the transfer of Key Exchange
payload larger than 64KB, the same approach can be used to transfer
large public-key, certificate or signature if there is a need to
Tjhai, et al. Expires May 5, 2021 [Page 7]
Internet-Draft Beyond 64KB November 2020
support hybrid authentication or even multiple certificates with
large constituent component.
3. Operational Considerations
While using hash and URL method to transport large key-establishment
data requires minimal modification to IKEv2 protocol, there are
disadvantages from deployment point of view that may make this method
impractical. Firstly, an IKE peer that originates a hash and URL
value will also need to implement additional infrastructure so that
it can serve HTTP requests in order to allow the actual key-
establishment data to be fetched. While this may not be an issue for
Internet facing peers, in the context of road-warrior or remote-
access cases, the hash and URL value is initiated by an IKE peer that
is usually a device sitting behind a network address translation
(NAT) device and as such, it may not be able to run a publicly
reachable HTTP server infrastructure on the same device. An possible
solution for these cases is to publish the key-establishment data to
a separate server, which is not practical as one cannot expect an IKE
initiator to always have deployed an HTTP server. Lastly, IKE peers
are predominantly deployed at the network edge where strict firewall
rules are generally enforced. The need to open up another port to
serve HTTP requests may cause either technical or policy complication
that render this approach unacceptable.
Unlike the aforementioned hash and URL method, the payload
fragmentation method does not require additional infrastructure,
however, there is non-zero probability of lost packets when sending a
large number of fragments over a UDP connection. Given a set of
fragments, when transmitted, each one of them is not individually
acknowledged and if any one of them is lost, the entire set will have
to be retransmitted. As a consequence, given the size of the payload
and also the potential of multiple retransmissions, there may be a
noticeable delay in establishing an security association (SA), in
particular in lossy network conditions. Therefore, implementations
MAY use a longer timeout value for the purpose of dead-peer
detection, but a balance needs to be struck as too large of a value
will open up security vulnerabilities as discussed in the following
section. In the unlikely event where there is a frequent
retransmission due to loss of fragments, implementations MAY send the
IKE messages over a TCP connection as specified in [RFC8229]. In
this instance, the peers SHOULD NOT advertise support for IKE
fragmentation as this is already handled inherently by the TCP
stream.
Tjhai, et al. Expires May 5, 2021 [Page 8]
Internet-Draft Beyond 64KB November 2020
4. Security Considerations
The hash and URL approach is vulnerable to (distributed) denial of
service attacks as an unauthenticated rogue peer may trick a
legitimate peer to fetch a large amount of random meaningless data
from a remote server. Implementations SHOULD NOT blindly download
all of the data in the given URL. Because a legitimate key-
establishment payload should be DER-encoded, they SHOULD download the
first few octets to determine the length of the ASN.1 structure
representing these octets, then only continue to download the
remaining decoded number of octets if the length is expected for the
chosen key-establishment algorithm. It should be noted that the
content of the data to be downloaded may be under attacker's control
and therefore even if the length is as expected, the content may be
meaningless bit that is of no use for key-establishment.
There is no exception to the payload fragmentation method, it is also
vulnerable to the same attack vectors. Malicious peers may send a
large number of fragments, but incomplete, to the legitimate peer
causing memory exhaustion.
In order to counter these attacks, downloading or accepting the
transfer of a large number of octets SHOULD only be carried out when
the peer has been authenticated. In other words, key-establishment
using large data should not be done to establish an IKE SA, but it
should only be used to establish Child SA or rekeying of IKE SA from
Child SA. If, for whatever reason, an IKE SA has to be established
using the large key-establishment data, then it is RECOMMENDED that
the strategies and recommendations described in [RFC8019] be
implemented.
If TCP encapsulation is used, refer to the security considerations in
[RFC8229].
Lastly, downloading or transferring large amounts of data is an
expensive operation, bandwidth and memory wise. Consequently,
implementations should consider using a longer rekeying interval or
SHOULD consider relaxing forward secrecy requirements but using CCA-
secure key-establishment algorithm only. With chosen-ciphertext
attack (CCA)-secure schemes, there is no loss in security if the
public-key is reused.
5. References
Tjhai, et al. Expires May 5, 2021 [Page 9]
Internet-Draft Beyond 64KB November 2020
5.1. Normative References
[I-D.ietf-ipsecme-ikev2-intermediate]
Smyslov, V., "Intermediate Exchange in the IKEv2
Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work
in progress), September 2020.
[I-D.ietf-ipsecme-ikev2-multiple-ke]
Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2-
multiple-ke-01 (work in progress), July 2020.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>.
5.2. Informative References
[BSI] Federal Office for Information Security, "Cryptographic
Mechanisms: Recommendations and Key Lengths", 2020, <https
://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publication
s/TechGuidelines/TG02102/BSI-TR-02102-1.pdf>.
[CM] Classic McEliece submission team, "Classic McEliece: NIST
post-quantum cryptography standardization finalist", 2020,
<https://classic.mceliece.org/>.
[FIPS-202]
National Institute of Standards and Technology, "SHA-3
Standard: Permutation-Based Hash and Extendable-Output
Functions", 2015, <https://doi.org/10.6028/NIST.FIPS.202>.
[McEliece]
McEliece, R., "A Public-key Cryptosystem based on
Algebraic Coding Theory", DSN Progress Report 42-44,
1978.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Tjhai, et al. Expires May 5, 2021 [Page 10]
Internet-Draft Beyond 64KB November 2020
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
Protocol Version 2 (IKEv2) Implementations from
Distributed Denial-of-Service Attacks", RFC 8019,
DOI 10.17487/RFC8019, November 2016,
<https://www.rfc-editor.org/info/rfc8019>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>.
Authors' Addresses
CJ Tjhai
Post-Quantum
UK
Email: cjt@post-quantum.com
Tobias Heider
genua GmbH
DE
Email: me@tobhe.de
Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd) 124460
RU
Phone: +7 495 276 0211
Email: svan@elvis.ru
Tjhai, et al. Expires May 5, 2021 [Page 11]