-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-kampanakis-ssh-pq-ke.txt
784 lines (523 loc) · 30.7 KB
/
draft-kampanakis-ssh-pq-ke.txt
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
CURDLE P. Kampanakis
Internet-Draft AWS
Intended status: Experimental D. Stebila
Expires: 11 November 2024 University of Waterloo
T. Hansen
AWS
10 May 2024
PQ/T Hybrid Key Exchange in SSH
draft-kampanakis-curdle-ssh-pq-ke-02
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 November 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kampanakis, et al. Expires 11 November 2024 [Page 1]
Internet-Draft PQ SSH May 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. PQ/T Hybrid Key Exchange . . . . . . . . . . . . . . . . . . 4
2.1. PQ/T Hybrid Key Exchange Method Abstraction . . . . . . . 4
2.2. PQ/T Hybrid Key Exchange Message Numbers . . . . . . . . 5
2.3. PQ/T Hybrid Key Exchange Method Names . . . . . . . . . . 5
2.3.1. mlkem768nistp256-sha256 . . . . . . . . . . . . . . . 5
2.3.2. mlkem1024nistp384-sha384 . . . . . . . . . . . . . . 6
2.3.3. mlkem768x25519-sha256 . . . . . . . . . . . . . . . . 6
2.4. Shared Secret K . . . . . . . . . . . . . . . . . . . . . 7
2.5. Key Derivation . . . . . . . . . . . . . . . . . . . . . 7
3. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Other Combiners . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Secure Shell (SSH) [RFC4251] performs key establishment using key
exchange methods based on (Elliptic Curve) Diffie-Hellman style
schemes defined in [RFC5656] and [RFC8731]. The cryptographic
security of these key exchanges relies on certain instances of the
discrete logarithm problem being computationally infeasible to solve
for adversaries.
Kampanakis, et al. Expires 11 November 2024 [Page 2]
Internet-Draft PQ SSH May 2024
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 [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.
This document addresses the problem by extending the SSH Transport
Layer Protocol [RFC4253] key exchange with Post-Quantum Traditional
(PQ/T) Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology] key exchange
methods. 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. [PQ-PROOF] [PQ-PROOF2] contain proofs of
security for such PQ/T Hybrid key exchange schemes.
In the context of the [NIST_PQ], key exchange algorithms are
formulated as key encapsulation mechanisms (KEMs), which consist of
three algorithms:
* 'KeyGen() -> (pk, sk)': A probabilistic key generation algorithm,
which generates a public key 'pk' and a secret key 'sk'.
* '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'.
* '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.
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 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.
Kampanakis, et al. Expires 11 November 2024 [Page 3]
Internet-Draft PQ SSH May 2024
The post-quantum KEM used in the document is ML-KEM. ML-KEM was
standardized in 2024 [FIPS203]. [ EDNOTE: Reference normatively the
ratified version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever
ratified. Otherwise keep a normative reference of [FIPS203]. And
remove the reference to [FIPS203-ipd]. ]
1.1. Requirements Language
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 [RFC2119].
2. PQ/T Hybrid Key Exchange
2.1. PQ/T Hybrid Key Exchange Method Abstraction
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 [RFC4251].
In a PQ/T Hybrid key exchange, instead of SSH_MSG_KEXDH_INIT
[RFC4253] or SSH_MSG_KEX_ECDH_INIT [RFC5656], the client sends
byte SSH_MSG_KEX_HYBRID_INIT
string C_INIT
where C_INIT is the concatenation of C_PK2 and C_PK1. 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.
Instead of SSH_MSG_KEXDH_REPLY [RFC4253] or SSH_MSG_KEX_ECDH_REPLY
[RFC5656], the server sends
byte SSH_MSG_KEX_HYBRID_REPLY
string K_S, server's public host key
string S_REPLY
string the signature on the exchange hash
where S_REPLY is the concatenation of S_CT2 and 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.
Kampanakis, et al. Expires 11 November 2024 [Page 4]
Internet-Draft PQ SSH May 2024
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. K_CL and K_PQ are used together to generate
the shared secret K according to Section 2.4.
2.2. PQ/T Hybrid Key Exchange Message Numbers
The message numbers 30-49 are key-exchange-specific and in a private
namespace defined in [RFC4250] that may be redefined by any key
exchange method [RFC4253] without requiring an IANA registration
process.
The following private namespace message numbers are defined in this
document:
#define SSH_MSG_KEX_HYBRID_INIT 30
#define SSH_MSG_KEX_HYBRID_REPLY 31
2.3. PQ/T Hybrid Key Exchange Method Names
The PQ/T Hybrid key exchange method names defined in this document
(to be used in SSH_MSG_KEXINIT [RFC4253]) are
mlkem768nistp256-sha256
mlkem1024nistp384-sha384
mlkem768x25519-sha256
These instantiate the abstract PQ/T Hybrid key exchanges defined in
Section 2.1.
2.3.1. mlkem768nistp256-sha256
mlkem768nistp256-sha256 defines that the traditional client and
server public keys C_PK1, S_PK1 belong to the NIST P-256 curve
[nist-sp800-186]. The private and public keys are generated as
described therein. The public keys are defined as octet strings for
NIST P-256 as per [RFC5656]; 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 [RFC5656] (key agreement method ecdh-
sha2-nistp256).
Kampanakis, et al. Expires 11 November 2024 [Page 5]
Internet-Draft PQ SSH May 2024
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 [FIPS203]. [ EDNOTE: Reference normatively the ratified
version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified.
Otherwise keep a normative reference of [FIPS203]. And remove the
reference to [FIPS203-ipd]. ]
The HASH function used in the key exchange [RFC4253] is SHA-256
[nist-sha2] [RFC6234].
2.3.2. mlkem1024nistp384-sha384
mlkem1024nistp384-sha384 defines that the classical client and server
public keys C_PK1, S_PK1 belong to the NIST P-384 curve
[nist-sp800-186]. The private and public keys are generated as
described therein. The public keys are defined as octet strings for
NIST P-384 as per [RFC5656]; 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 [RFC5656] (key agreement method ecdh-
sha2-nistp384).
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 [FIPS203]. [ EDNOTE: Reference normatively the ratified
version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified.
Otherwise keep a normative reference of [FIPS203]. And remove the
reference to [FIPS203-ipd]. ].
The HASH function used in the key exchange [RFC4253] is SHA-384
[nist-sha2] [RFC6234].
This method is compliant with CNSA 2.0 requirements [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.
2.3.3. mlkem768x25519-sha256
mlkem768x25519-sha256 defines that the traditional client and server
public keys C_PK1, S_PK1 belong to the Curve25519 curve [RFC7748].
Private and public keys are generated as described therein. The
public keys are defined as strings of 32 bytes as per [RFC8731]. The
K_CL shared secret is generated from the exchanged C_PK1 and S_PK1
public keys as defined in [RFC8731] (key agreement method
Kampanakis, et al. Expires 11 November 2024 [Page 6]
Internet-Draft PQ SSH May 2024
curve25519-sha256).
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 [FIPS203]. [ EDNOTE: Reference normatively the ratified
version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified.
Otherwise keep a normative reference of [FIPS203]. And remove the
reference to [FIPS203-ipd]. ].
The HASH function used in the key exchange [RFC4253] is SHA-256
[nist-sha2] [RFC6234].
2.4. Shared Secret K
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
K = HASH(K_PQ || K_CL)
This is similar, but not the same (for efficiency), logic as in TLS
1.3 [I-D.ietf-tls-hybrid-design]. In [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.
The ECDH shared secret was traditionally encoded as an integer as per
[RFC4253], [RFC5656], and [RFC8731] 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 [RFC4251].
2.5. Key Derivation
The derivation of encryption keys MUST be done from the shared secret
K according to Section 7.2 in [RFC4253] with a modification on the
exchange hash H.
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
Kampanakis, et al. Expires 11 November 2024 [Page 7]
Internet-Draft PQ SSH May 2024
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
K, the shared secret used in H, was traditionally encoded as an
integer (mpint) as per [RFC4253], [RFC5656], and [RFC8731]. In this
specification, K is the hash output of the two concatenated byte
arrays (Section 2.4) which is not an integer. Thus, K is encoded as
a string using the process described in Section 5 of [RFC4251] and is
then fed along with other data in H to the key exchange method's HASH
function to generate encryption keys.
3. Message Size
An implementation adhering to [RFC4253] 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 (Section 2.3) 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.
4. Acknowledgements
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.
5. IANA Considerations
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 [IANA-SSH].
Kampanakis, et al. Expires 11 November 2024 [Page 8]
Internet-Draft PQ SSH May 2024
6. Security Considerations
The security considerations given in [RFC5656] and [RFC8731] also
apply to the ECDH part of the P/T Hybrid key exchange schemes defined
in this document.
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 [LUCKY13] and
Raccoon [RACCOON] attacks. In [RFC8731] and [RFC5656], 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.
[NIST-SP-800-56C] and [NIST-SP-800-135] 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). [NIST-SP-800-56C] 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. [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.
[PQ-PROOF] [PQ-PROOF2] contain proofs of security for PQ/T Hybrid key
exchange schemes. [PQ-PROOF2] 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
Kampanakis, et al. Expires 11 November 2024 [Page 9]
Internet-Draft PQ SSH May 2024
proposed in options (2b) and (2c) in Appendix A. 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. 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.
7. References
7.1. Normative References
[FIPS203] "*** BROKEN REFERENCE ***".
[FIPS203-ipd]
National Institute of Standards and Technology (NIST),
"Module-Lattice-based Key-Encapsulation Mechanism
Standard", NIST Federal Information Processing Standards,
24 August 2023, <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.203.ipd.pdf>.
[I-D.draft-cfrg-schwabe-kyber-04]
Schwabe, P. and B. Westerbaan, "Kyber Post-Quantum KEM",
Work in Progress, Internet-Draft, draft-cfrg-schwabe-
kyber-04, 2 January 2024,
<https://datatracker.ietf.org/doc/html/draft-cfrg-schwabe-
kyber-04>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
7.2. Informative References
Kampanakis, et al. Expires 11 November 2024 [Page 10]
Internet-Draft PQ SSH May 2024
[CNSA2] National Security Agency (NSA), "Announcing the Commercial
National Security Algorithm Suite 2.0", April 2024,
<https://www.nsa.gov/Press-Room/News-
Highlights/Article/Article/3148990/nsa-releases-future-
quantum-resistant-qr-algorithm-requirements-for-national-
se/>.
[I-D.connolly-cfrg-xwing-kem]
Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing:
general-purpose hybrid post-quantum KEM", Work in
Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-
02, 26 March 2024, <https://datatracker.ietf.org/doc/html/
draft-connolly-cfrg-xwing-kem-02>.
[I-D.hoffman-c2pq]
Hoffman, P. E., "The Transition from Classical to Post-
Quantum Cryptography", Work in Progress, Internet-Draft,
draft-hoffman-c2pq-07, 26 May 2020,
<https://datatracker.ietf.org/doc/html/draft-hoffman-c2pq-
07>.
[I-D.ietf-pquip-pqt-hybrid-terminology]
D, F. and M. P, "Terminology for Post-Quantum Traditional
Hybrid Schemes", Work in Progress, Internet-Draft, draft-
ietf-pquip-pqt-hybrid-terminology-03, 9 May 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
pqt-hybrid-terminology-03>.
[I-D.ietf-tls-hybrid-design]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-10, 5 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-10>.
[I-D.josefsson-chempat]
Josefsson, S., "Chempat: Generic Instantiated PQ/T Hybrid
Key Encapsulation Mechanisms", Work in Progress, Internet-
Draft, draft-josefsson-chempat-01, 14 April 2024,
<https://datatracker.ietf.org/doc/html/draft-josefsson-
chempat-01>.
[IANA-SSH] IANA, "Secure Shell (SSH) Protocol Parameters", 2021,
<https://www.iana.org/assignments/ssh-parameters/ssh-
parameters.xhtml>.
Kampanakis, et al. Expires 11 November 2024 [Page 11]
Internet-Draft PQ SSH May 2024
[LUCKY13] Al Fardan, N.J. and K.G. Paterson, "Lucky Thirteen:
Breaking the TLS and DTLS record protocols", 2013,
<https://ieeexplore.ieee.org/
iel7/6547086/6547088/06547131.pdf>.
[nist-sha2]
NIST, "FIPS PUB 180-4", 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[NIST-SP-800-135]
National Institute of Standards and Technology (NIST),
"Recommendation for Existing Application-Specific Key
Derivation Functions", December 2011,
<https://doi.org/10.6028/NIST.SP.800-135r1>.
[NIST-SP-800-56C]
National Institute of Standards and Technology (NIST),
"Recommendation for Key-Derivation Methods in Key-
Establishment Schemes", August 2020,
<https://doi.org/10.6028/NIST.SP.800-56Cr2>.
[nist-sp800-186]
NIST, "SP 800-186", 2019,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-186-draft.pdf>.
[NIST_PQ] NIST, "Post-Quantum Cryptography", 2020,
<https://csrc.nist.gov/projects/post-quantum-
cryptography>.
[PQ-PROOF] Campagna, M. and A. Petcher, "Security of Hybrid Key
Encapsulation", 2020, <https://eprint.iacr.org/2020/1364>.
[PQ-PROOF2]
Petcher, A. and M. Campagna, "Security of Hybrid Key
Establishment using Concatenation", 2023,
<https://eprint.iacr.org/2023/972>.
[RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J.,
Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and
Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)",
September 2020, <https://raccoon-attack.com/>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<https://www.rfc-editor.org/info/rfc4250>.
Kampanakis, et al. Expires 11 November 2024 [Page 12]
Internet-Draft PQ SSH May 2024
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<https://www.rfc-editor.org/info/rfc5656>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method Using Curve25519 and
Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
<https://www.rfc-editor.org/info/rfc8731>.
Appendix A. Other Combiners
Other combiners to derive K and the SSH keys were considered while
working on this document. These include
(1) K = K_PQ || K_CL. All SSH keys are derived from K as defined in
Section 7.2 in [RFC4253].
(2) All SSH keys are derived from K as defined in Section 7.2 in
[RFC4253].
(a) K = HASH(K_PQ, K_CL). This is the option adopted in this
specification.
(b) K = HMAC-HASH(K_PQ, K_CL)
(c) K = HMAC-HASH(0, K_PQ || K_CL)
(3) 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)).
Option (3) follows the Extract-and-Expand logic described in
[NIST-SP-800-56C]. 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.
Kampanakis, et al. Expires 11 November 2024 [Page 13]
Internet-Draft PQ SSH May 2024
We also considered combiners like the ones proposed in
[I-D.josefsson-chempat] and [I-D.connolly-cfrg-xwing-kem].
[I-D.connolly-cfrg-xwing-kem] 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 [PQ-PROOF2] and discussed in Section 6.
Authors' Addresses
Panos Kampanakis
AWS
Email: [email protected]
Douglas Stebila
University of Waterloo
Email: [email protected]
Torben Hansen
AWS
Email: [email protected]
Kampanakis, et al. Expires 11 November 2024 [Page 14]