idnits 2.17.1 draft-gajcowski-cnsa-ssh-profile-00.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 (August 14, 2020) is 1350 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: February 15, 2021 August 14, 2020 7 Commercial National Security Algorithm (CNSA) Suite Cryptography for 8 Secure Shell (SSH) 9 draft-gajcowski-cnsa-ssh-profile-00 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 IPSec. 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 February 15, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. The Commercial National Security Algorithm Suite . . . . . . 3 64 4. CNSA and Secure Shell . . . . . . . . . . . . . . . . . . . . 3 65 4.1. Hash Functions . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. Digital Signatures . . . . . . . . . . . . . . . . . . . 4 67 5. Security Mechanism Negotiation and Initialization . . . . . . 5 68 6. Key Exchange and Server Authentication . . . . . . . . . . . 5 69 6.1. ECDH Key Exchange . . . . . . . . . . . . . . . . . . . . 6 70 6.2. DH Key Exchange . . . . . . . . . . . . . . . . . . . . . 6 71 7. User Authentication . . . . . . . . . . . . . . . . . . . . . 6 72 8. Confidentiality and Data Integrity of SSH Binary Packets . . 7 73 8.1. Galois/Counter Mode . . . . . . . . . . . . . . . . . . . 7 74 8.2. Data Integrity . . . . . . . . . . . . . . . . . . . . . 8 75 9. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 12.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 This document specifies conventions for using the United States 86 National Security Agency's CNSA Suite algorithms [CNSA] with Secure 87 Shell Transport Layer Protocol [RFC4253] and the Secure Shell 88 Authentication Protocol [RFC4252]. It applies to the capabilities, 89 configuration, and operation of all components of US National 90 Security Systems that employ IPSec. US National Security Systems are 91 described in NIST Special Publication 800-59 [SP80059]. It is also 92 appropriate for all other US Government systems that process high- 93 value information. It is made publicly available for use by 94 developers and operators of these and any other system deployments. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 3. The Commercial National Security Algorithm Suite 106 The National Security Agency (NSA) profiles commercial cryptographic 107 algorithms and protocols as part of its mission to support secure, 108 interoperable communications for US Government National Security 109 Systems. To this end, it publishes guidance both to assist with the 110 US Government transition to new algorithms, and to provide vendors - 111 and the Internet community in general - with information concerning 112 their proper use and configuration. 114 Recently, cryptographic transition plans have become overshadowed by 115 the prospect of the development of a cryptographically-relevant 116 quantum computer. NSA has established the Commercial National 117 Security Algorithm (CNSA) Suite to provide vendors and IT users near- 118 term flexibility in meeting their IA interoperability requirements. 119 The purpose behind this flexibility is to avoid vendors and customers 120 making two major transitions in a relatively short timeframe, as we 121 anticipate a need to shift to quantum-resistant cryptography in the 122 near future. 124 NSA is authoring a set of RFCs, including this one, to provide 125 updated guidance concerning the use of certain commonly available 126 commercial algorithms in IETF protocols. These RFCs can be used in 127 conjunction with other RFCs and cryptographic guidance (e.g., NIST 128 Special Publications) to properly protect Internet traffic and data- 129 at-rest for US Government National Security Systems. 131 4. CNSA and Secure Shell 133 Several RFCs have documented how each of the CNSA components are to 134 be integrated into Secure Shell (SSH): 136 kex algorithms 138 ecdh-sha2-nistp384 [RFC5656] 140 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 The purpose of this document is to draw upon all of these documents 159 to provide guidance for CNSA compliant implementations of Secure 160 Shell. Note that while compliant Secure Shell implementations MUST 161 follow the guidance in this document, that requirement does not in 162 and of itself imply that a given implementation of Secure Shell is 163 suitable for use national security systems. An implementation must 164 be validated by the appropriate authority before such usage is 165 permitted. 167 4.1. Hash Functions 169 The approved CNSA hash function for all purposes is SHA-384, as 170 defined in [FIPS180]. However, SHA-512 (sha2-512) is recommended for 171 the Diffie-Hellman kex algorithms and for RSA public key algorithms 172 due to lack of specification of SHA-384 in [RFC8268] and [RFC8332]. 173 Any hash algorithm other than SHA-384 or SHA-512 MUST NOT be used. 175 4.2. Digital Signatures 177 Servers MUST be authenticated using digital signatures. The public 178 key algorithm implemented MUST be ecdsa-sha2-nistp384 or rsa- 179 sha2-512. The RSA public key modulus MUST be 3072 or 4096 bits in 180 size; clients MUST NOT accept RSA signatures from a public key 181 modulus of any other size. 183 Implementations MUST NOT employ a trust on first use (TOFU) security 184 model where a client accepts the first public host key presented to 185 it from a not yet verified server. This allows for the possibility 186 of a man in the middle attack, where an attacker can present itself 187 to the client as the server. 189 The public host keys presented MUST be verified as belonging to the 190 presenting party before the signature is accepted. This 191 certification SHOULD be done using certificates, provided the use of 192 certificates has been approved for that environment. Otherwise, the 193 user MUST validate the presented public key (and/or certificate) by 194 some other means, possibly through an offline mechanism. 195 Certificates MUST be X.509v3 certificates and their use MUST comply 196 with [RFC8603]. 198 5. Security Mechanism Negotiation and Initialization 200 As described in [RFC4253], the exchange of SSH_MSG_KEXINIT between 201 the server and the client establishes which key agreement algorithm, 202 MAC algorithm, host key algorithm (server authentication algorithm), 203 and encryption algorithm are to be used. This section specifies the 204 use of CNSA components in the Secure Shell algorithm negotiation, key 205 agreement, server authentication, and user authentication. 207 The choice of all but the user authentication methods are determined 208 by the exchange of SSH_MSG_KEXINIT between the client and the server. 210 The SSH_MSG_KEXINIT name lists can be used to constrain the choice of 211 cryptographic algorithms in accordance with the guidance given in 212 Section 2. One of the following kex_algorithms MUST be used. 214 ecdh-sha2-nistp384 [RFC5656] 216 diffie-hellman-group15-sha512 [RFC8268] 218 diffie-hellman-group16-sha512 [RFC8268] 220 One of the name lists from the following list MUST be used for the 221 encryption algorithms and mac algorithm. This option MUST be used. 223 encryption_algorithm name_list := { AEAD_AES_256_GCM } 225 mac_algorithm name_list := { AEAD_AES_256_GCM } 227 One of the following public key algorithms MUST be used. 229 rsa-sha2-512 [RFC8332] 231 ecdsa-sha2-nistp384 [RFC5656] 233 6. Key Exchange and Server Authentication 235 Either ECDH or DH MUST be used to establish a shared secret value 236 between the client and the server. A signature on the exchange hash 237 value derived from the newly established shared secret value is used 238 to authenticate the server to the client. 240 The key exchange to be used is determined by the name lists exchanged 241 in the SSH_MSG_KEXINT packets as described in [RFC4253]. 243 A compliant system MUST NOT allow the reuse of ephemeral/exchange 244 values in a key exchange algorithm due to security concerns related 245 to this practice. Section 5.6.3.3 of [SP80056A] states that an 246 ephemeral private key must be used in exactly one key establishment 247 transaction and must be destroyed (zeroized) as soon as possible. 248 Section 5.8 of [SP80056A] states that such shared secrets must be 249 destroyed (zeroized) immediately after its use. CNSA compliant 250 systems MUST follow these mandates. 252 6.1. ECDH Key Exchange 254 The key exchange begins with the SSH_MSG_KEXECDH_INIT message which 255 contains the client's ephemeral public key used to generate a shared 256 secret value. 258 The server responds to a SSH_MSG_KEXECDH_INIT message with a 259 SSH_MSG_KEXECDH_REPLY message which contains the server's ephemeral 260 public key, the server's public host key, and a signature of the 261 exchange hash value formed from the newly established shared secret 262 value. The public key algorithm MUST be ecdsa-sha2-nistp384 or rsa- 263 sha2-512. 265 6.2. DH Key Exchange 267 The key exchange begins with the SSH_MSG_KEXDH_INIT message which 268 contains the client's diffie-hellman exchange value used to generate 269 a shared secret value. 271 The server responds to a SSH_MSG_KEXDH_INIT message with a 272 SSH_MSG_KEXDH_REPLY message. The SSH_MSG_KEXDH_REPLY contains the 273 server's diffie-hellman exchange value, the server's public host key, 274 and a signature of the exchange hash value formed from the newly 275 established shared secret value. The public key algorithm MUST be 276 ecdsa-sha2-nistp384 or rsa-sha2-512. 278 7. User Authentication 280 The Secure Shell Transport Layer Protocol authenticates the server to 281 the host but does not authenticate the user (or the user's host) to 282 the server. All users MUST be authenticated, MUST follow [RFC4252], 283 and SHOULD be authenticated using a public key method. Users MAY 284 authenticate using passwords. Other methods of authentication MUST 285 not be used, including "none". 287 When authenticating with public key, the following public key 288 algorithms MUST be used: 290 ecdsa-sha2-nistp384 [RFC5656] 292 rsa-sha2-512 [RFC8332] 294 The server MUST verify that the presented key is a valid 295 authenticator for the user. This SHOULD be done using certificates. 296 Certificates MUST be X.509v3 certificates and their use MUST comply 297 with [RFC8603]. 299 If authenticating with RSA, the client's public key modulus MUST be 300 3072 or 4096 bits in size, and the server MUST NOT accept signatures 301 from an RSA public key modulus of any other size. 303 If authenticating by passwords, it is essential that passwords have 304 sufficient entropy to protect against dictionary attacks. During 305 authentication, the password MUST be protected in the established 306 encrypted communications channel. Additional guidelines are provided 307 in [SP80063]. 309 8. Confidentiality and Data Integrity of SSH Binary Packets 311 Secure Shell transfers data between the client and the server using 312 its own binary packet structure. The SSH binary packet structure is 313 independent of any packet structure on the underlying data channel. 314 The contents of each binary packet and portions of the header are 315 encrypted, and each packet is authenticated with its own message 316 authentication code. AES GCM will both encrypt the packet and form a 317 16-octet authentication tag to ensure data integrity. 319 8.1. Galois/Counter Mode 321 Use of AES GCM in Secure Shell is described in [RFC5647]. CNSA 322 complaint SSH implementations MUST support AEAD_AES_GCM_256 to 323 provide confidentiality and ensure data integrity. No other 324 confidentiality or data integrity algorithms are permitted. 326 The AES GCM invocation counter is incremented mod 2^64. That is, 327 after processing a binary packet: 329 invocation_counter = invocation_counter + 1 mod 2^64 331 The invocation counter MUST NOT repeat a counter value. 333 8.2. Data Integrity 335 As specified in [RFC5647], all 16 octets of the authentication tag 336 MUST be used as the SSH data integrity value of the SSH binary 337 packet. 339 9. Rekeying 341 Secure Shell allows either the server or client to request that the 342 Secure Shell connection be rekeyed. The cipher suite being employed 343 MUST NOT be changed when a rekey occurs. 345 10. Security Considerations 347 The security considerations of [RFC4251], [RFC4252], [RFC4253], 348 [RFC5647], and [RFC5656] apply. 350 11. IANA Considerations 352 No IANA actions are requested. 354 12. References 356 12.1. Normative References 358 [CNSA] Committee for National Security Systems, "Use of Public 359 Standards for Secure Information Sharing", CNSSP 15, 360 October 2016, 361 . 363 [FIPS180] National Institute of Standards and Technology, "Secure 364 Hash Standard (SHS)", Federal Information Processing 365 Standard 180-4, August 2015, 366 . 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 375 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 376 January 2006, . 378 [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 379 Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, 380 January 2006, . 382 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 383 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 384 January 2006, . 386 [RFC5647] Igoe, K. and J. Solinas, "AES Galois Counter Mode for the 387 Secure Shell Transport Layer Protocol", RFC 5647, 388 DOI 10.17487/RFC5647, August 2009, 389 . 391 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 392 Integration in the Secure Shell Transport Layer", 393 RFC 5656, DOI 10.17487/RFC5656, December 2009, 394 . 396 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 397 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 398 May 2017, . 400 [RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie- 401 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 402 (SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017, 403 . 405 [RFC8332] Bider, D., "Use of RSA Keys with SHA-256 and SHA-512 in 406 the Secure Shell (SSH) Protocol", RFC 8332, 407 DOI 10.17487/RFC8332, March 2018, 408 . 410 [RFC8603] Jenkins, M. and L. Zieglar, "Commercial National Security 411 Algorithm (CNSA) Suite Certificate and Certificate 412 Revocation List (CRL) Profile", RFC 8603, 413 DOI 10.17487/RFC8603, May 2019, 414 . 416 12.2. Informative References 418 [SP80056A] 419 National Institute of Standards and Technology, 420 "Recommendation for Pair-Wise Key Establishment Schemes 421 Using Discrete Logarithm Cryptography", NIST Special 422 Publication 800-56A, Revision 3, April 2018, 423 . 426 [SP80059] National Institute of Standards and Technology, "Guideline 427 for Identifying an Information System as a National 428 Security System", Special Publication 800-59 , August 429 2003, . 432 [SP80063] National Institute of Standards and Technology, "Digital 433 Identity Guidelines", NIST Special Publication 800-63, 434 Revision 3, June 2017, 435 . 438 Authors' Addresses 440 Nicholas Gajcowski 441 National Security Agency 443 Email: nhgajco@nsa.gov 445 Michael Jenkins 446 National Security Agency 448 Email: mjjenki@cyber.nsa.gov