< draft-tjhai-ipsecme-hybrid-qske-ikev2-02.txt   draft-tjhai-ipsecme-hybrid-qske-ikev2-03.txt >
Internet Engineering Task Force C. Tjhai Internet Engineering Task Force C. Tjhai
Internet-Draft M. Tomlinson Internet-Draft M. Tomlinson
Intended status: Informational Post-Quantum Intended status: Informational Post-Quantum
Expires: January 2, 2019 G. Bartlett Expires: July 18, 2019 G. Bartlett
S. Fluhrer S. Fluhrer
Cisco Systems Cisco Systems
D. Van Geest D. Van Geest
ISARA Corporation ISARA Corporation
Z. Zhang
Onboard Security
O. Garcia-Morchon O. Garcia-Morchon
Philips Philips
July 1, 2018 V. Smyslov
ELVIS-PLUS
January 14, 2019
Framework to Integrate Post-quantum Key Exchanges into Internet Key Framework to Integrate Post-quantum Key Exchanges into Internet Key
Exchange Protocol Version 2 (IKEv2) Exchange Protocol Version 2 (IKEv2)
draft-tjhai-ipsecme-hybrid-qske-ikev2-02 draft-tjhai-ipsecme-hybrid-qske-ikev2-03
Abstract Abstract
This document describes how to extend Internet Key Exchange Protocol This document describes how to extend Internet Key Exchange Protocol
Version 2 (IKEv2) so that the shared secret exchanged between peers Version 2 (IKEv2) so that the shared secret exchanged between peers
has resistance against quantum computer attacks. The basic idea is has resistance against quantum computer attacks. The basic idea is
to exchange one or more post-quantum key exchange payloads in to exchange one or more post-quantum key exchange payloads in
conjunction with the existing (Elliptic Curve) Diffie-Hellman conjunction with the existing (Elliptic Curve) Diffie-Hellman
payload. payload.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2019. This Internet-Draft will expire on July 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2
1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3
1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Document organization . . . . . . . . . . . . . . . . . . 4 1.4. Document Organization . . . . . . . . . . . . . . . . . . 4
2. Design criteria . . . . . . . . . . . . . . . . . . . . . . . 5 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Framework of Hybrid Post-quantum Key Exchange . . . . . . 6 3. The Framework of Hybrid Post-Quantum Key Exchange . . . . . . 6
3.1. Overall design . . . . . . . . . . . . . . . . . . . . . 6 3.1. Overall design . . . . . . . . . . . . . . . . . . . . . 6
3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 7 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 8
3.2.1. First Protocol Round . . . . . . . . . . . . . . . . 8 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 8
3.2.2. IKE_AUX round . . . . . . . . . . . . . . . . . . . . 10 3.2.2. INTERMEDIATE Round: Additional Key Exchanges . . . . 9
3.2.3. IKE_AUX exchange . . . . . . . . . . . . . . . . . . 11 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 10
3.3. Post-quantum Group Transform Type and Group Identifiers . 11 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 10
3.4. Hybrid Group Negotiation . . . . . . . . . . . . . . . . 12 4. Alternative Design . . . . . . . . . . . . . . . . . . . . . 11
3.5. Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. Alternative Design . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Security considerations . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
1.1. Problem Description 1.1. Problem Description
Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296 Internet Key Exchange Protocol (IKEv2) as specified in RFC 7296
[RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie- [RFC7296] uses the Diffie-Hellman (DH) or Elliptic Curve Diffie-
Hellman (ECDH) algorithm to establish a shared secret between an Hellman (ECDH) algorithm to establish a shared secret between an
initiator and a responder. The security of the DH and ECDH initiator and a responder. The security of the DH and ECDH
algorithms relies on the difficulty to solve a discrete logarithm algorithms relies on the difficulty to solve a discrete logarithm
problem in multiplicative and elliptic curve groups respectively when problem in multiplicative and elliptic curve groups respectively when
the order of the group parameter is large enough. While solving such the order of the group parameter is large enough. While solving such
a problem remains difficult with current computing power, it is a problem remains difficult with current computing power, it is
believed that general purpose quantum computers will be able to solve believed that general purpose quantum computers will be able to solve
this problem, implying that the security of IKEv2 is compromised. this problem, implying that the security of IKEv2 is compromised.
There are, however, a number of cryptosystems that are conjectured to There are, however, a number of cryptosystems that are conjectured to
be resistant against quantum computer attack. This family of be resistant against quantum computer attack. This family of
cryptosystems are known as post-quantum cryptography (PQC). It is cryptosystems are known as post-quantum cryptography (PQC). It is
ometime also referred to as quantum-safe cryptography (QSC) or sometimes also referred to as quantum-safe cryptography (QSC) or
quantum-resistant cryptography (QRC). quantum-resistant cryptography (QRC).
1.2. Proposed Extension 1.2. Proposed Extension
This document describes a framework to integrate QSC for IKEv2, while This document describes a framework to integrate QSC for IKEv2, while
maintaining backwards compatibility, to derive a set of IKE keys that maintaining backwards compatibility, to derive a set of IKE keys that
have resistance to quantum computer attacks. Our framework allows have resistance to quantum computer attacks. Our framework allows
the negotiation of one or more QSC algorithm to exchange data, in the negotiation of one or more QSC algorithm to exchange data, in
addition to the existing DH or ECDH key exchange data. We believe addition to the existing DH or ECDH key exchange data. We believe
that the feature of using more than one post-quantum algorithm is that the feature of using more than one post-quantum algorithm is
important as many of these algorithms are relatively new and there important as many of these algorithms are relatively new and there
may be a need to hedge the security risk with multiple key exchange may be a need to hedge the security risk with multiple key exchange
data from several distinct QSC algorithms. data from several distinct QSC algorithms.
The secrets established from each key exchange are combined in a way The secrets established from each key exchange are combined in a way
such that should the post-quantum secrets not be present, the derived such that should the post-quantum secrets not be present, the derived
shared secret is equivalent to that of the standard IKEv2; on the shared secret is equivalent to that of the standard IKEv2; on the
other hand, a post-quantum shared secret is obtained if both other hand, a post-quantum shared secret is obtained if both
classical and post-quantum key exchange data are present. This classical and post-quantum key exchange data are present. This
framework also applies to key exchanges in IKE Security Associations framework also applies to key exchanges in IKE Security Associations
(SAs) for Encapsulating Security Payload (ESP) [ESP] or (SAs) for Encapsulating Security Payload (ESP) [RFC4303] or
Authentication Header (AH) [AH], i.e. Child SAs, in order to provide Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to
a stronger guarantee of forward security. provide a stronger guarantee of forward security.
Some post-quantum key exchange payloads may have size larger than the Some post-quantum key exchange payloads may have size larger than the
standard MTU size, and therefore there could be issues with standard MTU size, and therefore there could be issues with
fragmentation at IP layer. IKE does allow transmission over TCP fragmentation at IP layer. IKE does allow transmission over TCP
where fragmentation is not an issue [RFC8229]; however, we believe where fragmentation is not an issue [RFC8229]; however, we believe
that a UDP-based solution will be required too. IKE does have a that a UDP-based solution will be required too. IKE does have a
mechanism to handle fragmentation within UDP [RFC7383], however that mechanism to handle fragmentation within UDP [RFC7383], however that
is only applicable to messages exchanged after the IKE_SA_INIT. To is only applicable to messages exchanged after the IKE_SA_INIT. To
use this mechanism, we use the IKE_AUX exchange as outlined in use this mechanism, we use the INTERMEDIATE exchange as outlined in
[I-D.smyslov-ipsecme-ikev2-aux]. With this mechanism, we do an [I-D.smyslov-ipsecme-ikev2-aux]. With this mechanism, we do an
initial key exchange, using a smaller, possibly non-quantum resistant initial key exchange, using a smaller, possibly non-quantum resistant
primitive, such as ECDH. Then, before we do the IKE_AUTH exchange, primitive, such as ECDH. Then, before we do the IKE_AUTH exchange,
we perform one or more IKE_AUX exchanges, each of which includes a we perform one or more INTERMEDIATE exchanges, each of which includes
secondary key exchange. As the IKE_AUX exchange is encrypted, the a secondary key exchange. As the INTERMEDIATE exchange is encrypted,
IKE fragmentation protocol RFC7383 can be used. The IKE SK values the IKE fragmentation protocol RFC7383 can be used. The IKE SK
will be updated after each exchange, and so the final IKE SK values values will be updated after each exchange, and so the final IKE SK
will depend on all the key exchanges, hence they are secure if any of values will depend on all the key exchanges, hence they are secure if
the key exchanges are secure. any of the key exchanges are secure.
Note that readers should consider the approach in this document as Note that readers should consider the approach in this document as
providing a long term solution in upgrading the IKEv2 protocol to providing a long term solution in upgrading the IKEv2 protocol to
support post-quantum algorithms. A short term solution to make IKEv2 support post-quantum algorithms. A short term solution to make IKEv2
key exchange quantum secure is to use post-quantum pre-shared keys as key exchange quantum secure is to use post-quantum pre-shared keys as
discussed in [I-D.ietf-ipsecme-qr-ikev2]. discussed in [I-D.ietf-ipsecme-qr-ikev2].
1.3. Changes 1.3. Changes
Changes in this draft in each version iterations. Changes in this draft in each version iterations.
draft-tjhai-ipsecme-hybrid-qske-ikev2-02
o Use new transform types to negotiate additional key exchanges,
rather than using the KE payloads of IKE SA.
draft-tjhai-ipsecme-hybrid-qske-ikev2-01 draft-tjhai-ipsecme-hybrid-qske-ikev2-01
o Use IKE_AUX to perform multiple key exchanges in succession. o Use INTERMEDIATE to perform multiple key exchanges in succession.
o Handle fragmentation by keeping the first key exchange (a standard o Handle fragmentation by keeping the first key exchange (a standard
IKE_SA_INIT with a few extra notifies) small, and encrypting the IKE_SA_INIT with a few extra notifies) small, and encrypting the
rest of the key exchanges. rest of the key exchanges.
o Simplify the negotiation of the 'extra' key exchanges. o Simplify the negotiation of the 'extra' key exchanges.
draft-tjhai-ipsecme-hybrid-qske-ikev2-00 draft-tjhai-ipsecme-hybrid-qske-ikev2-00
o We added a feature to allow more than one post-quantum key o We added a feature to allow more than one post-quantum key
exchange algorithms to be negotiated and used to exchange a post- exchange algorithms to be negotiated and used to exchange a post-
quantum shared secret. quantum shared secret.
o Instead of relying on TCP encapsulation to deal with IP level o Instead of relying on TCP encapsulation to deal with IP level
fragmentation, we introduced a new key exchange payload that can fragmentation, we introduced a new key exchange payload that can
be sent as multiple fragments within IKE_SA_INIT message. be sent as multiple fragments within IKE_SA_INIT message.
1.4. Document organization 1.4. Document Organization
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
summarizes design criteria. Section 3 describes how post-quantum key summarizes design criteria. Section 3 describes how post-quantum key
exchange is performed between two IKE peers and how keying materials exchange is performed between two IKE peers and how keying materials
are derived. The rationale behind the approach of this extension is are derived for both SAs and child SAs. A summary of alternative
described in Section 3. Section 4 discusses security considerations approaches that have been considered, but later discarded, are
an lastly, Section 5 discusses IANA considerations for the name described in Section 4. Section 5 discusses IANA considerations for
spaces introduced in this document. the namespaces introduced in this document, and lastly Section 6
discusses security considerations.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document, are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Design criteria 2. Design Criteria
The design of the proposed post-quantum IKEv2 is driven by the The design of the proposed post-quantum IKEv2 is driven by the
following criteria: following criteria:
1) Need for post-quantum cryptography in IPsec. Quantum computers 1) Need for post-quantum cryptography in IPsec. Quantum computers
might become feasible in the next 5-10 years. If current might become feasible in the next 5-10 years. If current
Internet communications are monitored and recorded today (D), Internet communications are monitored and recorded today (D),
the communications could be decrypted as soon as a quantum- the communications could be decrypted as soon as a quantum-
computer is available (e.g., year Q) if key negotiation only computer is available (e.g., year Q) if key negotiation only
relies on non post-quantum primitives. This is a high threat relies on non post-quantum primitives. This is a high threat
skipping to change at page 6, line 36 skipping to change at page 6, line 42
10) Backwards compatibility and interoperability. This is a 10) Backwards compatibility and interoperability. This is a
fundamental requirement to ensure that hybrid post-quantum IKEv2 fundamental requirement to ensure that hybrid post-quantum IKEv2
and a non-post-quantum IKEv2 implementations are interoperable. and a non-post-quantum IKEv2 implementations are interoperable.
11) FIPS compliance. IPsec is widely used in Federal Information 11) FIPS compliance. IPsec is widely used in Federal Information
Systems and FIPS certification is an important requirement. Systems and FIPS certification is an important requirement.
However, algorithms that are believed to be post-quantum are not However, algorithms that are believed to be post-quantum are not
FIPS compliant yet. Still, the goal is that the overall hybrid FIPS compliant yet. Still, the goal is that the overall hybrid
post-quantum IKEv2 design can be FIPS compliant. post-quantum IKEv2 design can be FIPS compliant.
3. The Framework of Hybrid Post-quantum Key Exchange 3. The Framework of Hybrid Post-Quantum Key Exchange
3.1. Overall design 3.1. Overall design
This design assigns new group identifiers (Transform Type 4) to the This design assigns new group identifiers (Transform Type 4) to the
various post-quantum key exchanges (which will be defined later). We various post-quantum key exchanges (which will be defined later). We
specifically do not make a distinction between classical (DH and specifically do not make a distinction between classical (DH and
ECDH) and post-quantum key exchanges, nor post-quantum algorithms ECDH) and post-quantum key exchanges, nor post-quantum algorithms
which are true key exchanges versus post-quantum algorithms that act which are true key exchanges versus post-quantum algorithms that act
as key transport mechanisms; all are treated equivalently by the as key transport mechanisms; all are treated equivalently by the
protocol. In order to support both hybrid key exchanges (that is, protocol. In order to support both hybrid key exchanges (that is,
relying on distinct key exchanges) and fragmentation, the proposed relying on distinct key exchanges) and fragmentation, the proposed
hybrid post-quantum IKEv2 protocol extends IKE [RFC7296] by adding hybrid post-quantum IKEv2 protocol extends IKE [RFC7296] by adding
additional key exchange messages (IKE_AUX) between the IKE_SA_INIT additional key exchange messages (INTERMEDIATE) between the
and the IKE_AUTH exchanges. In order to minimize communication IKE_SA_INIT and the IKE_AUTH exchanges. In order to minimize
overhead, only the key shares that are agreed to be used are actually communication overhead, only the key shares that are agreed to be
exchanged. In order to achieve this, the IKE_SA_INIT exchange now used are actually exchanged. In order to achieve this, the
includes notify payloads that negotiate the extra key exchanges to be IKE_SA_INIT exchange now includes notify payloads that negotiate the
used. The initiator IKE_SA_INIT message includes a notify that lists extra key exchanges to be used. The initiator IKE_SA_INIT message
the extra key exchange policy required by the initiator; the includes a notify that lists the extra key exchange policy required
responder selects one of the listed policies, and includes that as a by the initiator; the responder selects one of the listed policies,
notify in the response IKE_SA_INIT message. Then, the initiator and and includes that as a notify in the response IKE_SA_INIT message.
the responder perform one (or possibly more) IKE_AUX exchange; each Then, the initiator and the responder perform one (or possibly more)
such exchange includes a KE payload for the key exchange that was INTERMEDIATE exchange; each such exchange includes a KE payload for
negotiated. the key exchange that was negotiated.
Here is an overview of the initial exchanges: Here is an overview of the initial exchanges:
Initiator Responder Initiator Responder
-------------------------------------------------------- --------------------------------------------------------
<-- IKE_SA_INIT (and extra key exchange negotiation) --> <-- IKE_SA_INIT (and extra key exchange negotiation) -->
<-- {IKE_AUX (hybrid post-quantum key exchange)} --> <-- {INTERMEDIATE (hybrid post-quantum key exchange)} -->
... ...
<-- {IKE_AUX (hybrid post-quantum key exchange)} --> <-- {INTERMEDIATE (hybrid post-quantum key exchange)} -->
<-- {IKE_AUTH} --> <-- {IKE_AUTH} -->
The extra post-quantum key exchanges can use algorithms that are The extra post-quantum key exchanges can use algorithms that are
currently considered to be resistant to quantum computer attacks. currently considered to be resistant to quantum computer attacks.
These algorithms are collectively referred to as post-quantum These algorithms are collectively referred to as post-quantum
algorithms in this document. algorithms in this document.
Most post-quantum key agreement algorithms are relatively new, and
thus are not fully trusted. There are also many proposed algorithms,
with different trade-offs and relying on different hard problems.
The concern is that some of these hard problems may turn out to be
easier to solve than anticipated (and thus the key agreement
algorithm not be as secure as expected). A hybrid solution allows us
to deal with this uncertainty by combining a classical key exchanges
with a post-quantum one, as well as leaving open the possibility of
multiple post-quantum key exchanges.
The method that we use to perform hybrid key exchange also addresses
the fragmentation issue. The initial IKE_INIT messages do not have
any inherent fragmentation support within IKE; however that can
include a relatively short KE payload (e.g. one for group 14, 19 or
31). The rest of the KE payloads are encrypted within INTERMEDIATE
messages; because they are encrypted, the standard IKE fragmentation
solution [RFC7383] is available.
3.2. Overall Protocol 3.2. Overall Protocol
In the simplest case, the initiator is happy with a single key In the simplest case, the initiator is happy with a single key
exchange (and has no interest in supporting multiple), and he is not exchange (and has no interest in supporting multiple), and he is not
concerned with possible fragmentation of the IKE_SA_INIT messages concerned with possible fragmentation of the IKE_SA_INIT messages
(either because the key exchange he selects is small enough not to (either because the key exchange he selects is small enough not to
fragment, or he is confident that fragmentation will be handled fragment, or he is confident that fragmentation will be handled
either by IP fragmentation, or transport via TCP). In the following either by IP fragmentation, or transport via TCP). In the following
we overview the two protocol rounds involved in the hybrid post- we overview the two protocol rounds involved in the hybrid post-
quantum protocol. quantum protocol.
In this case, the initiator performs the IKE_SA_INIT as standard, In this case, the initiator performs the IKE_SA_INIT as standard,
inserting this prefered key exchange (which is possibly a post- inserting this preferred key exchange (which is possibly a post-
quantum algorithm) as the listed Transform Type 4, and including the quantum algorithm) as the listed Transform Type 4, and including the
initiator KE payload. If the responder accepts the policy, he initiator KE payload. If the responder accepts the policy, he
responds with an IKE_SA_INIT response, and IKE continues as usual. responds with an IKE_SA_INIT response, and IKE continues as usual.
If the initiator desires to negotiate multiple key exchanges, or he If the initiator desires to negotiate multiple key exchanges, or he
needs IKE to handle any possible fragmentation, then he uses the needs IKE to handle any possible fragmentation, then he uses the
protocol listed below. protocol listed below.
3.2.1. First Protocol Round 3.2.1. IKE_SA_INIT Round: Negotiation
In the first round, the IKE_SA_INIT request and response messages
negotiate the initial IKE SAs (as currently), as well as the key
exchanges that will be used within the IKE_AUX phase below.
The initiator negotiates cryptographic suites as per RFC7296, with
the listed Transform Type 4 (and KE payload) being either the first
key exchange on his desired list of key exchanges, or alternatively a
small classical one (in order to enable fragmentation support of the
later key exchanges). In addition, the initial IKE_SA_INIT message
will include the following two Notify payloads:
o The N(AUX_EXCHANGE_SUPPORTED) notify, as specified in
[I-D.smyslov-ipsecme-ikev2-aux]. This draft makes no requirements
about the included data.
o An N(EXTRA_KEY_EXCHANGE_POLICY) notify, which has a Protocol ID
and SPI Size of 0, and includes the below data.
This data will be the list of groups that the initiator is willing to
negotiate during the IKE_AUX phase below. The initiator signifies
this by specifying the specific list of the sets of key exchanges
that he will allow. The list MUST be ordered from most prefered to
least prefered. This is encoded as a series of 2 byte values; a
specified list of acceptable groups is given as the specific
Transform IDs, followed by a 0x00 value. For example, if the NewHope
post-quantum key exchange is 0x40, Round2 is 0x42, and SIKE is 0x47,
then the data payload:
0040 0000
0042 0047 0000
0042 0000
will signify that the initiator is willing to perform IKE_AUX with
either NewHope, Round2 followed by SIKE, or only Round2.
If the initiator is willing to skip the IKE_AUX phase, he can signify
that by including a 0000 value as a list; for example:
0040 0000
0042 0047 0000
0042 0000
0000
would signify either (NewHope), (Round2, SIKE), (Round2) or skipping
the IKE_AUX entirely.
When the responder that supports the hybrid exchange receives an
IKE_SA_INIT message with the AUX_EXHANGE_SUPPORTED and
EXTRA_KEY_EXCHANGE_POLICY notifies, then (after processing the IKE
message as normal), it scans through the policy listed within the
EXTRA_KEY_EXCHANGE_POLICY Notify payload. If the responder finds a
list of key exchanges that is consistent with its own policy, it
includes N(AUX_EXCHANGE_SUPPORTED) and N(EXTRA_KEY_EXCHANGE_LIST)
notifies, which both have 0 Protocol IDs and SPI sizes. The data for
the EXTRA_KEY_EXCHANGE_LIST notify would have data specifying the
list of acceptable Transform IDs as a series of 2 byte values. If
the responder's policy requires it to perform the extra key exchange,
but none of the key exchange lists are acceptable, it returns an
error in a notification with type NO_PROPOSAL_CHOSEN.
For example, if the single transform Round2 is accepted, then the
data payload will consist of:
0042
If the set Round2 and SIKE is accepted, then the data payload will
consist of:
0042 0047
If no IKE_AUX transforms is desired, then the data payload will be
empty (or alternatively no such notification is included, which
implies the same thing).
On success, the responder will create the IKE SA and SK values based
on SAi1, SAr1 and KE payloads as normal.
When the initiator receives the reply IKE_SA_INIT message, it checks Multiple key exchanges are negotiated using the standard IKEv2
for the existence of the AUX_EXCHANGE_SUPPORTED and mechanism, via SA payload. For this purpose several new transform
EXTRA_KEY_EXCHANGE_LIST notifies. If those notifies are not present, types, namely Additional Key Exchange 1, Additional Key Exchange 2,
then the initiator treats it as if no extra key exchanges were chosen Additional Key Exchange 3, etc., are defined. They are collectively
(and then can proceed by either rejecting the exchange, or proceed called Additional Key Exchanges and have slightly different semantics
using the single negotiated key exchange, depending on local policy). than existing IKEv2 transform types. They are interpreted as
additional key exchanges that peers agreed to perform in a series of
INTERMEDIATE exchanges. The possible transform IDs for these
transform types are the same as IDs for the transform type 4 (Diffie-
Hellman Group), so they all share a single IANA registry for
transform IDs.
If those notifies are present, then the responder verifies that the Key exchange method negotiated via transform type 4 MUST always take
key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST are one of place in the IKE_SA_INIT exchange. Additional Key Exchanges
the options within its local policy; if so, it processes the negotiated via newly defined transforms MUST take place in series of
IKE_SA_INIT message as normal, and then proceeds to the IKE_AUX INTERMEDIATE exchanges, in an order of the values of their transform
round. types, so that key exchange negotiated using transform type N always
precedes that of transform type N + 1. Each INTERMEDIATE exchange
MUST bear exactly one key exchange method. Note that with this
semantics, Additional Key Exchanges transforms are not associated
with any particular type of key exchange and don't have any specific
per transform type transform ID IANA registry. Instead they all
share a single registry for transform IDs - "Diffie-Hellman Group
Transform IDs", as well as Transform Type 4. All new key exchange
algorithms (both classical or quantum safe) should be added to this
registry. This approach gives peers flexibility in defining the ways
they want to combine different key exchange methods.
3.2.1.1. Note on responder policy check When forming a proposal the initiator adds transforms for the
IKE_SA_INIT exchange using transform type 4. In most cases they will
contain classical key exchange methods, however it is not a
requirement. Additional key exchange methods are proposed using
Additional Key Exchanges transform types. All these transform types
are optional, the initiator is free to select any of them for
proposing additional key exchange methods. Consequently, if none of
Additional Key Exchanges are included in the proposal, then this
proposal indicates performing standard IKEv2, as defined in
[RFC7296]. If the initiator includes any transform of type N (where
N is among Additional Key Exchanges) in the proposal, the responder
MUST select one of the algorithms proposed using this type. A
transform ID NONE may be added to those transform types which contain
key exchange methods that the initiator believes are optional.
One reason that the initiator may select the initial key exchange The responder performs negotiation using standard IKEv2 procedure
(the type 4 transform within the SAi1 payload) is not for security, described in Section 3.3 of [RFC7296]. However, for the Additional
but instead to simply establish keys to allow fragmentation of the Key Exchange types the responder's choice MUST NOT contain equal
IKE_AUX message. Because of this possibility, if the receiver sees a transform IDs (apart from NONE), and the ID selected for Transform
list of key exchanges listed within the EXTRA_KEY_EXCHANGE_LIST that Type 4 MUST NOT appear in any of Additional Key Exchange transforms.
satisfies its policies, it SHOULD accept it (assuming that the SAi1 In other words, all selected key exchange methods must be different.
payload is otherwise acceptable), even if the key payload within the
SAi1 is not necessary according to its policy.
3.2.2. IKE_AUX round 3.2.2. INTERMEDIATE Round: Additional Key Exchanges
For each extra key exchange agreed to in the IKE_SA_INIT exchange, For each extra key exchange agreed to in the IKE_SA_INIT exchange,
the initiator and the responder perform an IKE_SA_AUX exchange, as the initiator and the responder perform an INTERMEDIATE exchange, as
described in [I-D.smyslov-ipsecme-ikev2-aux]. described in [I-D.smyslov-ipsecme-ikev2-aux].
This exchange is as follows: This exchange is as follows:
Initiator Responder Initiator Responder
------------------------------------------------- -------------------------------------------------
HDR, SK {Ni2, KEi2} --> HDR, SK {Ni2, KEi2} -->
<-- HDR, SK {Nr2, KEr2} <-- HDR, SK {Nr2, KEr2}
The initiator sends a nonce in the Ni2 payload, and the key exchange The initiator sends a nonce in the Ni2 payload, and the key exchange
skipping to change at page 11, line 8 skipping to change at page 10, line 26
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED, Ni2 | Nr2 | SPIi | SPIr) = prf+ (SKEYSEED, Ni2 | Nr2 | SPIi | SPIr)
Note that the negotiated transform types (the encryption type, hash Note that the negotiated transform types (the encryption type, hash
type, prf type) are not modified. type, prf type) are not modified.
Both the initiator and the responder will use this updated key values Both the initiator and the responder will use this updated key values
for the next message. for the next message.
If the EXTRA_KEY_EXCHANGE_LIST has negotiated more than one key 3.2.3. IKE_AUTH Exchange
exchange, then this exchange is performed once for every key exchange
on the list.
3.2.3. IKE_AUX exchange
After the IKE_AUX exchanges have completed, then the initiator and After the INTERMEDIATE exchanges have completed, then the initiator
the responder will perform an IKE_AUTH exchange. This exchange is and the responder will perform an IKE_AUTH exchange. This exchange
the standard IKE exchange, except that the initiator and responder is the standard IKE exchange, except that the initiator and responder
signed octets are modified as described in signed octets are modified as described in
[I-D.smyslov-ipsecme-ikev2-aux]. [I-D.smyslov-ipsecme-ikev2-aux].
3.3. Post-quantum Group Transform Type and Group Identifiers 3.2.4. CREATE_CHILD_SA Exchange
In generating keying material within IKEv2, both initiator and
responder negotiate up to four cryptographic algorithms in the SA
payload of an IKE_SA_INIT or a CREATE_CHILD_SA exchange. One of the
negotiated algorithms is a Diffie-Hellman algorithm, which is used
for key exchange. This negotiation is done using the Transform Type
4 (Diffie-Hellman Group) where each Diffie-Hellman group is assigned
a unique value.
We expect that in the future, IANA will assign permanent values to
these transforms. Until it does, we will use the following values
for the below key exchanges (which will need to be specified in more
detail elsewhere). Official identifiers will be maintained by IANA
and updated during the NIST standardization process.
Name Number Key exchange
--------------------------------------------------
NIST_CANDIDATE_1 0x9100 The 1st candidate of
NIST PQC submission
NIST_CANDIDATE_2 0x9101 The 2nd candidate of
NIST PQC submission
Because we are using transforms in the private use space, both the
initiator and responder must include a vendor id with this payload:
d4 48 11 94 c0 c3 4c 9d d1 22 76 aa 9a 4e 80 d5 The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose of
creating additional Child SAs, rekeying them and rekeying IKE SA
itself. When creating or rekeying Child SAs, the peers may
optionally perform a Diffie-Hellmann key exchange to add a fresh
entropy into the session keys, in case of IKE SA rekeying, the key
exchange is mandatory.
This payload is the MD5 hash of "IKEv2 Quantum Safe Key Exchange If the IKE SA was created using multiple key exchange methods, the
v1"). If the other side does not include this vendor id, an peers may want continue using multiple key exchanges in the
implementation MUST NOT process these private use transforms as CREATE_CHILD_SA exchange too. If the initiator includes any
listed in this draft. Additional Key Exchanges transform in the SA payload (along with
Transform Type 4) and the responder agrees to perform additional key
exchanges, then the additional key exchanges are performed in a
series of the INFORMATIONAL exchanges that follows the
CREATE_CHILD_SA exchange in an order of the values of their transform
types, so that key exchange negotiated using transform type N always
precedes key exchange negotiated using transform type N + 1. Each
INFORMATIONAL exchange MUST bear exactly one key exchange method.
Key exchange negotiated via Transform Type 4 always takes place in
the CREATE_CHILD_SA exchange, as per IKEv2 specification.
3.4. Hybrid Group Negotiation Since after IKE SA is created the window size may be greater than
one, and multiple concurrent exchanges may be active, it is essential
to link the INFORMATIONAL exchanges together and with the
CREATE_CHILD_SA exchange. A new status type notification
ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its Notify Message
Type is <TBA by IANA>, Protocol ID and SPI Size are both set to 0.
The data associated with this notification is a blob meaningful only
to the responder, so that the responder can correctly link successive
exchanges. For the initiator the content of this notification is an
opaque blob.
Most post-quantum key agreement algorithms are relatively new, and The responder MUST include this notification in a CREATE_CHILD_SA or
thus are not fully trusted. There are also many proposed algorithms, INFORMATIONAL response message in case next exchange is expected,
with different trade-offs and relying on different hard problems. filling it with some data that would allow linking this exchange to
The concern is that some of these hard problems may turn out to be the next one. The initiator MUST copy the received notification with
easier to solve than anticipated (and thus the key agreement its content intact into the request message of the next exchange.
algorithm not be as secure as expected). A hybrid solution allows us
to deal with this uncertainty by combining a classical key exchanges
with a post-quantum one, as well as leaving open the possibility of
multiple post-quantum key exchanges.
The method that we use to perform hybrid key exchange also addresses Below is an example of three additional key exchanges.
the fragmentation issue. The initial IKE_INIT messages do not have
any inherent fragmentation support within IKE; however that can
include a relatively short KE payload (e.g. one for group 14, 19 or
31). The rest of the KE payloads are encrypted within IKE_AUX
messages; because they are encrypted, the standard IKE fragmentation
solution [RFC7383] is available.
3.5. Child SAs Initiator Responder
-----------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1)}
This method of performing hybrid key exchanges, by performing HDR(INFORMATIONAL), SK {Ni2, KEi2,
multiple exchanges in series, solves the issue by making the IKE SK N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
values be a function of all the key exchanges performed. Hence, we <-- HDR(INFORMATIONAL), SK {Nr2, KEr2,
achieve the goal of making the IKE exchange secure if any of the key N(ADDITIONAL_KEY_EXCHANGE)(link2)}
exchanges are secure.
This proposal allows the support of multiple post-quantum algorithms HDR(INFORMATIONAL), SK {Ni3, KEi3,
(in case we don't have full confidence in any one); this is N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
implemented by having the initiator list all the combinations of <-- HDR(INFORMATIONAL), SK {Nr3, KEr3,
extra key exchanges he finds acceptable. It is not anticipated that N(ADDITIONAL_KEY_EXCHANGE)(link3)}
there will be a need for a large number of different combinations of
key exchanges, hence this relatively simple encoding method was
selected as a reasonable compromise between simplicity and
functionality.
This method also allows us to fragment large post-quantum key HDR(INFORMATIONAL), SK {Ni4, KEi4,
exchanges; all the initiator needs to assure is that the initial key N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
exchange (which has the KE payloads exchanged during IKE_SA_INIT) is <-- HDR(INFORMATIONAL), SK {Nr4, KEr4}
small enough not to cause fragmentation.
4. Alternative Design 4. Alternative Design
This section gives an overview on a number of alternative approaches This section gives an overview on a number of alternative approaches
that we have considered, but later discarded. These approaches are: that we have considered, but later discarded. These approaches are:
o Sending the classical and post-quantum key exchanges as a single o Sending the classical and post-quantum key exchanges as a single
transform transform
We considered combining the various key exchanges into a single We considered combining the various key exchanges into a single
large KE payload; this effort is documented in a previous version large KE payload; this effort is documented in a previous version
of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This of this draft (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This
does allow us to cleanly apply hybrid key exchanges during the does allow us to cleanly apply hybrid key exchanges during the
child SA; however it does add considerable complexity, and child SA; however it does add considerable complexity, and
requires an independant fragmentation solution. requires an independent fragmentation solution.
o Sending post-quantum proposals and policies in KE payload only o Sending post-quantum proposals and policies in KE payload only
With the objective of not introducing unnecessary notify payloads, With the objective of not introducing unnecessary notify payloads,
we considered communicating the hybrid post-quantum proposal in we considered communicating the hybrid post-quantum proposal in
the KE payload during the first pass of the protocol exchange. the KE payload during the first pass of the protocol exchange.
Unfortunately, this design is susceptible to the following Unfortunately, this design is susceptible to the following
downgrade attack. Consider the scenario where there is an MitM downgrade attack. Consider the scenario where there is an MitM
attacker sitting between an initiator and a responder. The attacker sitting between an initiator and a responder. The
initiator proposes, through SAi payload, to use a hybrid post- initiator proposes, through SAi payload, to use a hybrid post-
skipping to change at page 16, line 4 skipping to change at page 15, line 4
The Total KE Payload Data Length indicates the size of the The Total KE Payload Data Length indicates the size of the
assembled KE payload data in octets. Finally, the actual fragment assembled KE payload data in octets. Finally, the actual fragment
is carried in Fragment KE Payload field. is carried in Fragment KE Payload field.
We discarded this approach because we believe that the working We discarded this approach because we believe that the working
group may not be happy using the RESERVED field to change the group may not be happy using the RESERVED field to change the
format of a packet and that implementers may not like the format of a packet and that implementers may not like the
complexity added from checking the fragmentation flag in each complexity added from checking the fragmentation flag in each
received payload. More importantly, fragmenting the messages in received payload. More importantly, fragmenting the messages in
this way may leave the system to be more prone to denial of this way may leave the system to be more prone to denial of
service (DoS) attacks. By using IKE_AUX to transport the large service (DoS) attacks. By using INTERMEDIATE to transport the
post-quantum key exchange payloads, there is no longer any issue large post-quantum key exchange payloads, there is no longer any
with fragmentation. issue with fragmentation.
o Group sub-identifier o Group sub-identifier
As discussed in Section 3.3, each group identifier is used to As discussed before, each group identifier is used to distinguish
distinguish a post-quantum algorithm. Further classification a post-quantum algorithm. Further classification could be made on
could be made on a particular post-quantum algorithm by assigning a particular post-quantum algorithm by assigning additional value
additional value alongside the group identifier. This sub- alongside the group identifier. This sub- identifier value may be
identifier value may be used to assign different security used to assign different security parameter sets to a given post-
parameter sets to a given post-quantum algorithm. However, this quantum algorithm. However, this level of details does not fit
level of details does not fit the principles of the document where the principles of the document where it should deal with generic
it should deal with generic hybrid key exchange protocol, not a hybrid key exchange protocol, not a specific ciphersuite.
specific ciphersuite. Furthermore, there are enough Diffie- Furthermore, there are enough Diffie- Hellman group identifiers
Hellman group identifiers should this be required in the future. should this be required in the future.
5. Security considerations 5. IANA Considerations
This document also adds the following Transform Types to the
"Transform Type Values" registry:
Type Description Used In Reference
------------------------------------------------------------------------
6 Additional Key Exchange 1 (optional in IKE, AH and ESP) [RFCXXXX]
7 Additional Key Exchange 2 (optional in IKE, AH and ESP) [RFCXXXX]
8 Additional Key Exchange 3 (optional in IKE, AH and ESP) [RFCXXXX]
9 Additional Key Exchange 4 (optional in IKE, AH and ESP) [RFCXXXX]
10 Additional Key Exchange 5 (optional in IKE, AH and ESP) [RFCXXXX]
11 Additional Key Exchange 6 (optional in IKE, AH and ESP) [RFCXXXX]
12 Additional Key Exchange 7 (optional in IKE, AH and ESP) [RFCXXXX]
This document also defines a new Notify Message Types in the "Notify
Message Types - Status Types" registry:
<TBA> ADDITIONAL_KEY_EXCHANGE
6. Security Considerations
The key length of the Encryption Algorithm (Transform Type 1), the The key length of the Encryption Algorithm (Transform Type 1), the
Pseudorandom Function (Transform Type 2) and the Integrity Algorithm Pseudorandom Function (Transform Type 2) and the Integrity Algorithm
(Transform Type 3), all have to be of sufficient length to prevent (Transform Type 3), all have to be of sufficient length to prevent
attacks using Grover's algorithm [GROVER]. In order to use the attacks using Grover's algorithm [GROVER]. In order to use the
extension proposed in this document, the key lengths of these extension proposed in this document, the key lengths of these
transforms SHALL be at least 256 bits long in order to provide transforms SHALL be at least 256 bits long in order to provide
sufficient resistance to quantum attacks. Accordingly the post- sufficient resistance to quantum attacks. Accordingly the post-
quantum security level achieved is at least 128 bits. quantum security level achieved is at least 128 bits.
skipping to change at page 17, line 33 skipping to change at page 17, line 5
authenticity. authenticity.
This draft does not attempt to address key exchanges with KE payloads This draft does not attempt to address key exchanges with KE payloads
longer than 64k; the current IKE payload format does not allow that longer than 64k; the current IKE payload format does not allow that
as a possibility. If such huge KE payloads are required, a work as a possibility. If such huge KE payloads are required, a work
around (such as making the KE payload a URL and a hash of the real around (such as making the KE payload a URL and a hash of the real
payload) would be needed. At the current time, it appears likely payload) would be needed. At the current time, it appears likely
that there will be plenty of key exchanges available that would not that there will be plenty of key exchanges available that would not
require such a workaround. require such a workaround.
6. References 7. References
[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005, <http://www.rfc-editor.org/info/rfc4302>.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for
Database Search", Proc. of the Twenty-Eighth Annual ACM
Symposium on the Theory of Computing (STOC 1996), 1996.
[I-D.ietf-ipsecme-qr-ikev2] 7.1. Normative References
Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov,
"Postquantum Preshared Keys for IKEv2", draft-ietf-
ipsecme-qr-ikev2-03 (work in progress), June 2018.
[I-D.smyslov-ipsecme-ikev2-aux] [I-D.smyslov-ipsecme-ikev2-aux]
Smyslov, V., "Auxiliary Exchange in the IKEv2 Protocol", Smyslov, V., "Intermediate Exchange in the IKEv2
draft-smyslov-ipsecme-ikev2-aux-00 (work in progress), Protocol", draft-smyslov-ipsecme-ikev2-aux-02 (work in
January 2018. progress), December 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[GROVER] Grover, L., "A Fast Quantum Mechanical Algorithm for
Database Search", Proc. of the Twenty-Eighth Annual ACM
Symposium on the Theory of Computing (STOC 1996), 1996.
[I-D.ietf-ipsecme-qr-ikev2]
Fluhrer, S., McGrew, D., Kampanakis, P., and V. Smyslov,
"Postquantum Preshared Keys for IKEv2", draft-ietf-
ipsecme-qr-ikev2-05 (work in progress), December 2018.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, (IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014, DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>. <https://www.rfc-editor.org/info/rfc7383>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
skipping to change at page 19, line 4 skipping to change at page 18, line 31
C. Tjhai C. Tjhai
Post-Quantum Post-Quantum
Email: cjt@post-quantum.com Email: cjt@post-quantum.com
M. Tomlinson M. Tomlinson
Post-Quantum Post-Quantum
Email: mt@post-quantum.com Email: mt@post-quantum.com
G. Bartlett G. Bartlett
Cisco Systems Cisco Systems
Email: grbartle@cisco.com Email: grbartle@cisco.com
S. Fluhrer S. Fluhrer
Cisco Systems Cisco Systems
Email: sfluhrer@cisco.com Email: sfluhrer@cisco.com
D. Van Geest D. Van Geest
ISARA Corporation ISARA Corporation
Email: daniel.vangeest@isara.com Email: daniel.vangeest@isara.com
Z. Zhang
Onboard Security
Email: zzhang@onboardsecurity.com
O. Garcia-Morchon O. Garcia-Morchon
Philips Philips
Email: oscar.garcia-morchon@philips.com Email: oscar.garcia-morchon@philips.com
Valery Smyslov
ELVIS-PLUS
Email: svan@elvis.ru
 End of changes. 55 change blocks. 
271 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/