rfc8732xml2.original.xml   rfc8732.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC1321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.1321.xml">
<!ENTITY RFC2743 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2743.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC3526 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3526.xml">
<!ENTITY RFC4462 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4462.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4648.xml">
<!ENTITY RFC5656 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5656.xml">
<!ENTITY RFC6194 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6194.xml">
<!ENTITY RFC6234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6234.xml">
<!ENTITY RFC7546 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7546.xml">
<!ENTITY RFC7748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7748.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8268 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8268.xml">
<!ENTITY SSHCURVES PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml3/referen
ce.I-D.draft-ietf-curdle-ssh-curves-08.xml'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc autobreaks="yes"?>
<?rfc docmapping="yes"?>
<rfc category="std" docName="draft-ietf-curdle-gss-keyex-sha2-10" <rfc number="8732" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude" c
ipr="trust200902" updates="4462"> ategory="std"
docName="draft-ietf-curdle-gss-keyex-sha2-10" ipr="trust200902"
updates="4462" obsoletes="" submissionType="IETF" xml:lang="en"
tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.35.0 -->
<front> <front>
<title abbrev="GSS Keyex SHA2">GSS-API Key Exchange with SHA2</title> <title abbrev="GSS Keyex SHA-2">Generic Security Service Application
Program Interface (GSS-API) Key Exchange with SHA-2</title>
<seriesInfo name="RFC" value="8732"/>
<author fullname="Simo Sorce" initials="S." surname="Sorce"> <author fullname="Simo Sorce" initials="S." surname="Sorce">
<organization>Red Hat, Inc.</organization> <organization>Red Hat, Inc.</organization>
<address> <address>
<postal> <postal>
<street>140 Broadway</street> <street>140 Broadway, 24th Floor</street>
<street>24th Floor</street>
<city>New York</city> <city>New York</city>
<region>NY</region> <region>NY</region>
<code>10025</code> <code>10025</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>simo@redhat.com</email> <email>simo@redhat.com</email>
</address> </address>
</author> </author>
<author fullname="Hubert Kario" initials="H." surname="Kario"> <author fullname="Hubert Kario" initials="H." surname="Kario">
<organization>Red Hat, Inc.</organization> <organization>Red Hat, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Purkynova 115</street> <street>Purkynova 115</street>
<city>Brno</city> <city>Brno</city>
<code>612 00</code> <code>612 00</code>
<country>Czech Republic</country> <country>Czech Republic</country>
</postal> </postal>
<email>hkario@redhat.com</email> <email>hkario@redhat.com</email>
</address> </address>
</author> </author>
<date month="February" year="2020"/>
<date month="Jul" year="2019" />
<area>Security</area> <area>Security</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>Internet Engineering Task Force</workgroup>
<keyword>SSH</keyword>
<abstract> <abstract>
<t>This document specifies additions and amendments to RFC4462. <t>This document specifies additions and amendments to RFC 4462.
It defines a new key exchange method that uses SHA-2 for integrity and It defines a new key exchange method that uses SHA-2 for integrity and
deprecates weak DH groups. The purpose of this specification is to deprecates weak Diffie-Hellman (DH) groups. The purpose of this specificat
modernize the cryptographic primitives used by GSS Key Exchanges.</t> ion is to
modernize the cryptographic primitives used by Generic Security Service (G
SS) key exchanges.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t><xref target="RFC4462">SSH GSS-API Methods</xref> allows the use of <name>Introduction</name>
<xref target="RFC2743">GSSAPI</xref> for authentication and key exchange <t>Secure Shell (SSH) Generic Security Service Application Program Interfa
in SSH. It defines three exchange methods all based on DH groups and ce (GSS-API)
SHA-1. This document updates RFC4462 with new methods intended to support methods <xref target="RFC4462" format="default"></xref>
allow the use of GSS-API
<xref target="RFC2743" format="default"></xref> for authentication and key
exchange
in SSH. <xref target="RFC4462" format="default"></xref> defines three exch
ange methods all based on DH groups and
SHA-1. This document updates <xref target="RFC4462" format="default"></xre
f> with new methods intended to support
environments that desire to use the SHA-2 cryptographic hash functions. environments that desire to use the SHA-2 cryptographic hash functions.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Rationale"> <name>Rationale</name>
<t>Due to security concerns with SHA-1 <xref target="RFC6194"/> and with <t>Due to security concerns with SHA-1 <xref target="RFC6194"
MODP groups with less than 2048 bits <xref target="NIST-SP-800-131Ar1"/> format="default"/> and with modular exponentiation (MODP) groups with les
we propose the use of hashes based on SHA-2 <xref target="RFC6234"/> s than 2048 bits <xref
target="NIST-SP-800-131Ar2" format="default"/>,
we propose the use of hashes based on SHA-2 <xref target="RFC6234" format=
"default"/>
with DH group14, group15, with DH group14, group15,
group16, group17 and group18 <xref target="RFC3526"/>. Additionally we group16, group17, and group18 <xref target="RFC3526" format="default"/>. A
add support for key exchange based on Elliptic Curve Diffie Hellman with dditionally, we
the NIST P-256, P-384 and P-521 <xref target="SEC2v2"/> as well as the add support for key exchange based on Elliptic Curve Diffie-Hellman with
X25519 and X448 <xref target="RFC7748"/> curves. the NIST P-256, P-384, and P-521 <xref target="SEC2v2" format="default"/>,
Following the practice of <xref target="RFC8268"/> only SHA-256 and as well as the
SHA-512 hashes are used for DH groups. For NIST curves the same X25519 and X448 <xref target="RFC7748" format="default"/> curves.
curve-to-hashing algorithm pairing used in <xref target="RFC5656"/> is Following the practice of <xref target="RFC8268" format="default"/>, only
SHA-256 and
SHA-512 hashes are used for DH groups. For NIST curves, the same
curve-to-hashing algorithm pairing used in <xref target="RFC5656" format="
default"/> is
adopted for consistency.</t> adopted for consistency.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Document Conventions</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Document Conventions">
<t>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 <xref target="RFC2119">RFC2119</xref>
<xref target="RFC8174">RFC8174</xref> when, and only when, they
appear in all capitals, as shown here.</t>
</section> </section>
<section numbered="true" toc="default" anchor="sect4">
<section title="New Diffie-Hellman Key Exchange methods"> <name>New Diffie-Hellman Key Exchange Methods</name>
<t>This document adopts the same naming convention defined in <xref <t>This document adopts the same naming convention defined in <xref
target="RFC4462"/> to define families of methods that cover any target="RFC4462" format="default"/> to define families of methods that
cover any
GSS-API mechanism used with a specific Diffie-Hellman group and GSS-API mechanism used with a specific Diffie-Hellman group and
SHA-2 Hash combination.</t> SHA-2 hash combination.</t>
<texttable anchor="gss_ex_alg" title="New key exchange algorithms"> <table anchor="gss_ex_alg" align="center">
<ttcol align="left">Key Exchange Method Name</ttcol> <name>New Key Exchange Algorithms</name>
<ttcol align="left">Implementation Recommendations</ttcol> <thead>
<c>gss-group14-sha256-*</c><c>SHOULD/RECOMMENDED</c> <tr>
<c>gss-group15-sha512-*</c><c>MAY/OPTIONAL</c> <th align="left">Key Exchange Method Name</th>
<c>gss-group16-sha512-*</c><c>SHOULD/RECOMMENDED</c> <th align="left">Implementation Recommendations</th>
<c>gss-group17-sha512-*</c><c>MAY/OPTIONAL</c> </tr>
<c>gss-group18-sha512-*</c><c>MAY/OPTIONAL</c> </thead>
</texttable> <tbody>
<tr>
<td align="left">gss-group14-sha256-*</td>
<td align="left"><bcp14>SHOULD</bcp14>/<bcp14>RECOMMENDED</bcp14></t
d>
</tr>
<tr>
<td align="left">gss-group15-sha512-*</td>
<td align="left"><bcp14>MAY</bcp14>/<bcp14>OPTIONAL</bcp14></td>
</tr>
<tr>
<td align="left">gss-group16-sha512-*</td>
<td align="left"><bcp14>SHOULD</bcp14>/<bcp14>RECOMMENDED</bcp14></t
d>
</tr>
<tr>
<td align="left">gss-group17-sha512-*</td>
<td align="left"><bcp14>MAY</bcp14>/<bcp14>OPTIONAL</bcp14></td>
</tr>
<tr>
<td align="left">gss-group18-sha512-*</td>
<td align="left"><bcp14>MAY</bcp14>/<bcp14>OPTIONAL</bcp14></td>
</tr>
</tbody>
</table>
<t>Each key exchange method prefix is registered by this document. <t>Each key exchange method prefix is registered by this document.
The IESG is the change controller of all these key exchange methods; 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 this does NOT imply that the IESG is considered to be in control of
the corresponding GSS-API mechanism.</t> the corresponding GSS-API mechanism.</t>
<t> <t>
Each method in any <xref target="fam_met">family of methods</xref> Each method in any family of methods (<xref target="fam_met" format="def ault"></xref>)
specifies GSS-API-authenticated Diffie-Hellman key exchanges as specifies GSS-API-authenticated Diffie-Hellman key exchanges as
described in Section 2.1 of <xref target="RFC4462"/>. The <xref described in <xref target="RFC4462" sectionFormat="of"
target="gss_ex_alg">method name for each method</xref> is the section="2.1"/>. The method name for each method (<xref
concatenation of the family name prefix with the Base64 encoding of target="gss_ex_alg" format="default"></xref>) is the
the MD5 hash <xref target="RFC1321"/> of the ASN.1 DER encoding concatenation of the family name prefix with the base64 encoding of
<xref target="ISO-IEC-8825-1"/> of the corresponding GSS-API the MD5 hash <xref target="RFC1321" format="default"/> of the ASN.1 DER
mechanism's OID. Base64 encoding is described in Section 4 of encoding
<xref target="RFC4648"/>.</t> <xref target="ISO-IEC-8825-1" format="default"/> of the corresponding GS
<texttable anchor="fam_met" title="Family method references"> S-API
<ttcol align="left">Family Name prefix</ttcol> mechanism's OID. Base64 encoding is described in
<ttcol align="left">Hash Function</ttcol> <xref target="RFC4648" sectionFormat="of" section="4"/>.</t>
<ttcol align="left">Group </ttcol> <table anchor="fam_met" align="center">
<ttcol align="left">Reference</ttcol> <name>Family Method References</name>
<c>gss-group14-sha256-</c><c>SHA-256</c><c>2048-bit MODP</c> <thead>
<c>Section 3 of <xref target="RFC3526"/></c> <tr>
<c>gss-group15-sha512-</c><c>SHA-512</c><c>3072-bit MODP</c> <th align="left">Family Name Prefix</th>
<c>Section 4 of <xref target="RFC3526"/></c> <th align="left">Hash Function</th>
<c>gss-group16-sha512-</c><c>SHA-512</c><c>4096-bit MODP</c> <th align="left">Group </th>
<c>Section 5 of <xref target="RFC3526"/></c> <th align="left">Reference</th>
<c>gss-group17-sha512-</c><c>SHA-512</c><c>6144-bit MODP</c> </tr>
<c>Section 6 of <xref target="RFC3526"/></c> </thead>
<c>gss-group18-sha512-</c><c>SHA-512</c><c>8192-bit MODP</c> <tbody>
<c>Section 7 of <xref target="RFC3526"/></c> <tr>
</texttable> <td align="left">gss-group14-sha256-</td>
<td align="left">SHA-256</td>
<td align="left">2048-bit MODP</td>
<td align="left"><xref target="RFC3526"
sectionFormat="of" section="3"/></td>
</tr>
<tr>
<td align="left">gss-group15-sha512-</td>
<td align="left">SHA-512</td>
<td align="left">3072-bit MODP</td>
<td align="left"><xref target="RFC3526"
sectionFormat="of" section="4"/></td>
</tr>
<tr>
<td align="left">gss-group16-sha512-</td>
<td align="left">SHA-512</td>
<td align="left">4096-bit MODP</td>
<td align="left"><xref target="RFC3526"
sectionFormat="of" section="5"/></td>
</tr>
<tr>
<td align="left">gss-group17-sha512-</td>
<td align="left">SHA-512</td>
<td align="left">6144-bit MODP</td>
<td align="left"><xref target="RFC3526"
sectionFormat="of" section="6"/></td>
</tr>
<tr>
<td align="left">gss-group18-sha512-</td>
<td align="left">SHA-512</td>
<td align="left">8192-bit MODP</td>
<td align="left"><xref target="RFC3526"
sectionFormat="of" section="7"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default" anchor="sect5">
<name>New Elliptic Curve Diffie-Hellman Key Exchange Methods</name>
<t>In <xref target="RFC5656" format="default"/>, new SSH key exchange algo
rithms based on
elliptic curve cryptography are introduced. We reuse much of
<xref target="RFC5656" sectionFormat="of" section="4"/>
to define GSS-API-authenticated Elliptic Curve Diffie-Hellman (ECDH) key e
xchanges.</t>
<t>Additionally, we also utilize the curves defined in <xref target="RFC87
31" format="default"/> to complement the three classic
NIST-defined curves required by <xref target="RFC5656" format="default"/>.
</t>
<section anchor="gen_gss_ecdh" numbered="true" toc="default">
<name>Generic GSS-API Key Exchange with ECDH</name>
<t>This section reuses much of the scheme defined in
<xref target="RFC4462" sectionFormat="of" section="2.1"/> and combines i
t with the scheme defined in
<xref target="RFC5656" sectionFormat="of" section="4"/>; in particular,
all checks and
verification steps prescribed in
<xref target="RFC5656" sectionFormat="of" section="4"/> apply
here as well.</t>
<section title="New Elliptic Curve Diffie-Hellman Key Exchange methods"> <t>The key-agreement schemes "ECDHE-Curve25519" and "ECDHE-Curve448" per
<t>In <xref target="RFC5656"/> new SSH key exchange algorithms based on form
Elliptic Curve Cryptography are introduced. We reuse much of section 4 the Diffie-Hellman protocol using the functions X25519 and X448,
of <xref target="RFC5656"/> respectively. Implementations <bcp14>MUST</bcp14> compute these function
to define GSS-API-authenticated ECDH Key Exchanges.</t> s using
<t>Additionally, we also utilize the curves defined in <xref the algorithms described in <xref target="RFC7748" format="default"/>. W
target="I-D.ietf-curdle-ssh-curves"/> to complement the three classic hen they do
NIST-defined curves required by <xref target="RFC5656"/>.</t> so, implementations <bcp14>MUST</bcp14> check whether the computed Diffi
e-Hellman
<section title="Generic GSS-API Key Exchange with ECDH" anchor="gen_gss_ec
dh">
<t>This section reuses much of the scheme defined in Section 2.1 of
<xref target="RFC4462"/> and combines it with the scheme defined in
Section 4 of <xref target="RFC5656"/>; in particular, all checks and
verification steps prescribed in Section 4 of
<xref target="RFC5656"/> apply here as well.</t>
<t>Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 perform
the Diffie-Helman protocol using the functions X25519 and X448,
respectively. Implementations MUST compute these functions using
the algorithms described in <xref target="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 shared secret is the all-zero value and abort if so, as described in
Section 6 of <xref target="RFC7748"/>. Alternative implementations <xref target="RFC7748" sectionFormat="of" section="6"/>. Alternati
of these functions SHOULD abort when either input forces the shared ve implementations of these functions
secret to one of a small set of values, as discussed in Section 7 of <bcp14>SHOULD</bcp14> abort when either the client or the server input
<xref target="RFC7748"/>.</t> forces the shared secret to one of a small set of values, as
described in Sections <xref target="RFC7748" section="6"
<t>This section defers to <xref target="RFC7546"/> as the source of sectionFormat="bare"/> and <xref target="RFC7748" section="7"
information on GSS-API context establishment operations, Section 3 sectionFormat="bare"/> of <xref target="RFC7748"/>.</t>
being the most relevant. All Security Considerations described in <t>This section defers to <xref target="RFC7546" format="default"/> as t
<xref target="RFC7546"/> apply here too.</t> he source of
information on GSS-API context establishment operations, Section <xref
target="RFC7546" sectionFormat="bare" section="3"/>
being the most relevant. All security considerations described in
<xref target="RFC7546" format="default"/> apply here, too.</t>
<t>The parties each generate an ephemeral key pair, according to <t>The parties each generate an ephemeral key pair, according to
Section 3.2.1 of <xref target="SEC1v2"/>. Keys are verified upon Section 3.2.1 of
<xref target="SEC1v2" format="default"/>. Keys are verified upon
receipt by the parties according to Section 3.2.3.1 of receipt by the parties according to Section 3.2.3.1 of
<xref target="SEC1v2"/>.</t> <xref target="SEC1v2" format="default"/>.</t>
<t>For NIST curves, the keys use the uncompressed point representation
<t>For NIST Curves the keys use the uncompressed point representation and <bcp14>MUST</bcp14> be converted using the algorithm in Section 2.3.
and MUST be converted using the algorithm in Section 2.3.4 of 4 of
<xref target="SEC1v2"/>. If the conversion fails or the point is <xref target="SEC1v2" format="default"/>. If the conversion fails or the
transmitted using the compressed representation, the key exchange MUST point is
transmitted using the compressed representation, the key exchange <bcp14
>MUST</bcp14>
fail.</t> fail.</t>
<t>A GSS context is established according to
<t>A GSS Context is established according to Section 4 of <xref target="RFC5656" sectionFormat="of" section="4"/>; the client init
<xref target="RFC5656"/>; The client initiates the establishment iates the establishment
using GSS_Init_sec_context() and the server responds to it using using GSS_Init_sec_context(), and the server responds to it using
GSS_Accept_sec_context(). For the negotiation, the client MUST set GSS_Accept_sec_context(). For the negotiation, the client <bcp14>MUST</b
cp14> set
mutual_req_flag and integ_req_flag to "true". In addition, mutual_req_flag and integ_req_flag to "true". In addition,
deleg_req_flag MAY be set to "true" to request access delegation, if deleg_req_flag <bcp14>MAY</bcp14> be set to "true" to request access del egation, if
requested by the user. Since the key exchange process authenticates requested by the user. Since the key exchange process authenticates
only the host, the setting of anon_req_flag is immaterial to this only the host, the setting of anon_req_flag is immaterial to this
process. If the client does not support the "gssapi-keyex" user process. If the client does not support the "gssapi-keyex" user
authentication method described in Section 4 of authentication method described in
<xref target="RFC4462"/>, or does not intend to use that method in <xref target="RFC4462" sectionFormat="of" section="4"/>, or does not int
end to use that method in
conjunction with the GSS-API context established during key exchange, conjunction with the GSS-API context established during key exchange,
then anon_req_flag SHOULD be set to "true". Otherwise, this flag MAY then anon_req_flag <bcp14>SHOULD</bcp14> be set to "true". Otherwise,
be set to true if the client wishes to hide its identity. this flag <bcp14>MAY</bcp14>
be set to "true" if the client wishes to hide its identity.
This key exchange process will exchange only a single message token This key exchange process will exchange only a single message token
once the context has been established, therefore the once the context has been established; therefore, the
replay_det_req_flag and sequence_req_flag SHOULD be set to "false". replay_det_req_flag and sequence_req_flag <bcp14>SHOULD</bcp14> be set t
o "false".
</t> </t>
<t>The client <bcp14>MUST</bcp14> include its public key with the first
<t>The client MUST include its public key with the first message it message it
sends to the server during this process; if the server receives sends to the server during this process; if the server receives
more than one key or none at all, the key exchange MUST fail.</t> more than one key or none at all, the key exchange <bcp14>MUST</bcp14> f
ail.</t>
<t>During GSS Context establishment multiple tokens may be exchanged <t>During GSS context establishment, multiple tokens may be exchanged
by the client and the server. When the GSS Context is established by the client and the server. When the GSS context is established
(major_status is GSS_S_COMPLETE) the parties check that (major_status is GSS_S_COMPLETE), the parties check that
mutual_state and integ_avail are both "true". If not the key mutual_state and integ_avail are both "true". If not, the key
exchange MUST fail.</t> exchange <bcp14>MUST</bcp14> fail.</t>
<t>Once a party receives the peer's public key, it proceeds to compute
<t>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
a shared secret K. For NIST Curves the computation is done according to Section 3.3.1 of <xref target="SEC1v2" format="default"/>, and the re
to Section 3.3.1 of <xref target="SEC1v2"/> and the resulting value sulting value
z is converted to the octet string K using the conversion defined z is converted to the octet string K using the conversion defined
in Section 2.3.5 of <xref target="SEC1v2"/>. For curve25519 and in Section 2.3.5 of <xref target="SEC1v2" format="default"/>. For curve2
curve448 the algorithms in Section 6 of <xref target="RFC7748"/> are 5519 and
curve448, the algorithms in <xref target="RFC7748"
sectionFormat="of" section="6"/> are
used instead.</t> used instead.</t>
<t>To verify the integrity of the handshake, peers use the hash
<t>To verify the integrity of the handshake, peers use the Hash function defined by the selected key exchange method to calculate H:
Function defined by the selected Key Exchange method to calculate H:
</t> </t>
<t>H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).</t> <t>H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).</t>
<t>The GSS_GetMIC() call is used by the server with H as the payload <t>The server uses the GSS_GetMIC() call with H as the payload
and generates a MIC. The GSS_VerifyMIC() call is used by the client to to generate a Message Integrity Code (MIC).
verify the MIC.</t>
The GSS_VerifyMIC() call is used by the client to
verify the MIC.</t>
<t>If any GSS_Init_sec_context() or GSS_Accept_sec_context() returns <t>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 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 any other GSS-API call returns a major_status other than
GSS_S_COMPLETE, the key exchange MUST fail. The same recommendations GSS_S_COMPLETE, the key exchange <bcp14>MUST</bcp14> fail. The same reco
expressed in Section 2.1 of <xref target="RFC4462"/> are followed with mmendations
regards to error reporting.</t> expressed in <xref target="RFC4462" sectionFormat="of" section="2.1"/> a
re followed with
regard to error reporting.</t>
<t>The following is an overview of the key exchange process: <t>The following is an overview of the key exchange process:
<figure> </t>
<artwork>
Client Server
------ ------
Generate ephemeral key pair.
Calls GSS_Init_sec_context().
SSH_MSG_KEXGSS_INIT ---------------&gt;
Verify received key is valid. <artwork name="" type="" align="left" alt=""><![CDATA[
(Optional) &lt;------------- SSH_MSG_KEXGSS_HOSTKEY Client Server
------ ------
Generates ephemeral key pair.
Calls GSS_Init_sec_context().
SSH_MSG_KEXGSS_INIT --------------->
(Loop) Verifies received key.
| Calls GSS_Accept_sec_context(). (Optional) <------------- SSH_MSG_KEXGSS_HOSTKEY
| &lt;------------ SSH_MSG_KEXGSS_CONTINUE
| Calls GSS_Init_sec_context().
| SSH_MSG_KEXGSS_CONTINUE ------------&gt;
Calls GSS_Accept_sec_context(). (Loop)
Generate ephemeral key pair. | Calls GSS_Accept_sec_context().
Compute shared secret. | <------------ SSH_MSG_KEXGSS_CONTINUE
Computes hash H. | Calls GSS_Init_sec_context().
Calls GSS_GetMIC( H ) = MIC. | SSH_MSG_KEXGSS_CONTINUE ------------>
&lt;------------ SSH_MSG_KEXGSS_COMPLETE
Verify received key is valid. Calls GSS_Accept_sec_context().
Compute shared secret. Generates ephemeral key pair.
Compute hash = H Computes shared secret.
Calls GSS_VerifyMIC( MIC, H ) Computes hash H.
</artwork> Calls GSS_GetMIC( H ) = MIC.
</figure> <------------ SSH_MSG_KEXGSS_COMPLETE
</t>
<t>This is implemented with the following messages:</t> Verifies received key.
<figure> Computes shared secret.
<preamble>The client sends:</preamble> Computes hash H.
<artwork> Calls GSS_VerifyMIC( MIC, H ).]]></artwork>
byte SSH_MSG_KEXGSS_INIT <t>This is implemented with the following messages:</t>
string output_token (from GSS_Init_sec_context()) <t>The client sends:</t>
string Q_C, client's ephemeral public key octet string <dl newline="false" spacing="normal" indent="12">
</artwork> <dt>byte</dt>
</figure> <dd>SSH_MSG_KEXGSS_INIT</dd>
<figure> <dt>string</dt>
<preamble>The server may respond with:</preamble> <dd>output_token (from GSS_Init_sec_context())</dd>
<artwork> <dt>string</dt>
byte SSH_MSG_KEXGSS_HOSTKEY <dd>Q_C, client's ephemeral public key octet string</dd>
string server public host key and certificates (K_S) </dl>
</artwork> <t>The server may respond with:</t>
</figure> <dl newline="false" spacing="normal" indent="12">
<figure> <dt>byte</dt>
<preamble>The server sends:</preamble> <dd>SSH_MSG_KEXGSS_HOSTKEY</dd>
<artwork> <dt>string</dt>
byte SSH_MSG_KEXGSS_CONTINUE <dd>server public host key and certificates (K_S)</dd>
string output_token (from GSS_Accept_sec_context()) </dl>
</artwork>
</figure> <t>The server sends:</t>
<dl newline="false" spacing="normal" indent="12">
<dt>byte</dt>
<dd>SSH_MSG_KEXGSS_CONTINUE</dd>
<dt>string</dt>
<dd>output_token (from GSS_Accept_sec_context())</dd>
</dl>
<t>Each time the client receives the message described above, it <t>Each time the client receives the message described above, it
makes another call to GSS_Init_sec_context().</t> makes another call to GSS_Init_sec_context().</t>
<figure> <t>The client sends:</t>
<preamble>The client sends:</preamble> <dl newline="false" spacing="normal" indent="12">
<artwork> <dt>byte</dt>
byte SSH_MSG_KEXGSS_CONTINUE <dd>SSH_MSG_KEXGSS_CONTINUE</dd>
string output_token (from GSS_Init_sec_context()) <dt>string</dt>
</artwork> <dd>output_token (from GSS_Init_sec_context())</dd>
</figure> </dl>
<figure>
<preamble>As the final message the server sends either:</preamble>
<artwork>
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())
</artwork>
</figure>
<figure>
<preamble>Or the following if no output_token is available:</preamble>
<artwork>
byte SSH_MSG_KEXGSS_COMPLETE
string Q_S, server's ephemeral public key octet string
string mic_token (MIC of H)
boolean FALSE
</artwork>
</figure>
<figure>
<preamble>The hash H is computed as the HASH hash of the
concatenation of the following:</preamble>
<artwork>
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
</artwork>
</figure>
<t>This value is called the exchange hash, and it is used to <t>As the final message, the server sends the following if an
authenticate the key exchange. The exchange hash SHOULD be kept output_token is produced:</t>
<dl newline="false" spacing="normal" indent="12">
<dt>byte</dt>
<dd>SSH_MSG_KEXGSS_COMPLETE</dd>
<dt>string</dt>
<dd>Q_S, server's ephemeral public key octet string</dd>
<dt>string</dt>
<dd>mic_token (MIC of H)</dd>
<dt>boolean</dt>
<dd>TRUE</dd>
<dt>string</dt>
<dd>output_token (from GSS_Accept_sec_context())</dd>
</dl>
<t>If no output_token is produced, the server sends:</t>
<dl newline="false" spacing="normal" indent="12">
<dt>byte</dt>
<dd>SSH_MSG_KEXGSS_COMPLETE</dd>
<dt>string</dt>
<dd>Q_S, server's ephemeral public key octet string</dd>
<dt>string</dt>
<dd>mic_token (MIC of H)</dd>
<dt>boolean</dt>
<dd>FALSE</dd>
</dl>
<t>The hash H is computed as the HASH hash of the
concatenation of the following:</t>
<dl newline="false" spacing="normal" indent="12">
<dt>string</dt>
<dd>V_C, the client's version string (CR, NL excluded)</dd>
<dt>string</dt>
<dd>V_S, server's version string (CR, NL excluded)</dd>
<dt>string</dt>
<dd>I_C, payload of the client's SSH_MSG_KEXINIT</dd>
<dt>string</dt>
<dd>I_S, payload of the server's SSH_MSG_KEXINIT</dd>
<dt>string</dt>
<dd>K_S, server's public host key</dd>
<dt>string</dt>
<dd>Q_C, client's ephemeral public key octet string</dd>
<dt>string</dt>
<dd>Q_S, server's ephemeral public key octet string</dd>
<dt>mpint</dt>
<dd>K, shared secret</dd>
</dl>
<t>This value is called the "exchange hash", and it is used to
authenticate the key exchange. The exchange hash <bcp14>SHOULD</bcp14> b
e kept
secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the 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 server or received by the client, then the empty string is used in
place of K_S when computing the exchange hash.</t> place of K_S when computing the exchange hash.</t>
<t>Since this key exchange method does not require the host key to <t>Since this key exchange method does not require the host key to
be used for any encryption operations, the SSH_MSG_KEXGSS_HOSTKEY be used for any encryption operations, the SSH_MSG_KEXGSS_HOSTKEY
message is OPTIONAL. If the "null" host key algorithm described in message is <bcp14>OPTIONAL</bcp14>. If the "null" host key algorithm des
Section 5 of <xref target="RFC4462"/> is used, this message MUST cribed in
NOT be sent.</t> <xref target="RFC4462" sectionFormat="of" section="5"/> is used, this me
ssage <bcp14>MUST
<t>If the client receives a SSH_MSG_KEXGSS_CONTINUE message after NOT</bcp14> be sent.</t>
<t>If the client receives an SSH_MSG_KEXGSS_CONTINUE message after
a call to GSS_Init_sec_context() has returned a major_status code 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 of GSS_S_COMPLETE, a protocol error has occurred, and the key
exchange MUST fail.</t> exchange <bcp14>MUST</bcp14> fail.</t>
<t>If the client receives an SSH_MSG_KEXGSS_COMPLETE message and a
<t>If the client receives a SSH_MSG_KEXGSS_COMPLETE message and a
call to GSS_Init_sec_context() does not result in a major_status 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 code of GSS_S_COMPLETE, a protocol error has occurred, and the key
exchange MUST fail.</t> exchange <bcp14>MUST</bcp14> fail.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="ECDH Key Exchange Methods"> <name>ECDH Key Exchange Methods</name>
<texttable anchor="ecc_ex_alg" title="New key exchange methods"> <table anchor="ecc_ex_alg" align="center">
<ttcol align="left">Key Exchange Method Name</ttcol> <name>New Key Exchange Methods</name>
<ttcol align="left">Implementation Recommendations</ttcol> <thead>
<c>gss-nistp256-sha256-*</c><c>SHOULD/RECOMMENDED</c> <tr>
<c>gss-nistp384-sha384-*</c><c>MAY/OPTIONAL</c> <th align="left">Key Exchange Method Name</th>
<c>gss-nistp521-sha512-*</c><c>MAY/OPTIONAL</c> <th align="left">Implementation Recommendations</th>
<c>gss-curve25519-sha256-*</c><c>SHOULD/RECOMMENDED</c> </tr>
<c>gss-curve448-sha512-*</c><c>MAY/OPTIONAL</c> </thead>
</texttable> <tbody>
<t>Each key exchange method prefix is registered by this document. <tr>
<td align="left">gss-nistp256-sha256-*</td>
<td align="left"><bcp14>SHOULD</bcp14>/<bcp14>RECOMMENDED</bcp14><
/td>
</tr>
<tr>
<td align="left">gss-nistp384-sha384-*</td>
<td align="left"><bcp14>MAY</bcp14>/<bcp14>OPTIONAL</bcp14></td>
</tr>
<tr>
<td align="left">gss-nistp521-sha512-*</td>
<td align="left"><bcp14>MAY</bcp14>/<bcp14>OPTIONAL</bcp14></td>
</tr>
<tr>
<td align="left">gss-curve25519-sha256-*</td>
<td align="left"><bcp14>SHOULD</bcp14>/<bcp14>RECOMMENDED</bcp14><
/td>
</tr>
<tr>
<td align="left">gss-curve448-sha512-*</td>
<td align="left"><bcp14>MAY</bcp14>/<bcp14>OPTIONAL</bcp14></td>
</tr>
</tbody>
</table>
<t>Each key exchange method prefix is registered by this document.
The IESG is the change controller of all these key exchange methods; 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 this does NOT imply that the IESG is considered to be in control of
the corresponding GSS-API mechanism.</t> the corresponding GSS-API mechanism.</t>
<t> <t>
Each method in any <xref target="fam_met_ecc">family of methods</xref> Each method in any family of methods (<xref target="fam_met_ecc" format=
"default"></xref>)
specifies GSS-API-authenticated Elliptic Curve Diffie-Hellman key specifies GSS-API-authenticated Elliptic Curve Diffie-Hellman key
exchanges as described in <xref target="gen_gss_ecdh"/>. The <xref exchanges as described in <xref target="gen_gss_ecdh"
target="ecc_ex_alg">method name for each method</xref> is the format="default"/>. The method name for each method (<xref
concatenation of the family method name with the Base64 encoding of target="ecc_ex_alg" format="default"></xref>) is the
the MD5 hash <xref target="RFC1321"/> of the ASN.1 DER encoding concatenation of the family method name with the base64 encoding of
<xref target="ISO-IEC-8825-1"/> of the corresponding GSS-API the MD5 hash <xref target="RFC1321" format="default"/> of the ASN.1 DER
mechanism's OID. Base64 encoding is described in Section 4 of encoding
<xref target="RFC4648"/>.</t> <xref target="ISO-IEC-8825-1" format="default"/> of the corresponding GS
<texttable anchor="fam_met_ecc" title="Family method refences"> S-API
<ttcol align="left">Family Name prefix</ttcol> mechanism's OID. Base64 encoding is described in
<ttcol align="left">Hash Function</ttcol> <xref target="RFC4648" sectionFormat="of" section="4"/>.</t>
<ttcol align="left">Parameters / Function Name</ttcol> <table anchor="fam_met_ecc" align="center">
<ttcol align="left">Definition</ttcol> <name>Family Method References</name>
<c>gss-nistp256-sha256-</c><c>SHA-256</c><c>secp256r1</c> <thead>
<c>Section 2.4.2 of <xref target="SEC2v2"/></c> <tr>
<c>gss-nistp384-sha384-</c><c>SHA-384</c><c>secp384r1</c> <th align="left">Family Name Prefix</th>
<c>Section 2.5.1 of <xref target="SEC2v2"/></c> <th align="left">Hash Function</th>
<c>gss-nistp521-sha512-</c><c>SHA-512</c><c>secp521r1</c> <th align="left">Parameters / Function Name</th>
<c>Section 2.6.1 of <xref target="SEC2v2"/></c> <th align="left">Definition</th>
<c>gss-curve25519-sha256-</c><c>SHA-256</c><c>X22519</c> </tr>
<c>Section 5 of <xref target="RFC7748"/></c> </thead>
<c>gss-curve448-sha512-</c><c>SHA-512</c><c>X448</c> <tbody>
<c>Section 5 of <xref target="RFC7748"/></c> <tr>
</texttable> <td align="left">gss-nistp256-sha256-</td>
<td align="left">SHA-256</td>
<td align="left">secp256r1</td>
<td align="left">Section 2.4.2 of <xref target="SEC2v2" format="de
fault"/></td>
</tr>
<tr>
<td align="left">gss-nistp384-sha384-</td>
<td align="left">SHA-384</td>
<td align="left">secp384r1</td>
<td align="left">Section 2.5.1 of <xref target="SEC2v2" format="de
fault"/></td>
</tr>
<tr>
<td align="left">gss-nistp521-sha512-</td>
<td align="left">SHA-512</td>
<td align="left">secp521r1</td>
<td align="left">Section 2.6.1 of <xref target="SEC2v2" format="de
fault"/></td>
</tr>
<tr>
<td align="left">gss-curve25519-sha256-</td>
<td align="left">SHA-256</td>
<td align="left">X22519</td>
<td align="left"><xref target="RFC7748"
sectionFormat="of" section="5"/></td>
</tr>
<tr>
<td align="left">gss-curve448-sha512-</td>
<td align="left">SHA-512</td>
<td align="left">X448</td>
<td align="left"><xref target="RFC7748"
sectionFormat="of" section="5"/></td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section numbered="true" toc="default" anchor="sect6">
<section title="Deprecated Algorithms"> <name>Deprecated Algorithms</name>
<t>Because they have small key lengths and are no longer strong in <t>Because they have small key lengths and are no longer strong in
the face of brute-force attacks, the algorithms in the following the face of brute-force attacks, the algorithms in the following
table are considered deprecated and SHOULD NOT be used.</t> table are considered deprecated and <bcp14>SHOULD NOT</bcp14> be used.</t>
<texttable> <table align="center">
<preamble>Deprecated Algorithms</preamble> <name>Deprecated Algorithms</name>
<ttcol align="left">Key Exchange Method Name</ttcol> <thead>
<ttcol align="left">Implementation Recommendations</ttcol> <tr>
<c>gss-group1-sha1-*</c><c>SHOULD NOT</c> <th align="left">Key Exchange Method Name</th>
<c>gss-group14-sha1-*</c><c>SHOULD NOT</c> <th align="left">Implementation Recommendations</th>
<c>gss-gex-sha1-*</c><c>SHOULD NOT</c> </tr>
</texttable> </thead>
<tbody>
<tr>
<td align="left">gss-group1-sha1-*</td>
<td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr>
<tr>
<td align="left">gss-group14-sha1-*</td>
<td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr>
<tr>
<td align="left">gss-gex-sha1-*</td>
<td align="left"><bcp14>SHOULD NOT</bcp14></td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document augments the SSH Key Exchange Method Names in <xref <t>This document augments the SSH key exchange message names
target="RFC4462"/>.</t> that were defined in <xref
<texttable> target="RFC4462" format="default"/> (see and <xref
<preamble>IANA is requested to update the <xref target="sect6"/>); IANA has listed this
target="IANA-KEX-NAMES">SSH Protocol Parameters</xref> registry document as reference for those entries in the "SSH Protocol Parameters" <
with the following entries:</preamble> xref target="IANA-KEX-NAMES"
<ttcol align="left">Key Exchange Method Name</ttcol> format="default"></xref> registry.</t>
<ttcol align="left">Reference</ttcol> <t>In addition, IANA has updated the registry to include the SSH key
<c>gss-group1-sha1-*</c><c>This draft</c> exchange message names described in Sections <xref
<c>gss-group14-sha1-*</c><c>This draft</c> target="sect4" format="counter"/> and
<c>gss-gex-sha1-*</c><c>This draft</c> <xref target="sect5" format="counter"/>.</t>
<c>gss-group14-sha256-*</c><c>This draft</c> <table align="center">
<c>gss-group15-sha512-*</c><c>This draft</c> <name>Additions/Changes to the Key Exchange Method Names Registry</name>
<c>gss-group16-sha512-*</c><c>This draft</c> <thead>
<c>gss-group17-sha512-*</c><c>This draft</c> <tr>
<c>gss-group18-sha512-*</c><c>This draft</c> <th align="left">Key Exchange Method Name</th>
<c>gss-nistp256-sha256-*</c><c>This draft</c> <th align="left">Reference</th>
<c>gss-nistp384-sha384-*</c><c>This draft</c> </tr>
<c>gss-nistp521-sha512-*</c><c>This draft</c> </thead>
<c>gss-curve25519-sha256-*</c><c>This draft</c> <tbody>
<c>gss-curve448-sha512-*</c><c>This draft</c> <tr>
</texttable> <td align="left">gss-group1-sha1-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-group14-sha1-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-gex-sha1-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-group14-sha256-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-group15-sha512-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-group16-sha512-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-group17-sha512-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-group18-sha512-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-nistp256-sha256-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-nistp384-sha384-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-nistp521-sha512-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-curve25519-sha256-*</td>
<td align="left">RFC 8732</td>
</tr>
<tr>
<td align="left">gss-curve448-sha512-*</td>
<td align="left">RFC 8732</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<section title="New Finite Field DH mechanisms"> <section numbered="true" toc="default">
<name>New Finite Field DH Mechanisms</name>
<t>Except for the use of a different secure hash function and larger <t>Except for the use of a different secure hash function and larger
DH groups, no significant changes has been made to the protocol DH groups, no significant changes have been made to the protocol
described by <xref target="RFC4462"/>; therefore all the original described by <xref target="RFC4462" format="default"/>; therefore, all t
Security Considerations apply.</t> he original
security considerations apply.</t>
</section> </section>
<section title="New Elliptic Curve DH mechanisms"> <section numbered="true" toc="default">
<t>Although a new cryptographic primitive is used with these methods <name>New Elliptic Curve DH Mechanisms</name>
<t>Although a new cryptographic primitive is used with these methods,
the actual key exchange closely follows the key exchange defined in the actual key exchange closely follows the key exchange defined in
<xref target="RFC5656"/>; therefore all the original Security <xref target="RFC5656" format="default"/>; therefore, all the original s
Considerations as well as those expressed in <xref target="RFC5656"/> ecurity
considerations, as well as those expressed in <xref target="RFC5656" for
mat="default"/>,
apply.</t> apply.</t>
</section> </section>
<section title="GSSAPI Delegation"> <section numbered="true" toc="default">
<t>Some GSSAPI mechanisms can act on a request to delegate credentials <name>GSS-API Delegation</name>
<t>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 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 care must be taken to ensure that the acceptor being authenticated
matches the target the user intended. Some mechanism implementations matches the target the user intended. Some mechanism implementations
(such as commonly used krb5 libraries) may use insecure DNS resolution t o (such as commonly used krb5 libraries) may use insecure DNS resolution t o
canonicalize the target name; in these cases spoofing a DNS response canonicalize the target name; in these cases, spoofing a DNS response
that points to an attacker-controlled machine may result in the user that points to an attacker-controlled machine may result in the user
silently delegating credentials to the attacker, who can then silently delegating credentials to the attacker, who can then
impersonate the user at will.</t> impersonate the user at will.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<?rfc rfcedstyle="no"?> <references>
<references title="Normative References"> <name>References</name>
<references>
&RFC1321; <name>Normative References</name>
&RFC2743; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.1321.xml"/>
<!--DH GROUPS--> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2743.xml"/>
&RFC3526; <!--DH GROUPS-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<!--SSH GSS-API Methods--> ence.RFC.3526.xml"/>
<!--SSH GSS-API Methods-->
&RFC4462; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4462.xml"/>
&RFC4648; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4648.xml"/>
<!-- SSH ECC Algorithms --> <!-- SSH ECC Algorithms -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC5656; ence.RFC.5656.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&RFC7546; ence.RFC.7546.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
&SSHCURVES; ence.RFC.7748.xml"/>
<!--Key words for use in RFCs to Indicate Requirement Levels-->
&RFC7748; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<!--Key words for use in RFCs to Indicate Requirement Levels--> <!--ECC specifications-->
&RFC2119;
<!--ECC specifications--> <!-- draft-ietf-curdle-ssh-curves-12 -->
<reference anchor="RFC8731" target="https://www.rfc-editor.org/info/rfc8731">
<front>
<title>Secure Shell (SSH) Key Exchange Method Using Curve25519 and
Curve448</title>
<author initials='A' surname='Adamantiadis' fullname='Arish Adamantiadis'>
<organization/>
</author>
<author initials='S' surname='Josefsson' fullname='Simon Josefsson'>
<organization/>
</author>
<author initials='M' surname='Baushke' fullname='Mark D. Baushke'>
<organization/>
</author>
<date month='February' year='2020'/>
</front>
<seriesInfo name="RFC" value="8731"/>
<seriesInfo name="DOI" value="10.17487/RFC8731"/>
</reference>
<reference <reference anchor="SEC1v2">
anchor="SEC1v2">
<front> <front>
<title>SEC 1: Elliptic Curve Cryptography</title> <title>SEC 1: Elliptic Curve Cryptography</title>
<author> <seriesInfo name="Version" value="2.0"/>
<organization>Certicom Research</organization> <author>
</author> <organization>Standards for Efficient Cryptography Group</organiza
<date year="2009"/> tion>
</author>
<date month="May" year="2009"/>
</front> </front>
<seriesInfo </reference>
name="Standards for Efficient Cryptography"
value="SEC 1"/>
<seriesInfo
name="Version"
value="2.0"/>
</reference>
<reference <reference anchor="SEC2v2">
anchor="SEC2v2">
<front> <front>
<title>SEC 2: Recommended Elliptic Curve Domain Parameters</title> <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
<author> <seriesInfo name="Version" value="2.0"/>
<organization>Certicom Research</organization> <author>
</author> <organization>Standards for Elliptic Cryptography Group</organizat
<date year="2010"/> ion>
</author>
<date month="January" year="2010"/>
</front> </front>
<seriesInfo </reference>
name="Standards for Efficient Cryptography" <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
value="SEC 2"/> ence.RFC.8174.xml"/>
<seriesInfo </references>
name="Version"
value="2.0"/>
</reference>
&RFC8174;
</references>
<references title="Informative References">
&RFC6194;
&RFC8268;
<!--SHA-2-->
&RFC6234;
<reference <references>
anchor="ISO-IEC-8825-1" <name>Informative References</name>
target="http://standards.iso.org/ittf/PubliclyAvailableStandards/c0683 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
45_ISO_IEC_8825-1_2015.zip"> ence.RFC.6194.xml"/>
<front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<title>ASN.1 encoding rules: Specification of Basic Encoding Rules ence.RFC.8268.xml"/>
<!--SHA-2-->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6234.xml"/>
<reference anchor="ISO-IEC-8825-1"
target="http://standards.iso.org/ittf/PubliclyAvailableStandar
ds/c068345_ISO_IEC_8825-1_2015.zip">
<front>
<title>Information technology -- ASN.1 encoding rules: Specification
of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding (BER), Canonical Encoding Rules (CER) and Distinguished Encoding
Rules (DER)</title> Rules (DER)</title>
<author> <seriesInfo name="ISO/IEC" value="8825-1:2015"/>
<organization>International Organization for Standardization / <seriesInfo name="ITU-T Recommendation" value="X.690"/>
International Electrotechnical Commission</organization> <author>
</author> <organization>ITU-T</organization>
<date day="15" month="November" year="2015"/> </author>
</front> <date month="November" year="2015"/>
<seriesInfo name="ISO/IEC" value="8825-1"/> </front>
</reference> </reference>
<reference <reference anchor="NIST-SP-800-131Ar2"
anchor="NIST-SP-800-131Ar1" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.8 NIST.SP.800-131Ar2.pdf">
00-131Ar1.pdf"> <front>
<front> <title>Transitioning of the Use of Cryptographic Algorithms and Key
<title>Transitions: Recommendation for Transitioning of Lengths</title>
the Use of Cryptographic Algorithms and Key Lengths</title> <seriesInfo name="NIST Special Publication" value="800-131A Revision
<author> 2"/>
<organization <seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/>
abbrev="NIST">National Institute of Standards and Technology <author>
</organization> <organization abbrev="NIST">National Institute of Standards and Te
</author> chnology
<date month="November" year="2015"/> </organization>
</front> </author>
<seriesInfo <date month="November" year="2015"/>
name="NIST Special Publication" </front>
value="800-131A Revision 1"/> </reference>
</reference>
<reference <reference anchor="IANA-KEX-NAMES"
anchor="IANA-KEX-NAMES" target="https://www.iana.org/assignments/ssh-parameters/">
target="https://www.iana.org/assignments/ssh-parameters/ssh-parameters <front>
.xhtml#ssh-parameters-16"> <title> Secure Shell (SSH) Protocol Parameters: Key Exchange Method
<front> Names</title>
<title> Secure Shell (SSH) Protocol Parameters: Key Exchange Method Na <author>
mes</title> <organization abbrev="IANA">IANA
<author> </organization>
<organization </author>
abbrev="IANA">Internet Assigned Numbers Authority </front>
</organization> </reference>
</author> </references>
<date day="2" month="June" year="2005"/>
</front>
</reference>
</references> </references>
</back> </back>
</rfc> </rfc>
 End of changes. 88 change blocks. 
518 lines changed or deleted 712 lines changed or added

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