< draft-ietf-curdle-ssh-kex-sha2-03.txt   draft-ietf-curdle-ssh-kex-sha2-04.txt >
Internet Engineering Task Force M. Baushke Internet Engineering Task Force M. Baushke
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 4253, 4419, 4432, 4462, 5656 March 14, 2016 Updates: 4253, 4419, 4432, 4462, 5656 September 7, 2016
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: September 15, 2016 Expires: March 11, 2017
Key Exchange (KEX) Method Updates and Recommendations for Secure Shell Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
(SSH) (SSH)
draft-ietf-curdle-ssh-kex-sha2-03 draft-ietf-curdle-ssh-kex-sha2-04
Abstract Abstract
This document adds recommendations for adoption of ssh-curves from This document adds recommendations for adoption of ssh-curves from
the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential
(MODP) Groups, and deprecates some previously specified Key Exchange (MODP) Groups, and deprecates some previously specified Key Exchange
Method algorithm names for the Secure Shell (SSH) protocol. It also Method algorithm names for the Secure Shell (SSH) protocol. It also
updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying
the set key exchange algorithms that currently exist and which ones the set key exchange algorithms that currently exist and which ones
MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2016. This Internet-Draft will expire on March 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
1. Overview and Rationale 1. Overview and Rationale
Secure Shell (SSH) is a common protocol for secure communication on Secure Shell (SSH) is a common protocol for secure communication on
the Internet. In [RFC4253], SSH originally defined the Key Exchange the Internet. In [RFC4253], SSH originally defined the Key Exchange
Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley Method Name diffie-hellman-group1-sha1 which used [RFC2409] Oakley
Group 1 (a MODP group with 768 bits) and SHA-1 [RFC3174]. Due to Group 1 (a 768-bit MODP group) and SHA-1 [RFC3174]. Due to recent
recent security concerns with SHA-1 [RFC6194] and with MODP groups security concerns with SHA-1 [RFC6194] and with MODP groups with less
with less than 2048 bits [NIST-SP-800-131Ar1] implementer and users than 2048 bits [NIST-SP-800-131Ar1] implementer and users request
request support for larger MODP group sizes with data integrity support for larger MODP group sizes with data integrity verification
verification using the SHA-2 family of secure hash algorithms as well using the SHA-2 family of secure hash algorithms as well as MODP
as MODP groups providing more security. groups providing more security.
The United States Information Assurance Directorate (IAD) at the The United States Information Assurance Directorate (IAD) at the
National Security Agency (NSA) has published a FAQ National Security Agency (NSA) has published a FAQ
[MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve
Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes
less than SHA2-384 are no longer sufficient for transport of Top less than SHA2-384 are no longer sufficient for transport of Top
Secret information. It is for this reason that this draft moves Secret information. It is for this reason that this draft moves
ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange
method. This is the same reason that the stronger MODP groups being method. This is the same reason that the stronger MODP groups being
introduced are using SHA2-512 as the hash algorithm. Group14 is introduced are using SHA2-512 as the hash algorithm. Group14 is
already present in most SSH implementations and most implementations already present in most SSH implementations and most implementations
already have a SHA2-256 implementation, so diffie-hellman- already have a SHA2-256 implementation, so diffie-hellman-
group14-sha256 is provided as an easy to implement and faster to use group14-sha256 is provided as an easy to implement and faster to use
key exchange for small embedded applications. 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] that the NIST recommended It has been observed in [safe-curves] that the NIST recommended
Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not Elliptic Curve Prime Curves (P-256, P-384, and P-521) are perhaps not
the best available for Elliptic Curve Cryptography (ECC) Security. the best available for Elliptic Curve Cryptography (ECC) Security.
For this reason, none of the [RFC5656] curves are marked as a MUST For this reason, none of the [RFC5656] curves are marked as a MUST
implement. However, the requirement that "every compliant SSH ECC implement. However, the requirement that "every compliant SSH ECC
implementation MUST implement ECDH key exchange" is now taken to mean implementation MUST implement ECDH key exchange" is now taken to mean
that if ecdsa-sha2-[identifier] is implemented, then ecdh- that if ecdsa-sha2-[identifier] is implemented, then ecdh-
sha2-[identifier] MUST be implemented. sha2-[identifier] MUST be implemented.
skipping to change at page 3, line 20 skipping to change at page 3, line 22
3. Key Exchange Algorithms 3. Key Exchange Algorithms
This memo adopts the style and conventions of [RFC4253] in specifying This memo adopts the style and conventions of [RFC4253] in specifying
how the use of new data key exchange is indicated in SSH. how the use of new data key exchange is indicated in SSH.
A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The A new set of Elliptic Curve Diffie-Hellman ssh-curves exist. The
curve25519-sha256 MUST be adopted where possible. curve25519-sha256 MUST be adopted where possible.
As a hedge against uncertainty raised by the NSA IAD FAQ publication, As a hedge against uncertainty raised by the NSA IAD FAQ publication,
three new MODP Diffie-Hellman based key exchanges are proposed for five new MODP Diffie-Hellman based key exchanges are proposed for
inclusion in the set of key exchange method names as well as the inclusion in the set of key exchange method names as well as the
curve448-sha512 curve. curve448-sha512 curve.
The following new key exchange algorithms are defined: The following new key exchange algorithms are defined:
Key Exchange Method Name Note Key Exchange Method Name Note
diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group14-sha256 SHOULD/RECOMMENDED
diffie-hellman-group15-sha512 MAY/OPTIONAL
diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group16-sha512 SHOULD/RECOMMENDED
diffie-hellman-group17-sha512 MAY/OPTIONAL
diffie-hellman-group18-sha512 MAY/OPTIONAL diffie-hellman-group18-sha512 MAY/OPTIONAL
Figure 1 Figure 1
The SHA-2 family of secure hash algorithms are defined in The SHA-2 family of secure hash algorithms are defined in
[FIPS-180-4]. [FIPS-180-4].
The method of key exchange used for the name "diffie-hellman- The method of key exchange used for the name "diffie-hellman-
group14-sha256" is the same as that for "diffie-hellman-group14-sha1" group14-sha256" is the same as that for "diffie-hellman-group14-sha1"
except that the SHA2-256 hash algorithm is used. except that the SHA2-256 hash algorithm is used. This new method is
desirable for interoperability with resource-constrained devices.
The group16 and group18 names are the same as those specified in The group15 through group18 names are the same as those specified in
[RFC3526] 4096-bit MODP Group 16 and 8192-bit MODP Group 18. [RFC3526] 3072-bit MODP Group 15, 4096-bit MODP Group 16, 6144-bit
MODP Group 17, and 8192-bit MODP Group 18. All of these groups are
within the guidelines for CNSA Suite for Top Secret.
The SHA2-512 algorithm is to be used when "sha512" is specified as a The SHA2-512 algorithm is to be used when "sha512" is specified as a
part of the key exchange method name. part of the key exchange method name.
4. IANA Considerations 4. IANA Considerations
This document augments the Key Exchange Method Names in [RFC4253]. This document augments the Key Exchange Method Names in [RFC4253].
It downgrades the use of SHA-1 hashing for key exchange methods in It downgrades the use of SHA-1 hashing for key exchange methods in
[RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to MAY [RFC4419], [RFC4432], and [RFC4462]. It also moves from MUST to MAY
the ecdh-sha2-nistp256 given in [RFC5656]. the ecdh-sha2-nistp256 given in [RFC5656].
skipping to change at page 4, line 30 skipping to change at page 4, line 37
ecdh-sha2-nistp384 RFC5656 SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD
ecdh-sha2-nistp521 RFC5656 SHOULD ecdh-sha2-nistp521 RFC5656 SHOULD
ecdh-sha2-* RFC5656 MAY ecdh-sha2-* RFC5656 MAY
ecmqv-sha2 RFC5656 MAY ecmqv-sha2 RFC5656 MAY
gss-gex-sha1-* RFC4462 SHOULD NOT gss-gex-sha1-* RFC4462 SHOULD NOT
gss-group1-sha1-* RFC4462 SHOULD NOT gss-group1-sha1-* RFC4462 SHOULD NOT
gss-group14-sha1-* RFC4462 MAY gss-group14-sha1-* RFC4462 MAY
gss-* RFC4462 MAY gss-* RFC4462 MAY
rsa1024-sha1 RFC4432 SHOULD NOT rsa1024-sha1 RFC4432 SHOULD NOT
rsa2048-sha256 RFC4432 MAY rsa2048-sha256 RFC4432 MAY
diffie-hellman-group14-sha256 This Draft MAY diffie-hellman-group14-sha256 This Draft SHOULD
diffie-hellman-group15-sha512 This Draft MAY
diffie-hellman-group16-sha512 This Draft SHOULD diffie-hellman-group16-sha512 This Draft SHOULD
diffie-hellman-group17-sha512 This Draft MAY
diffie-hellman-group18-sha512 This Draft MAY diffie-hellman-group18-sha512 This Draft MAY
curve25519-sha256 ssh-curves MUST curve25519-sha256 ssh-curves MUST
curve448-sha512 ssh-curves MAY curve448-sha512 ssh-curves MAY
Figure 2 Figure 2
The Note in the above table is an implementation suggestion/ The Note column in the above table is an implementation suggestion/
recommendation for the listed key exchange method. It is up to the 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. end-user as to what algorithms they choose to be able to negotiate.
The guidance of his document is that the SHA-1 algorithm hashing 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 SHOULD NOT be used. If it is used, it should only be provided for
backwards compatibility, should not be used in new designs, and backwards compatibility, should not be used in new designs, and
should be phased out of existing key exchanges as quickly as possible should be phased out of existing key exchanges as quickly as possible
because of its known weaknesses. Any key exchange using SHA-1 SHOULD 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 NOT be in a default key exchange list if at all possible. If they
are needed for backward compatibility, they SHOULD be listed after are needed for backward compatibility, they SHOULD be listed after
skipping to change at page 6, line 31 skipping to change at page 7, line 7
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, DOI 10.17487/RFC3526, May 2003, RFC 3526, DOI 10.17487/RFC3526, May 2003,
<http://www.rfc-editor.org/info/rfc3526>. <http://www.rfc-editor.org/info/rfc3526>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>. January 2006, <http://www.rfc-editor.org/info/rfc4253>.
7.2. Informative References 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] [I-D.ietf-curdle-ssh-curves]
Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key Adamantiadis, A. and S. Josefsson, "Secure Shell (SSH) Key
Exchange Method using Curve25519 and Curve448", draft- Exchange Method using Curve25519 and Curve448", draft-
ietf-curdle-ssh-curves-00 (work in progress), March 2016. ietf-curdle-ssh-curves-00 (work in progress), March 2016.
[MFQ-U-OO-815099-15] [MFQ-U-OO-815099-15]
"National Security Agency/Central Security Service", "CNSA "National Security Agency/Central Security Service", "CNSA
Suite and Quantum Computing FAQ", January 2016, Suite and Quantum Computing FAQ", January 2016,
<https://www.iad.gov/iad/library/ia-guidance/ia-solutions- <https://www.iad.gov/iad/library/ia-guidance/ia-solutions-
for-classified/algorithm-guidance/cnsa-suite-and-quantum- for-classified/algorithm-guidance/cnsa-suite-and-quantum-
 End of changes. 15 change blocks. 
18 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/