idnits 2.17.1 draft-igoe-secsh-suiteb-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 293 has weird spacing: '...me-list kex...' == Line 294 has weird spacing: '...me-list ser...' == Line 295 has weird spacing: '...me-list enc...' == Line 296 has weird spacing: '...me-list enc...' == Line 297 has weird spacing: '...me-list mac...' == (12 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2011) is 4815 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SUITEBCERT' is mentioned on line 111, but not defined -- Looks like a reference, but probably isn't: '16' on line 292 == Unused Reference: 'RFC2119' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'RFC5759' is defined on line 543, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-igoe-secsh-x509v3-03 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K.M. Igoe 3 Internet Draft National Security Agency 4 Intended Status: Informational February 18, 2011 5 Expires: August 22, 2011 7 Suite B Cryptographic Suites for Secure Shell 8 draft-igoe-secsh-suiteb-06 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 22, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the BSD License. 48 Abstract 50 This document describes the architecture of a Suite B compliant 51 implementation of the Secure Shell Transport Layer Protocol and the 52 Secure Shell Authentication Protocol. Suite B secure shell makes use 53 of elliptic curve Diffie-Hellmann (ECDH) key agreement, the elliptic 54 curve digital signature algorithm (ECDSA), the Advanced Encryption 55 Standard running in Galois Counter Mode (AES-GCM), two members of the 56 SHA-2 family of hashes (SHA-256 and SHA-384), and X.509 57 certificates. 59 Table of Contents 61 1. Conventions Used in this Document................................3 62 2. Suite B and Secure Shell.........................................3 63 2.1. Minimum Levels of Security (minLOS).........................4 64 2.2. Digital Signatures and Certificates.........................4 65 2.3. Non-Signature Primitives....................................5 66 3. Security Mechanism Negotiation and Initialization................6 67 3.1. Algorithm negotiation: SSH_MSG_KEXINIT......................7 68 4. Key Exchange and Server Authentication...........................8 69 4.1. SSH_MSG_KEXECDH_INIT........................................8 70 4.2. SSH_MSG_KEXECDH_REPLY.......................................9 71 4.3. Key and Initialization Vector Derivation....................9 72 5. User Authentication..............................................9 73 5.1. First SSH_MSG_USERAUTH_REQUEST Message.....................10 74 5.2. Second SSH_MSG_USERAUTH_REQUEST Message....................10 75 6. Confidentiality and Data Integrity of SSH Binary Packets........11 76 6.1. Galois/Counter Mode........................................11 77 6.2. Data Integrity.............................................11 78 7. Rekeying........................................................11 79 8. Security Considerations.........................................12 80 9. IANA Requirements...............................................12 81 10. References.....................................................12 82 10.1. Normative References......................................12 83 10.2. Informative References....................................12 85 1. Conventions Used in this Document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119. 91 2. Suite B and Secure Shell 93 Several RFCs have been drafted that document how each of the Suite B 94 components are to be integrated into Secure Shell: 96 kex algorithms 97 ecdh-sha2-nistp256 [SSH-ECC] 98 ecdh-sha2-nistp384 [SSH-ECC] 99 server host key algorithms 100 x509v3-ecdsa-sha2-nistp256 [SSH-X509] 101 x509v3-ecdsa-sha2-nistp384 [SSH-X509] 102 encryption algorithms (both client_to_server and server_to_client) 103 AEAD_AES_128_GCM [SSH-GCM] 104 AEAD_AES_256_GCM [SSH-GCM] 105 mac algorithms (both client_to_server and server_to_client) 106 AEAD_AES_128_GCM [SSH-GCM] 107 AEAD_AES_256_GCM [SSH-GCM] 109 In Suite B, public key certificates used to verify signatures MUST be 110 compliant with the Suite B Certificate Profile specified in RFC 5759 111 [SUITEBCERT]. 113 The purpose of this document is to draw upon all of these documents 114 to provide guidance for Suite B compliant implementations of secure 115 shell (hereafter referred to as SecSh-B). Note that while SecSh-B 116 MUST follow the guidance in this document, that does not in and of 117 itself imply a given implementation of secure shell is suitable for 118 use in protecting classified data. An implementation of SecSh-B must 119 be validated by the appropriate authority before such usage is 120 permitted. 122 The two elliptic curves used in Suite B appear in the literature 123 under two different names. For sake of clarity we list both names 124 below. 126 Curve NIST name SECG name OID [SEC2] 127 --------------------------------------------------------------- 128 P-256 nistp256 secp256r1 1.2.840.10045.3.1.7 129 P-384 nistp384 secp384r1 1.3.132.0.34 131 A description of these curves can be found in [NIST] or [SEC2]. 133 For sake of brevity, ECDSA-256 will be used to denote ECDSA on P-256 134 using SHA-256, and ECDSA-384 will be used to denote ECDSA on P-384 135 using SHA-384. 137 2.1. Minimum Levels of Security (minLOS) 139 Suite B provides for two levels of cryptographic security, namely a 140 128-bit minimum level of security (minLOS_128) and a 192-bit minimum 141 level of security (minLOS_192). As we shall see below, the 142 ECDSA-256/384 signature algorithms and corresponding X.509v3 143 certificates are treated somewhat differently than the non-signature 144 primitives (kex algorithms, encryption algorithms and mac algorithms 145 in secure shell parlance). 147 2.2. Digital Signatures and Certificates 149 SecSh-B uses ECDSA-256/384 for server authentication, user 150 authentication, and in X.509 certificates. [SSH-X509] defines two 151 methods, x509v3-ecdsa-sha2-nistp256 and x509v3-ecdsa-sha2-nistp384, 152 that are to be used for server and user authentication. The 153 following conditions must be met: 155 1) The server MUST share its public key with the host using an 156 X.509v3 certificate as described on [SSH-X509]. This public 157 key MUST be used to authenticate the server to the host using 158 ECDSA-256 or ECDSA-384 as appropriate (see section 3). 160 2) User authentication MUST begin with public key authentication 161 using ECDSA-256/384 with X.509v3 certificates (see section 4). 162 Additional user authentication methods MAY be used, but only 163 after the certificate based ECDSA authentication has been 164 successfully completed. 166 3) The X.509v3 certificates MUST use only the two Suite B digital 167 signatures, ECDSA-256 and ECDSA-384. 169 4) ECDSA-256 MUST NOT be used to sign an ECDSA-384 public key. 171 5) ECDSA-384 MAY be used to sign an ECDSA-256 public key. 173 6) At minLOS_192, all SecSh-B implementations MUST be able to 174 verify ECDSA-384 signatures. 176 7) At minLOS_128, all SecSh-B implementations MUST be able to 177 verify ECDSA-256 signatures and SHOULD be able to verify 178 ECDSA-384 signatures unless it is absolutely certain that the 179 implementation will never need to verify certificates 180 originating from an authority which uses an ECDSA-384 signing 181 key. 183 8) At minLOS_128, each SecSh-B server and each SecSh-B user MUST 184 have either an ECDSA-256 signing key with corresponding X.509V3 185 certificate, an ECDSA-384 signing key with corresponding 186 X.509v3 certificate, or both. 188 9) At minLOS_192-bit each SecSh-B server and each SecSh-B user 189 MUST have an ECDSA-384 signing key with corresponding X.509v3 190 certificate. 192 The selection of signature algorithm to be used for server 193 authentication is governed by the server_host_key_algorithms 194 name-list in the SSH_MSG_KEXINIT packet (see section 2.1). The key 195 exchange and server authentication are performed by the 196 SSH_MSG_KEXECDH_REPLY packets (see section 3). User authentication 197 is done via the SSH_USER_AUTH_REQUEST messages (see section 4). 199 2.3. Non-Signature Primitives 201 This section covers the constraints the choice of minimum security 202 level imposes upon the selection of key agreement protocol (kex 203 algorithm), encryption algorithm, and data integrity algorithm (mac 204 algorithm). We divide the non-signature algorithms into two families 205 as shown in table 1. 207 +--------------+----------------------+----------------------+ 208 | Algorithm | Family 1 | Family 2 | 209 +==============+======================+======================+ 210 | kex | ecdh-sha2-nistp256 | ecdh-sha2-nistp384 | 211 +--------------+----------------------+----------------------+ 212 | encryption | AEAD_AES_128_GCM | AEAD_AES_256_GCM | 213 +--------------+----------------------+----------------------+ 214 | mac | AEAD_AES_128_GCM | AEAD_AES_256_GCM | 215 +--------------+-----------------------+---------------------+ 217 Table 1: Families of Non-signature Algorithms 218 is Suite B Complaint Secure Shell 220 At the 128-bit minimum level of security: 222 - the non-signature algorithms MUST either come exclusively from 223 Family 1 or exclusively from Family 2. 225 - the selection of Family 1 versus Family 2 is independent of the 226 choice of server host key algorithm. 228 At the 192-bit minimum level of security: 230 - the non-signature algorithms MUST all come from Family 2. 232 Most of the constraints described in this section can be achieved by 233 severely restricting the kex_algorithms, encryption_algorithms, and 234 mac_algorithms name lists offered in the SSH_MSG_KEXINIT packet. See 235 section 2.1 for details. 237 3. Security Mechanism Negotiation and Initialization 239 As described in [SSH-Tran], the exchange of SSH_MSG_KEXINIT between 240 the server and the client establishes which key agreement algorithm, 241 mac algorithms, host key algorithm (server authentication algorithm), 242 and encryption algorithms are to be used. This section describes how 243 the Suite B components are to be used in the secure shell algorithm 244 negotiation, key agreement, server authentication and user 245 authentication. 247 Negotiation and initialization of a Suite B secure shell connection 248 involves the following secure shell messages (where C->S denotes a 249 message from the client to the server and S->C denotes a server to 250 client message): 252 SSH_MSG_KEXINIT C->S Contains lists of algorithms 253 acceptable to the client. 255 SSH_MSG_KEXINIT S->C Contains lists of algorithms 256 acceptable to the server. 258 SSH_MSG_KEXECDH_INIT C->S Contains the client's ephemeral 259 elliptic curve Diffie-Hellman key. 261 SSH_MSG_KEXECDH_REPLY S->C Contains a certificate with the 262 server's ECDSA public signature 263 key, the server's ephemeral ECDH 264 contribution, and an ECDSA digital 265 signature of the newly formed 266 exchange hash value. 268 SSH_MSG_USERAUTH_REQUEST C->S Contains the user's name, the 269 name of the service the user is 270 requesting, the name of the 271 authentication method the client 272 wishes to use, and method specific 273 fields. 275 When not in the midst of processing a key exchange, either party may 276 initiate a key re-exchange by sending an SSH_MSG_KEXINIT packet. All 277 packets exchanged during the re-exchange are encrypted and 278 authenticated using the current keys until the conclusion of the 279 re-exchange, at which point a SSH_MSG_NEWKEYS initiates a change to 280 the newly established keys. Otherwise the re-exchange protocol is 281 identical to the initial key exchange protocol. See section 9 of 282 [SSH-Tran]. 284 3.1. Algorithm negotiation: SSH_MSG_KEXINIT 286 The choice of all but the user authentication methods are determined 287 by the exchange of SSH_MSG_KEXINIT between the client and the 288 server. As described in [SSH-Tran], the SSH_MSG_KEXINIT packet has 289 the following structure: 291 byte SSH_MSG_KEXINIT 292 byte[16] cookie (random bytes) 293 name-list kex_algorithms 294 name-list server_host_key_algorithms 295 name-list encryption_algorithms_client_to_server 296 name-list encryption_algorithms_server_to_client 297 name-list mac_algorithms_client_to_server 298 name-list mac_algorithms_server_to_client 299 name-list compression_algorithms_client_to_server 300 name-list compression_algorithms_server_to_client 301 name-list languages_client_to_server 302 name-list languages_server_to_client 303 boolean first_kex_packet_follows 304 uint32 0 (reserved for future extension) 306 The SSH_MSG_KEXINIT namelists can be used to constrain the choice of 307 non-signature and host key algorithms in accordance with the guidance 308 given in section 1. Table 2 lists three allowable namelists for the 309 non-signature algorithms. One of these options MUST be used. 311 Family 1 only (min_LOS 128): 312 kex_algorithm name_list := { ecdh_sha2_nistp256 } 313 encryption_algorithm name_list := { AEAD_AES_128_GCM } 314 mac_algorithm name_list := { AEAD_AES_128_GCM } 316 Family 2 only (min_LOS 128 or 192): 317 kex_algorithm name_list := { ecdh_sha2_nistp384 } 318 encryption_algorithm name_list := { AEAD_AES_256_GCM } 319 mac_algorithm name_list := { AEAD_AES_256_GCM } 321 Family 1 or Family 2 (min_LOS 128): 322 kex_algorithm name_list := { ecdh_sha2_nistp256, 323 ecdh_sha2_nistp384 } 324 encryption_algorithm name_list := { AEAD_AES_128_GCM, 325 AEAD_AES_256_GCM } 326 mac_algorithm name_list := { AEAD_AES_128_GCM, 328 AEAD_AES_256_GCM } 330 Table 2: Allowed Non-signature Algorithm Namelists 332 Table 3 lists three allowable namelists for the server host key 333 algorithms. One of these options MUST be used. 335 ECDSA-256 only (min_LOS 128): 336 server_host_key_algorithms name_list := 337 { x509v3-ecdsa-sha2-nistp256 } 339 ECDSA-384 only (min_LOS 128 or 192): 340 server_host_key_algorithms name_list := 341 { x509v3-ecdsa-sha2-nistp384 } 343 ECDSA-256 or ECDSA-384 (min_LOS 128): 344 server_host_key_algorithms name_list := 345 { x509v3-ecdsa-sha2-nistp256, 346 x509v3-ecdsa-sha2-nistp384 } 348 Table 3: Allowed Server Host Key Algorithm Namelists 350 4. Key Exchange and Server Authentication 352 SecSh-B uses ECDH to establish a shared secret value between the 353 client and the server. An X.509v3 certificate containing the 354 server's public signing ECDSA key and an ECDSA signature on the 355 exchange hash value derived from the newly established shared secret 356 value are used to authenticate the server to the client. 358 4.1. SSH_MSG_KEXECDH_INIT 360 The key exchange to be used in Secure Shell is determined by the 361 namelists exchanged in the SSH_MSG_KEXINIT packets. In Suite B, one 362 of the following key agreement methods MUST be used to generate a 363 shared secret value (SSV): 365 ecdh-sha2-nistp256 ephemeral-ephemeral elliptic curve 366 Diffie-Hellman on nistp256 with SHA-256 367 ecdh-sha2-nistp384 ephemeral-ephemeral elliptic curve 368 Diffie-Hellman on nistp384 with SHA-384 370 and the format of the SSH_MSG_KEXECDH_INIT message is: 372 byte SSH_MSG_KEXDH_INIT 373 string Q_C // client's ephemeral contribution to the ECDH 374 // exchange, encoded as an octet string 376 where the encoding of the elliptic curve point Q_C as an octet string 377 is as specified in section 2.3.3 of [SEC1]. 379 4.2. SSH_MSG_KEXECDH_REPLY 381 The SSH_MSG_KEXECDH_REPLY contains the server's contribution to the 382 ECDH exchange, the server's public signature key, and a signature of 383 the exchange hash value formed from the newly established shared 384 secret value. As stated is secion 2.1, in SecSh-B, the server host 385 key algorithm MUST be either x509v3-ecdsa-sha2-nistp256 or 386 x509v3-ecdsa-sha2-nistp384. 388 The format of the SSH_MSG_KEXECDH_REPLY is: 390 byte SSH_MSG_KEXECDH_REPLY 391 string K_S // A string encoding an X.509v3 certificate 392 // containing the server's ECDSA public host key 393 string Q_S // server's ephemeral contribution to the ECDH 394 // exchange, encoded as an octet string 395 string Sig_S // an octet string containing the server's 396 // signature of the newly established exchange 397 // hash value 399 Details on the structure and encoding of the X.509v3certificate can 400 be found in section 2 of [SSH-X509]. The encoding of the elliptic 401 curve point Q_C as an octet string is as specified in section 2.3.3 402 of [SEC1] and the encoding of the ECDSA signature Sig_S as an octet 403 string is as described in section 3.1.2 of [SSH-ECC]. 405 4.3. Key and Initialization Vector Derivation 407 As specified in [SSH-Tran], the encryption keys and initialization 408 vectors needed by secure shell are derived directly from the SSV 409 using the hash function specified by the key agreement algorithm 410 (SHA-256 for ecdh-sha2-nistp256 and SHA-384 for ecdh-sha2-nistp384). 411 The client to server channel and the server to client channel will 412 have independent keys and initialization vectors. These keys will 413 remain constant until a re-exchange results in the formation of a new 414 SSV. 416 5. User Authentication 418 The Secure Shell Transport Layer Protocol authenticates the server to 419 the host but does not authenticate the user (or the user's host) to 420 the server. For this reason, condition (2) of section 1.2 requires 421 that all users of SecSh-B MUST be authenticated using ECDSA-256/384 422 signatures and X.509v3 certificates. [SSH-X509] provides two 423 methods, x509v3-ecdsa-sha2-nistp256 and x509v3-ecdsa-sha2-nistp384, 424 that MUST be used to achieve this goal. At minLOS 128, either one of 425 these methods may be used, but at minLOS 192 426 x509v3-ecdsa-sha2-nistp384 MUST be used. 428 5.1. First SSH_MSG_USERAUTH_REQUEST Message 430 The user's public key is sent to the server using an 431 SSH_MSG_USERAUTH_REQUEST message. When an x509v3-ecdsa-sha2-* user 432 authentication method is being used, the structure of the 433 SSH_MSG_USERAUTH_REQUEST message should be: 435 byte SSH_MSG_USERAUTH_REQUEST 436 string user_name // in ISO-10646 UTF-8 encoding 437 string service_name // service name in US-ASCII 438 string "publickey" 439 boolean FALSE 440 string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256 441 // or x509v3-ecdsa-sha2-nistp384 442 string public_key_blob // X509.v3 certificate 444 Details on the structure and encoding of the X.509v3 certificate can 445 be found in section 2 of [SSH-X509]. 447 5.2. Second SSH_MSG_USERAUTH_REQUEST Message 449 Once the server has responded to the request message with an 450 SSH_MSG_USERAUTH_PK_OK message, the client uses a second 451 SSH_MSG_USERAUTH_REQUEST message to perform the actual 452 authentication: 454 byte SSH_MSG_USERAUTH_REQUEST 455 string user_name // in ISO-10646 UTF-8 encoding 456 string service_name // service name in US-ASCII 457 string "publickey" 458 boolean TRUE 459 string public_key_algorithm_name // x509v3-ecdsa-sha2-nistp256 460 // or x509v3-ecdsa-sha2-nistp384 462 string Sig_U 464 The signature field Sig_U is an ECDSA signature of the concatenation 465 of several values, including the session identifier, user name, 466 service name, public key algorithm name, and the user's public 467 signing key. The user's public signing key MUST be the signing key 468 conveyed in the X.509v3 certificate sent in the first 469 SSH_MSG_USERAUTH_REQUEST message. The encoding of the ECDSA 470 signature Sig_U as an octet string is as described in section 3.1.2 471 of [SSH-ECC]. 473 The server MUST respond with either SSH_MSG_USERAUTH_SUCCESS (if no 474 more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the 475 request failed, or more authentications are needed). 477 6. Confidentiality and Data Integrity of SSH Binary Packets 479 Secure shell transfers data between the client and the server using 480 its own binary packet structure. The SSH binary packet structure is 481 independent of any packet structure on the underlying data channel. 482 The contents of each binary packet and portions of the header are 483 encrypted and each packet is authenticated with its own message 484 authentication code. AES GCM will both encrypt the packet and form a 485 16-octet authentication tag to ensure data integrity. 487 6.1. Galois/Counter Mode 489 [SSH-GCM] describes how AES Galois Counter Mode is to be used in 490 secure shell. Suite B SSH implementations MUST support 491 AEAD_AES_GCM_128 and SHOULD support AEAD_AES_GCM_256 to provide both 492 confidentiality and ensure data integrity. No other confidentiality 493 or data integrity algorithms are permitted. 495 These algorithms rely on two counters: 497 Invocation Counter: A 64-bit integer, incremented after each call 498 to AES-GCM to process an SSH binary packet. The initial value of 499 the invocation counter is determined by the SSH initialization 500 vector. 502 Block Counter: A 32-bit integer, set to one at the start of each 503 new SSH binary packet and incremented as each 16-octet block of 504 data is processed. 506 Ensuring that these counters are properly implemented is crucial to 507 the security of the system. The reader is referred to [SSH-GCM] for 508 details on the format, initialization and usage of these counters and 509 their relationship to the initialization vector and the SSV. 511 6.2. Data Integrity 513 The reader is reminded that, as specified in [SSH-GCM], Suite B 514 requires that all 16-octets of the authentication tag MUST be used as 515 the SSH data integrity value of the SSH binary packet. 517 7. Rekeying 519 Secure Shell allows either the server or client to request that the 520 secure shell connection be rekeyed. Suite B places no constraints on 521 how frequently this is to be done, but it does require that the 522 cipher suite being employed MUST NOT be changed when a rekey occurs. 524 8. Security Considerations 526 When using ecdh_sha2_nistp256, each exponent used in the key exchange 527 must have 256 bits of entropy. Similarly, when using 528 ecdh_sha2_nistp384, each exponent used in the key exchange must have 529 384 bits of entropy. The security considerations of [SSH-Arch] 530 apply. 532 9. IANA Requirements 534 No action required. 536 10. References 538 10.1. Normative References 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, March 1997. 543 [RFC5759] Solinas, J. and L.Zieglar, Suite B Certificates and 544 Certificate Revocation List (CRL) Profile, RFC 5759, 545 January 2010. 547 [SSH-Arch] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 548 Protocol Architecture", RFC 4251, January 2006. 550 [SSH-Tran] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 551 Transport Layer Protocol", RFC 4253, January 2006. 553 [SSH-ECC] Green, J. and D.Stebila, Ed., "Elliptic-Curve Algorithm 554 Integration in the Secure Shell Transport Layer", 555 RFC 5656, December 2009. 557 [SSH-GCM] Igoe, K. and J. Solinas, "AES Galois Counter Mode for 558 the Secure Shell Transport Layer Protocol", 559 RFC 5647, August 2009. 561 [SSH-X509] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 562 Shell Authentication", 563 draft-igoe-secsh-x509v3-03 (work in progress), 564 July 2010. 566 10.2. Informative References 568 [NIST] National Institute of Standards and Technology, 569 "Recommendation for Key Management - Part 1", NIST 570 Special Publication 800-57. 572 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 573 Curve Cryptography", SEC 1 v2.0, May 2009, 574 . 576 [SEC2] Standards for Efficient Cryptography Group, "Recommended 577 Elliptic Curve Domain Parameters", SEC 2 v1.0, September 578 2000. 579 . 581 Author's Addresses 582 Kevin M. Igoe 583 NSA/CSS Commercial Solutions Center 584 National Security Agency 585 EMail: kmigoe@nsa.gov 587 Acknowledgement 589 Funding for the RFC Editor function is provided by the IETF 590 Administrative Support Activity (IASA).