<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3174.xml">
<!ENTITY RFC3526 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3526.xml">
<!ENTITY RFC3766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml">
<!ENTITY RFC4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY RFC4419 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4419.xml">
<!ENTITY RFC4432 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4432.xml">
<!ENTITY RFC4462 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4462.xml">
<!ENTITY RFC5656 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5656.xml">
<!ENTITY RFC6194 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6194.xml">
<!ENTITY SSHCURVES PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-josefsson-ssh-curves-04.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="no"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std"
     docName="draft-ietf-curdle-ssh-kex-sha2-01"
     updates="4253, 4419, 4432, 4462, 5656"
     ipr="trust200902">
 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->

   <title abbrev="Key Exchange Updates for SSH">
     Key Exchange Method Updates for Secure Shell (SSH)</title>
    <author initials="M. D." surname="Baushke" fullname="Mark D.
    Baushke">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>1133 Innovation Way</street>
          <city>Sunnyvale</city>
          <region>CA</region>
          <code>94089-1228</code>
          <country>US</country>
        </postal>
        <phone>+1 408 745 2952</phone>
        <email>mdb@juniper.net</email>
        <uri>http://www.juniper.net/</uri>
      </address>
    </author>
   <date year="2016" />

   <workgroup>Internet Engineering Task Force</workgroup>
   <abstract>
     <t>This document deprecates some previously specified Key
     Exchange Method algorithm names as well as defining a few added
     Modular Exponential (MODP) Groups for the Secure Shell (SSH)
     protocol. It also updates <xref
     target="RFC4253"/>, <xref target="RFC4419"/>, <xref
     target="RFC4462"/>, and <xref target="RFC5656"/> by specifying
     the set key exchange algorithms that currently exist and which
     ones MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key
     exchange methods use the SHA-2 family of hashes.</t>
   </abstract>
 </front>

 <middle>
   <section title="Overview and Rationale">
     <t>Secure Shell (SSH) is a common protocol for secure
     communication on the Internet. In <xref target="RFC4253"/>, SSH
     originally defined the Key Exchange Method Name
     diffie-hellman-group1-sha1 which used <xref target="RFC2409"/>
     Oakley Group 1 (a MODP group with 768 bits) and SHA-1 <xref
     target="RFC3174"/>. Due to recent security concerns with SHA-1
     <xref target="RFC6194"/> and with MODP groups with less than 2048
     bits <xref target="NIST-SP-800-131Ar1"/> implementer and users
     request support for larger MODP group sizes with data integrity
     verification using the SHA-2 family of secure hash algorithms as
     well as MODP groups providing more security.</t>
     <t>The United States Information Assurance Directorate at the
     National Security Agency has published a FAQ <xref
     target="MFQ-U-OO-815099-15"/> suggesting that the use of ECDH
     using the nistp256 curve and SHA-2 based hashes less than SHA2-384
     are no longer sufficient for transport of Top Secret information.
     It is for this reason that this draft moves ecdh-sha2-nistp256
     from a REQUIRED to OPTIONAL as a key exchange method. This is the
     same reason that the stronger MODP groups being introduced are
     using SHA2-512 as the hash algorithm. Group14 is already present
     in most SSH implementations and most implementations already have
     a SHA2-256 implementation, so diffie-hellman-group14-sha256 is
     provided as an easy to implement and faster to use key exchange
     for small embedded applications.</t>
     <t>It has been observed in <xref target="safe-curves"/> that the
     NIST recommended Elliptic Curve Prime Curves (P-256, P-384, and
     P-521) are perhaps not the best available for Elliptic Curve
     Cryptography Security. For this reason, none of the <xref
     target="RFC5656"/> curves are marked as a MUST implement.
     However, the requirement that "every compliant SSH ECC
     implementation MUST implement ECDH key exchange" is now taken to
     mean that if ecdsa-sha2-[identifier] is implemented, then
     ecdh-sha2-[identifier] MUST be implemented.</t>
     <t>Please send comments on this draft to ietf-ssh@NetBSD.org.</t>
   </section>

   <section title="Requirements Language">
     <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in <xref
     target="RFC2119"/>.</t>
   </section>

   <section title="Key Exchange Algorithms">
     <t>This memo adopts the style and conventions of
     <xref target="RFC4253"/> in specifying how the use of new
     data key exchange is indicated in SSH.
     </t>
     <figure anchor="figure.algs">
       <preamble>The following new key exchange algorithms are
       defined:</preamble>
       <artwork>
