-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-kampanakis-ssh-pq-ke.xml
612 lines (543 loc) · 47.6 KB
/
draft-kampanakis-ssh-pq-ke.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
<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="exp"
docName="draft-kampanakis-curdle-ssh-pq-ke-03"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.38.1 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="PQ SSH">PQ/T Hybrid Key Exchange in SSH</title>
<seriesInfo name="Internet-Draft" value="draft-kampanakis-curdle-ssh-pq-ke-03"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- <author fullname="Panos Kampanakis" initials="P." role="editor" surname="Kampanakis"> -->
<author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
<organization>AWS</organization>
<address>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Douglas Stebila" initials="D." surname="Stebila">
<organization>University of Waterloo</organization>
<address>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Torben Hansen" initials="T." surname="Hansen">
<organization>AWS</organization>
<address>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2024"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>CURDLE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>post-quantum SSH</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange methods based on traditional ECDH key exchange and post-quantum key encapsulation schemes. These methods are defined for use in the SSH Transport Layer Protocol. <!-- TODO: Update to hybrid if we end up doing hybrid. --> <!-- It also defines post-quantum public key authentication methods based on post-quantum signature schemes These methods are defined for use in the SSH Authentication Protocol. --> </t>
</abstract>
<!-- <note>
<t>[EDNOTE: The goal of this draft is to start the standardization of PQ algorithms in SSH early to mitigate the potential record-and-harvest later with a quantum computer attacks. This draft is not expected to be finalized before the NIST PQ Project has standardized PQ algorithms. After NIST has standardized then this document will replace TBD1, TBD3 with the appropriate algorithms and parameters before proceeding to ratification. ]</t>
<t>[EDNOTE: Discussion of this work is encouraged to happen on the IETF WG Mailing List or in the GitHub repository which contains the draft: https://github.com/csosto-pk/pq-ssh/issues.]</t>
</note> -->
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>Secure Shell (SSH) <xref target="RFC4251" format="default"/> performs key establishment using key exchange methods based on (Elliptic Curve) Diffie-Hellman style schemes defined in <xref target="RFC5656" format="default"/> and <xref target="RFC8731" format="default"/>. <!-- SSH <xref target="RFC4252" format="default"/> <xref target="RFC8332" format="default"/> <xref target="RFC8709" format="default"/> also defines public key authentication methods based on RSA, ECDSA, or EdDSA signature schemes.--> The cryptographic security of these key exchanges <!-- and signature schemes-->relies on certain instances of the discrete logarithm <!-- and integer factorization --> problem being computationally infeasible to solve for adversaries. </t>
<t>However, if sufficiently large quantum computers become available, these instances would no longer be computationally infeasible rendering the current key exchange and authentication methods in SSH insecure <xref target="I-D.hoffman-c2pq"/>. While large quantum computers are not available today an adversary could record the encrypted communication sent between the client and server in an SSH session and later decrypt it when sufficiently large quantum computers become available. This kind of attack is known as a "harvest-now-decrypt-later" attack. <!--Record-and-harvest attacks do not apply retroactively to authentication but a quantum computer could threaten SSH authentication by impersonating as a legitimate client or server. --></t>
<t>This document addresses the problem by extending the SSH Transport Layer Protocol <xref target="RFC4253" format="default"/> key exchange with Post-Quantum Traditional (PQ/T) Hybrid <xref target="I-D.ietf-pquip-pqt-hybrid-terminology"/> key exchange methods. <!--and the SSH Authentication Protocol <xref target="RFC4252" format="default"/> with public key methods based on post-quantum signature schemes--><!--TODO: Update to hybrid if we end up doing hybrid. --> The security provided by each individual key exchange scheme in a PQ/T Hybrid key exchange method is independent. This means that the PQ/T Hybrid key exchange method will always be at least as secure as the most secure key exchange scheme executed as part of the exchange. <xref target="PQ-PROOF" format="default"/> <xref target="PQ-PROOF2" format="default"/> contain proofs of security for such PQ/T Hybrid key exchange schemes.</t>
<t>In the context of the <xref target="NIST_PQ" format="default"/>, key exchange algorithms are formulated as key encapsulation mechanisms (KEMs), which consist of three algorithms:</t>
<ul>
<li>'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key 'sk'.</li>
<li>'Encaps(pk) -> (ct, ss)': A probabilistic encapsulation algorithm, which takes as input a public key 'pk' and outputs a ciphertext 'ct' and shared secret 'ss'. </li>
<li>'Decaps(sk, ct) -> ss': A decapsulation algorithm, which takes as input a secret key 'sk' and ciphertext 'ct' and outputs a shared secret 'ss', or in some cases a distinguished error value.</li>
</ul>
<t>The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (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 common design pattern for obtaining security under key reuse is to apply the Fujisaki-Okamoto (FO) transform <xref target="FO" format="default"/> or a variant thereof <xref target="HHK" format="default"/>. --> A weaker security notion is indistinguishability under chosen plaintext attack (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.</t>
<!-- <t>The corresponding post-quantum signature algorithms defined in the <xref target="NIST_PQ" format="default">NIST Post-Quantum Cryptography Standardization Project</xref> are </t>
<ul>
<li>'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm, which generates a public key 'pk' and a secret key 'sk'.</li>
<li>'Sign(m, sk) -> sig': A deterministic signing algorithm, which takes as input a message 'm' and a private key 'sk' and outputs a signature 'sig'. </li>
<li>'Verify(m, pk, sigma) -> pass/fail': A verification algorithm, which takes as input a message 'm', a public key 'pk' and a signature 'sig' and outputs a verification pass or failure of the signature on the message.</li>
</ul> -->
<t>The post-quantum KEM used in the document is ML-KEM. ML-KEM was standardized in 2024 <xref target="FIPS203"/> with three parameter variants, ML-KEM-512, ML-KEM-768, and ML-KEM-1024.</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" format="default"/>.</t>
</section>
</section>
<section anchor="kex" numbered="true" toc="default">
<name>PQ/T Hybrid Key Exchange</name>
<section anchor="kex-abstr" numbered="true" toc="default">
<name>PQ/T Hybrid Key Exchange Method Abstraction</name>
<t>This section defines the abstract structure of a PQ/T Hybrid key exchange method. This structure must be instantiated with two key exchange schemes. The byte and string types are to be interpreted in this document as described in <xref target="RFC4251" format="default"/>.</t>
<t>In a PQ/T Hybrid key exchange, instead of SSH_MSG_KEXDH_INIT <xref target="RFC4253" format="default"/> or SSH_MSG_KEX_ECDH_INIT <xref target="RFC5656" format="default"/>, the client sends</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
byte SSH_MSG_KEX_HYBRID_INIT
string C_INIT
]]></artwork>
<t>where C_INIT is the concatenation of C_PK2 and C_PK1 (C_INIT = C_PK2 || C_PK1, where || depicts concatenation). C_PK1 and C_PK2 represent the ephemeral client public keys used for each key exchange of the PQ/T Hybrid mechanism. Typically, C_PK1 represents a traditional / classical (i.e., ECDH) key exchange public key. C_PK2 represents the 'pk' output of the corresponding post-quantum KEM's 'KeyGen' at the client. </t>
<t>Instead of SSH_MSG_KEXDH_REPLY <xref target="RFC4253" format="default"/> or SSH_MSG_KEX_ECDH_REPLY <xref target="RFC5656" format="default"/>, the server sends</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
byte SSH_MSG_KEX_HYBRID_REPLY
string K_S, server's public host key
string S_REPLY
string the signature on the exchange hash
]]></artwork>
<t>where S_REPLY is the concatenation of S_CT2 and S_PK1 (S_REPLY = S_CT2 || S_PK1). Typically, S_PK1 represents the ephemeral (EC)DH server public key. S_CT2 represents the ciphertext 'ct' output of the corresponding KEM's 'Encaps' algorithm generated by the server which encapsulates a secret to the client public key C_PK2. Before producing S_CT2, if the ML-KEM public key checks defined in Section 7.1 of <xref target="FIPS203"/> fail, the server MUST reject the SSH_MSG_KEX_HYBRID_INIT message with a disconnect (SSH_MSG_DISCONNECT) of the session and use the SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message. <!--The client decapsulates the ciphertext by using its private key which leads to K_PQ, a post-quantum shared secret for SSH.--></t>
<!-- <t>[EDNOTE: Initially we were encoding the client and server traditional and post-quantum public key/ciphertext as its own string. We since switched to an encoding method which concatenates them together as a single string in the C_INIT, S_REPLY message. This method concatenates the raw values rather than the length of each value plus the value. The total length of the concatenation is still known, but the relative lengths of the individual values that were concatenated is no longer part of the representation. This assumes that the lengths of individual values are fixed once the algorithm is selected, which is the case for traditional key exchange methods currently supported by SSH and all post-quantum KEMs in Round 3 of the NIST post-quantum standardization project. If that is the WG consensus we need to put a note of this in the Appendix for historical reference and expand on the concatenated string here in this section. For example, the C_CL is represented as a fixed length 32 byte string for Curve25519. ] </t> -->
<t>C_PK1, S_PK1, C_PK2, S_CT2 are used to establish two shared secrets, K_CL and K_PQ. K_CL is the output from the classical ECDH exchange using C_PK1 and S_PK1. K_PQ is the post-quantum shared secret decapsulated from S_CT2. If the decapsulation checks defined in Section 7.2 of <xref target="FIPS203"/> fail, the client MUST reject the SSH_MSG_KEX_HYBRID_INIT message with a disconnect (SSH_MSG_DISCONNECT) of the session and use the SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message. K_CL and K_PQ are used together to generate the shared secret K according to Section 2.4. </t>
</section>
<section anchor="message-numbers" numbered="true" toc="default">
<name>PQ/T Hybrid Key Exchange Message Numbers</name>
<t>The message numbers 30-49 are key-exchange-specific and in a private namespace defined in <xref target="RFC4250" format="default"/> that may be redefined by any key exchange method <xref target="RFC4253" format="default"/> without requiring an IANA registration process.<!-- EDNOTE: https://github.com/openssh/openssh-portable/blob/2dc328023f60212cd29504fc05d849133ae47355/ssh2.h#L100 includes the numbers for OpenSSH. Also a discussion about it in https://groups.google.com/g/comp.security.ssh/c/f5jNVb0fMe4/m/U93doB0Sfn4J --> </t>
<t>The following private namespace message numbers are defined in this document:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
#define SSH_MSG_KEX_HYBRID_INIT 30
#define SSH_MSG_KEX_HYBRID_REPLY 31
]]></artwork>
</section>
<section anchor="kex-methods" numbered="true" toc="default">
<name>PQ/T Hybrid Key Exchange Method Names</name>
<t>The PQ/T Hybrid key exchange method names defined in this document (to be used in SSH_MSG_KEXINIT <xref target="RFC4253" format="default"/>) are </t>
<artwork align="left" name="" type="" alt=""><![CDATA[
mlkem768nistp256-sha256
mlkem1024nistp384-sha384
mlkem768x25519-sha256
]]></artwork>
<t>These instantiate the abstract PQ/T Hybrid key exchanges defined in <xref target="kex-abstr" format="default"/>. </t>
<section numbered="true" toc="default">
<name>mlkem768nistp256-sha256</name>
<t>mlkem768nistp256-sha256 defines that the traditional client and server public keys C_PK1, S_PK1 belong to the NIST P-256 curve <xref target="nist-sp800-186" format="default"/>. The private and public keys are generated as described therein. The public keys are defined as octet strings for NIST P-256 as per <xref target="RFC5656" format="default"/>; point compression may be used. The K_CL shared secret is generated from the exchanged C_PK1 and S_PK1 public keys as defined in <xref target="RFC5656" format="default"/> (key agreement method ecdh-sha2-nistp256).</t>
<t>The post-quantum C_PK2 and S_CT2 represent ML-KEM-768 public key and ciphertext from the client and server respectively which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT2 using the client post-quantum KEM private key as defined in <xref target="FIPS203"/>. </t>
<t>The HASH function used in the key exchange <xref target="RFC4253" format="default"/> is SHA-256 <xref target="nist-sha2" format="default"/> <xref target="RFC6234" format="default"/>. <!-- We used SHA-256 here because of efficiency and because it is in all implementations. We considered SHAKE256 and its performance would be slightly worse but it would offer a better proof. We chose SHA-2 because of prevalence though. We did not use SHA-384 as it was not necessary to map to 192-bits of classical security because P-256 is 128 anyway. --></t>
</section>
<section numbered="true" toc="default">
<name>mlkem1024nistp384-sha384</name>
<t>mlkem1024nistp384-sha384 defines that the classical client and server public keys C_PK1, S_PK1 belong to the NIST P-384 curve <xref target="nist-sp800-186" format="default"/>. The private and public keys are generated as described therein. The public keys are defined as octet strings for NIST P-384 as per <xref target="RFC5656" format="default"/>; point compression may be used. The K_CL shared secret is generated from the exchanged C_PK1 and S_PK1 public keys as defined in <xref target="RFC5656" format="default"/> (key agreement method ecdh-sha2-nistp384).</t>
<t>The post-quantum C_PK2 and S_CT2 represent ML-KEM-1024 public key and ciphertext from the client and server respectively which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT2 using the client post-quantum KEM private key as defined in <xref target="FIPS203"/>.</t>
<t>The HASH function used in the key exchange <xref target="RFC4253" format="default"/> is SHA-384 <xref target="nist-sha2" format="default"/> <xref target="RFC6234" format="default"/>.<!-- We used SHA-384 here in order to comply with NIST CNSA 2.0 has requirements. We considered SHAKE256 and its performance would be slightly worse but it would offer a better proof. We chose SHA-2 because of prevalence though. --></t>
<t>This method is compliant with CNSA 2.0 requirements <xref target="CNSA2"/> until 2033. CNSA 2.0 requires support for ML-KEM-1024 in 2025 and makes it mandatory without any classical algorithm in the key exchange in 2033. </t>
</section>
<section numbered="true" toc="default">
<name>mlkem768x25519-sha256</name>
<t>mlkem768x25519-sha256 defines that the traditional client and server public keys C_PK1, S_PK1 belong to the Curve25519 curve <xref target="RFC7748" format="default"/>. Private and public keys are generated as described therein. The public keys are defined as strings of 32 bytes as per <xref target="RFC8731" format="default"/>. The K_CL shared secret is generated from the exchanged C_PK1 and S_PK1 public keys as defined in <xref target="RFC8731" format="default"/> (key agreement method curve25519-sha256).</t>
<t>The post-quantum C_PK2 and S_CT2 represent ML-KEM-768 public key and ciphertext from the client and server respectively which are encoded as octet strings. The K_PQ shared secret is decapsulated from the ciphertext S_CT2 using the client post-quantum KEM private key as defined in <xref target="FIPS203"/>.</t>
<t>The HASH function used in the key exchange <xref target="RFC4253" format="default"/> is SHA-256 <xref target="nist-sha2" format="default"/> <xref target="RFC6234" format="default"/>.<!-- We used SHA-256 here because of efficiency and because it is in all implementations. We considered SHAKE256 and its performance would be slightly worse but it would offer a better proof. We chose SHA-2 because of prevalence though. We did not use SHA-384 as it was not necessary to map to 192-bits of classical security because P-256 is 128 anyway. --></t>
</section>
</section>
<section anchor="shared-secret" numbered="true" toc="default">
<name>Shared Secret K</name>
<t>The PQ/T Hybrid key exchange establishes K_CL and K_PQ from the ECDH and ML-KEM key exchanges respectively. The shared secret, K, is the HASH output of the concatenation of the two shared secrets K_CL and K_PQ as </t>
<artwork align="left" name="" type="" alt=""><![CDATA[
K = HASH(K_PQ || K_CL)
]]></artwork>
<t>This is similar, but not the same (for efficiency)<!-- The cost of just concatenating and using in the SSH key derivation because SSH key derivation hashes the shared key K 6 times, so the larger the K, the more compression function invocations we will need. -->, logic as in TLS 1.3 <xref target="I-D.ietf-tls-hybrid-design"/>. In <xref target="I-D.ietf-tls-hybrid-design"/>, the classical and post-quantum exchanged secrets are concatenated and used in the key schedule whereas in this document they are concatenated and hashed before being used in SSH's key derivation methodology.</t>
<t>The ECDH shared secret was traditionally encoded as an integer as per <xref target="RFC4253" format="default"/>, <xref target="RFC5656" format="default"/>, and <xref target="RFC8731" format="default"/> and used in deriving the key. In this specification, the two shared secrets, K_PQ and K_CL, are fed into the hash function to derive K. Thus, K_PQ and K_CL are encoded as fixed-length byte arrays, not as integers. Byte arrays are defined in Section 5 of <xref target="RFC4251" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Key Derivation</name>
<t>The derivation of encryption keys MUST be done from the shared secret K according to Section 7.2 in <xref target="RFC4253" format="default"/> with a modification on the exchange hash H. </t>
<t>The PQ/T Hybrid key exchange hash H is the result of computing the HASH, where HASH is the hash algorithm specified in the named PQ/T Hybrid key exchange method name, over the concatenation of the following </t>
<artwork align="left" name="" type="" alt=""><![CDATA[
string V_C, client identification string (CR and LF excluded)
string V_S, server identification string (CR and LF excluded)
string I_C, payload of the client's SSH_MSG_KEXINIT
string I_S, payload of the server's SSH_MSG_KEXINIT
string K_S, server's public host key
string C_INIT, client message octet string
string S_REPLY, server message octet string
string K, SSH shared secret
]]></artwork>
<t>K, the shared secret used in H, was traditionally encoded as an integer (mpint) as per <xref target="RFC4253" format="default"/>, <xref target="RFC5656" format="default"/>, and <xref target="RFC8731" format="default"/>. In this specification, K is the hash output of the two concatenated byte arrays (<xref target="shared-secret" format="default"/>) which is not an integer. Thus, K is encoded as a string using the process described in Section 5 of <xref target="RFC4251" format="default"/> and is then fed along with other data in H to the key exchange method's HASH function to generate encryption keys.
</t>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<!--
<section anchor="key_auth" numbered="true" toc="default">
<name>Key Authentication</name>
<t>[EDNOTE: Discuss if hybrid auth keys which combine classical and PQ signatures are necessary. Since authentication cannot be broken retroactively, even if the PQ signature algorithms got broken, we could switch to a classical algorithm to at least keep the classical security. On the other hand, that would take time to deploy while these entities would be vulnerabile to impersonation attacks. Hybrid signatures add some overhead, but could provide the peace of mind of remaining secure with the classical algorithm without scrambling to deploy a change even if the PQ algorithms got broken. ]</t>
<section anchor="sig-pk-format" numbered="true" toc="default">
<name>Public Key Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
string "ssh-TBD3"
string key
]]></artwork>
<t>Here, 'key' is the x-octet public key described in the TBD3 specification.</t>
<t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
[TODO]
<t>string "ssh-sphincsplus"
string key</t>
<t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
</section>
<section anchor="sig-format" numbered="true" toc="default">
<name>Signature Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
string "ssh-TBD3"
string signature
]]></artwork>
<t>Here, 'signature' is the x-octet signature produced in accordance with the TBD3 specification. </t>
<t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
[TODO ]
<t>string "ssh-sphincsplus"
string key</t>
<t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
</section>
<section anchor="sig-alg" numbered="true" toc="default">
<name>Signing and Verification</name>
<t>Signatures are generated according to the procedure in TBD3 specification</t>
<t>Signatures are verified according to the procedure in TBD3 specification</t>
<t>[EDNOTE: Placeholder. Algorithms will be identified after NIST Round 3 concludes.]</t>
</section>
[TODO: Update this section later]
<section anchor="sshfp" numbered="true" toc="default">
<name>SSHFP DNS resource records</name>
<t>Usage and generation of SSHFP DNS resource record is described in [RFC4255]. This section illustrates the generation of SSHFP resource records.</t>
</section>
</section>-->
<section numbered="true" toc="default">
<name>Message Size</name>
<t>An implementation adhering to <xref target="RFC4253" format="default"/> must be able to support packets with an uncompressed payload length of 32768 bytes or less and a total packet size of 35000 bytes or less (including 'packet_length', 'padding_length', 'payload', 'random padding', and 'mac'). These numbers represent what must be 'minimally supported' by implementations. This can present a problem when using post-quantum key exchange schemes because some post-quantum schemes can produce much larger messages than what is normally produced by existing key exchange methods defined for SSH. This document does not define any method names (<xref target="kex-methods" format="default"/>) that cause any PQ/T Hybrid key exchange method related packets to exceed the minimally supported packet length. This document does not define behavior in cases where a PQ/T Hybrid key exchange message cause a packet to exceed the minimally supported packet length.</t>
</section>
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The authors want to thank Gerado Ravago from AWS for implementing the draft and finding issues. We also want to thank Damien Miller and Markus Friedl for their feedback and for bringing some of the SSH key exchange methods in this document in OpenSSH.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<!-- <t>All drafts are required to have an IANA considerations section (see RFC5226 Guidelines for Writing an IANA Considerations Section in RFCs for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.</t> -->
<t>This memo includes requests of IANA to register new method names "mlkem768nistp256-sha256", "mlkem1024nistp384-sha384", and "mlkem768x25519-sha256" to be registered by IANA in the "Key Exchange Method Names" registry for SSH <xref target="IANA-SSH" format="default"/>. </t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations given in <xref target="RFC5656" format="default"/> and <xref target="RFC8731" format="default"/> also apply to the ECDH part of the P/T Hybrid key exchange schemes defined in this document.</t>
<t>The way a derived binary secret string is encoded (i.e., adding or removing zero bytes for encoding) before it is hashed may lead to a variable-length secret which raises the potential for a side-channel attack. In broad terms, when the secret is longer, the hash function may need to process more blocks internally which could determine the length of what is hashed. This could leak the most significant bit of the derived secret and/or allow detection of when the most significant bytes are zero. In some unfortunate circumstances, this has led to timing attacks, e.g. the Lucky Thirteen <xref target="LUCKY13" format="default"/> and Raccoon <xref target="RACCOON" format="default"/> attacks. In <xref target="RFC8731" format="default"/> and <xref target="RFC5656" format="default"/>, the ECDH shared secrets were mpint and fixed-length integer encoded respectively which raised a potential for such side-channel attacks. This problem is addressed in this document by encoding K_PQ and K_CL as fixed-length byte arrays and K as a string. Implementations MUST use these encodings for K_PQ, K_CL, and K.</t>
<t><xref target="NIST-SP-800-56C" format="default"/> and <xref target="NIST-SP-800-135" format="default"/> gives NIST recommendations for key derivation methods in key exchange protocols. Some PQ/T Hybrid combinations may combine the shared secret from a NIST-approved algorithm (e.g., ECDH using the nistp256/secp256r1 curve or ML-KEM) with a shared secret from a non-approved algorithm (e.g., X25519). <xref target="NIST-SP-800-56C" format="default"/> lists simple concatenation as an approved method for generation of a PQ/T Hybrid shared secret in which one of the constituent shared secret is from an approved method. Thus, the combination of the two shared secrets in this document is FIPS-approved assuming the ECDH curve and ML-KEM negotiated parameters are FIPS approved. <xref target="NIST-SP-800-135"/> also approves the key derivation used in SSH. This method is the same used in this document to derive keys from the quantum-resistant shared secret for use in SSH. Thus, the keys derived from the PQ/T Hybrid key exchange in this document are FIPS approved.</t>
<t><xref target="PQ-PROOF" format="default"/> <xref target="PQ-PROOF2" format="default"/> contain proofs of security for PQ/T Hybrid key exchange schemes. <xref target="PQ-PROOF2" format="default"/> discusses how the key combination to derive K and the derivation of SSH symmetric keys in this document can be proven IND-CPA and IND-CCA2 secure with some assumptions. IND-CPA is achieved if we assume the HASH calls perform as a KDF which is a reasonable assumption. IND-CCA2 security is achieved by assuming the HASH is a random oracle which is a stronger assumption especially for hash functions like SHA-2 which permit length extension concerns. To leverage a HASH which is more suitable as a random oracle, we could use SHAKE256 or introduce HMAC-SHA-256 as proposed in options (2b) and (2c) in <xref target="appendix"/>. This document uses SHA2 which is ubiquitous although it makes an IND-CCA2 proof need stronger assumptions because even SSH's traditional key derivation has not been proven to be IND-CCA2. <!-- EDNOTE: Even if the K combiner was IND-CCA2 (i.e. if we used connolly-cfrg-xwing-kem or josefsson-chempat combiner, the rest of the key derivation would not be. --> 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). Implementations also MUST NOT reuse randomness in the generation of KEM ciphertexts.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references>
<name>References</name>
<references>
<name>Normative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4251.xml"?>
<!--<?rfc include="reference.RFC.4252.xml"?> -->
<?rfc include="reference.RFC.4253.xml"?>
<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="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<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>
</reference> -->
</references>
<references>
<name>Informative References</name>
<!-- Here we use entities that we defined at the beginning. -->
<?rfc include="reference.RFC.4250.xml"?>
<?rfc include="reference.RFC.5656.xml"?>
<!--<?rfc include="reference.RFC.8332.xml"?>-->
<!--<?rfc include="reference.RFC.8709.xml"?>-->
<?rfc include="reference.RFC.6234.xml"?>
<?rfc include="reference.RFC.8731.xml"?>
<?rfc include="reference.RFC.7748.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls-hybrid-design.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.hoffman-c2pq.xml"?>
<reference anchor="I-D.ietf-pquip-pqt-hybrid-terminology" target="https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqt-hybrid-terminology-03">
<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>
<date month="May" day="9" year="2024"/>
<abstract>
<t> One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. </t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pquip-pqt-hybrid-terminology-03"/>
</reference>
<reference anchor="IANA-SSH" target="https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml">
<front>
<title>Secure Shell (SSH) Protocol Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date year="2021"/>
</front>
</reference>
<reference anchor="NIST_PQ" target="https://csrc.nist.gov/projects/post-quantum-cryptography">
<front>
<title>Post-Quantum Cryptography</title>
<author>
<organization>NIST</organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="nist-sp800-186" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-186-draft.pdf">
<front>
<title>SP 800-186</title>
<author>
<organization>NIST</organization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="nist-sha2" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
<front>
<title>FIPS PUB 180-4</title>
<author>
<organization>NIST</organization>
</author>
<date year="2015"/>
</front>
</reference>
<!-- <reference anchor="HHK">
<front>
<title>A Modular Analysis of the Fujisaki-Okamoto Transformation</title>
<seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/>
<seriesInfo name="Theory of Cryptography" value="pp. 341-371"/>
<author initials="D." surname="Hofheinz" fullname="Dennis Hofheinz">
<organization/>
</author>
<author initials="K." surname="Hovelmanns" fullname="Kathrin Hovelmanns">
<organization/>
</author>
<author initials="E." surname="Kiltz" fullname="Eike Kiltz">
<organization/>
</author>
<date year="2017"/>
</front>
</reference> -->
<reference anchor="CNSA2" target="https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/">
<front>
<title>Announcing the Commercial National Security Algorithm Suite 2.0</title>
<author>
<organization>National Security Agency (NSA)</organization>
</author>
<date year="2024" month="April"/>
</front>
</reference>
<!-- <reference anchor="FO">
<front>
<title>Secure Integration of Asymmetric and Symmetric Encryption Schemes</title>
<seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/>
<seriesInfo name="Journal of Cryptology" value="Vol. 26, pp. 80-101"/>
<author initials="E." surname="Fujisaki" fullname="Eiichiro Fujisaki">
<organization/>
</author>
<author initials="T." surname="Okamoto" fullname="Tatsuaki Okamoto">
<organization/>
</author>
<date year="2011" month="December"/>
</front>
</reference>-->
<reference anchor="NIST-SP-800-56C" target="https://doi.org/10.6028/NIST.SP.800-56Cr2">
<front>
<title>Recommendation for Key-Derivation Methods in Key-Establishment Schemes</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date year="2020" month="August"/>
</front>
</reference>
<reference anchor="NIST-SP-800-135" target="https://doi.org/10.6028/NIST.SP.800-135r1">
<front>
<title>Recommendation for Existing Application-Specific Key Derivation Functions</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date year="2011" month="December"/>
</front>
</reference>
<reference anchor="RACCOON" target="https://raccoon-attack.com/">
<front>
<title>Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)</title>
<author initials="R." surname="Merget">
<organization/>
</author>
<author initials="M." surname="Brinkmann">
<organization/>
</author>
<author initials="N." surname="Aviram">
<organization/>
</author>
<author initials="J." surname="Somorovsky">
<organization/>
</author>
<author initials="J." surname="Mittmann">
<organization/>
</author>
<author initials="J." surname="Schwenk">
<organization/>
</author>
<date year="2020" month="September"/>
</front>
</reference>
<reference anchor="LUCKY13" target="https://ieeexplore.ieee.org/iel7/6547086/6547088/06547131.pdf">
<front>
<title>Lucky Thirteen: Breaking the TLS and DTLS record protocols</title>
<author initials="N.J." surname="Al Fardan">
<organization/>
</author>
<author initials="K.G." surname="Paterson">
<organization/>
</author>
<date year="2013"/>
</front>
</reference>
<reference anchor="PQ-PROOF" target="https://eprint.iacr.org/2020/1364">
<front>
<title>Security of Hybrid Key Encapsulation</title>
<author initials="M." surname="Campagna" fullname="Matthew Campagna">
<organization></organization>
</author>
<author initials="A." surname="Petcher" fullname="Adam Petcher">
<organization></organization>
</author>
<date year="2020"/>
</front>
</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>
<reference anchor="I-D.connolly-cfrg-xwing-kem" target="https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-02">
<front>
<title>X-Wing: general-purpose hybrid post-quantum KEM</title>
<author initials="D." surname="Connolly" fullname="Deirdre Connolly">
<organization>SandboxAQ</organization>
</author>
<author initials="P." surname="Schwabe" fullname="Peter Schwabe">
<organization>MPI-SP, Radboud University</organization>
</author>
<author initials="B." surname="Westerbaan" fullname="Bas Westerbaan">
<organization>Cloudflare</organization>
</author>
<date month="March" day="26" year="2024"/>
<abstract>
<t> This memo defines X-Wing, a general-purpose post-quantum/traditional hybrid key encapsulation mechanism (PQ/T KEM) built on X25519 and ML- KEM-768. </t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-connolly-cfrg-xwing-kem-02"/>
</reference>
<reference anchor="I-D.josefsson-chempat" target="https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-01">
<front>
<title>Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms</title>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson"> </author>
<date month="April" day="14" year="2024"/>
<abstract>
<t> This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 combined with post quantum methods ML-KEM-768, ML-KEM-1024, Streamlined NTRU Prime sntrup761, and Classic McEliece. </t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-josefsson-chempat-01"/>
</reference>
</references>
</references>
<section anchor="appendix" numbered="true" toc="default">
<name>Other Combiners</name>
<t>Other combiners to derive K and the SSH keys were considered while working on this document. These include</t>
<ol type="(%d)">
<li>K = K_PQ || K_CL. All SSH keys are derived from K as defined in Section 7.2 in <xref target="RFC4253" format="default"/>.</li>
<li><t>All SSH keys are derived from K as defined in Section 7.2 in <xref target="RFC4253" format="default"/>. </t>
<ol type="(%c)">
<li>K = HASH(K_PQ, K_CL). This is the option adopted in this specification.</li>
<li>K = HMAC-HASH(K_PQ, K_CL)</li>
<li>K = HMAC-HASH(0, K_PQ || K_CL)</li>
</ol>
</li>
<li>K = HKDF-HASH_Extract(0, K_PQ || K_CL). SSH keys are now derived from K using HKDF-HASH(K, H || session_id, 6*sizeof(HASH)).</li>
</ol>
<t>Option (3) follows the Extract-and-Expand logic described in <xref target="NIST-SP-800-56C" format="default"/>. It deviates from existing SSH key derivation significantly and might be viewed as too far from the current SSH design. It probably would be a good approach for SSH to move from basic hashing everywhere to use proper KDFs with extract/expand, but that should be a separate effort.</t>
<t>We also considered combiners like the ones proposed in <xref target="I-D.josefsson-chempat" format="default"/> and <xref target="I-D.connolly-cfrg-xwing-kem" format="default"/>. <xref target="I-D.connolly-cfrg-xwing-kem" format="default"/> has a separate IND-CCA2 security proof. Although such combiners may be proven IND-CCA2 secure, to be IND-CCA2, the SSH key derivation would still require the assumptions laid out in <xref target="PQ-PROOF2" format="default"/> and discussed in <xref target="Security" format="default"/>.</t>
</section>
</back>
</rfc>