generated from martinthomson/internet-draft-template
-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-kampanakis-ml-kem-ikev2-09.xml
510 lines (502 loc) · 37.4 KB
/
draft-kampanakis-ml-kem-ikev2-09.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
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-kampanakis-ml-kem-ikev2-09" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.18.2 -->
<front>
<title abbrev="ML-KEM IKEv2">Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<seriesInfo name="Internet-Draft" value="draft-kampanakis-ml-kem-ikev2-09"/>
<author fullname="Panos Kampanakis">
<organization>Amazon Web Services</organization>
<address>
<email>kpanos@amazon.com</email>
</address>
</author>
<author fullname="Gerardo Ravago">
<organization>Amazon Web Services</organization>
<address>
<email>gcr@amazon.com</email>
</address>
</author>
<date/>
<area>Security</area>
<workgroup>IPSECME</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>NIST recently standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This draft specifies how to use ML-KEM as an additional key exchange in IKEv2 along with traditional key exchanges. This Post-Quantum Traditional Hybrid Key Encapsulation Mechanism approach allows for negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM.</t>
</abstract>
</front>
<middle>
<section anchor="introduction">
<name>Introduction</name>
<t>A Cryptanalytically-relevant Quantum Computer (CRQC), if it became a reality, could threaten today's public key establishment algorithms. Someone storing encrypted communications that use (Elliptic Curve) Diffie-Hellman ((EC)DH) to establish keys could decrypt these communications in the future after a CRQC became available to them. Such communications include Internet Key Exchange Protocol Version 2 (IKEv2).</t>
<t>To address this concern, the Mixing Preshared Keys in IKEv2 specification <xref target="RFC8784"/> introduced Post-quantum Preshared Keys as a temporary option for stirring a pre-shared key of adequate entropy in the derived Child SA encryption keys in order to provide quantum-resistance. This specification can be used in conjunction with PPK as defined in <xref target="RFC8784"/>. </t>
<t>Since then, NIST has been working on a public project <xref target="NIST-PQ"/> for standardizing quantum-resistant algorithms which include key encapsulation and signatures. At the end of Round 3, they picked Kyber as the first Key Encapsulation Mechanism (KEM) for standardization <xref target="I-D.draft-cfrg-schwabe-kyber-04"/>. Kyber was then standardized as Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) in 2024 <xref target="FIPS203"/>.</t>
<t>As post-quantum public keys and ciphertexts may make UDP packet sizes larger than common network Maximum Transport Units (MTU), the Intermediate Exchange in IKEv2 document <xref target="RFC9242"/> defined how to do additional large message exchanges by using new IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages which can be fragmented at the IKEv2 layer before causing IP fragmentation <xref target="RFC7383"/>. Because <xref target="RFC9242"/> messages can only be used after IKE_SA_INIT, if a PQ KEM does not fit inside IKE_SA_INIT without causing IP fragmentation, then it should be used after IKE_SA_INIT as an additional key establishment algorithm. The Multiple Key Exchanges in IKEv2 specification <xref target="RFC9370"/> defined how to do up to seven additional key exchanges by using IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages and by deriving new SKEYSEED and KEYMAT key materials. This specification was created to enable new post-quantum key exchanges to be used in the derived IKE and Child SA keys and provide quantum resistance.</t>
<t>This document describes how ML-KEM can be used as a quantum-resistant KEM in IKEv2 in an IKE_SA_INIT key exchange, or in one additional IKE_INTERMEDIATE or IKE_FOLLOWUP_KE key exchange after an initial IKE_SA_INIT or CREATE_CHILD_SA respectively. This approach of combining a quantum-resistant with a traditional algorithm, is commonly called Post-Quantum Traditional (PQ/T) Hybrid <xref target="I-D.ietf-pquip-pqt-hybrid-terminology-04"/> key exchange and combines the security of a well-established algorithm with relatively new quantum-resistant algorithms. The result is a new Child SA key or an IKE or Child SA rekey with keying material which is safe against a CRQC. Another use of a PQ/T Hybrid key exchange in IKEv2 is for someone that wants to exchange keys using the high security parameter of ML-KEM. As these may not fit in common network packet payload sizes, they will need to be sent in a IKE_FOLLOWUP_KE or CREATE_CHILD_SA key exchange which can be fragmented. This specification is a profile of the Multiple Key Exchanges in IKEv2 specification <xref target="RFC9370"/> and registers new algorithm identifiers for ML-KEM key exchanges in IKEv2.</t>
<section anchor="kems">
<name>KEMs</name>
<t>In the context of the NIST Post-Quantum Cryptography Standardization Project <xref target="NIST-PQ"/>, key exchange algorithms are formulated as KEMs, which consist of three steps:</t>
<ul spacing="normal">
<li>
<t>'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm, which generates a public / encapsulation key 'pk' and a private / decapsulation key 'sk'. The resulting pk is sent to the responder in the KEi payload.</t>
</li>
<li>
<t>'Encaps(pk) -> (ct, ss)': A probabilistic encapsulation algorithm, which takes as input a public key 'pk' (from the KEi) and outputs a ciphertext 'ct' and shared secret 'ss'. The 'ct' is sent back to intiator in the KEr payload.</t>
</li>
<li>
<t>'Decaps(sk, ct) -> ss': A decapsulation algorithm, which takes as input a secret key 'sk' and ciphertext 'ct' (from the KEr) and outputs a shared secret 'ss', or in some rare cases a distinguished error value.</t>
</li>
</ul>
</section>
<section anchor="ml-kem">
<name>ML-KEM</name>
<t>ML-KEM is a standardized lattice-based key encapsulation mechanism <xref target="FIPS203"/>. It uses Module Learning with Errors as its underlying primitive which is a structured lattices variant that offers good performance and relatively small and balanced key and ciphertext sizes. ML-KEM was standardized with three parameters, ML-KEM-512, ML-KEM-768, and ML-KEM-1024. These were mapped by NIST to the three security levels defined in the NIST PQC Project, Level 1, 3, and 5. These levels correspond to the hardness of breaking AES-128, AES-192 and AES-256 respectively.</t>
<t>This specification introduces ML-KEM-512, ML-KEM-768 and ML-KEM-1024 to IKEv2 key exchanges as conservative security level parameters which will not have material performance impact on IKEv2/IPsec tunnels which usually stay up for long periods of time and transfer sizable amounts of data. Since the ML-KEM-768 and ML-KEM-1024 public key and ciphertext sizes can exceed the typical network MTU, these key exchanges could require two or three network IP packets from both the initiator and the responder. </t>
</section>
<section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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 anchor="ml-kem-in-ikev2">
<name>ML-KEM in IKEv2</name>
<section anchor="ml-kem-in-ikeintermediate-messages">
<name>ML-KEM in IKE_INTERMEDIATE or CREATE_CHILD_SA messages</name>
<t>ML-KEM key exchanges can be negotiated in IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages as defined in the Multiple Key Exchanges in IKEv2 specification <xref target="RFC9370"/>. We summarize them here for completeness. </t>
<t>Section 2.2.2 of <xref target="RFC9370"/> specifies that KEi(0), KEr(0) are regular key exchange messages in the first IKE_SA_INIT exchange which end up generating a set of keying material, SK_d, SK_a[i/r], and SK_e[i/r]. The peers then perform an IKE_INTERMEDIATE exchange, carrying new Key Exchange payloads. These are protected with the SK_e[i/r] and SK_a[i/r] keys which were derived from the IKE_SA_INIT as per Section 3.3.1 of the Intermediate Exchange in IKEv2 document <xref target="RFC9242"/>. The initiator generates an ML-KEM keypair (sk, pk) using KeyGen(), and sends the public key (pk) to the responder inside a KEi(1) payload. The responder will encapsulate a shared secret ss using Encaps(pk) and the resulting ciphertext (ct) is sent to initiator using the KEr(1). After the initiator receives KEr(1), it will decapsulate it using Decaps(sk, ct). Both Encaps and Decaps return the shared secret (ss) and both peers have a common shared secret SK(1) at the end of this KE(1) exchange.
The ML-KEM shared secret is stirred into new keying material SK_d, SK_a[i/r], and SK_e[i/r] as defined in Section 2.2.2 of the Multiple Key Exchanges in IKEv2 document <xref target="RFC9370"/>. Afterwards the peers continue to the IKE_AUTH exchange phase as defined in Section 3.3.2 of the Intermediate Exchange in IKEv2 specification <xref target="RFC9242"/>.</t>
<t>ML-KEM can also be used to create or rekey a Child SA or rekey the IKE SA by using a IKE_FOLLOWUP_KE message after a CREATE_CHILD_SA message. After the ML-KEM additional key exchange KE(1) has taken place using and IKE_FOLLOWUP_KE exchange, the IKE or Child SA are rekeyed by stirring the new ML-KEM shared secret SK(1) in SKEYSEED and KEYMAT as specified in Section 2.2.4 of <xref target="RFC9370"/>.</t>
<t>ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP packet sizes larger typical network MTUs (1500 bytes). Thus, IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages carrying ML-KEM public keys and ciphertexts may be IKEv2 fragmented as per the IKEv2 Message Fragmentation specification <xref target="RFC7383"/>. </t>
<t>Although, this document focuses on using ML-KEM as the second key exchange in a PQ/T Hybrid KEM <xref target="I-D.ietf-pquip-pqt-hybrid-terminology-04"/> scenario, ML-KEM-512 and ML-KEM-768 Key Exchange Method identifiers TBD35 and TBD36 respectively <bcp14>MAY</bcp14> be used in IKE_SA_INIT as a quantum-resistant-only key exchange. The encapsulation key and ciphertext sizes for these ML-KEM parameters may not push the UDP packet to size larger than typical network MTUs of 1500 bytes. ML-KEM-1024 Key Exchange Method identifier TBD37 <bcp14>SHOULD NOT</bcp14> be used in IKE_SA_INIT messages which could exceed typical network MTUs and cannot be IKEv2 fragmented. </t>
</section>
<section anchor="key-exchange-payload">
<name>Key Exchange Payload</name>
<t>The KE payload is shown below and the fields inside it has meaning as defined in Section 3.4 of the IKEv2 standard <xref target="RFC7296"/>:</t>
<artwork><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Exchange Method Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<t>The Key Exchange Data from the initiator to the responder contains the public key (pk) from the KeyGen() operation encoded as a raw byte array (i.e., output of ByteEncode) as defined in Section 7.1 of Module-Lattice-Based KEM standard <xref target="FIPS203"/>.</t>
<t>The Key Exchange Data from the responder to the initiator contains the ciphertext (ct) from the Encaps operation encoded as a raw byte array.</t>
<t><xref target="ke_payload_table"/> shows the Payload Length, Key Exchange Method Num identifier and the Key Exchange Data Size in octets for Key Exchange Payloads from the initiator and the responder for the ML-KEM variants specified in this document.</t>
<table anchor="ke_payload_table">
<name>Key Exchange Payload Fields</name>
<thead>
<tr>
<th align='center'>KEM</th>
<th align='center'>Payload Length (initiator / responder)</th>
<th align='center'>Key Exchange Method Num</th>
<th align='center'>Data Size in Octets (initiator / responder)</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">ML-KEM-512</td>
<td align="center">808 / 776</td>
<td align="center">TBD35</td>
<td align="center">800 / 768</td>
</tr>
<tr>
<td align="center">ML-KEM-768</td>
<td align="center">1192 / 1096</td>
<td align="center">TBD36</td>
<td align="center">1184 / 1088 </td>
</tr>
<tr>
<td align="center">ML-KEM-1024</td>
<td align="center">1576 / 1576</td>
<td align="center">TBD37</td>
<td align="center">1568 / 1568</td>
</tr>
</tbody>
</table>
</section>
<section anchor="receipent-tests">
<name>Recipient Tests</name>
<t>Receiving and handling of malformed ML-KEM public keys or ciphertexts <bcp14>SHOULD</bcp14> follow the input validation described in the Module-Lattice-Based KEM standard <xref target="FIPS203"/>.</t>
<t>Responders <bcp14>SHOULD</bcp14> perform the checks specified in section 7.2 of the Module-Lattice-Based KEM standard <xref target="FIPS203"/> before the Encaps(pk) operation. If the checks fail, the responder <bcp14>SHOULD</bcp14> send a Notify payload of type INVALID_SYNTAX as a response to the request from initiator.</t>
<t>Initiators <bcp14>SHOULD</bcp14> perform the Ciphertext type check specified in section 7.3 of the Module-Lattice-Based KEM standard <xref target="FIPS203"/> before the Decaps(sk, ct) operation. If the check fails, the initiator <bcp14>MUST</bcp14> reject the ciphertext and <bcp14>MUST</bcp14> fail the exchange. In this case, the initiator <bcp14>MAY</bcp14> send a Notify payload of type INVALID_SYNTAX to the responder as a separate INFORMATIONAL exchange, usually with no other payloads. This is an exception for the general rule of not starting new exchanges based on errors in responses.</t>
<t>Note that during decapsulation, ML-KEM uses implicit rejection which leads the decapsulating entity to implicitly reject the decapsulated shared secret by setting it to a hash of the ciphertext together with a random value stored in the ML-KEM secret when the re-encrypted shared secret does not match the original one.</t>
</section>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>All security considerations from <xref target="RFC9242"/> and <xref target="RFC9370"/> apply to the ML-KEM exchanges described in this specification.</t>
<t>The main security property for KEMs standardized by NIST is indistinguishability under adaptive chosen ciphertext attacks (IND-CCA2), which means that shared secret values should be indistinguishable from random strings even given the ability to have arbitrary ciphertexts decapsulated. IND-CCA2 corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused. A weaker security notion is indistinguishability under chosen plaintext attacks (IND-CPA), which means that the shared secret values should be indistinguishable from random strings given a copy of the public key. IND-CPA roughly corresponds to security against a passive attacker, and sometimes corresponds to one-time key exchange. As with (EC)DH keys today, generating an ephemeral key exchange keypair for ECDH and ML-KEM is still REQUIRED per connection by this specification (IND-CPA security). </t>
<t>The ML-KEM public key generated by the initiator and the ciphertext generated by the responder use randomness (usually a seed) which MUST be independent of any other random seed used in the IKEv2 negotiation. For example, at the initiator, the ML-KEM and (EC)DH keypairs used in a PQ/T Hybrid key exchange should not be generated from the same seed.</t>
<t>SKEYSEED and KEYMAT in this specification are generated from PQ/T Hybrid key exchanges by using shared secrets, nonces, and SPIs with a pseudorandom function as defined in <xref target="RFC9370"/>. As discussed in <xref target="PQ-PROOF2"/>, such PQ/T Hybrid key derivations are IND-CPA, but not proven to be IND-CCA2 secure although the keys could be reused if the nonces are never reused. </t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>IANA is requested to assign three values for the names "mlkem-512", "mlkem-768", and "mlkem-1024" in the IKEv2 "Transform Type 4 - Key Exchange Method Transform IDs" and has listed this document as the reference. The Recipient Tests field should also point to this document:</t>
<table anchor="tab1">
<name>Updates to the IANA "Transform Type 4 - Key Exchange Method Transform IDs" table</name>
<thead>
<tr>
<th align="left">Number</th>
<th align="left">Name</th>
<th align="left">Status</th>
<th align="left">Recipient Tests</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">TBD35</td>
<td align="left">ml-kem-512</td>
<td align="left"> </td>
<td align="left">[TBD, this draft, <xref target="receipent-tests"/>],</td>
<td align="left">[TBD, this draft] </td>
</tr>
<tr>
<td align="left">TBD36</td>
<td align="left">ml-kem-768</td>
<td align="left"> </td>
<td align="left">[TBD, this draft, <xref target="receipent-tests"/>],</td>
<td align="left">[TBD, this draft]</td>
</tr>
<tr>
<td align="left">TBD37</td>
<td align="left">ml-kem-1024</td>
<td align="left"> </td>
<td align="left">[TBD, this draft, <xref target="receipent-tests"/>],</td>
<td align="left">[TBD, this draft]</td>
</tr>
<tr>
<td align="left">38-1023</td>
<td align="left">Unassigned</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
</tbody>
</table>
</section>
</middle>
<back>
<references>
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<reference anchor="FIPS203" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf">
<front>
<title>Module-Lattice-Based Key-Encapsulation Mechanism Standard</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date year="2024" month="August" day="13"/>
</front>
<seriesInfo name="NIST" value="Federal Information Processing Standards"/>
</reference>
<reference anchor="RFC9242">
<front>
<title>Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
<date month="May" year="2022"/>
<abstract>
<t>This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment. The Intermediate Exchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9242"/>
<seriesInfo name="DOI" value="10.17487/RFC9242"/>
</reference>
<reference anchor="RFC9370">
<front>
<title>Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author fullname="CJ. Tjhai" initials="CJ." surname="Tjhai"/>
<author fullname="M. Tomlinson" initials="M." surname="Tomlinson"/>
<author fullname="G. Bartlett" initials="G." surname="Bartlett"/>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
<author fullname="D. Van Geest" initials="D." surname="Van Geest"/>
<author fullname="O. Garcia-Morchon" initials="O." surname="Garcia-Morchon"/>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
<date month="May" year="2023"/>
</front>
<seriesInfo name="RFC" value="9370"/>
<seriesInfo name="DOI" value="10.17487/RFC9370"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC7296">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="Y. Nir" initials="Y." surname="Nir"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
<date month="October" year="2014"/>
</front>
<seriesInfo name="STD" value="79"/>
<seriesInfo name="RFC" value="7296"/>
<seriesInfo name="DOI" value="10.17487/RFC7296"/>
</reference>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology-04" target="https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqt-hybrid-terminology-04">
<front>
<title>Terminology for Post-Quantum Traditional Hybrid Schemes</title>
<author initials="F." surname="D" fullname="Florence D">
<organization>UK National Cyber Security Centre</organization>
</author>
<author initials="M." surname="P" fullname="Michael P">
<organization>UK National Cyber Security Centre</organization>
</author>
<author initials="B." surname="Hale" fullname="Britta Hale">
<organization>Naval Postgraduate School</organization>
</author>
<date month="September" day="10" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-04"/>
</reference>
<reference anchor="NIST-PQ">
<front>
<title>Post-Quantum Cryptography</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date/>
</front>
<seriesInfo name="https://csrc.nist.gov/projects/post-quantum-cryptography" value=""/>
</reference>
<reference anchor="RFC8784">
<front>
<title>Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security</title>
<author fullname="S. Fluhrer" initials="S." surname="Fluhrer"/>
<author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
<date month="June" year="2020"/>
<abstract>
<t>The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8784"/>
<seriesInfo name="DOI" value="10.17487/RFC8784"/>
</reference>
<reference anchor="I-D.draft-cfrg-schwabe-kyber-04" target="https://datatracker.ietf.org/doc/html/draft-cfrg-schwabe-kyber-04">
<front>
<title>Kyber Post-Quantum KEM</title>
<author fullname="Peter Schwabe" initials="P." surname="Schwabe">
<organization>MPI-SP & Radboud University</organization>
</author>
<author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
<organization>Cloudflare</organization>
</author>
<date month="January" day="2" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-cfrg-schwabe-kyber-04"/>
</reference>
<reference anchor="RFC7383">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation</title>
<author fullname="V. Smyslov" initials="V." surname="Smyslov"/>
<date month="November" year="2014"/>
<abstract>
<t>This document describes a way to avoid IP fragmentation of large Internet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allow IP fragments to pass through.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7383"/>
<seriesInfo name="DOI" value="10.17487/RFC7383"/>
</reference>
<reference anchor="PQ-PROOF2" target="https://eprint.iacr.org/2023/972">
<front>
<title>Security of Hybrid Key Establishment using Concatenation</title>
<author initials="A." surname="Petcher" fullname="Adam Petcher">
<organization></organization>
</author>
<author initials="M." surname="Campagna" fullname="Matthew Campagna">
<organization></organization>
</author>
<date year="2023"/>
</front>
</reference>
</references>
</references>
<section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name>
<t>The authors would like to thank Valery Smyslov, Graham Bartlett, Scott Fluhrer, Ben S, and Leonie Bruckert for their valuable feedback.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA9Vc7XLbNpf+z6vAOj9s7ysptpw4jqftu6qlNB7HjmM77Xby
ZjIQCUlcUyRLUFbVOL2WvZa9sn3OAUCC+nCStrszdWZiiSSA8/mcD4But9uB
LmUafZBJlqpjURYzFcR5wZ902d3be77XDaIsTOUUt6NCjsr2rZzmMpW3sW5P
k/atmrbjW3XXDUJZHgtdRkGYpVqleqaPxTbNuB3k8XEgRJmFuLJQehtfdFaU
hRpp78pi6l8o4zLBmluXmS7bv8xkWs6m4uViWMSROFMLMfg1nMh0rMQ8Lifi
/FX7bHAu4lSUEyVO01IVqSqbD14WGUjIEvGjKnScpaIrdk7PBnfd3a1ADoeF
usNydiK+vhXo2XAaa3r4ZpGDmtPBzYtAFkoei2sVzoq4XATzrLgdF9ksx+3L
68HJ+SC4nR9XNLT7JLUgkiXGf+z3bgafglu1wKgIQmmLyzcCX4VyVIIFXpzu
1VxVlzwJrA4J5KycZAXNC4EKMZoliVHdpUwzLc4q1fHtrBjLNP5NluDvWPSm
8jcI5Sc1BG/FXRwqLfgxNZVxcixuc5rjPyQ/1gmzabC6zA+qkEWUiSt5J8fZ
H1hkHBaNFdKsmGLonSIDegH5dvcOjkX/9Wlnf69zuNc9enxxen3ToTsd3ApE
EKejNWPacU7ixo+zq/MsmiWq/UqWJahoD6VWLNb2IA1lrmcJUyzOFQk51lNx
TZ4C7rZ4mkrSwjJ5LC54hEygeo1VZqUS2agapgV+ixtMl2ZJNl6IHaJ8lycw
xtHd6x60947a3Sd8UasiVprYcavQgGPxQkWQMq1iGQWVMG1IEg+P6/WMavgR
N8Fl/8WxmJRlro8fP07vknw21B0wV3bG2d1j+kBXHpPMmnLtQHydPBpB5UxF
+/JNU5rspW+sl54Ui7zMxoXMJ4v/Q2ntH7Yhsk3CcmyGughrHvMi+y8Vlvpx
7sFKO/QIDoJ2uy3kUJeFDMsgeDfoX7y+GRyLmwl5WqlSljhoLSexNpgo8KHM
xBiIc9q76ImzgQizSOUZntekA+vJHXFa4s4sicRQCSl0xS0tdmsnG8N0Ccdk
6QBgHicJWKQhSVbS2jLKcqKjBTmJXl/oHKCbFTBhnqMFGQtF00jQHMV3cTSD
qLHeMFF2mfkkDidEs24QW2RTQGauilJcqbtYzTvMucwhOokBhlWQH6kwjrDg
cGEw12Cf+OmHjngvgoD0JQoVQl7JouI0/g0jDFcgXaRqbtCv4XNT53MtS2QI
JrHijFyUpOn0VkDlNHNpJmH2Yj2ZYk2iulKPzkHrCAYiJtmcyMdMTraSTA3y
jGJjj0kTjitaKpQVFCzHJuxAbW6c2BkkSQylhOJkVtypXdGPR1iz/VIlyVSm
lqCJwe9KnFgwmxsbSdU4K2OIALNjJfaAk0kMY7nuEVHaSgPxR2g5gk7GMobz
CDZf4HqywOqYcAHBJOqO5OICJ8A0h4sVxq+gL9gKPyzmSt6mwA4IBxzWQonZ
qjERQylUCF11AuMd0ziKEhUEjyjKFQDSkGQQBD3j+utJqdDBkiJ2Tq7enOy2
RDyixYYqRAiBTSC6JoirLeso5QQX4HUC0JRAuNZcaB2yFZmMM4ThyVQb8yiz
SC5YnEaNrMWOuM6mCikO7BBPQ752BgyAZKazFMTSdE7EZB+f0afY2Rmc7PZf
7pI9OdUpoydDORyE1iBpY7qldWymMpqVM6gTRgqBSEESEXMyyTuEQ3JWazZm
xjgNk1n09fnN49NLrUJRztJUJY7Hmub1xga/nnFEGZz0X67kKCA+Lmjkh+ve
h9OL0xt4itZyrHQHzn+TkUfBPbVBSaSEIShuiY8f/3n14uTo2dGTT58ITdl4
oIVGlneJgRNZmHis2UNFqaZ5huRiIQzwsYoROApWpxR5odp2EJHKEKkwIdhT
tEy+cCJH9IRBe9x61sSM4zkkZ9AHFAsvBXaqFcQJyaagDkVTMl//Br6ed590
wVekRnGKFSzYRJkHLyKRBcMKC6sSqSdug4ok2dOLm8HV+aB/iqTRjeiInhZ+
8DI0EybMNDB+YRYoKH6kbHRgC6ZCWao4l7/GUwy5KWSKiAGIf5vGAP2d85u3
cMRNa2oHwKNCjglcwZsFZjZLxjBWCMk3VwQzhu9lQj1+CT+zGQLmZTUtu0bH
yfLg2d5aWc5y+qBNdKvl2py9kuZmnsjijS2wwK/PBj9fDwZ9vo7P570bnhPp
Ex6Sibae2ADs+UMcmjDJqLRkeusdjq4s2Zvw7c3G1An8YajAPKmUWCQUdOho
8xvI0KZpEKHxFBd/aYSzZhNFagQ1SnUoY5BWe4GZKNTxOJUEWhBIj8END0Xk
cFfZDB8OWnRtIfI4vCUPXgwJ2bRBu7jQFrQ2JNk7iD67SxSbZ4Acp+1+x9Sg
4agYt3U4mcuhat/SEu29g0+fOna5uVkvbaYduPjVSf+OCYi7pMGPH71ighZz
2RkmbiyEZykxrQfQw++ESySv1EgVirCjqm4Sk0MV+IIQE4k7i+BfwrSNnzBN
uERRzdERrzFlMY81aVLlhCtuOZiVIwF6a5DZgwoLNc3ulKGoehDWvCKA90B6
zrKycEYODAPXYREPbaJl5eNnb9YQGgbol7i141K09tx7xY8bAcnET5o5TCTq
oJDzMQrPy1WyC1cmq4UVzxKWnUFd3yEphZY8hj5VdwpF9zj7wwei1CGEcx/d
zM5MVLfoYTNRkwWYdeGyozixmvCQT7ImxnB/wlOirvJUAYhIWc2FX14s4Y+T
KSHHo0ckZh0EpwaJEJBL9WtpyhjFNZ3YWMNVVZnzxctVlGktKaQGFQpNVIaS
cxkLIEqq1B7JEFg0hBSKMjSFug15ptiGY/6g0p1d0f5O7OS3LaFvd7ePRY9E
NpTDGLl+aTPCsUpVIZsZYasqcfie0jVM0pDt/HabhYw6DJmaMkXEtr7d7tDi
BhGwrFk+RE2l9brlm7XLyuqlvFWcw8Qp0t4NJCAQ4iYRGMY5vJZ1sx2W5q7N
ayyV21obCvuKKdQQTFgylbhD9EXq6yhaYp/XXEdHTeUqRVxxwuI0Em14vGZp
RyShdDxDTYanVVHgmTuZzFSHgANZkKQRtpFGYqWy02TvZCNNVAUysJnGmkva
ambWBEYh+FCkiWTOEBdOMo0I4PEB0EeRjWzn9KLfPjnpdXedRKYK+ZCpuJuc
MbGgY+Jq9qWVE2UKZuRTEX7pkrJRbSpvV8bDGSyFgNCJBGmyGMYl57I1ddrT
GoG3oxEOUgClUN5H2uQ9VloVvEDDIXNs+FNFy9V4vqk99rWcS+TuFpZLLq8i
k2VTZdsG3kwdABaKYLsjYFVUKELAFQFp5jDsAXVYLeSJjNM1SrjsrdMBkf6X
6MGoAE5F6b+FulomVsiXwPRsNp4gBn9W1pAcosuKrMnoy3hKiXJzBgSxNt1o
gGOH4dhAdhC4Hq/m0ndduyRpZCsPtEv+lgnHe18EJvSbLE28UrJIY9dqGRB6
GNiCs7B1JRx+8yKexrxIFX+ps1bMQspSK/FpGBGidFoaG8tGIwqe4yxD0q0K
7pMSeSbqVk0PPaWOEF0cyoQeMApYQkgNPenN+aBpFXF0y2UhYStYumUfbz/d
71afnx0eGYuy3/eRRnKmApnOIUAgZp57WAgTIzXayOnMNYFeEl2VTrb4MDH+
zYmL3i0IGM+J/Rbl7LToU7eUnaA2ZrcQnDKiZhFpcQjg4PqjN7hu73dBOH94
3uW56HP36SFlWEh5jDS5M7AmC3JtAO2JYVkKRIHJEJtJjuTmglbFnTG0phA8
eVvr4FYqoMsgcZW6+SYQT3MgKpVVvODa5gnX2sZRF1SRUsjitiAmirOIBUSO
73UJHmLOA+p1psVYDZ6VMrheLnJOcau6/uZty7aZlotscOtoLdQvsxg2hDGC
a3UyGjcFyvCcEM21gIcZ2ywhbUxdIk6GI1sTsE2oAmGBoewkS+9MW9wUsX0y
PE7ctYnznDFn1OfeOn97fbPVMr8F4Ik+Xw3evD29GvTp8/XL3qtX1YfAPnH9
8vXbV/36Uz3y5PX5+eCibwbjqmhcCrbOez9vGeveen15c/r6ovdqy3iEX7dQ
jmrKdQpTRY6YwyExcAUNe9H3J5f/89/7T2ya3t3ffw4wNF+O9p9RR2vOzSDO
lVJI3Hylcjggv5WcIRGgAL7jUiYAAclRbZ4KKJwiw7+/I8m8PxbfDMN8/8l3
9gIx3LjoZNa4yDJbvbIy2AhxzaU1y1TSbFxfknST3t7Pje9O7t7Fb/6ZAJpE
e//on98FATWSl7Y6hRcjXeW2to1TRY+m4dvkpupxRg9OYppqiGV+AdaiIRRr
jAcknJ9mGh9w3e3+YqDOwtg2dZv+YvsoFI4afdqds8Gu6x4759w1oFnXu40R
+2Kn1++fDfZ3TeuOoErQjrR4YoLLaZ8A5+Ap+fXBoVcSMtrU3xhsmpB843s0
PiFoprYsNdw2mkLMzGCVChBgsoK5pF2kRkucpGK5paKe4WUVWXgfi3h04bLa
oakwnObnhFLb+sFvP9Mcm5t9Q8Ccsul4c92Kd/bFVSNgCB0qVKS///47ymc3
9jM/V25a2jD5/I8QD98PXvavdjx2kTZf92KE7rNB3BIXcSt4d7Hjs/5h8J8n
L3sXP2DE28vL11c3g/7u+3b7u+BzhOPnG9Czbr2C1ytaXzLH6s8FJPzuZHB1
A+h6/0VzfAFLQSUY/0mi9kx8hGx29nc/kWy/mu/mdNdnmKygyYI1E7kxvbc3
L3dFp9P5mgVXR7OhBUAk9SvXTQa8rhVvsoluB/+Wm0VsBzt7u6wf/OaAVqgx
SoTC+d7StqZ1DLcPxZ1Z35+qagWln7mrFbdplrpemnESPookm5e7PvsQkfw/
yHfx4+K9CYf4qtzXom6EV1jQ8GSzOcDVxcKGg5qaIPieUhO7y0BNXpu72WZd
EwDcuBYiQlEw4dRJa6BrLhdJJqOqJUUEAv1KCLxO3lXNgmPI8OfvzHKK/jne
CGKcMg86B519T5m8f2Qw+YGNC9ownBHrtMdqa3ealWbrrs4GkRlPYBnQLrgP
rnXm6fpkkbcXlQruL1EXDI9w34AF4lpzhlZvEqoKUzpPwFQVco7JSmNnSVyW
iWorlO6UztJTWMMvVJFIwtSmJjmbcpuKTpIpOlHQjFMzrZbC7bZezqLrKpnD
FqqR9jCuzlQ0GwyaY1aj/YYSoN4CrZqBHbr+1UzSHQMgtVl4afQXS2A5gHk9
IyOOzzFZre4xWnGJcSim7+w2ttC3RHazy9gRnvdxCZVmc9qyD6nDJ92GI1aS
jb0h5udsQAJotEJgmxsN3YDavgU1+r26DVmFbNpWfnZwRO0J/XUVl14quah2
o/MG5GZhgmzDZDNVpUXJR4/2G+Z8cmdYy4Oa6nE6U65adqhew24+kVq5fnxj
795gEIezlhuMmkByYmJbVw/tz1pw8zy7gfem7yguSN92LdNU47zxCXJSjxpI
uiKM8zs88+RArMZFI1W7lW1y0H2oRM+mhhbqDfo7fxu2a6vs1jQI1jBqIbru
8Czh84PYvBaI1wkpdrXYUNGGtmy0UGrIflJD7LPu80NEXz5zxmF7bZjfX3Ot
u+baQSD28HBXHCCjfioOxTNxJJ5/zbXgH+0/+S+4bxqJuD+5RzY7uB5c/Tjo
g8j7ilz3yCuVjqED+3P/l9Agmu5xrspJFomL2VQ0SGhQVv/8VTT8mZ/74PcN
dxqc9WUpNzz3+19Aw5+WgzProL2kb3Mg0kPYZhKwv3/0xETFltAGDpfsZRSr
+khT1aV0nr4J8tZUj7za825nmSAvxNEje0dHDxOEJTcvV6cePNfzw8Zyy008
eubp4WfW+0sF8PTZGoqWJPBZir5CArwejIKW3OSq9S41DTl4uqYv0WxWmHb3
A1F73Ur+XrjtYnnHbjZWBHyeB9PVja/lYS5U0MlEOhDIx1pMbhDW+1Cmd81H
jZZOMtXRivrNeaZ1TBtVS7PX9KyTJsODjaHsUhAW6zFD8Cu1s5LNzR7PKP2+
T3Vaa1NOscbO/F6RVhsNoybOHvagFvbnCfUTsKVNgzpf4tpK2sOm67o1Xq6x
uV5dqVCpFWyrNpMJryuZ3bsla2tkk7ikLT8d/H+oSzfkPZ2HuwXeeehqv9Wr
p+2hOLl0LE4fC9MDc5comf8WFI12nEDpCvKHmP4rdk0fg+45CzYHCJwtrPYc
mqWBmS9uFjYrFU116ruG0DW5HWWW17OhVr/MeIe15Y6eN0yDRVyXwZWF+xyv
aRI6wXwkXo0MSBVx/bGoPqr6qqqv5uaqSx/pCnebjHz/IXY8ClpOwDT08jQ2
v5y4b9wukDsTWosFXlV6YeWuW584p2MiutpWotEeR44d4ZhxnDg2HA/2dyE+
VbSwmGd5xPIkhdid/GXadKWbumralH+vaXLYs5NgnatC2kthhAt5Zyqmjedj
v3K1x+HpIHVvVk4+xPumf2y/FvsWB2zfx6jHuhhrhmXUWm2lQ/Yeh3bHLfKx
g1njOtDporbRzeRU8kJpuUS8hQduw1HzvmU20u2zMgm5PSCqzvV1PIZIX1uI
xjJVq7pxZ5hkQyp1T+h8CPeC6uLNHYZjCVgnMtuP3h3TXLd3qZq97tF2ikpG
pntD5+IG1NY9eXn6qv+BDmJXgviJcCh0K/M5FDuRt0ANW+ZIOG9yeqC7rsQr
+Sw21h7RGXPvaLgt2bXit/1YvU6hOi5ndoOn3tSw73GYowl0QL5OVWxiYeCN
EofNnPJ+IBaYxtQ5HUk9ocUtLW7fiWRXi4a7QBu4i6ugU0UyMrkXr1+9ev3T
28sPmMjHLRPQXeSzZ55hXUP4nOYoaU63lHHB556ZKjg0vwxSbawBpvd2nYVv
ZJQmchhugH11b86nsx64FgUorj1ZjmsOhy0nNXba6LTnRSfGKpBhYdPYZ7Vv
yOZGYcZoBgwPF433c0xwtGlCrXpzrOjGCxlfIM9KDIzabmPQe5mBSW8t9fTs
DXCw3FR+UDYVXUuR+wHZIPe6Qr6Qx4TONwgiWnx8REeV4hxX2iVd+RQEV3Tl
znSNAcH4L2HnHSG+JtYmV5vOBNJ1lcJb3aOM3ycwLkD5AhA1jkyUauzH/02P
O5362yUtwiD4udJ8+ssIcH1/HrDgtbTpK4vLIZ49GGJcbUpHqGaw54mi03a1
52hx6HYcKqosVPOR3rVL8ztalRY7YrBKco1InjpHjRY1n6xfptg/n8kvZPhP
M9fE0gob4KL7GS68mc3bYMtc/F0sxoYhK4Oq9KyRXivaIi+J5qHCteqes6Xm
ecEVpfCRa7o85ANqVZL4mWG5eek4CC4y3uWXdLqz+UwFWhzx42kOg4JkjJbq
EjlRMtL2DZlqNL+lV9pzs24oH2OqVOwfmV2qDIDXqP9Ku63BezvIuSaONc84
ymysSC8mlkt3htR0x+l9wZXCwi4xd/sxBe33uPcJm2REmTLlP9Qcmn3ErIjH
MWVRWarWbf2skRI1pktzlIv2PPhlB9/y6UVNZ6gEqDbXof47WQaf4jdv5QaP
6qMrJ3T0PrLH5qHGHr9kbG+GjZumFFrJuJvvK+R5snC5i5VUfSCnAdzlyiHA
jqGN355eposv8ruoKBB0aRJbOoc7Tvksm024XUeD/hKBFlvThP40xbPDoy1z
+st8p1bDlpeOowjaWjnM0l7bZ6ofO+3rLRvktKC3APhYXuM8mW6+PdMRnBQs
h1HTAbSnmlF/0gtzcVoaIXrzHQfBvTsJcu8fC1l/deXKPXX1Z9Mhl2r4uaA3
bQXXc6UsESbuV0i790Dx/s+vLqj9RwtWavHa+Pfi3c33/ZaoX6inFyqXM4xP
71vrHn1PbW5e4NBbgFtKf2yBTSscPKNZD+ysb1NjgSryVlnpv6/5/Gdl+fFY
PCrlcN/86YVvt95yca2rPUdyln/9IZv+15bgvw+whfrdvOc9lOEtuWUvvE2z
eaIibm5q0JCyNano260R7FZtffL+UIKhyBxoRL5Dhm/+/oMWc7b0JL61e6Qy
vRU/yoTOeVxPFzrJ7tiNSfTk1Xywn3ZVgRwze8TOsOk8A7jxvxT2JcPGRgAA
-->
</rfc>