wdiff draft-ietf-curdle-ssh-kex-sha2-06.txt draft-ietf-curdle-ssh-kex-sha2-07.txt

Internet Engineering Task Force M. Baushke
Internet-Draft Juniper Networks, Inc.
Updates: 4253, 4419, 4432, 4462, 5656 September 20, 2016 4250, 4253 (if approved) March 27, 2017
Intended status: Standards Track
Expires: March 24, September 28, 2017

Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
(SSH)
draft-ietf-curdle-ssh-kex-sha2-06
draft-ietf-curdle-ssh-kex-sha2-07

Abstract

This document adds recommendations for adoption of ssh-curves from
the [I-D.ietf-curdle-ssh-curves] and new-modp from is intended to update the
[I-D.ietf-curdle-ssh-modp-dh-sha2], and deprecates some previously
specified Key Exchange Method algorithm names recommended set of key
exchange methods for use in the Secure Shell (SSH) protocol. It also protocol to meet
evolving needs for stronger security. This RFC updates [RFC4253], [RFC4419], [RFC4462], and
[RFC5656] by specifying the set key exchange algorithms [RFC4253]
MUST algorithms. This RFC also notes that
currently exist and the [IANASSH] has replaced
[RFC4250] as the primary reference document for SSH Protocol Assigned
Numbers.

