idnits 2.17.1 draft-ietf-curdle-ssh-kex-sha2-08.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 the creation date from RFC4250, updated by this document, for RFC5378 checks: 2002-06-20) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 15, 2017) is 2565 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-curdle-ssh-curves-04 == Outdated reference: A later version (-09) exists of draft-ietf-curdle-ssh-modp-dh-sha2-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Baushke 3 Internet-Draft Juniper Networks, Inc. 4 Updates: 4250 (if approved) April 15, 2017 5 Intended status: Standards Track 6 Expires: October 17, 2017 8 Key Exchange (KEX) Method Updates and Recommendations for Secure Shell 9 (SSH) 10 draft-ietf-curdle-ssh-kex-sha2-08 12 Abstract 14 This document is intended to update the recommended set of key 15 exchange methods for use in the Secure Shell (SSH) protocol to meet 16 evolving needs for stronger security. This document updates RFC 17 4250. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 17, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3 68 3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 69 3.2. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 70 3.3. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 4 71 3.4. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4 72 3.5. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 4 73 3.6. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 74 3.7. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5 75 3.8. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 5 76 3.9. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 5 77 3.10. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 5 78 3.11. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 6 79 3.12. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 6 80 3.13. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 6 81 3.14. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 6 82 3.15. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 6 83 4. Summary Guidance for Key Exchange Method Names . . . . . . . 6 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 89 8.2. Informative References . . . . . . . . . . . . . . . . . 10 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Overview and Rationale 94 Secure Shell (SSH) is a common protocol for secure communication on 95 the Internet. In [RFC4253], SSH originally defined two Key Exchange 96 Method Names that MUST be implemented. Over time, what was once 97 considered secure, is no longer considered secure. The purpose of 98 this RFC is to recommend that some published key exchanges be 99 deprecated. This document updates [RFC4250]. 101 This document adds recommendations for adoption of Key Exchange 102 Methods which MUST, SHOULD+, SHOULD, SHOULD-, MAY, SHOULD NOT, and 103 MUST NOT be implemented. New key exchange methods will use the SHA-2 104 family of hashes and are drawn from these ssh-curves from 105 [I-D.ietf-curdle-ssh-curves] and new-modp from the 106 [I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex [NEWGSSAPI]. 108 [TO BE REMOVED: Please send comments on this draft to 109 curdle@ietf.org.] 111 2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 When used in the tables in this document, these terms indicate that 118 the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or MAY be 119 implemented as part of a Secure Shell implementation. Additional 120 terms used in this document are: 122 SHOULD+ This term means the same as SHOULD. However, it is likely 123 that an algorithm marked as SHOULD+ will be promoted at 124 some future time to be a MUST. 125 SHOULD- This term means the same as SHOULD. However, an algorithm 126 marked as SHOULD- may be deprecated to a MAY in a future 127 version of this document. 129 3. Key Exchange Methods 131 This memo adopts the style and conventions of [RFC4253] in specifying 132 how the use of data key exchange is indicated in SSH. 134 This RFC also collects Key Exchange Method Names in various existing 135 RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], 136 [I-D.ietf-curdle-ssh-modp-dh-sha2], [NEWGSSAPI], and 137 [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability for 138 implementation of MUST, SHOULD+, SHOULD, SHOULD-, SHOULD NOT, and 139 MUST NOT. Any method not explicitly listed, MAY be implemented. 141 This document is intended to provide guidance as to what Key Exchange 142 Algorithms are to be considered for new or updated SSH 143 implementations. This document will be superseded when one or more 144 of the listed algorithms are considered too weak to continue to use 145 securely, or when newer methods have been analyzed and found to be 146 secure with wide enough adoption to upgrade their recommendation from 147 MAY to SHOULD or MUST. 149 3.1. curve25519-sha256 151 The Curve25519 provides strong security and is efficient on a wide 152 range of architectures with properties that allow better 153 implementation properties compared to traditional elliptic curves. 154 The use of SHA2-256 for integrity is a reasonable one for this 155 method. This Key Exchange Method has multiple implementations and 156 SHOULD+ be implemented in any SSH interested in using elliptic curve 157 based key exchanges. 159 3.2. diffie-hellman-group-exchange-sha1 161 This set of ephemerally generated key exchange groups uses SHA-1 as 162 defined in [RFC4419]. However, SHA-1 has security concerns provided 163 in [RFC6194]. It is recommended that these key exchange groups NOT 164 be used. This key exchange MUST NOT be used. 166 3.3. diffie-hellman-group-exchange-sha256 168 This set of ephemerally generated key exchange groups uses SHA2-256 169 as defined in [RFC4419]. It is recommended implementations avoid any 170 MODP group with less than 2048 bits. This key exchange MAY be used. 172 3.4. diffie-hellman-group1-sha1 174 This method uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and 175 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 176 [RFC6194] and with MODP groups with less than 2048 bits 177 [NIST-SP-800-131Ar1], this method is considered insecure. This 178 method is being moved from MUST to MUST NOT. 180 3.5. diffie-hellman-group14-sha1 182 This method uses [RFC3526] group14 (a 2048-bit MODP group) which has 183 no concerns. This generated key exchange group uses SHA-1 which has 184 security concerns [RFC6194]. However, this group is still strong 185 enough and is widely deployed. This method is being moved from MUST 186 to SHOULD- to aid in transition to stronger SHA-2 based hashes. This 187 method will transition to MUST NOT when SHA-2 alternatives are more 188 generally available. 190 3.6. diffie-hellman-group14-sha256 192 This generated key exchange uses a 2048-bit sized MODP group along 193 with a SHA-2 (SHA2-256) hash. This represents the smallest Finite 194 Field Cryptography (FFC) Diffie-Hellman (DH) key exchange method 195 considered to be secure. It is a reasonably simple transition to 196 move from SHA-1 to SHA-2. This method MUST be implemented. 198 3.7. diffie-hellman-group16-sha512 200 The use of FFC DH is well understood and trusted. Adding larger 201 modulus sizes and protecting with SHA2-512 should give enough head 202 room to be ready for the next scare that someone has pre-computed. 203 This modulus is larger than that required by [CNSA-SUITE] and should 204 be sufficient to inter-operate with more paranoid nation-states. 205 This method SHOULD+ be implemented. 207 3.8. ecdh-sha2-nistp256 209 Elliptic Curve Diffie-Hellman (ECDH) are often implemented because 210 they are smaller and faster than using large FFC primes with 211 traditional Diffie-Hellman (DH). However, given [CNSA-SUITE] and 212 [safe-curves], this curve may not be as useful and strong as desired. 213 The SSH development community is divided on this and many 214 implementations do exist. However, there are good implementations of 215 this along with a constant-time SHA2-256 implementation. If an 216 implementer does not have a constant-time SHA2-384 implementation 217 (which helps avoid side-channel attacks), then this is the correct 218 ECDH to implement. If traditional ECDH key exchange methods are 219 implemented, then this method SHOULD- be implemented. 221 3.9. ecdh-sha2-nistp384 223 This ECDH method should be implemented because it is smaller and 224 faster than using large FFC primes with traditional Diffie-Hellman 225 (DH). Given [CNSA-SUITE], it is considered good enough for TOP 226 SECRET for now. This really needs a constant-time implementation of 227 SHA2-384 to be useful. If traditional ECDH key exchange methods are 228 implemented, then this method SHOULD+ be implemented. 230 3.10. gss-gex-sha1-* 232 This set of ephemerally generated key exchange groups uses SHA-1 233 which has security concerns [RFC6194]. It is recommended that these 234 key exchange groups NOT be used. This key exchange MUST NOT be 235 implemented. 237 3.11. gss-group1-sha1-* 239 This method suffers from the same problems of diffie-hellman- 240 group1-sha1. It uses [RFC7296] Oakley Group 2 (a 1024-bit MODP 241 group) and SHA-1 [RFC3174]. Due to recent security concerns with 242 SHA-1 [RFC6194] and with MODP groups with less than 2048 bits 243 [NIST-SP-800-131Ar1], this method is considered insecure. This 244 method MUST NOT be implemented. 246 3.12. gss-group14-sha1-* 248 This generated key exchange groups uses SHA-1 which has security 249 concerns [RFC6194]. If GSS-API key exchange methods are being used, 250 then this one SHOULD- be implemented until such time as SHA-2 251 variants may be implemented and deployed. 253 3.13. gss-group14-sha256-* 255 If the GSS-API is to be used, then this method SHOULD be implemented. 257 3.14. gss-group16-sha512-* 259 If the GSS-API is to be used, then this method SHOULD+ be 260 implemented. 262 3.15. rsa1024-sha1 264 The security of RSA 1024-bit modulus keys is not good enough any 265 longer. A minimum bit size should be 2048-bit groups. This 266 generated key exchange groups uses SHA-1 which has security concerns 267 [RFC6194]. This method MUST NOT be implemented. 269 4. Summary Guidance for Key Exchange Method Names 271 The Implement column is the current recommendations of this RFC. Key 272 Exchange Method Names are listed alphabetically. 274 Key Exchange Method Name Reference Implement 275 ---------------------------------- ---------- --------- 276 curve25519-sha256 ssh-curves SHOULD+ 277 diffie-hellman-group-exchange-sha1 RFC4419 MUST NOT 278 diffie-hellman-group1-sha1 RFC4253 MUST NOT 279 diffie-hellman-group14-sha1 RFC4253 SHOULD- 280 diffie-hellman-group14-sha256 new-modp MUST 281 diffie-hellman-group16-sha512 new-modp SHOULD+ 282 ecdh-sha2-nistp256 RFC5656 SHOULD- 283 ecdh-sha2-nistp384 RFC5656 SHOULD+ 284 gss-gex-sha1-* RFC4462 MUST NOT 285 gss-group1-sha1-* RFC4462 MUST NOT 286 gss-group14-sha1-* RFC4462 SHOULD- 287 gss-group14-sha256-* gss-keyex SHOULD 288 gss-group16-sha512-* gss-keyex SHOULD+ 289 rsa1024-sha1 RFC4432 MUST NOT 291 The full set of official [IANA-KEX] key algorithm method names not 292 otherwise mentioned in this document MAY be implemented. 294 The guidance of this document is that the SHA-1 algorithm hashing 295 MUST NOT be used. If it is used in implementations, it should only 296 be provided for backwards compatibility, should not be used in new 297 designs, and should be phased out of existing key exchanges as 298 quickly as possible because of its known weaknesses. Any key 299 exchange using SHA-1 SHOULD NOT be in a default key exchange list if 300 at all possible. If they are needed for backward compatibility, they 301 SHOULD be listed after all of the SHA-2 based key exchanges. 303 The [RFC4253] MUST diffie-hellman-group14-sha1 method SHOULD- be 304 retained for compatibility with older Secure Shell implementations. 305 It is intended that this key exchange method be phased out as soon as 306 possible. It SHOULD be listed after all possible SHA-2 based key 307 exchanges. 309 It is believed that all current SSH implementations should be able to 310 achieve an implementation of the "diffie-hellman-group14-sha256" 311 method. To that end, this is one method that MUST be implemented. 313 [TO BE REMOVED: This registration should take place at the following 314 location: ] 317 5. Acknowledgements 319 Thanks to the following people for review and comments: Denis Bider, 320 Peter Gutmann, Damien Miller, Niels Moeller, Matt Johnston, Iwamoto 321 Kouichi, Simon Josefsson, Dave Dugal, Daniel Migault, Anna Johnston. 323 Thanks to the following people for code to implement inter-operable 324 exchanges using some of these groups as found in an this draft: 325 Darren Tucker for OpenSSH and Matt Johnston for Dropbear. And thanks 326 to Iwamoto Kouichi for information about RLogin, Tera Term (ttssh) 327 and Poderosa implementations also adopting new Diffie-Hellman groups 328 based on this draft. 330 6. Security Considerations 332 This SSH protocol provides a secure encrypted channel over an 333 insecure network. It performs server host authentication, key 334 exchange, encryption, and integrity protection. It also derives a 335 unique session ID that may be used by higher-level protocols. 337 Full security considerations for this protocol are provided in 338 [RFC4251] 340 It is desirable to deprecate or remove key exchange method name that 341 are considered weak. A key exchange method may be weak because too 342 few bits are used, or the hashing algorithm is considered too weak. 344 The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT. 345 This method used [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and 346 SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 347 [RFC6194] and with MODP groups with less than 2048 bits 348 [NIST-SP-800-131Ar1], this method is no longer considered secure. 350 The United States Information Assurance Directorate (IAD) at the 351 National Security Agency (NSA) has published a FAQ 352 [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve 353 Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes 354 less than SHA2-384 are no longer sufficient for transport of Top 355 Secret information. It is for this reason that this draft moves 356 ecdh-sha2-nistp256 from a MUST to MAY as a key exchange method. This 357 is the same reason that the stronger MODP groups being adopted. As 358 the MODP group14 is already present in most SSH implementations and 359 most implementations already have a SHA2-256 implementation, so 360 diffie-hellman-group14-sha256 is provided as an easy to implement and 361 faster to use key exchange. Small embedded applications may find 362 this KEX desirable to use. 364 The NSA Information Assurance Directorate (IAD) has also published 365 the Commercial National Security Algorithm Suite (CNSA Suite) 366 [CNSA-SUITE] in which the 3072-bit MODP Group 15 in [RFC3526] is 367 explicitly mentioned as the minimum modulus to protect Top Secret 368 communications. 370 It has been observed in [safe-curves] that the NIST Elliptic Curve 371 Prime Curves (P-256, P-384, and P-521) are perhaps not the best 372 available for Elliptic Curve Cryptography (ECC) Security. For this 373 reason, none of the [RFC5656] curves are mandatory to implement. 374 However, the requirement that "every compliant SSH ECC implementation 375 MUST implement ECDH key exchange" is now taken to mean that if ecdsa- 376 sha2-[identifier] is implemented, then ecdh-sha2-[identifier] MUST be 377 implemented. 379 In a Post-Quantum Computing (PQC) world, it will be desirable to use 380 larger cyclic subgroups. To do this using Elliptic Curve 381 Cryptography will require much larger prime base fields, greatly 382 reducing their efficiency. Finite Field based Cryptography already 383 requires large enough base fields to accommodate larger cyclic 384 subgroups. Until such time as a PQC method of key exchange is 385 developed and adopted, it may be desirable to generate new and larger 386 DH groups to avoid precalcualtion attacks that are provably not 387 backdoored. 389 7. IANA Considerations 391 IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be 392 implemented as being deprecated by this document. 394 8. References 396 8.1. Normative References 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 404 Diffie-Hellman groups for Internet Key Exchange (IKE)", 405 RFC 3526, DOI 10.17487/RFC3526, May 2003, 406 . 408 [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) 409 Protocol Assigned Numbers", RFC 4250, 410 DOI 10.17487/RFC4250, January 2006, 411 . 413 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 414 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 415 January 2006, . 417 8.2. Informative References 419 [CNSA-SUITE] 420 "Information Assurance by the National Security Agency", 421 "Commercial National Security Algorithm Suite", September 422 2016, . 425 [I-D.ietf-curdle-ssh-curves] 426 Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure 427 Shell (SSH) Key Exchange Method using Curve25519 and 428 Curve448", draft-ietf-curdle-ssh-curves-04 (work in 429 progress), April 2017. 431 [I-D.ietf-curdle-ssh-modp-dh-sha2] 432 Baushke, M., "More Modular Exponential (MODP) Diffie- 433 Hellman (DH) Key Exchange (KEX) Groups for Secure Shell 434 (SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-04 (work in 435 progress), April 2017. 437 [IANA-KEX] 438 Internet Assigned Numbers Authority (IANA), "Secure Shell 439 (SSH) Protocol Parameters: Key Exchange Method Names", 440 March 2017, . 443 [MFQ-U-OO-815099-15] 444 "National Security Agency/Central Security Service", "CNSA 445 Suite and Quantum Computing FAQ", January 2016, 446 . 450 [NEWGSSAPI] 451 Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2", 452 December 2016, . 455 [NIST-SP-800-131Ar1] 456 Barker, and Roginsky, "Transitions: Recommendation for the 457 Transitioning of the Use of Cryptographic Algorithms and 458 Key Lengths", NIST Special Publication 800-131A Revision 459 1, November 2015, 460 . 463 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 464 (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, 465 . 467 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 468 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 469 January 2006, . 471 [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman 472 Group Exchange for the Secure Shell (SSH) Transport Layer 473 Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, 474 . 476 [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) 477 Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, 478 March 2006, . 480 [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, 481 "Generic Security Service Application Program Interface 482 (GSS-API) Authentication and Key Exchange for the Secure 483 Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 484 2006, . 486 [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm 487 Integration in the Secure Shell Transport Layer", 488 RFC 5656, DOI 10.17487/RFC5656, December 2009, 489 . 491 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 492 Considerations for the SHA-0 and SHA-1 Message-Digest 493 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 494 . 496 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 497 Kivinen, "Internet Key Exchange Protocol Version 2 498 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 499 2014, . 501 [safe-curves] 502 Bernstein, and Lange, "SafeCurves: choosing safe curves 503 for elliptic-curve cryptography.", February 2016, 504 . 506 Author's Address 507 Mark D. Baushke 508 Juniper Networks, Inc. 509 1133 Innovation Way 510 Sunnyvale, CA 94089-1228 511 US 513 Email: mdb@juniper.net 514 URI: http://www.juniper.net/