-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-ietf-ipsecme-ikev2-multiple-ke-00.xml
1571 lines (1373 loc) · 89.2 KB
/
draft-ietf-ipsecme-ikev2-multiple-ke-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC9242 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9242.xml">
<!ENTITY I-D.tjhai-ikev2-beyond-64k-limit SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.tjhai-ikev2-beyond-64k-limit.xml">
<!ENTITY I-D.ietf-ipsecme-g-ikev2 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ipsecme-g-ikev2.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5723 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5723.xml">
<!ENTITY RFC6023 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6023.xml">
<!ENTITY RFC7296 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC7383 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7383.xml">
<!ENTITY RFC8019 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8019.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8784 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8784.xml">
]>
<rfc docName="draft-ietf-ipsecme-ikev2-multiple-ke-12" updates="7296" category="std" ipr="*trust200902" consensus="true"><?rfc compact="yes"?>
<?rfc text-list-symbols="ooo*-o+"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="Multiple Key Exchanges in IKEv2">Multiple Key Exchanges in IKEv2</title>
<author fullname="C. Tjhai" initials="C." surname="Tjhai">
<organization>Post-Quantum</organization>
<address><postal><street></street>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="M. Tomlinson" initials="M." surname="Tomlinson">
<organization>Post-Quantum</organization>
<address><postal><street></street>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="G. Bartlett" initials="G." surname="Bartlett">
<organization>Quantum Secret</organization>
<address><postal><street></street>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer">
<organization>Cisco Systems</organization>
<address><postal><street></street>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="D. Van Geest" initials="D." surname="Van Geest">
<organization>ISARA Corporation</organization>
<address><postal><street></street>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon">
<organization>Philips</organization>
<address><postal><street></street>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Valery Smyslov" initials="V." surname="Smyslov">
<organization>ELVIS-PLUS</organization>
<address><postal><street></street>
</postal>
<email>[email protected]</email>
</address>
</author>
<date/>
<workgroup>Internet Engineering Task Force (IETF)</workgroup>
<abstract>
<t> This document describes how to extend the Internet Key Exchange Protocol
Version 2 (IKEv2) to allow multiple key exchanges to take place
while computing a shared secret during a Security Association (SA) setup.
</t>
<t> The primary application of this feature in IKEv2 is the ability to perform one or more
post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange,
so that the resulting shared key is resistant against quantum computer attacks.
Since there is currently no post-quantum key exchange that is as well-studied as (EC)DH,
performing multiple key exchanges with different post-quantum algorithms along
with the well-established classical key exchange algorithms addresses this concern, since the
overall security is at least as strong as each individual primitive.
</t>
<t> Another possible application for this extension is the ability to combine several key exchanges
in situations when no single key exchange algorithm is trusted by both initiator and responder.
</t>
<t> This document utilizes the IKE_INTERMEDIATE exchange, by means of which multiple key exchanges are
performed when an IKE SA is being established. It also introduces a new IKEv2 exchange IKE_FOLLOWUP_KE,
which is used for the same purpose when the IKE SA is up (during rekeys or creating additional Child SAs).
</t>
<t> This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)"
to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num"
to "Key Exchange Method". It also renames an IANA registry for this transform type
from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to
"Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize
key exchange algorithms that can be used in IKEv2.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" >
<section title="Problem Description" ><t>
Internet Key Exchange Protocol (IKEv2) as specified in <xref target="RFC7296"/>
uses the Diffie-Hellman (DH) or Elliptic Curve
Diffie-Hellman (ECDH) algorithm, which shall be referred to as (EC)DH collectively,
to establish a shared secret
between an initiator and a responder. The security of the (EC)DH algorithms relies
on the difficulty to solve a discrete logarithm
problem in multiplicative (and respectively elliptic curve) groups when
the order of the group parameter is large enough. While solving such
a problem remains infeasible with current computing power, it is
believed that general purpose quantum computers will be able to solve
this problem, implying that the security of IKEv2 is compromised.
There are, however, a number of cryptosystems that are conjectured to
be resistant against quantum computer attack. This family of
cryptosystems is known as post-quantum cryptography (PQC). It is
sometimes also referred to as quantum-safe cryptography (QSC) or
quantum-resistant cryptography (QRC).
</t>
</section>
<section title="Proposed Extension" >
<t>
This document describes a method to perform multiple successive key
exchanges in IKEv2. It allows integration of PQC in IKEv2, while
maintaining backwards compatibility, to derive a set of IKE keys that
is resistant to quantum computer attacks. This extension allows the
negotiation of one or more PQC algorithm to exchange data, in addition
to the existing (EC)DH key exchange data. It is believed that the
feature of using more than one post-quantum algorithms is important as
many of these algorithms are relatively new and there may be a need to
hedge the security risk with multiple key exchange data from several
distinct PQC algorithms.
</t>
<t>IKE peers perform multiple successive key exchanges to establish
an IKE Security Association (SA). Each exchange produces a piece of secret and
these secrets are combined in a way such that:
<ol type="(%c)">
<li>the final shared secret is computed from all of the component key exchange
secret;</li>
<li>the shared secret as specified in <xref target="RFC7296"/> is obtained
unless both peers support and agree to use the additional key exchanges introduced
in this specification; and</li>
<li>if any of the component key exchange method is a post-quantum algorithm,
the final shared secret is post-quantum secure.</li>
</ol>
</t>
<t>
Some post-quantum key exchange payloads may have sizes larger than
the standard maximum transmission unit (MTU) size, and therefore there could be issues with
fragmentation at the IP layer. In order to allow using those larger payload
sizes, this mechanism relies on the IKE_INTERMEDIATE exchange as specified
in <xref target="RFC9242"/>. With this
mechanism, the key exchange is initiated using a smaller, possibly
classical primitive, such as (EC)DH. Then, before
the IKE_AUTH exchange, one or more IKE_INTERMEDIATE exchanges are carried out,
each of which contains an additional key exchange. As the IKE_INTERMEDIATE
exchange is encrypted, the IKE fragmentation protocol <xref target="RFC7383" />
can be used. The IKE SK_* values are updated after each exchange as described in
<xref target="additional_ke"/>,
and so the final IKE SA keys depend on all the key exchanges,
hence they are secure if any of the key exchanges are secure.</t>
<t>While this extension is primarily aimed for IKE SAs due to the
potential fragmentation issue discussed above, it also applies to
CREATE_CHILD_SA exchanges as illustrated in
<xref target="create_child_sa_exchange"/> for creating/rekeying of
Child SAs and rekeying of IKE SAs.</t>
<t>
Note that readers should consider the approach defined in this document as
providing a long term solution in upgrading the IKEv2 protocol to
support post-quantum algorithms. A short term solution to make IKEv2
key exchange quantum secure is to use post-quantum pre-shared keys as
specified in <xref target="RFC8784"/>.</t>
<t> Note also that the proposed approach of performing multiple successive key exchanges
in such a way that resulting session keys depend on all of them is not limited
to only addressing the threat of quantum computer. It can also be used when all
of the performed key exchanges are classical (EC)DH primitives, where for some reasons
(e.g. policy requirements) it is essential to perform multiple of them.
</t>
<t>This specification does not attempt to address key exchanges with KE payloads
longer than 64 Kbytes; the current IKE payload format does not allow such as
possibility. At the time of writing, it appears likely that there
are a number of key exchanges available that would not have such
a requirement. However, if such a requirement is needed,
<xref target="I-D.tjhai-ikev2-beyond-64k-limit"/> discusses approaches
that could be taken to exchange huge payloads.</t>
</section>
<section title="Changes" >
<t>RFC EDITOR PLEASE DELETE THIS SECTION.</t>
<t> Changes in this draft in each version iterations.</t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-07</t>
<t><list style="symbols">
<t>Editorial changes.</t>
</list></t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-06</t>
<t><list style="symbols">
<t>Updated draft with the allocated IANA values.</t>
<t>Editorial changes following AD review.</t>
</list></t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-05</t>
<t><list style="symbols">
<t>Updated the reference to RFC9242.</t>
<t>Editorial changes.</t>
</list></t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-04</t>
<t><list style="symbols">
<t>Introduction and initial sections are reorganized.</t>
<t>More clarifications for error handling added.</t>
<t>ASCII arts displaying SA payload are added.</t>
<t>Clarification for handling multiple round trips key exchange methods added.</t>
<t>DoS concerns added into Security Considerations section.</t>
<t>Explicitly allow scenario when additional key exchanges are performed only after peers are authenticated.</t>
</list></t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-03</t>
<t><list style="symbols">
<t>More clarifications added.</t>
<t>Figure illustrating initial exchange added.</t>
<t>Minor editorial changes.</t>
</list></t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-02</t>
<t><list style="symbols">
<t>Added a reference on the handling of KE payloads larger than 64KB.</t>
</list></t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-01</t>
<t><list style="symbols">
<t>References are updated.</t>
</list></t>
<t>draft-ietf-ipsecme-ikev2-multiple-ke-00</t>
<t><list style="symbols">
<t>Draft name changed as result of WG adoption and generalization of the approach.</t>
<t>New exchange IKE_FOLLOWUP_KE is defined for additional key exchanges performed after CREATE_CHILD_SA.</t>
<t>Nonces are removed from all additional key exchanges.</t>
<t>Clarification that IKE_INTERMEDIATE must be negotiated is added.</t>
</list></t>
<t>draft-tjhai-ipsecme-hybrid-qske-ikev2-04</t>
<t><list style="symbols">
<t>Clarification about key derivation in case of multiple key exchanges in CREATE_CHILD_SA is added.</t>
<t>Resolving rekey collisions in case of multiple key exchanges is clarified.</t>
</list></t>
<t>draft-tjhai-ipsecme-hybrid-qske-ikev2-03</t>
<t><list style="symbols">
<t>Using multiple key exchanges CREATE_CHILD_SA is defined.</t>
</list></t>
<t>draft-tjhai-ipsecme-hybrid-qske-ikev2-02</t>
<t><list style="symbols">
<t>Use new transform types to negotiate additional key exchanges,
rather than using the KE payloads of IKE SA.</t>
</list></t>
<t>draft-tjhai-ipsecme-hybrid-qske-ikev2-01</t>
<t><list style="symbols">
<t>Use IKE_INTERMEDIATE to perform multiple key exchanges in succession.</t>
<t>Handle fragmentation by keeping the first key exchange (a standard
IKE_SA_INIT with a few extra notifies) small, and encrypting the rest
of the key exchanges.</t>
<t>Simplify the negotiation of the 'extra' key exchanges.</t>
</list></t>
<t>draft-tjhai-ipsecme-hybrid-qske-ikev2-00</t>
<t><list style="symbols">
<t>Added a feature to allow more than one post-quantum key
exchange algorithms to be negotiated and used to exchange a post-
quantum shared secret.</t>
<t>Instead of relying on TCP encapsulation to deal with IP level
fragmentation, a new key exchange payload that can
be sent as multiple fragments within IKE_SA_INIT message was introduced.</t>
</list>
</t>
</section>
<section title="Document Organization" >
<t>
The remainder of this document is organized as follows.
<xref target="specification"/> describes how
multiple key exchanges are performed between two IKE peers and how
keying materials are derived for both SAs and Child SAs.
<xref target="IANA"/> discusses IANA considerations for the namespaces
introduced in this document, and <xref target="security"/> discusses security
considerations. In the Appendices sections, some examples of multiple key exchanges
are illustrated in <xref target="sample-exchanges"/>,
<xref target="design"/> summarizes design criteria and a summary of alternative
approaches that have been considered, but later discarded, are described
in <xref target="altdesign"/>.
</t>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted
as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when,
they appear in all capitals, as shown here.
</t>
</section>
</section>
<section title="Multiple Key Exchanges" anchor="specification">
<section title="Design Overview">
<t> 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 may not be
as secure as expected. A hybrid solution, when multiple key exchanges are performed
and the calculated shared key depends on all of them, allows us to deal with this
uncertainty by combining a classical key exchange with a post-quantum
one, as well as leaving open the possibility of multiple post-quantum
key exchanges.</t>
<t> In order to be able to use IKE fragmentation <xref target="RFC7383"/> for those key exchanges
that may have long public keys, this specification utilizes the IKE_INTERMEDIATE exchange
defined in <xref target="RFC9242"/>.
The initial IKE_SA_INIT messages do not have any inherent fragmentation support within IKE; however, IKE_SA_INIT messages can include a
relatively short KE payload. The additional key exchanges are performed using IKE_INTERMEDIATE messages
that follow the IKE_SA_INIT exchange. This is to allow the standard IKE
fragmentation mechanisms (which cannot be used in IKE_SA_INIT) to be available for the potentially large
Key Exchange payloads with post-quantum algorithm data.
</t>
<t> Note that this document assumes, that each key exchange method requires one round trip and consumes exactly one IKE_INTERMEDIATE exchange.
This assumption is valid for all classic key exchange methods defined so far and for all post-quantum methods currently known.
For hypothetical future key exchange methods requiring multiple round trips to complete, a separate document should define how such
methods are split into several IKE_INTERMEDIATE exchanges.
</t>
<t> In order to minimize communication overhead, only the key shares that are agreed to be used
are actually exchanged. To negotiate additional key exchanges seven new Transform Types are defined.
These transforms and Transform Type 4 share the same Transform IDs.
</t>
<t> It is assumed that new Transform Type 4 identifiers will be assigned later for
various post-quantum key exchanges <xref target="IKEV2TYPE4ID"></xref>.
This specification does not make a distinction between classical (EC)DH
and post-quantum key exchanges, nor post-quantum algorithms which are
true key exchanges versus post-quantum algorithms that act as key
transport mechanisms; all are treated equivalently by the
protocol. This document renames a field in the Key Exchange Payload from
"Diffie-Hellman Group Num" to "Key Exchange Method". It also renames
Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)";
the corresponding renaming to the IANA registry is described in <xref target="IANA"/>.</t>
<t> The fact that newly defined transforms share
the same registry for possible Transform IDs with Transform Type 4, allows additional key exchanges
to be of any type - either post-quantum or classical (EC)DH
one. This approach allows any combination of the defined key exchange methods
to take place. This also allows IKE peers to perform a single post-quantum
key exchange in the IKE_SA_INIT without additional key exchanges,
provided that the IP fragmentation is not an issue and that hybrid key exchange is not needed.
</t>
<t> The SA payload in the IKE_SA_INIT message
includes one or more newly defined transforms which represent the extra key exchange policy required by the
initiator. The responder follows the usual IKEv2 negotiation rules: it selects a single transform of each type, and
returns all of them in the IKE_SA_INIT response message.
</t>
<t>
Then, provided that additional key exchanges are negotiated, the initiator and the responder
perform one or more IKE_INTERMEDIATE exchanges. Following that, the IKE_AUTH exchange authenticates peers
and completes IKE SA establishment.</t>
<figure><artwork align="center"><![CDATA[
Initiator Responder
---------------------------------------------------------------------
<-- IKE_SA_INIT (additional key exchanges negotiation) -->
<-- {IKE_INTERMEDIATE (additional key exchange)} -->
...
<-- {IKE_INTERMEDIATE (additional key exchange)} -->
<-- {IKE_AUTH} -->
]]></artwork></figure>
</section>
<section title="Protocol Details">
<t> In the simplest case, the initiator starts a single key exchange
(and has no interest in supporting multiple), and it is not concerned
with possible fragmentation of the IKE_SA_INIT messages (either because
the key exchange it selects is small enough not to fragment, or the initiator is
confident that fragmentation will be handled either by IP fragmentation,
or transport via TCP).</t>
<t> In this case, the initiator performs the IKE_SA_INIT for a single key exchange using a Transform Type 4
(possibly with a post quantum algorithm), and including the initator KE payload. If the responder accepts
the policy, it responds with an IKE_SA_INIT response, and IKE continues as usual.</t>
<t> If the initiator desires to negotiate multiple key exchanges, then the initiator uses the protocol
behavior listed below.</t>
<section anchor="negotiation" title="IKE_SA_INIT Round: Negotiation" >
<t> Multiple key exchanges are negotiated using the standard IKEv2 mechanism, via SA payload.
For this purpose seven new transform types, namely Additional Key Exchange 1 (with IANA assigned value 6),
Additional Key Exchange 2 (7), Additional Key Exchange 3 (8), Additional Key Exchange 4 (9),
Additional Key Exchange 5 (10), Additional Key Exchange 6 (11) and Additional Key Exchange 7 (12)
are defined. They are collectively called Additional Key Exchange transforms in this document
and have slightly different semantics than the existing IKEv2 transform types.
They are interpreted as an indication of additional key exchange methods that peers agree to perform
in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange. The allowed transform IDs for these transform types
are the same as the IDs for Transform Type 4, so they all share a single IANA registry for transform IDs.
</t>
<t> Key exchange method negotiated via Transform Type 4 always takes place
in the IKE_SA_INIT exchange, as defined in <xref target="RFC7296" />. Additional key exchanges negotiated via newly
defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges following the IKE_SA_INIT exchange,
performed in an order of the values of their transform types, so that key exchange negotiated using Additional Key Exchange i always precedes that of
Additional Key Exchange i + 1. Each additional key exchange method MUST be fully completed before the next one is started.
</t>
<t> Note that with these semantics, Additional Key Exchange transforms are not associated
with any particular type of key exchange and do not have any specific per transform type transform IDs IANA registry.
Instead they all share a single registry for transform IDs, namely "Key Exchange Method Transform IDs", which are also shared by Transform Type 4.
All key exchange algorithms (both classical or post-quantum) should be added to this registry.
This approach gives peers flexibility in defining the ways they want
to combine different key exchange methods.
</t>
<t> 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 (EC)DH key exchange methods,
however it is not a requirement. Additional key exchange methods are proposed using Additional Key Exchange
transform types. All of these transform types are optional, the initiator is free
to select any of them for proposing additional key exchange methods. Consequently,
if none of the Additional Key Exchange transforms is included in the proposal, then this proposal
indicates performing standard IKEv2, as defined in <xref target="RFC7296"/>.
On the other hand, if the initiator includes any Additional Key Exchange transform in the proposal,
the responder MUST select one of the algorithms proposed using this type. Note that this is not a
new requirement, but that this behavior is already specified in Section 2.7 of <xref target="RFC7296"/>.
A transform ID NONE MAY be added to those transform types which contain key exchange methods that
the initiator believes is optional according to its local policy.
</t>
<t> The responder performs the negotiation using the standard IKEv2 procedure described in Section 3.3 of <xref target="RFC7296"/>.
However, for the Additional Key Exchange types, the responder's choice MUST NOT contain duplicated algorithms (those with identical Transform ID and attributes),
except for the transform ID of NONE. An algorithm is represented as a transform, in some cases the transform
could include a set of associated attributes that define details of the algorithm. In this case, two
transforms can be the same, but the attributes must be different. Additionally, the order of the attributes
does not affect the equality of the algorithm, so two transforms (ID=alg1,ATTR1=attr1,ATTR2=attr2) and
(ID=alg1,ATTR2=attr2,ATTR1=attr1) define the same algorithm. If the responder is unable
to select non-duplicated algorithm for each proposed key exchange (either
because the proposal contains too few choices or due to the local policy restrictions on using the proposed algorithms),
then the responder MUST reject the message with an error notification of type NO_PROPOSAL_CHOSEN.
If the responder's message contains one or more duplicated choices, the initiator
should log the error and MUST treat the exchange as failed.
The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges, so that no new SA is created.
If this happens in the CREATE_CHILD_SA exchange, then the initiator MAY delete the IKE SA,
over which the invalid message was received, by sending a Delete payload.
</t>
<t> If the responder selects NONE for some Additional Key Exchange types (provided they are proposed by the initiator),
then the corresponding Additional Key Exchange(s) in the IKE_INTERMEDIATE exchange(s) MUST NOT take place.
Therefore if the initiator includes NONE in all of the Additional Key Exchange transforms and the
responder selects this value for all of them, then no IKE_INTERMEDIATE messages performing additional key
exchanges will take place between the peers. Note that the IKE_INTERMEDIATE exchanges may still take place for other purposes.
</t>
<t>The initiator MAY propose non-consecutive Additional Key Exchange transforms, for example
proposing Additional Key Exchange 2 and Additional Key Exchange 5 transforms only. The responder
MUST treat all of the omitted Additional Key Exchange transforms as if they are proposed with
Transform ID NONE.</t>
<t> Below is an example of the SA payload in the initiator's IKE_SA_INIT request message.
Here the abbreviation AKEi is used to denote the i-th Additional Key Exchange transform defined in this document,
and an abbreviation KE for the Key Exchange transform,
that this document renames from the Diffie-Hellman Group transform.
Additionally, the notations PQ_KEM_1, PQ_KEM_2 and PQ_KEM_3 are used to
represent some not-yet defined Transform IDs of some popular post-quantum
key exchange methods.</t>
<figure><artwork align="center" ><![CDATA[
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8,
| 9 transforms, SPI = 0x35a1d6f22564f89d )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform AKE2 ( ID = PQ_KEM_1 )
|
+-- Transform AKE2 ( ID = PQ_KEM_2 )
|
+-- Transform AKE3 ( ID = PQ_KEM_1 )
|
+-- Transform AKE3 ( ID = PQ_KEM_2 )
|
+-- Transform AKE5 ( ID = PQ_KEM_3 )
|
+-- Transform AKE5 ( ID = NONE )
]]></artwork></figure>
<t> In this example, the initiator proposes to perform initial key exchange using 4096-bit MODP group
followed by two mandatory additional key exchanges (i.e. Transforms AKE2 and AKE3) using PQ_KEM_1 and
PQ_KEM_2 methods in any order, then followed by additional key exchange (i.e. Transform AKE5) using
PQ_KEM_3 method that may be omitted.
</t>
<t> The responder might return the following SA payload, indicating that it agrees to
perform two additional key exchanges PQ_KEM_2 followed by PQ_KEM_1 and does not
want to perform PQ_KEM_3 additionally.
</t>
<figure><artwork align="center" ><![CDATA[
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 8,
| 6 transforms, SPI = 0x8df52b331a196e7b )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform AKE2 ( ID = PQ_KEM_2 )
|
+-- Transform AKE3 ( ID = PQ_KEM_1 )
|
+-- Transform AKE5 ( ID = NONE )
]]></artwork></figure>
<t> If the initiator includes any Additional Key Exchange transform types into the SA payload in the IKE_SA_INIT exchange request message,
then it MUST also negotiate the use of the IKE_INTERMEDIATE exchange as described in <xref target="RFC9242" />,
by including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the same message.
If the responder agrees to use additional key exchanges while establishing initial IKE SA,
it MUST also return this notification in the IKE_SA_INIT response message,
thus confirming that IKE_INTERMEDIATE exchange is supported and will be used for transferring additional key exchange data.
If the IKE_INTERMEDIATE exchange is not negotiated, then the peers MUST treat any Additional Key Exchange transforms
in the IKE_SA_INIT exchange messages as unknown transform types and skip the proposals they appear in.
If no other proposals are present in the SA payload, the peers will proceed as if no proposal is chosen
(i.e. the responder will send NO_PROPOSAL_CHOSEN notification).
</t>
<figure><artwork align="center" ><![CDATA[
Initiator Responder
---------------------------------------------------------------------
HDR, SAi1(.. AKE*...), KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1(.. AKE*...), KEr, Nr,
[CERTREQ],
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)
]]></artwork></figure>
<t> It is possible that an attacker manages to send a response to the initiator's IKE_SA_INIT request
before the legitimate responder does. If the initiator continues to create the IKE SA using this response, the attempt will fail.
Implementers may wish to consider a possible defense technique described in Section 2.4 of <xref target="RFC7296" />.
</t>
</section>
<section title="IKE_INTERMEDIATE Round: Additional Key Exchanges" anchor="additional_ke">
<t> For each additional key exchange agreed to in the IKE_SA_INIT exchange,
the initiator and the responder perform IKE_INTERMEDIATE exchange,
as described in <xref target="RFC9242"/>.</t>
<figure><artwork align="center" ><![CDATA[
Initiator Responder
---------------------------------------------------------------------
HDR, SK {KEi(n)} -->
<-- HDR, SK {KEr(n)}
]]></artwork></figure>
<t> The initiator sends key exchange data in the KEi(n) payload.
This message is protected with the current SK_ei/SK_ai keys.
The notation KEi(n) denotes the n-th IKE_INTERMEDIATE KE payload from the initiator
and the integer n is sequential starting from 1.</t>
<t> On receiving this, the responder sends back key exchange payload KEr(n),
which denotes the n-th IKE_INTERMEDIATE KE payload from the responder.
As before, this message is protected with the current SK_er/SK_ar keys.</t>
<t> The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the
n-th negotiated additional key exchange.
<!-- Note that the negotiated transform types (the encryption type, integrity type, prf type) are not modified. (do we need to say this?) -->
</t>
<t> Once this exchange is done, both sides compute an updated keying material:</t>
<figure><artwork align="center" ><![CDATA[
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
]]></artwork></figure>
<t> where SK(n) is the resulting shared secret of this key exchange,
Ni and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the
last generated SK_d, (derived from IKE_SA_INIT for the first use of IKE_INTERMEDIATE, otherwise from the previous IKE_INTERMEDIATE exchange).
The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are generated from the SKEYSEED(n) as follows:</t>
<figure><artwork align="center" ><![CDATA[
{SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)
]]></artwork></figure>
<t> Both the initiator and the responder use these updated key
values in the next exchange (IKE_INTERMEDIATE or IKE_AUTH).</t>
</section>
<section title="IKE_AUTH Exchange">
<t> After all IKE_INTERMEDIATE exchanges have completed, the initiator and
the responder perform an IKE_AUTH exchange. This exchange is
the standard IKE exchange as described in <xref target="RFC7296"/> with
the modification of AUTH payload calculation described in
<xref target="RFC9242"/>.</t>
</section>
<section title="CREATE_CHILD_SA Exchange" anchor="create_child_sa_exchange">
<t> The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes
of creating additional Child SAs, rekeying these and rekeying IKE SA itself.
When creating or rekeying Child SAs, the peers may optionally
perform a key exchange to add a fresh entropy into the session keys.
In case of IKE SA rekey, the key exchange is mandatory.
Peers supporting this specification may want to use multiple key exchanges
in these situations.
</t>
<t> Using multiple key exchanges with CREATE_CHILD_SA exchange is negotiated
similarly as in the initial IKE exchange, see <xref target="negotiation" />.
If the initiator includes any Additional Key Exchange 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 new IKE_FOLLOWUP_KE exchanges that follows the CREATE_CHILD_SA exchange.
The IKE_FOLLOWUP_KE exchange is introduced as a dedicated exchange for transferring data of additional key exchanges
following the key exchange performed in the CREATE_CHILD_SA. Its Exchange Type value is 44.
</t>
<t> Key exchange negotiated via Transform Type 4 always takes place in the CREATE_CHILD_SA exchange, as per IKEv2 specification.
Additional key exchanges are performed 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 additional key exchange method MUST be fully completed before the next one is started.
Note, that this document assumes, that each key exchange method consumes exactly one IKE_FOLLOWUP_KE exchange.
For the methods requiring multiple round trips, a separate document should define how such
methods are split into several IKE_FOLLOWUP_KE exchanges.
</t>
<t> After an IKE SA is created the window size may be greater than one and multiple
concurrent exchanges may be in progress, it is essential to link the IKE_FOLLOWUP_KE exchanges together
with the corresponding CREATE_CHILD_SA exchange. Due to the fact that once an IKE SA is created, all IKE exchanges
are independent and do not have built-in means to link one with another, a new status type
notification ADDITIONAL_KEY_EXCHANGE is introduced for this purpose.
Its Notify Message Type value is 16441, and 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.
</t>
<t> The responder MUST include this notification in a CREATE_CHILD_SA or
IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE exchange is expected, filling it with
some data that would allow linking the current exchange to the next one. The initiator
MUST send back this notification intact in the request message of the next IKE_FOLLOWUP_KE exchange.
</t>
<t> Below is an example of CREATE_CHILD_SA exchange followed by three additional key exchanges.
</t>
<figure><artwork align="center" ><![CDATA[
Initiator Responder
---------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(1),
N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1),
N(ADDITIONAL_KEY_EXCHANGE)(link2)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(2),
N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2),
N(ADDITIONAL_KEY_EXCHANGE)(link3)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(3),
N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)}
]]></artwork></figure>
<t> The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the
n-th negotiated additional key exchange.
</t>
<t> It is possible that due to some unexpected events (e.g. reboot)
the initiator may lose its state and forget that it is in the process of performing
additional key exchanges and thus never start the remaining IKE_FOLLOWUP_KE exchanges.
The responder MUST handle this situation gracefully and delete
the associated state if it does not receive the next expected
IKE_FOLLOWUP_KE request after some reasonable period of time.
Note that due to various factors such as computational resource and
key exchange algorithm used, it is not possible to give a normative
guidance on how long this timeout period should be. In general, 5-20
seconds of waiting time should be appropriate in most cases.
</t>
<t> It is also possible that the initiator may take too long to
prepare and send the next IKE_FOLLOWUP_KE request or due to the network
conditions, the request is retransmitted. In this case, the message may reach the responder
when it has already deleted the associated state
following the advice above. If the responder receives an IKE_FOLLOWUP_KE message for which it does not have a key exchange state,
it MUST send back a new error type notification
STATE_NOT_FOUND. This is a non-fatal error notification, its Notify Message Type is 47,
Protocol ID and SPI Size are both set to 0 and the data is empty. If the initiator receives
this notification in response to IKE_FOLLOWUP_KE exchange performing additional
key exchange, it MUST cancel this exchange and MUST treat the whole series
of exchanges started from the CREATE_CHILD_SA exchange as failed.
In most cases, the receipt of this notification is caused by premature deletion
of the corresponding state on the responder (the time period between
IKE_FOLLOWUP_KE exchanges appeared too long from the responder's point of view, e.g. due
to a temporary network failure). After receiving this notification the initiator MAY
start a new CREATE_CHILD_SA exchange which may eventually be followed by the IKE_FOLLOWUP_KE exchanges,
to retry the failed attempt. If the initiator continues to receive
STATE_NOT_FOUND notifications after several retries, it MUST treat this situation
as a fatal error and delete IKE SA by sending a DELETE payload.
</t>
<t> When rekeying the IKE SA or the Child SA, it is possible that the peers start doing this
at the same time, which is called simultaneous rekeying. Sections 2.8.1 and 2.8.2 of
<xref target="RFC7296" /> describe how IKEv2 handles this situation. In a nutshell
IKEv2 follows the rule that if in case of simultaneous rekeying, two identical new
IKE SAs (or two pairs of Child SAs) are created, then one of them should be deleted.
Which one is to be deleted is determined by comparing the values of four nonces
that are used in the colliding CREATE_CHILD_SA exchanges. The IKE SA (or pair of Child SAs)
that is created by the exchange in which the smallest nonce is used should be deleted by
the initiator of this exchange.
</t>
<t> With multiple key exchanges, the SAs are not yet created when the CREATE_CHILD_SA is completed,
they would be created only after the series of IKE_FOLLOWUP_KE exchanges is finished.
For this reason, if additional key exchanges are negotiated in the CREATE_CHILD_SA
exchange in which the smallest nonce is used, then because there is nothing to delete
yet, the initiator of this exchange just stops the rekeying process and it MUST NOT
initiate the IKE_FOLLOWUP_KE exchange.
</t>
<t> In most cases, rekey collisions are resolved in the CREATE_CHILD_SA exchange.
However, a situation may occur when due to packet loss, one of the peers receives the CREATE_CHILD_SA message
requesting rekey of SA that is already being rekeyed by this peer (i.e. the CREATE_CHILD_SA
exchange initiated by this peer has been already completed and the series of IKE_FOLLOWUP_KE exchanges is in progress).
In this case, a TEMPORARY_FAILURE notification MUST be sent in response to such a request.
</t>
<t> If multiple key exchanges are negotiated in the CREATE_CHILD_SA exchange, then the resulting keys are
computed as follows.</t>
<t>In case of IKE SA rekey:
</t>
<figure><artwork align="center" ><![CDATA[
SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))
]]></artwork></figure>
<t> In case of Child SA creation or rekey:
</t>
<figure><artwork align="center" ><![CDATA[
KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))
]]></artwork></figure>
<t> In both cases, SK_d is from the existing IKE SA; SK(0), Ni, Nr are the shared key and nonces
from the CREATE_CHILD_SA respectively; SK(1)...SK(n) are the shared keys from additional key exchanges.
</t>
</section>
<section title="Interaction with IKEv2 Extensions">
<t> It is believed that this specification requires no modification to the IKEv2 extensions defined so far.
In particular, IKE SA resumption mechanism defined in <xref target="RFC5723" /> can be used to resume
IKE SAs created using this specification.
</t>
<section title="Interaction with Childless IKE SA">
<t>It is possible to establish IKE SAs with post-quantum algorithms only using additional key exchanges,
but without using IKE_INTERMEDIATE exchanges. In this case, the IKE SA created from IKE_SA_INIT exchange
can be immediately rekeyed with CREATE_CHILD_SA using additional key exchanges where IKE_FOLLOWUP_KE
messages are used to carry the key exchange payload. If classical key exchange method is used in
the IKE_SA_INIT message, the very first Child SA created in IKE_AUTH will offer no resistance against the
quantum threats. Consequently, if the peers' local policy requires that all Child SAs to be post-quantum
secure, then the peers can avoid creating the very first Child SA by adopting <xref target="RFC6023"/>.
In this case, the initiator sends two types of
proposal in the IKE_SA_INIT request, one with and another one without Additional
Key Exchange transform(s). The responder chooses the latter proposal type and includes
CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response. Assuming that
the initiator supports childless IKE SA extension, then both peers performs
the modified IKE_AUTH exchange described in <xref target="RFC6023"/> and no
Child SA is created in this exchange. The peers should then immediately rekey
the IKE SA and subsequently create the Child SAs, all with additional key
exchanges using CREATE_CHILD_SA exchange.</t>
<t>It is also possible for the initiator to send proposals without Additional Key
Exchange transform(s) in the IKE_SA_INIT message and in this instance, the responder will have
no information whether or not the initiator supports the extension in this
specification. This may not be efficient as the responder will have to wait for
the subsequent CREATE_CHILD_SA request to determine whether or not the initiator's
request is appropriate for its local policy.</t>
<t>The support for childless IKE SA is not negotiated, but it is the responder that
indicates the support for this mode. As such, the responder cannot enforce the
initiator to use this mode and therefore, it is entirely possible that the
initiator does not support this extension and sends IKE_AUTH request as per
<xref target="RFC7296"/> instead of <xref target="RFC6023"/>. In this case, the
responder may respond with non-fatal error such as NO_PROPOSAL_CHOSEN notify message type.</t>
<t>Note that if the initial IKE SA is used to transfer sensitive information, then this information
will not be protected using the additional key exchanges, which may use post-quantum algorithms. In this arrangement,
the peers will have to use post-quantum algorithm in Transform Type 4 in order to mitigate the risk of quantum attack. </t>
</section>
</section>
</section>
</section>
<section title="IANA Considerations" anchor="IANA">
<t>This document adds new exchange type into the "IKEv2 Exchange Types" registry:</t>
<figure align="center"><artwork align="left"><![CDATA[
44 IKE_FOLLOWUP_KE
]]></artwork></figure>
<t>This document renames Transform Type 4 defined in "Transform Type Values" registry
from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)".</t>
<t>This document renames IKEv2 registry "Transform Type 4 - Diffie-Hellman Group Transform IDs" to
"Transform Type 4 - Key Exchange Method Transform IDs".</t>
<t>This document adds the following Transform Types to the "Transform Type Values" registry:</t>
<figure align="left"><artwork align="left"><![CDATA[
Type Description Used In
-----------------------------------------------------------------
6 Additional Key Exchange 1 (optional in IKE, AH, ESP)
7 Additional Key Exchange 2 (optional in IKE, AH, ESP)
8 Additional Key Exchange 3 (optional in IKE, AH, ESP)
9 Additional Key Exchange 4 (optional in IKE, AH, ESP)
10 Additional Key Exchange 5 (optional in IKE, AH, ESP)
11 Additional Key Exchange 6 (optional in IKE, AH, ESP)
12 Additional Key Exchange 7 (optional in IKE, AH, ESP)
]]></artwork></figure>
<t>This document defines a new Notify Message Type in the "Notify Message Types - Status Types" registry:</t>
<figure align="center"><artwork align="left"><![CDATA[
16441 ADDITIONAL_KEY_EXCHANGE
]]></artwork></figure>
<t>and a new Notify Message Type in the "Notify Message Types - Error Types" registry:</t>
<figure align="center"><artwork align="left"><![CDATA[
47 STATE_NOT_FOUND
]]></artwork></figure>
<section title="Additional Considerations and Changes">
<t>The IANA is requested to add the following instructions for designated experts
for Transform Type 4 sub-registry.</t>
<t>While adding new KE methods, the following considerations must be applied.
A KE method must take exactly one round-trip (one IKE exchange) and at the end
of this exchange, both peers must be able to derive the shared secret. In addition, any public value peers exchanged during a KE method must fit into a single IKE
message. If these restrictions are not met for a KE method, then there must be
documentation on how this KE method is used in IKEv2.</t>
<t>The following changes to IANA are also requested. It is assumed that
RFCXXXX refers to this specification.</t>
<t><list style="symbols">
<t>Add a reference to RFCXXXX in the "Transform Type 4 - Diffie-Hellman Group Transform IDs"
registry.</t>
<t>Replace the note on "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry with:
This registry was originally named "Transform Type 4 - Diffie-Hellman Group Transform IDs" and
was renamed to its current name by [RFCXXXX]. It has been referenced in its original name in
a number of RFCs prior to [RFCXXXX]. To find out requirement levels for Key Exchange Methods
for IKEv2, see [RFC8247].</t>
<t>Add this note to "Transform Type Values" registry: Transform Type "Transform Type 4 - Key
Exchange Method Transform IDs" was originally named "Transform Type 4 - Diffie-Hellman Group
Transform IDs" and was renamed to its current name by [RFCXXXX]. It has been referenced in its
original name in a number of RFCs prior to [RFCXXXX]. All "Additional Key Exchange" entries use
the same "Transform Type 4 - Key Exchange Method Transform IDs" as the "Key Exchange Method (KE)".</t>
<t>Append RFCXXXX to the Reference column of Transform Type 4 in the Transform Type Values registry.</t>
<t>Append this note to "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry: All
"Additional Key Exchange" entries use these values as the "Key Exchange Method (KE)".</t>
</list></t>
</section>
</section>
<section title="Security Considerations" anchor="security">
<t>The extension in this document is intended to mitigate two possible threats in IKEv2, namely
the compromise of (EC)DH key exchange using Shor's algorithm while remaining backward compatible;
and the potential compromise of existing or future PQC key exchange algorithms. To address the
former threat, this extension allows the establishment of a shared secret by using multiple key
exchanges, typically one classical (EC)DH and the other one post-quantum algorithm. In order to
address the latter threat, multiple key exchanges using a post-quantum algorithm can be composed to
form the shared key.
</t>
<t>Unlike key exchange methods (Transform Type 4), the Encryption Algorithm (Transform Type 1),
the Pseudorandom Function (Transform Type 2) and the Integrity Algorithm (Transform Type 3) are
not susceptible to Shor's algorithm. However, they are susceptible to Grover's attack <xref target="GROVER"/>,
which allows a quantum computer to perform a brute force key search using quadratically fewer
steps than the classical counterpart. Simply increasing the key length can mitigate this attack.
It was previously believed that one needed to double the key length of these algorithms. However,
there are a number of factors that suggest that it is quite unlikely to achieve the quadratic speed up
using Grover's algorithm. According to NIST <xref target="NISTPQCFAQ"/>, current applications can
continue using AES algorithm with the minimum key length of 128 bit. Nevertheless, if the data
needs to remain secure for many years to come, one may want to consider using a longer key size for the
algorithms in Transform Types 1-3.
</t>
<t>SKEYSEED is calculated from shared SK(x) using an algorithm defined
in Transform Type 2. While a quantum attacker may learn the value
of SK(x), if this value is obtained by means of a classical key exchange,
other SK(x) values generated by means of a post-quantum algorithm
ensure that the final SKEYSEED is not compromised. This assumes that
the algorithm defined in the Transform Type 2 is quantum resistant.
</t>
<t>The ordering of the additional key exchanges should not matter in general,
as only the final shared secret is of interest. Nonetheless, because the strength
of the running shared secret increases with every additional key exchange, an
implementer may want to first perform the most secure method (in some metrics) and
followed by less secure one(s).</t>
<t> The main focus of this document is to prevent a passive attacker
performing a "harvest and decrypt" attack. In other words, an attacker
that records messages exchanged today and proceeds to decrypt them once
he owns a quantum computer. This attack is prevented due to the hybrid
nature of the key exchange. Other attacks involving an active attacker
using a quantum-computer are not completely solved by this
document. This is for two reasons.</t>
<t> The first reason is because the authentication step remains
classical. In particular, the authenticity of the SAs established
under IKEv2 is protected using a pre-shared key or digital signature
algorithms. Whilst the pre-shared key option, provided the key is
long enough, is post-quantum secure, the other algorithms are not. Moreover,
in implementations where scalability is a requirement, the pre-shared
key method may not be suitable. Post-quantum authenticity may be
provided by using a post-quantum digital signature.
</t>
<t> Secondly, it should be noted that the purpose of post-quantum algorithms is
to provide resistance to attacks mounted in the future. The current
threat is that encrypted sessions are subject to eavesdropping and
archived with decryption by quantum computers taking place at some
point in the future. Until quantum computers become available there
is no point in attacking the authenticity of a connection because
there are no possibilities for exploitation. These only occur at
the time of the connection, for example by mounting an on-path
attack. Consequently there is less urgency for
post-quantum authenticity compared to post-quantum confidentiality.</t>
<t> Performing multiple key exchanges while establishing IKE SA
increases the responder's susceptibility to DoS attacks, because
of an increased amount of resources needed before the initiator
is authenticated. This is especially true for post-quantum
key exchange methods, where many of them are more memory and/or CPU intensive than the classical counterparts.
</t>
<t> Responders may consider recommendations from <xref target="RFC8019" />
to deal with increased DoS attack susceptibility. It is also possible that