This document adds recommendations for adoption of Key Exchange
Methods which ones MUST, SHOULD+, SHOULD, SHOULD-, MAY, and SHOULD NOT, and
MUST NOT be implemented. New key exchange methods will use the SHA-2
family of
hashes. hashes and are drawn from these from
[I-D.ietf-curdle-ssh-curves] and new-modp from the
[I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex [NEWGSSAPI].

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 24, September 28, 2017.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3
3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4
3.2. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4
3.3. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4
3.4. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 4
3.5. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 4
3.6. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 4
3.7. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 5
3.8. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 5
3.9. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 5
3.10. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 5
3.11. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 5
3.12. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 6
3.13. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 6
3.14. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 6
4. Summary Guidance for Key Exchange Method Names . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11

1. Overview and Rationale

Secure Shell (SSH) is a common protocol for secure communication on
the Internet. In [RFC4253], SSH originally defined the two Key Exchange
Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley
Group 2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent
security concerns with SHA-1 [RFC6194] and with MODP groups with less
than 2048 bits [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.

The United States Information Assurance Directorate (IAD) at the
National Security Agency (NSA) has published a FAQ
[MFQ-U-OO-815099-15] suggesting Names that the use of Elliptic Curve
Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes
less than SHA2-384 are MUST be implemented. Over time, what was once
considered secure, is no longer sufficient for transport considered secure. The purpose 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
adopted. As the MODP 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. Small embedded
applications may find
this KEX desirable to use.

The NSA Information Assurance Directorate (IAD) has also published
the Commercial National Security Algorithm Suite (CNSA Suite)
[CNSA-SUITE] in which the 3072-bit MODP Group 15 in RFC 3526 is
explicitly mentioned as the minimum modulus to protect Top Secret
communications.

It has been observed in [safe-curves] recommend 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 (ECC) Security.
For this reason, none of the [RFC5656] curves are marked as a MUST
implement. However, the requirement that "every compliant SSH ECC
implementation MUST implement ECDH some published key exchange" is now taken to mean
that if ecdsa-sha2-[identifier] is implemented, then ecdh-
sha2-[identifier] MUST exchanges be implemented. adopted
or reclassified and others retired.

[TO BE REMOVED: Please send comments on this draft to curdle@ietf.org.
curdle@ietf.org.]

2. Requirements Language

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 [RFC2119].

When used in the tables in this document, these terms indicate that
the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or MAY be
implemented as part of a Secure Shell implementation. Additional
terms used in this document are:

SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at
some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future
version of this document.

3. Key Exchange Algorithms Methods

This memo adopts the style and conventions of [RFC4253] in specifying
how the use of new data key exchange is indicated in SSH.

A new set

This RFC also collects Key Exchange Method Names in various existing
RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
[I-D.ietf-curdle-ssh-modp-dh-sha2], [NEWGSSAPI], and
[I-D.ietf-curdle-ssh-curves] and provides a suggested suitability for
implementation of Elliptic Curve Diffie-Hellman ssh-curves exist. The
curve25519-sha256 MUST, SHOULD+, SHOULD, SHOULD-, SHOULD NOT, and
MUST be adopted where possible.

As a hedge against uncertainty raised by the NSA IAD FAQ publication,
new MODP Diffie-Hellman based key exchanges NOT.

This document is intended to provide guidance as to what Key Exchange
Algorithms are proposed to be considered for
inclusion in the set new or updated SSH
implementations. This document will be superseded when one or more
of key exchange method names as well as the
curve448-sha512 curve.

The following new key exchange listed algorithms are defined:

Key Exchange Method Name Note
----------------------------- ------------------ considered too weak to continue to use
securely, or when newer methods have been analyzed and found to be
secure with wide enough adoption to upgrade their recommendation from
MAY to SHOULD or MUST.

3.1. curve25519-sha256 MUST/REQUIRED
curve448-sha512 MAY/OPTIONAL
diffie-hellman-group14-sha256 MUST/REQUIRED
diffie-hellman-group15-sha512 MAY/OPTIONAL
diffie-hellman-group16-sha512 SHOULD/RECOMMENDED
diffie-hellman-group17-sha512 MAY/OPTIONAL
diffie-hellman-group18-sha512 MAY/OPTIONAL
gss-group14-sha256-* SHOULD/RECOMMENDED
gss-group15-sha512-* MAY/OPTIONAL
gss-group16-sha512-* SHOULD/RECOMMENDED
gss-group17-sha512-* MAY/OPTIONAL
gss-group18-sha512-* MAY/OPTIONAL

The SHA-2 family Curve25519 provides strong security and is efficient on a wide
range of secure hash algorithms are defined in
[FIPS-180-4].

4. IANA Considerations architectures with properties that allow better
implementation properties compared to traditional elliptic curves.
The use of SHA2-256 for integrity is a reasonable one for this
method. This RFC augments the Key Exchange Method Names has a few implementations and
SHOULD+ be implemented in [RFC4253]. It
downgrades the use any SSH interested in using elliptic curve
based key exchanges.

3.2. diffie-hellman-group-exchange-sha1

This set of ephemerally generated key exchange groups uses SHA-1 hashing for
which has security concerns [RFC6194]. It is recommended that these
key exchange methods in
[RFC4419], [RFC4432], groups NOT be used. This key exchange MUST NOT be
implemented.

3.3. diffie-hellman-group1-sha1

This method uses [RFC2409] Oakley Group 2 (a 1024-bit MODP group) and [RFC4462]. It also moves
SHA-1 [RFC3174]. Due to recent security concerns with SHA-1
[RFC6194] and with MODP groups with less than 2048 bits
[NIST-SP-800-131Ar1], this method is considered insecure. This
method is being moved from MUST to
SHOULD the ecdh-sha2-nistp256 given MUST NOT.

3.4. diffie-hellman-group14-sha1

This generated key exchange groups uses SHA-1 which has security
concerns [RFC6194]. However, this group is still strong enough and
is widely deployed. This method is being moved from MUST to SHOULD-
to aid in [RFC5656].

It adds a new set of named "gss-*" methods transition to [RFC4462] stronger SHA-2 based hashes. This method
will transition to MUST NOT when SHA-2 alternatives are more
generally available.

3.5. diffie-hellman-group14-sha256

This generated key exchange uses a 2048-bit sized MODP group along
with a MAY
recommendation. SHA-2 (SHA2-256) hash. This represents the smallest Finite
Field cryptography Diffie-Hellman key exchange method. It is desirable a
reasonably simple transition to also include the new-modp move from the
[I-D.ietf-curdle-ssh-modp-dh-sha2] in this list.

It SHA-1 to SHA-2. This
method MUST be implemented.

3.6. diffie-hellman-group16-sha512

The use of FFC DH is desirable well understood and trusted. Adding larger
modulus sizes and protecting with SHA2-512 should give enough head
room to also include the ssh-curves from be ready for the
[I-D.ietf-curdle-ssh-curves] in next scare that someone has pre-computed.
This modulus is larger than that required by [CNSA-SUITE] and should
be sufficient to inter-operate with more paranoid nation-states.
This method SHOULD+ be implemented.

3.7. ecdh-sha2-nistp256

Elliptic Curve Diffie-Hellman (ECDH) are often implemented because
they are smaller and faster than using large FFC primes with
traditional Diffie-Hellman (DH). However, given [CNSA-SUITE] and
[safe-curves], this list. curve may not be as useful and strong as desired.
The "curve25519-sha256" SSH development community is currently available in some Secure Shell divided on this and many
implementations do exist. However, there are good implementations under of
this along with a constant-time SHA2-256 implementation. If an
implementer does not have a constant-time SHA2-384 implementation
(which helps avoid side-channel attacks), then this is the
name "curve25519-sha256@libssh.org" correct
ECDH to implement. This method SHOULD- be implemented.

3.8. ecdh-sha2-nistp384

This ECDH method should be implemented because it is smaller and
faster than using large FFC primes with traditional Diffie-Hellman
(DH). Given [CNSA-SUITE], it is the best candidate considered good enough for TOP
SECRET for now. This really needs a
fast, safe, constant-time implementation of
SHA2-384 to be useful. This method SHOULD+ be implemented.

3.9. gss-gex-sha1-*

This set of ephemerally generated key exchange groups uses SHA-1
which has security concerns [RFC6194]. It is recommended that these
key exchange groups NOT be used. This key exchange MUST NOT be
implemented.

3.10. gss-group1-sha1-*

This method suffers from the same problems of diffie-hellman-
group1-sha1. It uses [RFC2409] Oakley Group 2 (a 1024-bit MODP
group) and secure SHA-1 [RFC3174]. Due to recent security concerns with
SHA-1 [RFC6194] and with MODP groups with less than 2048 bits
[NIST-SP-800-131Ar1], this method is considered insecure. This
method MUST NOT be implemented.

3.11. gss-group14-sha1-*

This generated key exchange method.

IANA groups uses SHA-1 which has security
concerns [RFC6194]. If GSS-API key exchange methods are being used,
then this one SHOULD- be implemented until such time as SHA-2
variants may be implemented and deployed.

3.12. gss-group14-sha256-*

If the GSS-API is requested to update be used, then this method SHOULD be implemented.

3.13. gss-group16-sha512-*

If the SSH algorithm registry GSS-API is to ensure that
all be used, then this method SHOULD+ be
implemented.

3.14. rsa1024-sha1

The security of the listed RSA 1024-bit modulus keys is not good enough any
longer. A minimum bit size should be 2048-bit groups. This
generated key exchange groups uses SHA-1 which has security concerns
[RFC6194]. This method MUST NOT be implemented.

4. Summary Guidance for Key Exchange Method Name and References exist Names

The full set of official [IANASSH] key algorithm method names not
otherwise mentioned in
the following table. However, the this RFC MAY be implemented.

The Implement column is just the current recommendations of this RFC. Key
Exchange Method Names are listed alphabetically.

Key Exchange Method Name Reference Implement
------------------------------------ ----------
---------------------------------- ---------- ---------
curve25519-sha256 ssh-curves MUST
curve448-sha512 ssh-curves MAY SHOULD+
diffie-hellman-group-exchange-sha1 RFC4419 SHOULD MUST NOT
diffie-hellman-group-exchange-sha256 RFC4419 MAY
diffie-hellman-group1-sha1 RFC4253 SHOULD MUST NOT
diffie-hellman-group14-sha1 RFC4253 SHOULD SHOULD-
diffie-hellman-group14-sha256 new-modp MUST
diffie-hellman-group15-sha512 new-modp MAY
diffie-hellman-group16-sha512 new-modp SHOULD
diffie-hellman-group17-sha512 new-modp MAY
diffie-hellman-group18-sha512 new-modp MAY SHOULD+
ecdh-sha2-nistp256 RFC5656 SHOULD SHOULD-
ecdh-sha2-nistp384 RFC5656 SHOULD
ecdh-sha2-nistp521 RFC5656 SHOULD
ecdh-sha2-* RFC5656 MAY
ecmqv-sha2 RFC5656 SHOULD NOT SHOULD+
gss-gex-sha1-* RFC4462 SHOULD MUST NOT
gss-group1-sha1-* RFC4462 SHOULD MUST NOT
gss-group14-sha1-* RFC4462 SHOULD SHOULD-
gss-group14-sha256-* new-modp gss-keyex SHOULD
gss-group15-sha512-* new-modp MAY
gss-group16-sha512-* new-modp SHOULD
gss-group17-sha512-* new-modp MAY
gss-group18-sha512-* new-modp MAY
gss-* RFC4462 MAY gss-keyex SHOULD+
rsa1024-sha1 RFC4432 SHOULD MUST NOT
rsa2048-sha256 RFC4432 MAY

The Implement column in the above table is a suggestion/
recommendation for the listed key exchange method to be implemented
in the default list of key exchange methods. It is up to the end-
user as to what algorithms they choose to be able to negotiate, so
the KEX algorithms should be configurable by the administrator of the
server as well as the user of the client. This RFC is intended to
provide IANA defined names for these groups for interoperability.
The Note column of the IANA table should probably continue to point
to the implementation detail sections of the Reference RFCs where
appropriate.

The guidance of his this RFC is that the SHA-1 algorithm hashing SHOULD MUST NOT
be used. If it is used, used in implementations, 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 MUST 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.

The RFC4253 REQUIRED MUST diffie-hellman-group14-sha1 method SHOULD SHOULD- be
retained for compatibility with older Secure Shell implementations.
It is intended that this key exchange method be phased out as soon as
possible.

It is believed that all current SSH implementations should be able to
achieve an implementation of the "diffie-hellman-group14-sha256"
method. To that end, this is one method that MUST be implemented.

If GSS-API methods are available, then the RFC4462 REQUIRED gss-
group14-sha1-* method SHOULD be retained for compatibility with older
Secure Shell implementations and the gss-groups14-sha256-* method
SHOULD be added as for "sha1".

[TO BE REMOVED: This registration should take place at the following
location: <http://www.iana.org/assignments/ssh-parameters/ssh-
parameters.xhtml#ssh-parameters-16>]

5. Acknowledgements

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, Daniel Migault. Migault, Anna Johnston.

Thanks to the following people for code to implement interoperable inter-operable
exchanges using some of these groups as found in an this 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 this draft.

6. Security Considerations

The security considerations of [RFC4253] apply to this RFC.

It is desirable to deprecate or remove key exchange method name that
are considered weak. A key exchange method may be weak because too
few bits are used, or the hashing algorithm is considered too weak.

The diffie-hellman-group1-sha1 is being moved from MUST to MUST NOT.
This method used [RFC2409] Oakley Group 2 (a 1024-bit MODP group) and
SHA-1 [RFC3174]. Due to recent security considerations concerns with SHA-1
[RFC6194] and with MODP groups with less than 2048 bits
[NIST-SP-800-131Ar1], this method is no longer considered secure.

The United States Information Assurance Directorate (IAD) at the
National Security Agency (NSA) has published a FAQ
[MFQ-U-OO-815099-15] suggesting that the use of [RFC3526] suggest Elliptic Curve
Diffie-Hellman (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 these this draft moves
ecdh-sha2-nistp256 from a MUST to MAY as a key exchange method. This
is the same reason that the stronger MODP groups have security strengths given being adopted. As
the MODP 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. Small embedded applications may find
this table. They are based
on [RFC3766] Determining Strengths For Public Keys Used For
Exchanging Symmetric Keys.

Group modulus security strength estimates (RFC3526)

The NSA Information Assurance Directorate (IAD) has also published
the Commercial National Security Algorithm Suite (CNSA Suite)
[CNSA-SUITE] in bits | size |
+--------+----------+----------+----------+----------+----------+
| 14 | 2048-bit | 110 | 220- | 160 | 320- |
| 15 | which the 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- |
+--------+----------+---------------------+---------------------+

Figure 1

Many users seem MODP Group 15 in [RFC3526] is
explicitly mentioned as the minimum modulus to be interested protect Top Secret
communications.

It has been observed in [safe-curves] that the perceived safety NIST Elliptic Curve
Prime Curves (P-256, P-384, and P-521) are perhaps not the best
available for Elliptic Curve Cryptography (ECC) Security. For this
reason, none of the [RFC5656] curves are mandatory to 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.

In a Post-Quantum Computing (PQC) world, it will be desirable to use
larger cyclic subgroups. To do this using Elliptic Curve
Cryptography will require much larger MODP groups and hashing with SHA2-based algorithms. prime base fields, greatly
reducing their efficiency. Finite Field based Cryptography already
requires large enough base fields to accommodate larger cyclic
subgroups.

7. References

7.1. Normative References

[FIPS-180-4]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, DOI 10.17487/RFC3526, May 2003,
<http://www.rfc-editor.org/info/rfc3526>.

[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006,
<http://www.rfc-editor.org/info/rfc4250>.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>.

7.2. Informative References

[CNSA-SUITE]
"Information Assurance by the National Security Agency",
"Commercial National Security Algorithm Suite", September
2016, <https://www.iad.gov/iad/programs/iad-initiatives/
cnsa-suite.cfm>.

[I-D.ietf-curdle-ssh-curves]
Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key
Exchange Method using Curve25519 and Curve448", draft-
ietf-curdle-ssh-curves-00 (work in progress), March 2016.

[I-D.ietf-curdle-ssh-modp-dh-sha2]
Baushke, M., "More Modular Exponential (MODP) Diffie-
Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
(SSH)", draft-ietf-curdle-ssh-modp-dh-sha2-00 draft-ietf-curdle-ssh-modp-dh-sha2-03 (work in
progress), September 2016. March 2017.

[IANASSH] "Internet Assigned Numbers Authority", "IANA, Secure Shell
(SSH) Protocol Parameters", March 2017,
<http://www.iana.org/assignments/ssh-parameters/
ssh-parameters.xhtml>.

[MFQ-U-OO-815099-15]
"National Security Agency/Central Security Service", "CNSA
Suite and Quantum Computing FAQ", January 2016,
<https://www.iad.gov/iad/library/ia-guidance/ia-solutions-
for-classified/algorithm-guidance/cnsa-suite-and-quantum-
computing-faq.cfm>.

[NEWGSSAPI]
Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2",
December 2016, <https://tools.ietf.org/html/draft-ssorce-
gss-keyex-sha2-00>.

[NIST-SP-800-131Ar1]
Barker, and Roginsky, "Transitions: Recommendation for the
Transitioning of the Use of Cryptographic Algorithms and
Key Lengths", NIST Special Publication 800-131A Revision
1, November 2015,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-131Ar1.pdf>.

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<http://www.rfc-editor.org/info/rfc2409>.

[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<http://www.rfc-editor.org/info/rfc3174>.

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<http://www.rfc-editor.org/info/rfc3766>.

[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
Group Exchange for the Secure Shell (SSH) Transport Layer
Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006,
<http://www.rfc-editor.org/info/rfc4419>.

[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432,
March 2006, <http://www.rfc-editor.org/info/rfc4432>.

[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May
2006, <http://www.rfc-editor.org/info/rfc4462>.

[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009,
<http://www.rfc-editor.org/info/rfc5656>.

[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>.

[safe-curves]
Bernstein, and Lange, "SafeCurves: choosing safe curves
for elliptic-curve cryptography.", February 2016,
<https://safecurves.cr.yp.to/>.

Author's Address

Mark D. Baushke
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089-1228
US

Phone: +1 408 745 2952

Email: mdb@juniper.net
URI: http://www.juniper.net/