summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8732.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8732.txt')
-rw-r--r--doc/rfc/rfc8732.txt620
1 files changed, 620 insertions, 0 deletions
diff --git a/doc/rfc/rfc8732.txt b/doc/rfc/rfc8732.txt
new file mode 100644
index 0000000..49cf6a6
--- /dev/null
+++ b/doc/rfc/rfc8732.txt
@@ -0,0 +1,620 @@
+
+
+
+
+Internet Engineering Task Force (IETF) S. Sorce
+Request for Comments: 8732 H. Kario
+Updates: 4462 Red Hat, Inc.
+Category: Standards Track February 2020
+ISSN: 2070-1721
+
+
+ Generic Security Service Application Program Interface (GSS-API) Key
+ Exchange with SHA-2
+
+Abstract
+
+ This document specifies additions and amendments to RFC 4462. It
+ defines a new key exchange method that uses SHA-2 for integrity and
+ deprecates weak Diffie-Hellman (DH) groups. The purpose of this
+ specification is to modernize the cryptographic primitives used by
+ Generic Security Service (GSS) key exchanges.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8732.
+
+Copyright Notice
+
+ Copyright (c) 2020 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://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. Introduction
+ 2. Rationale
+ 3. Document Conventions
+ 4. New Diffie-Hellman Key Exchange Methods
+ 5. New Elliptic Curve Diffie-Hellman Key Exchange Methods
+ 5.1. Generic GSS-API Key Exchange with ECDH
+ 5.2. ECDH Key Exchange Methods
+ 6. Deprecated Algorithms
+ 7. IANA Considerations
+ 8. Security Considerations
+ 8.1. New Finite Field DH Mechanisms
+ 8.2. New Elliptic Curve DH Mechanisms
+ 8.3. GSS-API Delegation
+ 9. References
+ 9.1. Normative References
+ 9.2. Informative References
+ Authors' Addresses
+
+1. Introduction
+
+ Secure Shell (SSH) Generic Security Service Application Program
+ Interface (GSS-API) methods [RFC4462] allow the use of GSS-API
+ [RFC2743] for authentication and key exchange in SSH. [RFC4462]
+ defines three exchange methods all based on DH groups and SHA-1.
+ This document updates [RFC4462] with new methods intended to support
+ environments that desire to use the SHA-2 cryptographic hash
+ functions.
+
+2. Rationale
+
+ Due to security concerns with SHA-1 [RFC6194] and with modular
+ exponentiation (MODP) groups with less than 2048 bits
+ [NIST-SP-800-131Ar2], we propose the use of hashes based on SHA-2
+ [RFC6234] with DH group14, group15, group16, group17, and group18
+ [RFC3526]. Additionally, we add support for key exchange based on
+ Elliptic Curve Diffie-Hellman with the NIST P-256, P-384, and P-521
+ [SEC2v2], as well as the X25519 and X448 [RFC7748] curves. Following
+ the practice of [RFC8268], only SHA-256 and SHA-512 hashes are used
+ for DH groups. For NIST curves, the same curve-to-hashing algorithm
+ pairing used in [RFC5656] is adopted for consistency.
+
+3. Document Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+4. New Diffie-Hellman Key Exchange Methods
+
+ This document adopts the same naming convention defined in [RFC4462]
+ to define families of methods that cover any GSS-API mechanism used
+ with a specific Diffie-Hellman group and SHA-2 hash combination.
+
+ +--------------------------+--------------------------------+
+ | Key Exchange Method Name | Implementation Recommendations |
+ +==========================+================================+
+ | 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 |
+ +--------------------------+--------------------------------+
+
+ Table 1: New Key Exchange Algorithms
+
+ Each key exchange method prefix is registered by this document. The
+ IESG is the change controller of all these key exchange methods; this
+ does NOT imply that the IESG is considered to be in control of the
+ corresponding GSS-API mechanism.
+
+ Each method in any family of methods (Table 2) specifies GSS-API-
+ authenticated Diffie-Hellman key exchanges as described in
+ Section 2.1 of [RFC4462]. The method name for each method (Table 1)
+ is the concatenation of the family name prefix with the base64
+ encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding
+ [ISO-IEC-8825-1] of the corresponding GSS-API mechanism's OID.
+ Base64 encoding is described in Section 4 of [RFC4648].
+
+ +---------------------+---------------+----------+--------------+
+ | Family Name Prefix | Hash Function | Group | Reference |
+ +=====================+===============+==========+==============+
+ | gss-group14-sha256- | SHA-256 | 2048-bit | Section 3 of |
+ | | | MODP | [RFC3526] |
+ +---------------------+---------------+----------+--------------+
+ | gss-group15-sha512- | SHA-512 | 3072-bit | Section 4 of |
+ | | | MODP | [RFC3526] |
+ +---------------------+---------------+----------+--------------+
+ | gss-group16-sha512- | SHA-512 | 4096-bit | Section 5 of |
+ | | | MODP | [RFC3526] |
+ +---------------------+---------------+----------+--------------+
+ | gss-group17-sha512- | SHA-512 | 6144-bit | Section 6 of |
+ | | | MODP | [RFC3526] |
+ +---------------------+---------------+----------+--------------+
+ | gss-group18-sha512- | SHA-512 | 8192-bit | Section 7 of |
+ | | | MODP | [RFC3526] |
+ +---------------------+---------------+----------+--------------+
+
+ Table 2: Family Method References
+
+5. New Elliptic Curve Diffie-Hellman Key Exchange Methods
+
+ In [RFC5656], new SSH key exchange algorithms based on elliptic curve
+ cryptography are introduced. We reuse much of Section 4 of [RFC5656]
+ to define GSS-API-authenticated Elliptic Curve Diffie-Hellman (ECDH)
+ key exchanges.
+
+ Additionally, we also utilize the curves defined in [RFC8731] to
+ complement the three classic NIST-defined curves required by
+ [RFC5656].
+
+5.1. Generic GSS-API Key Exchange with ECDH
+
+ This section reuses much of the scheme defined in Section 2.1 of
+ [RFC4462] and combines it with the scheme defined in Section 4 of
+ [RFC5656]; in particular, all checks and verification steps
+ prescribed in Section 4 of [RFC5656] apply here as well.
+
+ The key-agreement schemes "ECDHE-Curve25519" and "ECDHE-Curve448"
+ perform the Diffie-Hellman protocol using the functions X25519 and
+ X448, respectively. Implementations MUST compute these functions
+ using the algorithms described in [RFC7748]. When they do so,
+ implementations MUST check whether the computed Diffie-Hellman shared
+ secret is the all-zero value and abort if so, as described in
+ Section 6 of [RFC7748]. Alternative implementations of these
+ functions SHOULD abort when either the client or the server input
+ forces the shared secret to one of a small set of values, as
+ described in Sections 6 and 7 of [RFC7748].
+
+ This section defers to [RFC7546] as the source of information on GSS-
+ API context establishment operations, Section 3 being the most
+ relevant. All security considerations described in [RFC7546] apply
+ here, too.
+
+ The parties each generate an ephemeral key pair, according to
+ Section 3.2.1 of [SEC1v2]. Keys are verified upon receipt by the
+ parties according to Section 3.2.3.1 of [SEC1v2].
+
+ For NIST curves, the keys use the uncompressed point representation
+ and MUST be converted using the algorithm in Section 2.3.4 of
+ [SEC1v2]. If the conversion fails or the point is transmitted using
+ the compressed representation, the key exchange MUST fail.
+
+ A GSS context is established according to Section 4 of [RFC5656]; the
+ client initiates the establishment using GSS_Init_sec_context(), and
+ the server responds to it using GSS_Accept_sec_context(). For the
+ negotiation, the client MUST set mutual_req_flag and integ_req_flag
+ to "true". In addition, deleg_req_flag MAY be set to "true" to
+ request access delegation, if requested by the user. Since the key
+ exchange process authenticates only the host, the setting of
+ anon_req_flag is immaterial to this process. If the client does not
+ support the "gssapi-keyex" user authentication method described in
+ Section 4 of [RFC4462], or does not intend to use that method in
+ conjunction with the GSS-API context established during key exchange,
+ then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY
+ be set to "true" if the client wishes to hide its identity. This key
+ exchange process will exchange only a single message token once the
+ context has been established; therefore, the replay_det_req_flag and
+ sequence_req_flag SHOULD be set to "false".
+
+ The client MUST include its public key with the first message it
+ sends to the server during this process; if the server receives more
+ than one key or none at all, the key exchange MUST fail.
+
+ During GSS context establishment, multiple tokens may be exchanged by
+ the client and the server. When the GSS context is established
+ (major_status is GSS_S_COMPLETE), the parties check that mutual_state
+ and integ_avail are both "true". If not, the key exchange MUST fail.
+
+ Once a party receives the peer's public key, it proceeds to compute a
+ shared secret K. For NIST curves, the computation is done according
+ to Section 3.3.1 of [SEC1v2], and the resulting value z is converted
+ to the octet string K using the conversion defined in Section 2.3.5
+ of [SEC1v2]. For curve25519 and curve448, the algorithms in
+ Section 6 of [RFC7748] are used instead.
+
+ To verify the integrity of the handshake, peers use the hash function
+ defined by the selected key exchange method to calculate H:
+
+ H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).
+
+ The server uses the GSS_GetMIC() call with H as the payload to
+ generate a Message Integrity Code (MIC). The GSS_VerifyMIC() call is
+ used by the client to verify the MIC.
+
+ If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns a
+ major_status other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, or
+ any other GSS-API call returns a major_status other than
+ GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations
+ expressed in Section 2.1 of [RFC4462] are followed with regard to
+ error reporting.
+
+ The following is an overview of the key exchange process:
+
+ Client Server
+ ------ ------
+ Generates ephemeral key pair.
+ Calls GSS_Init_sec_context().
+ SSH_MSG_KEXGSS_INIT --------------->
+
+ Verifies received key.
+ (Optional) <------------- SSH_MSG_KEXGSS_HOSTKEY
+
+ (Loop)
+ | Calls GSS_Accept_sec_context().
+ | <------------ SSH_MSG_KEXGSS_CONTINUE
+ | Calls GSS_Init_sec_context().
+ | SSH_MSG_KEXGSS_CONTINUE ------------>
+
+ Calls GSS_Accept_sec_context().
+ Generates ephemeral key pair.
+ Computes shared secret.
+ Computes hash H.
+ Calls GSS_GetMIC( H ) = MIC.
+ <------------ SSH_MSG_KEXGSS_COMPLETE
+
+ Verifies received key.
+ Computes shared secret.
+ Computes hash H.
+ Calls GSS_VerifyMIC( MIC, H ).
+
+ This is implemented with the following messages:
+
+ The client sends:
+
+ byte SSH_MSG_KEXGSS_INIT
+ string output_token (from GSS_Init_sec_context())
+ string Q_C, client's ephemeral public key octet string
+
+ The server may respond with:
+
+ byte SSH_MSG_KEXGSS_HOSTKEY
+ string server public host key and certificates (K_S)
+
+ The server sends:
+
+ byte SSH_MSG_KEXGSS_CONTINUE
+ string output_token (from GSS_Accept_sec_context())
+
+ Each time the client receives the message described above, it makes
+ another call to GSS_Init_sec_context().
+
+ The client sends:
+
+ byte SSH_MSG_KEXGSS_CONTINUE
+ string output_token (from GSS_Init_sec_context())
+
+ As the final message, the server sends the following if an
+ output_token is produced:
+
+ byte SSH_MSG_KEXGSS_COMPLETE
+ string Q_S, server's ephemeral public key octet string
+ string mic_token (MIC of H)
+ boolean TRUE
+ string output_token (from GSS_Accept_sec_context())
+
+ If no output_token is produced, the server sends:
+
+ byte SSH_MSG_KEXGSS_COMPLETE
+ string Q_S, server's ephemeral public key octet string
+ string mic_token (MIC of H)
+ boolean FALSE
+
+ The hash H is computed as the HASH hash of the concatenation of the
+ following:
+
+ string V_C, the client's version string (CR, NL excluded)
+ string V_S, server's version string (CR, NL excluded)
+ string I_C, payload of the client's SSH_MSG_KEXINIT
+ string I_S, payload of the server's SSH_MSG_KEXINIT
+ string K_S, server's public host key
+ string Q_C, client's ephemeral public key octet string
+ string Q_S, server's ephemeral public key octet string
+ mpint K, shared secret
+
+ This value is called the "exchange hash", and it is used to
+ authenticate the key exchange. The exchange hash SHOULD be kept
+ secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the
+ server or received by the client, then the empty string is used in
+ place of K_S when computing the exchange hash.
+
+ Since this key exchange method does not require the host key to be
+ used for any encryption operations, the SSH_MSG_KEXGSS_HOSTKEY
+ message is OPTIONAL. If the "null" host key algorithm described in
+ Section 5 of [RFC4462] is used, this message MUST NOT be sent.
+
+ If the client receives an SSH_MSG_KEXGSS_CONTINUE message after a
+ call to GSS_Init_sec_context() has returned a major_status code of
+ GSS_S_COMPLETE, a protocol error has occurred, and the key exchange
+ MUST fail.
+
+ If the client receives an SSH_MSG_KEXGSS_COMPLETE message and a call
+ to GSS_Init_sec_context() does not result in a major_status code of
+ GSS_S_COMPLETE, a protocol error has occurred, and the key exchange
+ MUST fail.
+
+5.2. ECDH Key Exchange Methods
+
+ +--------------------------+--------------------------------+
+ | Key Exchange Method Name | Implementation Recommendations |
+ +==========================+================================+
+ | gss-nistp256-sha256-* | SHOULD/RECOMMENDED |
+ +--------------------------+--------------------------------+
+ | gss-nistp384-sha384-* | MAY/OPTIONAL |
+ +--------------------------+--------------------------------+
+ | gss-nistp521-sha512-* | MAY/OPTIONAL |
+ +--------------------------+--------------------------------+
+ | gss-curve25519-sha256-* | SHOULD/RECOMMENDED |
+ +--------------------------+--------------------------------+
+ | gss-curve448-sha512-* | MAY/OPTIONAL |
+ +--------------------------+--------------------------------+
+
+ Table 3: New Key Exchange Methods
+
+ Each key exchange method prefix is registered by this document. The
+ IESG is the change controller of all these key exchange methods; this
+ does NOT imply that the IESG is considered to be in control of the
+ corresponding GSS-API mechanism.
+
+ Each method in any family of methods (Table 4) specifies GSS-API-
+ authenticated Elliptic Curve Diffie-Hellman key exchanges as
+ described in Section 5.1. The method name for each method (Table 3)
+ is the concatenation of the family method name with the base64
+ encoding of the MD5 hash [RFC1321] of the ASN.1 DER encoding
+ [ISO-IEC-8825-1] of the corresponding GSS-API mechanism's OID.
+ Base64 encoding is described in Section 4 of [RFC4648].
+
+ +------------------------+----------+---------------+---------------+
+ | Family Name Prefix | Hash | Parameters / | Definition |
+ | | Function | Function Name | |
+ +========================+==========+===============+===============+
+ | gss-nistp256-sha256- | SHA-256 | secp256r1 | Section |
+ | | | | 2.4.2 of |
+ | | | | [SEC2v2] |
+ +------------------------+----------+---------------+---------------+
+ | gss-nistp384-sha384- | SHA-384 | secp384r1 | Section |
+ | | | | 2.5.1 of |
+ | | | | [SEC2v2] |
+ +------------------------+----------+---------------+---------------+
+ | gss-nistp521-sha512- | SHA-512 | secp521r1 | Section |
+ | | | | 2.6.1 of |
+ | | | | [SEC2v2] |
+ +------------------------+----------+---------------+---------------+
+ | gss-curve25519-sha256- | SHA-256 | X22519 | Section 5 |
+ | | | | of |
+ | | | | [RFC7748] |
+ +------------------------+----------+---------------+---------------+
+ | gss-curve448-sha512- | SHA-512 | X448 | Section 5 |
+ | | | | of |
+ | | | | [RFC7748] |
+ +------------------------+----------+---------------+---------------+
+
+ Table 4: Family Method References
+
+6. Deprecated Algorithms
+
+ Because they have small key lengths and are no longer strong in the
+ face of brute-force attacks, the algorithms in the following table
+ are considered deprecated and SHOULD NOT be used.
+
+ +--------------------------+--------------------------------+
+ | Key Exchange Method Name | Implementation Recommendations |
+ +==========================+================================+
+ | gss-group1-sha1-* | SHOULD NOT |
+ +--------------------------+--------------------------------+
+ | gss-group14-sha1-* | SHOULD NOT |
+ +--------------------------+--------------------------------+
+ | gss-gex-sha1-* | SHOULD NOT |
+ +--------------------------+--------------------------------+
+
+ Table 5: Deprecated Algorithms
+
+7. IANA Considerations
+
+ This document augments the SSH key exchange message names that were
+ defined in [RFC4462] (see and Section 6); IANA has listed this
+ document as reference for those entries in the "SSH Protocol
+ Parameters" [IANA-KEX-NAMES] registry.
+
+ In addition, IANA has updated the registry to include the SSH key
+ exchange message names described in Sections 4 and 5.
+
+ +--------------------------+-----------+
+ | Key Exchange Method Name | Reference |
+ +==========================+===========+
+ | gss-group1-sha1-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-group14-sha1-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-gex-sha1-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-group14-sha256-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-group15-sha512-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-group16-sha512-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-group17-sha512-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-group18-sha512-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-nistp256-sha256-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-nistp384-sha384-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-nistp521-sha512-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-curve25519-sha256-* | RFC 8732 |
+ +--------------------------+-----------+
+ | gss-curve448-sha512-* | RFC 8732 |
+ +--------------------------+-----------+
+
+ Table 6: Additions/Changes to the
+ Key Exchange Method Names Registry
+
+8. Security Considerations
+
+8.1. New Finite Field DH Mechanisms
+
+ Except for the use of a different secure hash function and larger DH
+ groups, no significant changes have been made to the protocol
+ described by [RFC4462]; therefore, all the original security
+ considerations apply.
+
+8.2. New Elliptic Curve DH Mechanisms
+
+ Although a new cryptographic primitive is used with these methods,
+ the actual key exchange closely follows the key exchange defined in
+ [RFC5656]; therefore, all the original security considerations, as
+ well as those expressed in [RFC5656], apply.
+
+8.3. GSS-API Delegation
+
+ Some GSS-API mechanisms can act on a request to delegate credentials
+ to the target host when the deleg_req_flag is set. In this case,
+ extra care must be taken to ensure that the acceptor being
+ authenticated matches the target the user intended. Some mechanism
+ implementations (such as commonly used krb5 libraries) may use
+ insecure DNS resolution to canonicalize the target name; in these
+ cases, spoofing a DNS response that points to an attacker-controlled
+ machine may result in the user silently delegating credentials to the
+ attacker, who can then impersonate the user at will.
+
+9. References
+
+9.1. Normative References
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ DOI 10.17487/RFC1321, April 1992,
+ <https://www.rfc-editor.org/info/rfc1321>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2743] Linn, J., "Generic Security Service Application Program
+ Interface Version 2, Update 1", RFC 2743,
+ DOI 10.17487/RFC2743, January 2000,
+ <https://www.rfc-editor.org/info/rfc2743>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc3526>.
+
+ [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, <https://www.rfc-editor.org/info/rfc4462>.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+ <https://www.rfc-editor.org/info/rfc4648>.
+
+ [RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm
+ Integration in the Secure Shell Transport Layer",
+ RFC 5656, DOI 10.17487/RFC5656, December 2009,
+ <https://www.rfc-editor.org/info/rfc5656>.
+
+ [RFC7546] Kaduk, B., "Structure of the Generic Security Service
+ (GSS) Negotiation Loop", RFC 7546, DOI 10.17487/RFC7546,
+ May 2015, <https://www.rfc-editor.org/info/rfc7546>.
+
+ [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
+ for Security", RFC 7748, DOI 10.17487/RFC7748, January
+ 2016, <https://www.rfc-editor.org/info/rfc7748>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8731] Adamantiadis, A., Josefsson, S., and M. Baushke, "Secure
+ Shell (SSH) Key Exchange Method Using Curve25519 and
+ Curve448", RFC 8731, DOI 10.17487/RFC8731, February 2020,
+ <https://www.rfc-editor.org/info/rfc8731>.
+
+ [SEC1v2] Standards for Efficient Cryptography Group, "SEC 1:
+ Elliptic Curve Cryptography", Version 2.0, May 2009.
+
+ [SEC2v2] Standards for Elliptic Cryptography Group, "SEC 2:
+ Recommended Elliptic Curve Domain Parameters",
+ Version 2.0, January 2010.
+
+9.2. Informative References
+
+ [IANA-KEX-NAMES]
+ IANA, "Secure Shell (SSH) Protocol Parameters: Key
+ Exchange Method Names",
+ <https://www.iana.org/assignments/ssh-parameters/>.
+
+ [ISO-IEC-8825-1]
+ ITU-T, "Information technology -- ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", ISO/IEC 8825-1:2015, ITU-T Recommendation X.690,
+ November 2015,
+ <http://standards.iso.org/ittf/PubliclyAvailableStandards/
+ c068345_ISO_IEC_8825-1_2015.zip>.
+
+ [NIST-SP-800-131Ar2]
+ National Institute of Standards and Technology,
+ "Transitioning of the Use of Cryptographic Algorithms and
+ Key Lengths", DOI 10.6028/NIST.SP.800-131Ar2, NIST Special
+ Publication 800-131A Revision 2, November 2015,
+ <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
+ NIST.SP.800-131Ar2.pdf>.
+
+ [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,
+ <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>.
+
+ [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>.
+
+Authors' Addresses
+
+ Simo Sorce
+ Red Hat, Inc.
+ 140 Broadway, 24th Floor
+ New York, NY 10025
+ United States of America
+
+ Email: simo@redhat.com
+
+
+ Hubert Kario
+ Red Hat, Inc.
+ Purkynova 115
+ 612 00 Brno
+ Czech Republic
+
+ Email: hkario@redhat.com