< draft-ietf-curdle-ssh-kex-sha2-09.txt   draft-ietf-curdle-ssh-kex-sha2-10.txt >
Internet Engineering Task Force M. Baushke Internet Engineering Task Force M. Baushke
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Updates: 4250 (if approved) July 30, 2017 Updates: 4250 (if approved) January 2, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: January 31, 2018 Expires: July 6, 2018
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-09 draft-ietf-curdle-ssh-kex-sha2-10
Abstract Abstract
This document is intended to update the recommended set of key This document is intended to update the recommended set of key
exchange methods for use in the Secure Shell (SSH) protocol to meet exchange methods for use in the Secure Shell (SSH) protocol to meet
evolving needs for stronger security. This document updates RFC evolving needs for stronger security. This document updates RFC
4250. 4250.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 January 31, 2018. This Internet-Draft will expire on July 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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.
Table of Contents Table of Contents
1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3 3. Key Exchange Methods . . . . . . . . . . . . . . . . . . . . 3
3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4 3.1. curve25519-sha256 . . . . . . . . . . . . . . . . . . . . 4
3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4 3.2. curve448-sha512 . . . . . . . . . . . . . . . . . . . . . 4
3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4 3.3. diffie-hellman-group-exchange-sha1 . . . . . . . . . . . 4
3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 4 3.4. diffie-hellman-group-exchange-sha256 . . . . . . . . . . 4
3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4 3.5. diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . 4
3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 4 3.6. diffie-hellman-group14-sha1 . . . . . . . . . . . . . . . 5
3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5 3.7. diffie-hellman-group14-sha256 . . . . . . . . . . . . . . 5
3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 5 3.8. diffie-hellman-group15-sha512 . . . . . . . . . . . . . . 5
3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5 3.9. diffie-hellman-group16-sha512 . . . . . . . . . . . . . . 5
3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 5 3.10. diffie-hellman-group17-sha512 . . . . . . . . . . . . . . 5
3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 5 3.11. diffie-hellman-group18-sha512 . . . . . . . . . . . . . . 6
3.12. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 5 3.12. ecdh-sha2-nistp256 . . . . . . . . . . . . . . . . . . . 6
3.13. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 6 3.13. ecdh-sha2-nistp384 . . . . . . . . . . . . . . . . . . . 6
3.14. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . . . 6 3.14. ecdh-sha2-nistp521 . . . . . . . . . . . . . . . . . . . 6
3.15. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 6 3.15. gss-gex-sha1-* . . . . . . . . . . . . . . . . . . . . . 7
3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 6 3.16. gss-group1-sha1-* . . . . . . . . . . . . . . . . . . . . 7
3.17. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 6 3.17. gss-group14-sha1-* . . . . . . . . . . . . . . . . . . . 7
3.18. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 7 3.18. gss-group14-sha256-* . . . . . . . . . . . . . . . . . . 7
3.19. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 7 3.19. gss-group15-sha512-* . . . . . . . . . . . . . . . . . . 8
3.20. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 7 3.20. gss-group16-sha512-* . . . . . . . . . . . . . . . . . . 8
3.21. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 7 3.21. gss-group17-sha512-* . . . . . . . . . . . . . . . . . . 8
3.22. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 7 3.22. gss-group18-sha512-* . . . . . . . . . . . . . . . . . . 8
3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . . 8 3.23. gss-nistp256-sha256-* . . . . . . . . . . . . . . . . . . 8
3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . . 8 3.24. gss-nistp384-sha384-* . . . . . . . . . . . . . . . . . . 8
3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . . 8 3.25. gss-nistp521-sha512-* . . . . . . . . . . . . . . . . . . 9
3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . . 8 3.26. gss-curve25519-sha256-* . . . . . . . . . . . . . . . . . 9
3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . . 8 3.27. gss-curve448-sha512-* . . . . . . . . . . . . . . . . . . 9
3.28. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 8 3.28. rsa1024-sha1 . . . . . . . . . . . . . . . . . . . . . . 9
3.29. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 8 3.29. rsa2048-sha256 . . . . . . . . . . . . . . . . . . . . . 9
4. Selecting an appropriate hashing algorithm . . . . . . . . . 8 4. Selecting an appropriate hashing algorithm . . . . . . . . . 9
5. Summary Guidance for Key Exchange Method Names . . . . . . . 9 5. Summary Guidance for Key Exchange Method Names . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 two Key Exchange the Internet. In [RFC4253], SSH originally defined two Key Exchange
Method Names that MUST be implemented. Over time, what was once Method Names that MUST be implemented. Over time, what was once
considered secure, is no longer considered secure. The purpose of considered secure, is no longer considered secure. The purpose of
this RFC is to recommend that some published key exchanges be this RFC is to recommend that some published key exchanges be
deprecated as well as recommending some that SHOULD and one that MUST deprecated as well as recommending some that SHOULD and one that MUST
be adopted. This document updates [RFC4250]. be adopted. This document updates [RFC4250].
This document adds recommendations for adoption of Key Exchange This document adds recommendations for adoption of Key Exchange
Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be Methods which MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be
implemented. New key exchange methods will use the SHA-2 family of implemented. New key exchange methods will use the SHA-2 family of
hashes and are drawn from these ssh-curves from hashes found in [RFC6234] and are drawn from these ssh-curves from
[I-D.ietf-curdle-ssh-curves] and new-modp from the [I-D.ietf-curdle-ssh-curves] and DH MODP primes from the [RFC8268]
[I-D.ietf-curdle-ssh-modp-dh-sha2] and gss-keyex and gss-keyex [I-D.ietf-curdle-gss-keyex-sha2].
[I-D.ietf-curdle-gss-keyex-sha2].
[TO BE REMOVED: Please send comments on this draft to
curdle@ietf.org.]
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Key Exchange Methods 3. Key Exchange Methods
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 data key exchange is indicated in SSH. how the use of data key exchange is indicated in SSH.
This RFC also collects Key Exchange Method Names in various existing This RFC also collects Key Exchange Method Names in various existing
RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656], RFCs [RFC4253], [RFC4419], [RFC4432], [RFC4462], [RFC5656],
[I-D.ietf-curdle-ssh-modp-dh-sha2], [I-D.ietf-curdle-gss-keyex-sha2], [RFC8268], [I-D.ietf-curdle-gss-keyex-sha2], and
and [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability [I-D.ietf-curdle-ssh-curves] and provides a suggested suitability for
for implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any implementation of MUST, SHOULD, SHOULD NOT, and MUST NOT. Any method
method not explicitly listed, MAY be implemented. not explicitly listed, MAY be implemented.
This document is intended to provide guidance as to what Key Exchange This document is intended to provide guidance as to what Key Exchange
Algorithms are to be considered for new or updated SSH Algorithms are to be considered for new or updated SSH
implementations. This document will be superseded when one or more implementations. This document will be superseded when one or more
of the listed algorithms are considered too weak to continue to use of the listed algorithms are considered too weak to continue to use
securely, in which case they will likely be downgraded to SHOULD NOT securely, in which case they will likely be downgraded to SHOULD NOT
or MUST NOT. Or, when newer methods have been analyzed and found to or MUST NOT. Or, when newer methods have been analyzed and found to
be secure with wide enough adoption to upgrade their recommendation be secure with wide enough adoption to upgrade their recommendation
from MAY to SHOULD or MUST. from MAY to SHOULD or MUST.
3.1. curve25519-sha256 3.1. curve25519-sha256
The Curve25519 provides strong security and is efficient on a wide The Curve25519 provides strong security and is efficient on a wide
range of architectures with properties that allow better range of architectures with properties that allow better
implementation properties compared to traditional elliptic curves. implementation properties compared to traditional elliptic curves.
The use of SHA2-256 for integrity is a reasonable one for this The use of SHA2-256 (also known as SHA-256) as defined in [RFC6234]
method. This Key Exchange Method has multiple implementations and for integrity is a reasonable one for this method. This Key Exchange
SHOULD be implemented in any SSH interested in using elliptic curve Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to
based key exchanges. the IKEv2 Key Agreement described in [RFC8031]. This Key Exchange
Method has multiple implementations and SHOULD be implemented in any
SSH interested in using elliptic curve based key exchanges.
3.2. curve448-sha512 3.2. curve448-sha512
The Curve448 provides very strong security. It is probably stronger The Curve448 provides very strong security. It uses SHA2-512 (also
and more work than is currently needed. This method MAY be known as SHA-256) defined in [RFC6234] for integrity. It is probably
stronger and more work than is currently needed. This Key Exchange
Method is described in [I-D.ietf-curdle-ssh-curves] and is similar to
the IKEv2 Key Agreement described in [RFC8031]. This method MAY be
implemented. implemented.
3.3. diffie-hellman-group-exchange-sha1 3.3. diffie-hellman-group-exchange-sha1
This set of ephemerally generated key exchange groups uses SHA-1 as This set of ephemerally generated key exchange groups uses SHA-1 as
defined in [RFC4419]. However, SHA-1 has security concerns provided defined in [RFC4419]. However, SHA-1 has security concerns provided
in [RFC6194]. It is recommended that these key exchange groups NOT in [RFC6194], so it would be better to use a key exchange method
be used. This key exchange SHOULD NOT be used. which uses a SHA-2 hash as in [RFC6234] for integrity. This key
exchange SHOULD NOT be used.
3.4. diffie-hellman-group-exchange-sha256 3.4. diffie-hellman-group-exchange-sha256
This set of ephemerally generated key exchange groups uses SHA2-256 This set of ephemerally generated key exchange groups uses SHA2-256
as defined in [RFC4419]. [I-D.ietf-curdle-ssh-dh-group-exchange] as defined in [RFC4419]. [RFC8270] mandates implementations avoid
mandates implementations avoid any MODP group with less than 2048 any MODP group with less than 2048 bits. This key exchange MAY be
bits. This key exchange MAY be used. used.
3.5. diffie-hellman-group1-sha1 3.5. diffie-hellman-group1-sha1
This method uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and This method is decribed in [RFC4253] and uses [RFC7296] Oakley Group
SHA-1 [RFC3174]. Due to recent security concerns with SHA-1 2 (a 1024-bit MODP group) and SHA-1 [RFC3174]. Due to recent
[RFC6194] and with MODP groups with less than 2048 bits (see [LOGJAM] security concerns with SHA-1 [RFC6194] and with MODP groups with less
and [NIST-SP-800-131Ar1]), this method is considered insecure. This than 2048 bits (see [LOGJAM] and [NIST-SP-800-131Ar1]), this method
method is being moved from MUST to SHOULD NOT instead of MUST NOT is considered insecure. This method is being moved from MUST to
only to allow a transition time to get off of it. There are many old SHOULD NOT instead of MUST NOT only to allow a transition time to get
implementations out there that may still need to use this key off of it. There are many old implementations out there that may
exchange, it should be removed from server implementations as quickly still need to use this key exchange, it should be removed from server
as possible. implementations as quickly as possible.
3.6. diffie-hellman-group14-sha1 3.6. diffie-hellman-group14-sha1
This method uses [RFC3526] group14 (a 2048-bit MODP group) which is This method uses [RFC3526] group14 (a 2048-bit MODP group) which is
still a reasonable size. This key exchange group uses SHA-1 which still a reasonable size. This key exchange group uses SHA-1 which
has security concerns [RFC6194]. However, this group is still strong has security concerns [RFC6194]. However, this group is still strong
enough and is widely deployed. This method is being moved from MUST enough and is widely deployed. This method is being moved from MUST
to SHOULD to aid in transition to stronger SHA-2 based hashes. This to SHOULD to aid in transition to stronger SHA-2 based hashes. This
method will transition to SHOULD NOT when SHA-2 alternatives are more method will transition to SHOULD NOT when SHA-2 alternatives are more
generally available. generally available.
3.7. diffie-hellman-group14-sha256 3.7. diffie-hellman-group14-sha256
This key exchange uses the group14 (a 2048-bit MODP group) along with This key exchange method is defined in [RFC8268] and uses the group14
a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field (a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash as in
[RFC6234] for integrity. This represents the smallest Finite Field
Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered
to be secure. It is a reasonably simple transition to move from to be secure. It is a reasonably simple transition to move from
SHA-1 to SHA-2. This method MUST be implemented. SHA-1 to SHA-2. This method MUST be implemented.
3.8. diffie-hellman-group15-sha512 3.8. diffie-hellman-group15-sha512
This key exchange method is defined in [RFC8268] and uses group15
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity.
Note: The use of this 3072-bit MODP group would be equally justified Note: The use of this 3072-bit MODP group would be equally justified
to use SHA2-384 as the hash rather than SHA2-512. However, some to use SHA2-384 as the hash rather than SHA2-512. However, some
small implementations would rather only worry about two rather than small implementations would rather only worry about two rather than
three new hashing functions. This group does not really provide much three new hashing functions. This group does not really provide much
additional head room over the 2048-bit group14 FFC DH and the additional head room over the 2048-bit group14 FFC DH and the
predominate open source implementations are not adopting it. This predominate open source implementations are not adopting it. This
method MAY be implemented. method MAY be implemented.
3.9. diffie-hellman-group16-sha512 3.9. diffie-hellman-group16-sha512
This key exchange method is defined in [RFC8268] and uses group16
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity.
The use of FFC DH is well understood and trusted. Adding larger The use of FFC DH is well understood and trusted. Adding larger
modulus sizes and protecting with SHA2-512 should give enough head modulus sizes and protecting with SHA2-512 should give enough head
room to be ready for the next scare that someone has pre-computed it. room to be ready for the next scare that someone has pre-computed it.
This modulus (4096-bit) is larger than that required by [CNSA-SUITE] This modulus (4096-bit) is larger than that required by [CNSA-SUITE]
and should be sufficient to inter-operate with more paranoid nation- and should be sufficient to inter-operate with more paranoid nation-
states. This method SHOULD be implemented. states. This method SHOULD be implemented.
3.10. diffie-hellman-group17-sha512 3.10. diffie-hellman-group17-sha512
This key exchange method is defined in [RFC8268] and uses group17
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity.
The use of this 6144-bit MODP group is going to be slower than what The use of this 6144-bit MODP group is going to be slower than what
may be desirable. It is provided to help those who wish to avoid may be desirable. It is provided to help those who wish to avoid
using ECC algorithms. This method MAY be implemented. using ECC algorithms. This method MAY be implemented.
3.11. diffie-hellman-group18-sha512 3.11. diffie-hellman-group18-sha512
This key exchange method is defined in [RFC8268] and uses group18
along with a SHA-2 (SHA2-512) hash as in [RFC6234] for integrity.
The use of this 8192-bit MODP group is going to be slower than what The use of this 8192-bit MODP group is going to be slower than what
may be desirable. It is provided to help those who wish to avoid may be desirable. It is provided to help those who wish to avoid
using ECC algorithms. This method MAY be implemented. using ECC algorithms. This method MAY be implemented.
3.12. ecdh-sha2-nistp256 3.12. ecdh-sha2-nistp256
Elliptic Curve Diffie-Hellman (ECDH) are often implemented because This key exchange method is defined in [RFC5656]. Elliptic Curve
they are smaller and faster than using large FFC primes with Diffie-Hellman (ECDH) are often implemented because they are smaller
traditional Diffie-Hellman (DH). However, given [CNSA-SUITE] and and faster than using large FFC primes with traditional Diffie-
Hellman (DH). However, given [CNSA-SUITE] and [safe-curves], this
curve may not be as useful and strong as desired for handling TOP
SECRET information for some applications. The SSH development
community is divided on this and many implementations do exist. If
traditional ECDH key exchange methods are implemented, then this
method SHOULD be implemented.
[safe-curves], this curve may not be as useful and strong as desired It is advisable to match the ECDSA and ECDH algorithms to use the
for handling TOP SECRET information for some applications. The SSH same curve for both.
development community is divided on this and many implementations do
exist. If traditional ECDH key exchange methods are implemented,
then this method SHOULD be implemented. It is advisable to match the
ECDSA and ECDH algorithms to use the same family of curves.
3.13. ecdh-sha2-nistp384 3.13. ecdh-sha2-nistp384
This ECDH method should be implemented because it is smaller and This key exchange method is defined in [RFC5656]. This ECDH method
faster than using large FFC primes with traditional Diffie-Hellman should be implemented because it is smaller and faster than using
(DH). Given [CNSA-SUITE], it is considered good enough for TOP large FFC primes with traditional Diffie-Hellman (DH). Given
SECRET. If traditional ECDH key exchange methods are implemented, [CNSA-SUITE], it is considered good enough for TOP SECRET. If
then this method SHOULD be implemented. traditional ECDH key exchange methods are implemented, then this
method SHOULD be implemented.
Research into ways of breaking ECDSA continues. Papers such as
[ECDSA-Nonce-Leak] as well as concerns raised in [safe-curves] may
mean that this algorithm will need to be downgraded in the future
along the other ECDSA nistp curves.
3.14. ecdh-sha2-nistp521 3.14. ecdh-sha2-nistp521
This ECDH method may be implemented because it is smaller and faster This key exchange method is defined in [RFC5656]. This ECDH method
than using large FFC primes with traditional Diffie-Hellman (DH). It may be implemented because it is smaller and faster than using large
is not listed in [CNSA-SUITE], so it is not currently appropriate for FFC primes with traditional Diffie-Hellman (DH). It is not listed in
TOP SECRET. This method MAY be implemented. [CNSA-SUITE], so it is not currently appropriate for TOP SECRET. It
is possible that the mismatch between the 521-bit key and the 512-bit
hash could mean that as many as nine bits of this key could be at
risk of leaking if appropriate padding measures are not taken. This
method MAY be implemented, but is not recommended.
3.15. gss-gex-sha1-* 3.15. gss-gex-sha1-*
This set of ephemerally generated key exchange groups uses SHA-1 This key exchange method is defined in [RFC4462]. This set of
which has security concerns [RFC6194]. It is recommended that these ephemerally generated key exchange groups uses SHA-1 which has
key exchange groups NOT be used. This key exchange SHOULD NOT be security concerns [RFC6194]. It is recommended that these key
used. It is intended that it move to MUST NOT as soon as the exchange groups NOT be used. This key exchange SHOULD NOT be used.
majority of server implementations no longer offer it. It should be It is intended that it move to MUST NOT as soon as the majority of
removed from server implementations as quickly as possible. server implementations no longer offer it. It should be removed from
server implementations as quickly as possible.
3.16. gss-group1-sha1-* 3.16. gss-group1-sha1-*
This method suffers from the same problems of diffie-hellman- This key exchange method is defined in [RFC4462]. This method
group1-sha1. It uses [RFC7296] Oakley Group 2 (a 1024-bit MODP suffers from the same problems of diffie-hellman-group1-sha1. It
group) and SHA-1 [RFC3174]. Due to recent security concerns with uses [RFC7296] Oakley Group 2 (a 1024-bit MODP group) and SHA-1
SHA-1 [RFC6194] and with MODP groups with less than 2048 bits (see [RFC3174]. Due to recent security concerns with SHA-1 [RFC6194] and
[LOGJAM] and [NIST-SP-800-131Ar1]), this method is considered with MODP groups with less than 2048 bits (see [LOGJAM] and
insecure. This method SHOULD NOT be implemented. It is intended [NIST-SP-800-131Ar1]), this method is considered insecure. This
that it move to MUST NOT as soon as the majority of server method SHOULD NOT be implemented. It is intended that it move to
implementations no longer offer it. It should be removed from server MUST NOT as soon as the majority of server implementations no longer
implementations as quickly as possible. offer it. It should be removed from server implementations as
quickly as possible.
3.17. gss-group14-sha1-* 3.17. gss-group14-sha1-*
This generated key exchange groups uses SHA-1 which has security This key exchange method is defined in [RFC4462]. This generated key
concerns [RFC6194]. If GSS-API key exchange methods are being used, exchange groups uses SHA-1 which has security concerns [RFC6194]. If
then this one SHOULD be implemented until such time as SHA-2 variants GSS-API key exchange methods are being used, then this one SHOULD be
may be implemented and deployed. This method will transition to implemented until such time as SHA-2 variants may be implemented and
SHOULD NOT when SHA-2 alternatives are more generally available. No deployed. This method will transition to SHOULD NOT when SHA-2
other standard indicated that this method was anything other than alternatives are more generally available. No other standard
optional even though it was implemented in all GSS-API systems. This indicated that this method was anything other than optional even
method MAY be implemented. though it was implemented in all GSS-API systems. This method MAY be
implemented.
3.18. gss-group14-sha256-* 3.18. gss-group14-sha256-*
This key exchange uses the group14 (a 2048-bit MODP group) along with This key exchange method is defined in
a SHA-2 (SHA2-256) hash. This represents the smallest Finite Field [I-D.ietf-curdle-gss-keyex-sha2]. This key exchange uses the group14
Cryptography (FFC) Diffie-Hellman (DH) key exchange method considered (a 2048-bit MODP group) along with a SHA-2 (SHA2-256) hash. This
to be secure. It is a reasonably simple transition to move from represents the smallest Finite Field Cryptography (FFC) Diffie-
SHA-1 to SHA-2. If the GSS-API is to be used, then this method Hellman (DH) key exchange method considered to be secure. It is a
SHOULD be implemented. reasonably simple transition to move from SHA-1 to SHA-2. If the
GSS-API is to be used, then this method SHOULD be implemented.
3.19. gss-group15-sha512-* 3.19. gss-group15-sha512-*
The use of this 3072-bit MODP group does not really provide much This key exchange method is defined in
additional head room over the 2048-bit group14 FFC DH. If the GSS- [I-D.ietf-curdle-gss-keyex-sha2]. The use of this 3072-bit MODP
API is to be used, then this method MAY be implemented. group does not really provide much additional head room over the
2048-bit group14 FFC DH. If the GSS-API is to be used, then this
method MAY be implemented.
3.20. gss-group16-sha512-* 3.20. gss-group16-sha512-*
The use of FFC DH is well understood and trusted. Adding larger This key exchange method is defined in
modulus sizes and protecting with SHA2-512 should give enough head [I-D.ietf-curdle-gss-keyex-sha2]. The use of FFC DH is well
room to be ready for the next scare that someone has pre-computed. understood and trusted. Adding larger modulus sizes and protecting
This modulus (4096-bit) is larger than that required by [CNSA-SUITE] with SHA2-512 should give enough head room to be ready for the next
and should be sufficient to inter-operate with more paranoid nation- scare that someone has pre-computed. This modulus (4096-bit) is
states. If the GSS-API is to be used, then this method SHOULD be larger than that required by [CNSA-SUITE] and should be sufficient to
implemented. inter-operate with more paranoid nation-states. If the GSS-API is to
be used, then this method SHOULD be implemented.
3.21. gss-group17-sha512-* 3.21. gss-group17-sha512-*
The use of this 6144-bit MODP group is going to be slower than what This key exchange method is defined in
may be desirable. It is provided to help those who wish to avoid [I-D.ietf-curdle-gss-keyex-sha2]. The use of this 6144-bit MODP
using ECC algorithms. If the GSS-API is to be used, then this method group is going to be slower than what may be desirable. It is
MAY be implemented. provided to help those who wish to avoid using ECC algorithms. If
the GSS-API is to be used, then this method MAY be implemented.
3.22. gss-group18-sha512-* 3.22. gss-group18-sha512-*
The use of this 8192-bit MODP group is going to be slower than what This key exchange method is defined in
may be desirable. It is provided to help those who prefer to avoid [I-D.ietf-curdle-gss-keyex-sha2]. The use of this 8192-bit MODP
using ECC algorithms. If the GSS-API is to be used, then this method group is going to be slower than what may be desirable. It is
MAY be implemented. provided to help those who prefer to avoid using ECC algorithms. If
the GSS-API is to be used, then this method MAY be implemented.
3.23. gss-nistp256-sha256-* 3.23. gss-nistp256-sha256-*
If the GSS-API is to be used with ECC algorithms, then this method This key exchange method is defined in
SHOULD be implemented. [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with
ECC algorithms, then this method SHOULD be implemented.
3.24. gss-nistp384-sha384-* 3.24. gss-nistp384-sha384-*
If the GSS-API is to be used with ECC algorithms, then this method This key exchange method is defined in
SHOULD be implemented to permit TOP SECRET information to be [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with
communicated. ECC algorithms, then this method SHOULD be implemented to permit TOP
SECRET information to be communicated.
3.25. gss-nistp521-sha512-* 3.25. gss-nistp521-sha512-*
If the GSS-API is to be used with ECC algorithms, then this method This key exchange method is defined in
MAY be implemented. [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with
ECC algorithms, then this method MAY be implemented.
3.26. gss-curve25519-sha256-* 3.26. gss-curve25519-sha256-*
If the GSS-API is to be used with ECC algorithms, then this method This key exchange method is defined in
SHOULD be implemented. [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with
ECC algorithms, then this method SHOULD be implemented.
3.27. gss-curve448-sha512-* 3.27. gss-curve448-sha512-*
If the GSS-API is to be used with ECC algorithms, then this method This key exchange method is defined in
MAY be implemented. [I-D.ietf-curdle-gss-keyex-sha2]. If the GSS-API is to be used with
ECC algorithms, then this method MAY be implemented.
3.28. rsa1024-sha1 3.28. rsa1024-sha1
The security of RSA 1024-bit modulus keys is not good enough any This key exchange method is defined in [RFC4432]. The security of
longer. A key size should be 2048-bits. This generated key exchange RSA 1024-bit modulus keys is not good enough any longer. A key size
groups uses SHA-1 which has security concerns [RFC6194]. This method should be 2048-bits. This generated key exchange groups uses SHA-1
MUST NOT be implemented. which has security concerns [RFC6194]. This method MUST NOT be
implemented.
3.29. rsa2048-sha256 3.29. rsa2048-sha256
An RSA 2048-bit modulus key with a SHA2-256 hash. This method MAY be This key exchange method is defined in [RFC4432]. An RSA 2048-bit
modulus key with a SHA2-256 hash. At the present time, a 2048-bit
RSA key is considered to be suffiently strong in [NIST-SP-800-131Ar1]
to be permitted. In addition, the use of a SHA-2 hash as defined in
[RFC6234] is a good integrity measure. This method MAY be
implemented. implemented.
4. Selecting an appropriate hashing algorithm 4. Selecting an appropriate hashing algorithm
As may be seen from the above, the Key Exchange Methods area all As may be seen from the above, the Key Exchange Methods area all
using either SHA256 or SHA512 with the exception of the ecdh- using either SHA256 or SHA512 with the exception of the ecdh-
sha2-nistp384 which uses SHA384. sha2-nistp384 which uses SHA384.
The cited CNSA Suite specifies the use of SHA384 and says that SHA256 The cited CNSA Suite specifies the use of SHA384 and says that SHA256
is no longer good enough for TOP SECRET. Nothing is said about the is no longer good enough for TOP SECRET. Nothing is said about the
use of SHA512. It may be that the internal state of 1024 bits in use of SHA512. It may be that the internal state of 1024 bits in
both SHA384 and SHA512 makes the SHA384 more secure because it does both SHA384 and SHA512 makes the SHA384 more secure because it does
not leak an additional 128 bits of state. Of course, use of SHA384 not leak an additional 128 bits of state. Of course, the use of
also reduces the security strength to 192 bits instead of being 256 SHA384 also reduces the security strength to 384 bits instead of
bits or more. This seems to contradict the desire to double the being 512 bits. This seems to contradict the desire to double the
symmetric key strength in order to try to be safe from Post Quantum symmetric key strength in order to try to be safe from Post Quantum
Computing (PQC) attacks given a session key derived from the key Computing (PQC) attacks given a session key derived from the key
exchange will be limited to the security strength of the hash being exchange will be limited to the security strength of the hash being
used. used.
The move away from SHA256 to SHA512 for the newer key exchange The move away from SHA256 to SHA512 for the newer key exchange
methods is more to try to slow Grover's algorithm (a PQC attack) methods is more to try to slow Grover's algorithm (a PQC attack)
slightly. It is also the case that SHA2-512 may, in many modern slightly. It is also the case that SHA2-512 may, in many modern
CPUs, be implemented more efficiently using 64-bit arithmetic than CPUs, be implemented more efficiently using 64-bit arithmetic than
SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs SHA256 which is faster on 32-bit CPUs. The selection of SHA384 vs
skipping to change at page 9, line 32 skipping to change at page 10, line 29
The Implement column is the current recommendations of this RFC. Key The Implement column is the current recommendations of this RFC. Key
Exchange Method Names are listed alphabetically. Exchange Method Names are listed alphabetically.
Key Exchange Method Name Reference Implement Key Exchange Method Name Reference Implement
---------------------------------- ---------- ---------- ---------------------------------- ---------- ----------
curve25519-sha256 ssh-curves SHOULD curve25519-sha256 ssh-curves SHOULD
diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT
diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group1-sha1 RFC4253 SHOULD NOT
diffie-hellman-group14-sha1 RFC4253 SHOULD diffie-hellman-group14-sha1 RFC4253 SHOULD
diffie-hellman-group14-sha256 new-modp MUST diffie-hellman-group14-sha256 RFC8268 MUST
diffie-hellman-group16-sha512 new-modp SHOULD diffie-hellman-group16-sha512 RFC8268 SHOULD
ecdh-sha2-nistp256 RFC5656 SHOULD ecdh-sha2-nistp256 RFC5656 SHOULD
ecdh-sha2-nistp384 RFC5656 SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD
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-sha256-* gss-keyex SHOULD gss-group14-sha256-* gss-keyex SHOULD
gss-group16-sha512-* gss-keyex SHOULD gss-group16-sha512-* gss-keyex SHOULD
gss-nistp256-sha256-* gss-keyex SHOULD gss-nistp256-sha256-* gss-keyex SHOULD
gss-nistp384-sha384-* gss-keyex SHOULD gss-nistp384-sha384-* gss-keyex SHOULD
gss-curve25519-sha256-* gss-keyex SHOULD gss-curve25519-sha256-* gss-keyex SHOULD
rsa1024-sha1 RFC4432 MUST NOT rsa1024-sha1 RFC4432 MUST NOT
skipping to change at page 12, line 17 skipping to change at page 13, line 12
IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be IANA is requested to annotate entries in [IANA-KEX] which MUST NOT be
implemented as being deprecated by this document. implemented as being deprecated by this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
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>. <https://www.rfc-editor.org/info/rfc3526>.
[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, Protocol Assigned Numbers", RFC 4250,
DOI 10.17487/RFC4250, January 2006, DOI 10.17487/RFC4250, January 2006,
<http://www.rfc-editor.org/info/rfc4250>. <https://www.rfc-editor.org/info/rfc4250>.
[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, <https://www.rfc-editor.org/info/rfc4253>.
[RFC8031] Nir, Y. and S. Josefsson, "Curve25519 and Curve448 for the
Internet Key Exchange Protocol Version 2 (IKEv2) Key
Agreement", RFC 8031, DOI 10.17487/RFC8031, December 2016,
<https://www.rfc-editor.org/info/rfc8031>.
[RFC8268] Baushke, M., "More Modular Exponentiation (MODP) Diffie-
Hellman (DH) Key Exchange (KEX) Groups for Secure Shell
(SSH)", RFC 8268, DOI 10.17487/RFC8268, December 2017,
<https://www.rfc-editor.org/info/rfc8268>.
[RFC8270] Velvindron, L. and M. Baushke, "Increase the Secure Shell
Minimum Recommended Diffie-Hellman Modulus Size to 2048
Bits", RFC 8270, DOI 10.17487/RFC8270, December 2017,
<https://www.rfc-editor.org/info/rfc8270>.
9.2. Informative References 9.2. Informative References
[CNSA-SUITE] [CNSA-SUITE]
"Information Assurance by the National Security Agency", "Information Assurance by the National Security Agency",
"Commercial National Security Algorithm Suite", September "Commercial National Security Algorithm Suite", September
2016, <https://www.iad.gov/iad/programs/iad-initiatives/ 2016, <https://www.iad.gov/iad/programs/iad-initiatives/
cnsa-suite.cfm>. cnsa-suite.cfm>.
[ECDSA-Nonce-Leak]
De Mulder, Hutter, Marson, and Pearson, "Using
Bleichenbacher's Solution to the Hidden Number Problem to
Attack Nonce Leaks in 384-Bit ECDSA", IACR Cryptology
ePrint Archive 2013, August 2013,
<https://eprint.iacr.org/2013/346.pdf>.
[I-D.ietf-curdle-gss-keyex-sha2] [I-D.ietf-curdle-gss-keyex-sha2]
Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2", Sorce, S. and H. Kario, "GSS-API Key Exchange with SHA2",
draft-ietf-curdle-gss-keyex-sha2-02 (work in progress), draft-ietf-curdle-gss-keyex-sha2-03 (work in progress),
June 2017. December 2017.
[I-D.ietf-curdle-ssh-curves] [I-D.ietf-curdle-ssh-curves]
Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
Shell (SSH) Key Exchange Method using Curve25519 and Shell (SSH) Key Exchange Method using Curve25519 and
Curve448", draft-ietf-curdle-ssh-curves-05 (work in Curve448", draft-ietf-curdle-ssh-curves-06 (work in
progress), May 2017. progress), November 2017.
[I-D.ietf-curdle-ssh-dh-group-exchange]
Velvindron, L. and M. Baushke, "Increase SSH minimum
recommended DH modulus size to 2048 bits", draft-ietf-
curdle-ssh-dh-group-exchange-05 (work in progress), July
2017.
[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-07 (work in
progress), June 2017.
[IANA-KEX] [IANA-KEX]
Internet Assigned Numbers Authority (IANA), "Secure Shell Internet Assigned Numbers Authority (IANA), "Secure Shell
(SSH) Protocol Parameters: Key Exchange Method Names", (SSH) Protocol Parameters: Key Exchange Method Names",
March 2017, <http://www.iana.org/assignments/ssh- January 2018, <http://www.iana.org/assignments/ssh-
parameters/ssh-parameters.xhtml#ssh-parameters-16>. parameters/ssh-parameters.xhtml#ssh-parameters-16>.
[LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., [LOGJAM] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
Green, M., Halderman, J., Heninger, N., Springall, D., Green, M., Halderman, J., Heninger, N., Springall, D.,
Thome, E., Valenta, L., VanderSloot, B., Wustrow, E., Thome, E., Valenta, L., VanderSloot, B., Wustrow, E.,
Zanella-Beguelin, S., and P. Zimmermann, "Imperfect Zanella-Beguelin, S., and P. Zimmermann, "Imperfect
Forward Secrecy: How Diffie-Hellman Fails in Practice", Forward Secrecy: How Diffie-Hellman Fails in Practice",
ACM Conference on Computer and Communications Security ACM Conference on Computer and Communications Security
(CCS) 2015, 2015, <https://weakdh.org/imperfect-forward- (CCS) 2015, 2015,
secrecy-ccs15.pdf>. <https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf>.
[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/
for-classified/algorithm-guidance/cnsa-suite-and-quantum- ia-solutions-for-classified/algorithm-guidance/
computing-faq.cfm>. cnsa-suite-and-quantum-computing-faq.cfm>.
[NIST-SP-800-131Ar1] [NIST-SP-800-131Ar1]
Barker and Roginsky, "Transitions: Recommendation for the Barker and Roginsky, "Transitions: Recommendation for the
Transitioning of the Use of Cryptographic Algorithms and Transitioning of the Use of Cryptographic Algorithms and
Key Lengths", NIST Special Publication 800-131A Revision Key Lengths", NIST Special Publication 800-131A Revision
1, November 2015, 1, November 2015,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-131Ar1.pdf>. NIST.SP.800-131Ar1.pdf>.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<http://www.rfc-editor.org/info/rfc3174>. <https://www.rfc-editor.org/info/rfc3174>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <http://www.rfc-editor.org/info/rfc4251>. January 2006, <https://www.rfc-editor.org/info/rfc4251>.
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman [RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman
Group Exchange for the Secure Shell (SSH) Transport Layer Group Exchange for the Secure Shell (SSH) Transport Layer
Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006,
<http://www.rfc-editor.org/info/rfc4419>. <https://www.rfc-editor.org/info/rfc4419>.
[RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH) [RFC4432] Harris, B., "RSA Key Exchange for the Secure Shell (SSH)
Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432, Transport Layer Protocol", RFC 4432, DOI 10.17487/RFC4432,
March 2006, <http://www.rfc-editor.org/info/rfc4432>. March 2006, <https://www.rfc-editor.org/info/rfc4432>.
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, [RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch,
"Generic Security Service Application Program Interface "Generic Security Service Application Program Interface
(GSS-API) Authentication and Key Exchange for the Secure (GSS-API) Authentication and Key Exchange for the Secure
Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May
2006, <http://www.rfc-editor.org/info/rfc4462>. 2006, <https://www.rfc-editor.org/info/rfc4462>.
[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
Integration in the Secure Shell Transport Layer", Integration in the Secure Shell Transport Layer",
RFC 5656, DOI 10.17487/RFC5656, December 2009, RFC 5656, DOI 10.17487/RFC5656, December 2009,
<http://www.rfc-editor.org/info/rfc5656>. <https://www.rfc-editor.org/info/rfc5656>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <http://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[safe-curves] [safe-curves]
Bernstein and Lange, "SafeCurves: choosing safe curves for Bernstein and Lange, "SafeCurves: choosing safe curves for
elliptic-curve cryptography.", February 2016, elliptic-curve cryptography.", February 2016,
<https://safecurves.cr.yp.to/>. <https://safecurves.cr.yp.to/>.
Author's Address Author's Address
Mark D. Baushke Mark D. Baushke
Juniper Networks, Inc. Juniper Networks, Inc.
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089-1228 Sunnyvale, CA 94089-1228
US US
Email: mdb@juniper.net Email: mdb@juniper.net
URI: http://www.juniper.net/ URI: http://www.juniper.net/
 End of changes. 65 change blocks. 
183 lines changed or deleted 241 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/