Key Exchange Method Name          Note
diffie-hellman-group14-sha256     MAY/OPTIONAL
diffie-hellman-group16-sha512     SHOULD/RECOMMENDED
diffie-hellman-group18-sha512     MAY/OPTIONAL
       </artwork>
     </figure>
     <t>The SHA-2 family of secure hash algorithms are defined in
     <xref target="FIPS-180-4"/>.
     </t>
     <t>The method of key exchange used for the name
     "diffie-hellman-group14-sha256" is the same as that for
     "diffie-hellman-group14-sha1" except that the SHA2-256 hash
     algorithm is used.</t>
     <t>The group16 and group18 names are the same
     as those specified in <xref target="RFC3526"/>
     4096-bit MODP Group 16 and 8192-bit MODP Group 18.</t>
     <t>The SHA2-512 algorithm is to be used when "sha512" is
     specified as a part of the key exchange method name.</t>
   </section>

   <section title="IANA Considerations">
     <t>This document augments the Key Exchange Method Names in <xref
     target="RFC4253"/>. It downgrades the use of SHA-1 hashing for
     key exchange methods in <xref target="RFC4419"/>, <xref
     target="RFC4432"/>, and <xref target="RFC4462"/>. It also moves
     from MUST to MAY the ecdh-sha2-nistp256 given in <xref
     target="RFC5656"/>.</t>
     <t>It is desirable to also include the ssh-curves from the <xref
     target="I-D.josefsson-ssh-curves"/> in this list. The
     "curve25519-sha256" is currently available in some Secure Shell
     implementations under the name "curve25519-sha256@libssh.org" and
     is the best candidate for a fast, safe, and secure key exchange
     method.</t>
     <figure anchor="figure.iana">
       <preamble>IANA is requested to update the SSH
       algorithm registry with the following entries:</preamble>
       <artwork>
Key Exchange Method Name              Reference     Note
diffie-hellman-group-exchange-sha1    RFC4419       SHOULD NOT
diffie-hellman-group-exchange-sha256  RFC4419       MAY
diffie-hellman-group1-sha1            RFC4253       SHOULD NOT
diffie-hellman-group14-sha1           RFC4253       SHOULD
ecdh-sha2-nistp256                    RFC5656       MAY
ecdh-sha2-nistp384                    RFC5656       SHOULD
ecdh-sha2-nistp521                    RFC5656       SHOULD
ecdh-sha2-*                           RFC5656       MAY
ecmqv-sha2                            RFC5656       MAY
gss-gex-sha1-*                        RFC4462       SHOULD NOT
gss-group1-sha1-*                     RFC4462       SHOULD NOT
gss-group14-sha1-*                    RFC4462       MAY
gss-*                                 RFC4462       MAY
rsa1024-sha1                          RFC4432       SHOULD NOT
rsa2048-sha256                        RFC4432       MAY
diffie-hellman-group14-sha256         This Draft    MAY
diffie-hellman-group16-sha512         This Draft    SHOULD
diffie-hellman-group18-sha512         This Draft    MAY
curve25519-sha256                     ssh-curves    MUST
curve448-sha512                       ssh-curves    MAY
       </artwork>
     </figure>
     <t>The Note in the above table is an implementation
     suggestion/recommendation for the listed key exchange method. It
     is up to the end-user as to what algorithms they choose to be
     able to negotiate.</t>
     <t>The guidance of his document is that the SHA-1 algorithm
     hashing SHOULD NOT be used. If it is used, it should only be
     provided for backwards compatibility, should not be used in new
     designs, and should be phased out of existing key exchanges as
     quickly as possible because of its known weaknesses. Any key
     exchange using SHA-1 SHOULD NOT be in a default key exchange list
     if at all possible. If they are needed for backward
     compatibility, they SHOULD be listed after all of the SHA-2 based
     key exchanges.</t>
     <t>The RFC4253 REQUIRED diffie-hellman-group14-sha1 method SHOULD
     be retained for compatibility with older Secure Shell
     implementations. It is intended that this key exchange be phased
     out as soon as possible.</t>
   </section>

   <section title="Acknowledgements">
     <t>Thanks to the following people for review and comments: Denis
     Bider, Peter Gutmann, Damien Miller, Niels Moeller, Matt
     Johnston, Iwamoto Kouichi, Simon Josefsson, Dave Dugal.
     </t>
     <t>Thanks to the following people for code to implement
     interoperable exchanges using some of these groups as found in an
     the -01 draft: Darren Tucker for OpenSSH and Matt Johnston for
     Dropbear. And thanks to Iwamoto Kouichi for information about
     RLogin, Tera Term (ttssh) and Poderosa implementations also
     adopting new Diffie-Hellman groups based on the -01 draft.</t>
   </section>
   <section title="Security Considerations">
     <t>The security considerations of
     <xref target="RFC4253"/> apply to this
     document.
     </t>
     <t>The security considerations of
     <xref target="RFC3526"/> suggest that these
     MODP groups have security strengths given in this table.
     They are based on <xref target="RFC3766"/> Determining
     Strengths For Public Keys Used For Exchanging Symmetric Keys.
     </t>
     <figure anchor="figure.strength">
       <preamble>Group modulus security strength estimates (RFC3526)</preamble>
       <artwork>
