idnits 2.17.1 draft-gajcowski-cnsa-ssh-profile-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Secure Shell Transport Layer Protocol authenticates the server to the host but does not authenticate the user (or the user's host) to the server. All users MUST be authenticated, MUST follow [RFC4252], and SHOULD be authenticated using a public key method. Users MAY authenticate using passwords. Other methods of authentication MUST not be used, including "none". -- The document date (14 January 2022) is 833 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Gajcowski 3 Internet-Draft M. Jenkins 4 Intended status: Informational NSA 5 Expires: 18 July 2022 14 January 2022 7 Commercial National Security Algorithm (CNSA) Suite Cryptography for 8 Secure Shell (SSH) 9 draft-gajcowski-cnsa-ssh-profile-07 11 Abstract 13 The United States Government has published the NSA Commercial 14 National Security Algorithm (CNSA) Suite, which defines cryptographic 15 algorithm policy for national security applications. This document 16 specifies the conventions for using the United States National 17 Security Agency's CNSA Suite algorithms with the Secure Shell 18 Transport Layer Protocol and the Secure Shell Authentication 19 Protocol. It applies to the capabilities, configuration, and 20 operation of all components of US National Security Systems that 21 employ SSH. US National Security Systems are described in NIST 22 Special Publication 800-59. It is also appropriate for all other US 23 Government systems that process high-value information. It is made 24 publicly available for use by developers and operators of these and 25 any other system deployments. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 18 July 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. The Commercial National Security Algorithm Suite . . . . . . 3 63 4. CNSA and Secure Shell . . . . . . . . . . . . . . . . . . . . 3 64 5. Security Mechanism Negotiation and Initialization . . . . . . 5 65 6. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . 6 67 6.2. DH Key Exchange . . . . . . . . . . . . . . . . . . . . . 6 68 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Server Authentication . . . . . . . . . . . . . . . . . . 7 70 7.2. User Authentication . . . . . . . . . . . . . . . . . . . 7 71 8. Confidentiality and Data Integrity of SSH Binary Packets . . 8 72 8.1. Galois/Counter Mode . . . . . . . . . . . . . . . . . . . 8 73 8.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . 9 74 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 12.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This document specifies conventions for using the United States 85 National Security Agency's CNSA Suite algorithms [CNSA] with Secure 86 Shell Transport Layer Protocol [RFC4253] and the Secure Shell 87 Authentication Protocol [RFC4252]. It applies to the capabilities, 88 configuration, and operation of all components of US National 89 Security Systems that employ SSH. US National Security Systems are 90 described in NIST Special Publication 800-59 [SP80059]. It is also 91 appropriate for all other US Government systems that process high- 92 value information. It is made publicly available for use by 93 developers and operators of these and any other system deployments. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. The Commercial National Security Algorithm Suite 105 The National Security Agency (NSA) profiles commercial cryptographic 106 algorithms and protocols as part of its mission to support secure, 107 interoperable communications for US Government National Security 108 Systems. To this end, it publishes guidance both to assist with the 109 US Government transition to new algorithms, and to provide vendors - 110 and the Internet community in general - with information concerning 111 their proper use and configuration. 113 Recently, cryptographic transition plans have become overshadowed by 114 the prospect of the development of a cryptographically-relevant 115 quantum computer. NSA has established the Commercial National 116 Security Algorithm (CNSA) Suite to provide vendors and IT users near- 117 term flexibility in meeting their information assurance 118 interoperability requirements using current cryptography. The 119 purpose behind this flexibility is to avoid vendors and customers 120 making two major transitions (i.e. to elliptic curve cryptography, 121 and then to post-quantum cryptography) in a relatively short 122 timeframe, as we anticipate a need to shift to quantum-resistant 123 cryptography in the near future. 125 NSA is authoring a set of RFCs, including this one, to provide 126 updated guidance concerning the use of certain commonly available 127 commercial algorithms in IETF protocols. These RFCs can be used in 128 conjunction with other RFCs and cryptographic guidance (e.g., NIST 129 Special Publications) to properly protect Internet traffic and data- 130 at-rest for US Government National Security Systems. 132 4. CNSA and Secure Shell 134 Several RFCs have documented how each of the CNSA components are to 135 be integrated into Secure Shell (SSH): 137 kex algorithms 139 ecdh-sha2-nistp384 [RFC5656] 141 diffie-hellman-group15-sha512 [RFC8268] 142 diffie-hellman-group16-sha512 [RFC8268] 144 public key algorithms 146 ecdsa-sha2-nistp384 [RFC5656] 148 rsa-sha2-512 [RFC8332] 150 encryption algorithms (both client_to_server and server_to_client) 152 AEAD_AES_256_GCM [RFC5647] 154 MAC algorithms (both client_to_server and server_to_client) 156 AEAD_AES_256_GCM [RFC5647] 158 While the approved CNSA hash function for all purposes is SHA-384, as 159 defined in [FIPS180], commercial products are more likely to 160 incorporate the SHA-512 (sha2-512) based kex algorithms and public 161 key algorithms defined in [RFC8268] and [RFC8332]. Therefore, the 162 SHA-384 based kex and public key algorithms SHOULD be used; SHA-512 163 based algorithms MAY be used. Any hash algorithm other than SHA-384 164 or SHA-512 MUST NOT be used. 166 Use of AES GCM shall meet the requirements set forth in SP 800-38D 167 with the additional requirements that all 16 octets of the 168 authentication tag MUST be used as the SSH data integrity value and 169 that AES is used with a 256-bit key. Use of AES-GCM in SSH should be 170 done as described in RFC 5647, with the exception that AES-GCM need 171 not be listed as the MAC algorithm when its use is implicit (such as 172 done in aes256-gcm@openssh.com). In addition, RFC 5647 failed to 173 specify that the AES GCM invocation counter is incremented mod 2^64. 174 CNSA implementations MUST ensure the counter never repeats and is 175 properly incremented after processing a binary packet: 176 invocation_counter = invocation_counter + 1 mod 2^64. 178 The purpose of this document is to draw upon all of these documents 179 to provide guidance for CNSA compliant implementations of Secure 180 Shell. Algorithms specified in this document may be different to 181 mandatory-to-implement algorithms; in that case the latter will be 182 present but not used. Note that while compliant Secure Shell 183 implementations MUST follow the guidance in this document, that 184 requirement does not in and of itself imply that a given 185 implementation of Secure Shell is suitable for use national security 186 systems. An implementation must be validated by the appropriate 187 authority before such usage is permitted. 189 5. Security Mechanism Negotiation and Initialization 191 As described in Section 7.1 of [RFC4253], the exchange of 192 SSH_MSG_KEXINIT between the server and the client establishes which 193 key agreement algorithm, MAC algorithm, host key algorithm (server 194 authentication algorithm), and encryption algorithm are to be used. 195 This section specifies the use of CNSA components in the Secure Shell 196 algorithm negotiation, key agreement, server authentication, and user 197 authentication. 199 The choice of all but the user authentication methods are determined 200 by the exchange of SSH_MSG_KEXINIT between the client and the server. 202 The kex_algorithms name-list is used to negotiate a single key 203 agreement algorithm between the server and client in accordance with 204 the guidance given in Section 2. While ID.ietf-curdle-ssh-kex-sha2 205 establishes general guidance on the capabilities of SSH 206 implementations and requires support for "diffie-hellman- 207 group14-sha256", it MUST NOT be used. The result MUST be one of the 208 following kex_algorithms or the connection MUST be terminated. 210 ecdh-sha2-nistp384 [RFC5656] 212 diffie-hellman-group15-sha512 [RFC8268] 214 diffie-hellman-group16-sha512 [RFC8268] 216 One of the following sets MUST be used for the encryption_algorithms 217 and mac_algorithms name-lists. Either set MAY be used for each 218 direction (i.e. client_to_server, server_to_client) but the result 219 must be the same (i.e. use of AEAD_AES_256_GCM). This option MUST be 220 used. 222 encryption_algorithm_name_list := { AEAD_AES_256_GCM } 224 mac_algorithm_name_list := { AEAD_AES_256_GCM } 226 or 228 encryption_algorithm_name_list := { aes256-gcm@openssh.com } 230 mac_algorithm_name_list := {} 232 One of the following public key algorithms MUST be used. 234 rsa-sha2-512 [RFC8332] 236 ecdsa-sha2-nistp384 [RFC5656] 238 The procedures for applying the negotiated algorithms are given in 239 the following sections. 241 6. Key Exchange 243 The key exchange to be used is determined by the name-lists exchanged 244 in the SSH_MSG_KEXINIT packets as described above. Either elliptic 245 curve Diffie-Hellman (ECDH) or Diffie-Hellman (DH) MUST be used to 246 establish a shared secret value between the client and the server. 248 A compliant system MUST NOT allow the reuse of ephemeral/exchange 249 values in a key exchange algorithm due to security concerns related 250 to this practice. Section 5.6.3.3 of [SP80056A] states that an 251 ephemeral private key must be used in exactly one key establishment 252 transaction and must be destroyed (zeroized) as soon as possible. 253 Section 5.8 of [SP80056A] states that such shared secrets must be 254 destroyed (zeroized) immediately after its use. CNSA compliant 255 systems MUST follow these mandates. 257 6.1. ECDH Key Exchange 259 The key exchange begins with the SSH_MSG_KEXECDH_INIT message which 260 contains the client's ephemeral public key used to generate a shared 261 secret value. 263 The server responds to a SSH_MSG_KEXECDH_INIT message with a 264 SSH_MSG_KEXECDH_REPLY message which contains the server's ephemeral 265 public key, the server's public host key, and a signature of the 266 exchange hash value formed from the newly established shared secret 267 value. The kex algorithm MUST be ecdh-sha2-nistp384, and the public 268 key algorithm MUST be either ecdsa-sha2-nistp384 or rsa-sha2-512. 270 6.2. DH Key Exchange 272 The key exchange begins with the SSH_MSG_KEXDH_INIT message which 273 contains the client's DH exchange value used to generate a shared 274 secret value. 276 The server responds to a SSH_MSG_KEXDH_INIT message with a 277 SSH_MSG_KEXDH_REPLY message. The SSH_MSG_KEXDH_REPLY contains the 278 server's DH exchange value, the server's public host key, and a 279 signature of the exchange hash value formed from the newly 280 established shared secret value. The kex algorithm MUST be one of 281 diffie-hellman-group15-sha512 or diffie-hellman-group16-sha512, and 282 the public key algorithm MUST be either ecdsa-sha2-nistp384 or rsa- 283 sha2-512. 285 7. Authentication 287 7.1. Server Authentication 289 A signature on the exchange hash value derived from the newly 290 established shared secret value is used to authenticate the server to 291 the client. Servers MUST be authenticated using digital signatures. 292 The public key algorithm implemented MUST be ecdsa-sha2-nistp384 or 293 rsa-sha2-512. The RSA public key modulus MUST be 3072 or 4096 bits 294 in size; clients MUST NOT accept RSA signatures from a public key 295 modulus of any other size. 297 The following public key algorithms MUST be used: 299 ecdsa-sha2-nistp384 [RFC5656] 301 rsa-sha2-512 [RFC8332] 303 The client MUST verify that the presented key is a valid 304 authenticator for the server before verifying the server signature. 305 If possible, validation SHOULD be done using certificates. 306 Otherwise, the client MUST validate the presented public key through 307 some other secure, possibly off-line mechanism. Implementations MUST 308 NOT employ a trust on first use (TOFU) security model where a client 309 accepts the first public host key presented to it from a not yet 310 verified server. Use of a TOFU model would allow an intermediate 311 adversary to present itself to the client as the server. 313 Where X.509v3 certificates are used, their use MUST comply with 314 [RFC8603] 316 7.2. User Authentication 318 The Secure Shell Transport Layer Protocol authenticates the server to 319 the host but does not authenticate the user (or the user's host) to 320 the server. All users MUST be authenticated, MUST follow [RFC4252], 321 and SHOULD be authenticated using a public key method. Users MAY 322 authenticate using passwords. Other methods of authentication MUST 323 not be used, including "none". 325 When authenticating with public key, the following public key 326 algorithms MUST be used: 328 ecdsa-sha2-nistp384 [RFC5656] 330 rsa-sha2-512 [RFC8332] 332 The server MUST verify that the public key is a valid authenticator 333 for the user. If possible, validation SHOULD be done using 334 certificates. Otherwise, the server must validate the public key 335 through another secure, possibly off-line mechanism. 337 Where X.509v3 certificates are used, their use MUST comply with 338 [RFC8603]. 340 If authenticating with RSA, the client's public key modulus MUST be 341 3072 or 4096 bits in size, and the server MUST NOT accept signatures 342 from an RSA public key modulus of any other size. 344 To facilitate client authentication with RSA using SHA-512, clients 345 and servers SHOULD implement the server-sig-algs extension as 346 specified in [RFC8308]. In that case, in the SSH_MSG_KEXINIT, the 347 client SHALL include the indicator ext-info-c to the kex_algorithms 348 field, and the server SHOULD respond with a SSH_MSG_EXT_INFO message 349 containing the server-sig-algs extension. The server MUST list only 350 ecdsa-sha2-nistp384 and-or rsa-sha2-512 as the acceptable public key 351 algorithms in this response. 353 If authenticating by passwords, it is essential that passwords have 354 sufficient entropy to protect against dictionary attacks. During 355 authentication, the password MUST be protected in the established 356 encrypted communications channel. Additional guidelines are provided 357 in [SP80063]. 359 8. Confidentiality and Data Integrity of SSH Binary Packets 361 Secure Shell transfers data between the client and the server using 362 its own binary packet structure. The SSH binary packet structure is 363 independent of any packet structure on the underlying data channel. 364 The contents of each binary packet and portions of the header are 365 encrypted, and each packet is authenticated with its own message 366 authentication code. Use of the Advanced Encryption Standard in 367 Galois Counter Mode (AES GCM) will both encrypt the packet and form a 368 16-octet authentication tag to ensure data integrity. 370 8.1. Galois/Counter Mode 372 Use of AES GCM in Secure Shell is described in [RFC5647]. CNSA 373 complaint SSH implementations MUST support AES GCM (negotiated as 374 AEAD_AES_GCM_256 or aes256-gcm@openssh, see Section 5) to provide 375 confidentiality and ensure data integrity. No other confidentiality 376 or data integrity algorithms are permitted. 378 The AES GCM invocation counter is incremented mod 2^64. That is, 379 after processing a binary packet: 381 invocation_counter = invocation_counter + 1 mod 2^64 383 The invocation counter MUST NOT repeat a counter value. 385 8.2. Data Integrity 387 As specified in [RFC5647], all 16 octets of the authentication tag 388 MUST be used as the SSH data integrity value of the SSH binary 389 packet. 391 9. Rekeying 393 Section 9 of [RFC4253] allows either the server or the client to 394 initiate a 'key re-exchange by sending an SSH_MSG_KEXINIT packet' and 395 to 'change some or all of the (cipher) algorithms during re- 396 exchange.' This specification requires the same cipher suite to be 397 employed when re-keying, that is, the cipher algorithms MUST NOT be 398 changed when a rekey occurs. 400 10. Security Considerations 402 The security considerations of [RFC4251], [RFC4252], [RFC4253], 403 [RFC5647], and [RFC5656] apply. 405 11. IANA Considerations 407 No IANA actions are requested. 409 12. References 411 12.1. Normative References 413 [CNSA] Committee for National Security Systems, "Use of Public 414 Standards for Secure Information Sharing", CNSSP 15, 415 October 2016, 416 . 418 [FIPS180] National Institute of Standards and Technology, "Secure 419 Hash Standard (SHS)", Federal Information Processing 420 Standard 180-4, August 2015, 421 . 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 429 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 430 January 2006, . 432 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 433 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 434 January 2006, . 436 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 437 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 438 January 2006, . 440 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 441 Secure Shell Transport Layer Protocol", RFC 5647, 442 DOI 10.17487/RFC5647, August 2009, 443 . 445 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 446 Integration in the Secure Shell Transport Layer", 447 RFC 5656, DOI 10.17487/RFC5656, December 2009, 448 . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 452 May 2017, . 454 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 455 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 456 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 457 . 459 [RFC8308] Bider, D., "Extension Negotiation in the Secure Shell 460 (SSH) Protocol", RFC 8308, DOI 10.17487/RFC8308, March 461 2018, . 463 [RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in 464 the Secure Shell (SSH) Protocol", RFC 8332, 465 DOI 10.17487/RFC8332, March 2018, 466 . 468 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 469 Algorithm (CNSA) Suite Certificate and Certificate 470 Revocation List (CRL) Profile", RFC 8603, 471 DOI 10.17487/RFC8603, May 2019, 472 . 474 12.2. Informative References 476 [SP80056A] National Institute of Standards and Technology, 477 "Recommendation for Pair-Wise Key Establishment Schemes 478 Using Discrete Logarithm Cryptography", NIST Special 479 Publication 800-56A, Revision 3, April 2018, 480 . 482 [SP80059] National Institute of Standards and Technology, "Guideline 483 for Identifying an Information System as a National 484 Security System", Special Publication 800-59 , August 485 2003, . 487 [SP80063] National Institute of Standards and Technology, "Digital 488 Identity Guidelines", NIST Special Publication 800-63, 489 Revision 3, June 2017, 490 . 492 Authors' Addresses 494 Nicholas Gajcowski 495 National Security Agency 497 Email: nhgajco@uwe.nsa.gov 499 Michael Jenkins 500 National Security Agency 502 Email: mjjenki@cyber.nsa.gov