+--------+----------+---------------------+---------------------+
| Group  | Modulus  | Strength Estimate 1 | Strength Estimate 2 |
|        |          +----------+----------+----------+----------+
|        |          |          | exponent |          | exponent |
|        |          | in bits  | size     | in bits  | size     |
+--------+----------+----------+----------+----------+----------+
|  14    | 2048-bit |      110 |     220- |      160 |     320- |
|  15    | 3072-bit |      130 |     260- |      210 |     420- |
|  16    | 4096-bit |      150 |     300- |      240 |     480- |
|  17    | 6144-bit |      170 |     340- |      270 |     540- |
|  18    | 8192-bit |      190 |     380- |      310 |     620- |
+--------+----------+---------------------+---------------------+
       </artwork>
     </figure>
     <t>Many users seem to be interested in the perceived safety of
     using larger MODP groups and hashing with SHA2-based algorithms.</t>
   </section>

 </middle>

 <back>

   <references title="Normative References">
     &RFC2119;

     &RFC3526;

     &RFC4253;

     <reference
         anchor="FIPS-180-4"
         target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">
       <front>
         <title>Secure Hash Standard (SHS)</title>
         <author>
           <organization>National Institute of Standards and Technology
           </organization>
         </author>
         <date month="August" year="2015"/>
       </front>
       <seriesInfo name="FIPS PUB" value="180-4"/>
     </reference>

   </references>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->

     &RFC2409;

     &RFC3174;

     &RFC3766;

     &RFC4419;

     &RFC4432;

     &RFC4462;

     &RFC5656;

     &RFC6194;

     &SSHCURVES;

     <reference
         anchor="NIST-SP-800-131Ar1"
         target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">
       <front>
         <title>Transitions: Recommendation for the Transitioning of
         the Use of Cryptographic Algorithms and Key Lengths</title>
         <author surname="Barker" fullname="Elaine Barker"/>
         <author surname="Roginsky" fullname="Allen Roginsky"/>
         <date month="November" year="2015"/>
       </front>
       <seriesInfo
           name="NIST Special Publication" value="800-131A Revision 1"/>
     </reference>

     <reference
         anchor="MFQ-U-OO-815099-15"
         target="https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm">
       <front>
         <title>CNSA Suite and Quantum Computing FAQ</title>
         <author fullname="NSA/CSS">
           <organization abbrev="NSA/CSS">"National Security Agency/Central Security Service"</organization>
         </author>
         <date month="January" year="2016"/>
       </front>
     </reference>

     <reference
	 anchor="safe-curves"
	 target="https://safecurves.cr.yp.to/">
       <front>
       <title>SafeCurves: choosing safe curves for elliptic-curve
       cryptography.</title>
       <author surname="Bernstein" fullname="Daniel J. Bernstein"/>
       <author surname="Lange" fullname="Tanja Lange"/>
       <date month="February" year="2016"/>
       </front>
     </reference>

   </references>

   <!-- Change Log

v00 2015-12-10  MDB   Initial version

v01 2015-12-10  MDB   Fix SHA1 -> SHA-1 for the name of the algorithm.
                      Add recommendation that DH-group14-sha256 be
                      in the negotiation list before DH-group14-sha1.

v02 2016-02-12  MDB   List all of the key exchange methods currently
                      listed in the IANA registry for Secure Shell.
                      Update the rationale.

v03 2016-02-13  MDB   Adopt some feedback from the list.

v04 2016-02-14  MDB   Update Title to include the text 'Secure Shell'
                      Drop references to group15 and group17. Fix text
                      to use group16 and group18.

v05 2016-02-19  MDB   Demote ecdh-sha2-nistp384 to SHOULD from MUST.
                      Reference safecurves.cr.yp.to as justification.

v06 2016-03-01  MDB   Clarify RFC5656 SSH ECC MUST requirements.
                      Update to I-D.draft-josefsson-ssh-curves-04.
		      Add acknowledgements section.
v01 2016-03-07  MDB   Rename as draft-ietf-curdle-ssh-kex-sha2-01
                      from draft-baushke-ssh-dh-group-sha2-06
   -->
 </back>
</rfc>
