<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!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/reference.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"?>"rfc2629-xhtml.ent"> <rfc number="8732" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-curdle-gss-keyex-sha2-10" ipr="trust200902"updates="4462">updates="4462" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.35.0 --> <front> <title abbrev="GSS KeyexSHA2">GSS-APISHA-2">Generic Security Service Application Program Interface (GSS-API) Key Exchange withSHA2</title>SHA-2</title> <seriesInfo name="RFC" value="8732"/> <author fullname="Simo Sorce" initials="S." surname="Sorce"> <organization>Red Hat, Inc.</organization> <address> <postal> <street>140Broadway</street> <street>24thBroadway, 24th Floor</street> <city>New York</city> <region>NY</region> <code>10025</code><country>USA</country><country>United States of America</country> </postal> <email>simo@redhat.com</email> </address> </author> <author fullname="Hubert Kario" initials="H." surname="Kario"> <organization>Red Hat, Inc.</organization> <address> <postal> <street>Purkynova 115</street> <city>Brno</city> <code>612 00</code> <country>Czech Republic</country> </postal> <email>hkario@redhat.com</email> </address> </author> <datemonth="Jul" year="2019" />month="February" year="2020"/> <area>Security</area> <workgroup>Internet Engineering Task Force</workgroup> <keyword>SSH</keyword> <abstract> <t>This document specifies additions and amendments toRFC4462.RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weakDHDiffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used byGSS Key Exchanges.</t>Generic Security Service (GSS) key exchanges.</t> </abstract> </front> <middle> <sectiontitle="Introduction"> <t><xref target="RFC4462">SSH GSS-API Methods</xref> allowsnumbered="true" toc="default"> <name>Introduction</name> <t>Secure Shell (SSH) Generic Security Service Application Program Interface (GSS-API) methods <xref target="RFC4462" format="default"></xref> allow the use of GSS-API <xreftarget="RFC2743">GSSAPI</xref>target="RFC2743" format="default"></xref> for authentication and key exchange in SSH.It<xref target="RFC4462" format="default"></xref> defines three exchange methods all based on DH groups and SHA-1. This document updatesRFC4462<xref target="RFC4462" format="default"></xref> with new methods intended to support environments that desire to use the SHA-2 cryptographic hash functions. </t> </section> <sectiontitle="Rationale">numbered="true" toc="default"> <name>Rationale</name> <t>Due to security concerns with SHA-1 <xreftarget="RFC6194"/>target="RFC6194" format="default"/> and withMODPmodular exponentiation (MODP) groups with less than 2048 bits <xreftarget="NIST-SP-800-131Ar1"/>target="NIST-SP-800-131Ar2" format="default"/>, we propose the use of hashes based on SHA-2 <xreftarget="RFC6234"/>target="RFC6234" format="default"/> with DH group14, group15, group16,group17group17, and group18 <xreftarget="RFC3526"/>. Additionallytarget="RFC3526" format="default"/>. Additionally, we add support for key exchange based on Elliptic CurveDiffie HellmanDiffie-Hellman with the NIST P-256,P-384P-384, and P-521 <xreftarget="SEC2v2"/>target="SEC2v2" format="default"/>, as well as the X25519 and X448 <xreftarget="RFC7748"/>target="RFC7748" format="default"/> curves. Following the practice of <xreftarget="RFC8268"/>target="RFC8268" format="default"/>, only SHA-256 and SHA-512 hashes are used for DH groups. For NISTcurvescurves, the same curve-to-hashing algorithm pairing used in <xreftarget="RFC5656"/>target="RFC5656" format="default"/> is adopted for consistency.</t> </section> <sectiontitle="Document Conventions"> <t>Thenumbered="true" toc="default"> <name>Document Conventions</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119">RFC2119</xref>target="RFC2119"/> <xreftarget="RFC8174">RFC8174</xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectiontitle="Newnumbered="true" toc="default" anchor="sect4"> <name>New Diffie-Hellman Key Exchangemethods">Methods</name> <t>This document adopts the same naming convention defined in <xreftarget="RFC4462"/>target="RFC4462" format="default"/> to define families of methods that cover any GSS-API mechanism used with a specific Diffie-Hellman group and SHA-2Hashhash combination.</t><texttable<table anchor="gss_ex_alg"title="New key exchange algorithms"> <ttcolalign="center"> <name>New Key Exchange Algorithms</name> <thead> <tr> <th align="left">Key Exchange MethodName</ttcol> <ttcolName</th> <th align="left">ImplementationRecommendations</ttcol> <c>gss-group14-sha256-*</c><c>SHOULD/RECOMMENDED</c> <c>gss-group15-sha512-*</c><c>MAY/OPTIONAL</c> <c>gss-group16-sha512-*</c><c>SHOULD/RECOMMENDED</c> <c>gss-group17-sha512-*</c><c>MAY/OPTIONAL</c> <c>gss-group18-sha512-*</c><c>MAY/OPTIONAL</c> </texttable>Recommendations</th> </tr> </thead> <tbody> <tr> <td align="left">gss-group14-sha256-*</td> <td align="left"><bcp14>SHOULD</bcp14>/<bcp14>RECOMMENDED</bcp14></td> </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></td> </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. 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.</t> <t> Each method in any<xref target="fam_met">familyfamily ofmethods</xref>methods (<xref target="fam_met" format="default"></xref>) specifies GSS-API-authenticated Diffie-Hellman key exchanges as described inSection 2.1 of<xreftarget="RFC4462"/>.target="RFC4462" sectionFormat="of" section="2.1"/>. The<xref target="gss_ex_alg">methodmethod name for eachmethod</xref>method (<xref target="gss_ex_alg" format="default"></xref>) is the concatenation of the family name prefix with theBase64base64 encoding of the MD5 hash <xreftarget="RFC1321"/>target="RFC1321" format="default"/> of the ASN.1 DER encoding <xreftarget="ISO-IEC-8825-1"/>target="ISO-IEC-8825-1" format="default"/> of the corresponding GSS-API mechanism's OID. Base64 encoding is described inSection 4 of<xreftarget="RFC4648"/>.</t> <texttabletarget="RFC4648" sectionFormat="of" section="4"/>.</t> <table anchor="fam_met"title="Family method references"> <ttcolalign="center"> <name>Family Method References</name> <thead> <tr> <th align="left">Family Nameprefix</ttcol> <ttcolPrefix</th> <th align="left">HashFunction</ttcol> <ttcolFunction</th> <th align="left">Group</ttcol> <ttcol align="left">Reference</ttcol> <c>gss-group14-sha256-</c><c>SHA-256</c><c>2048-bit MODP</c> <c>Section 3 of <xref target="RFC3526"/></c> <c>gss-group15-sha512-</c><c>SHA-512</c><c>3072-bit MODP</c> <c>Section 4 of <xref target="RFC3526"/></c> <c>gss-group16-sha512-</c><c>SHA-512</c><c>4096-bit MODP</c> <c>Section 5 of <xref target="RFC3526"/></c> <c>gss-group17-sha512-</c><c>SHA-512</c><c>6144-bit MODP</c> <c>Section 6 of <xref target="RFC3526"/></c> <c>gss-group18-sha512-</c><c>SHA-512</c><c>8192-bit MODP</c> <c>Section 7 of <xref target="RFC3526"/></c> </texttable></th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <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> <sectiontitle="Newnumbered="true" toc="default" anchor="sect5"> <name>New Elliptic Curve Diffie-Hellman Key Exchangemethods">Methods</name> <t>In <xreftarget="RFC5656"/>target="RFC5656" format="default"/>, new SSH key exchange algorithms based onElliptic Curve Cryptographyelliptic curve cryptography are introduced. We reuse much ofsection 4 of<xreftarget="RFC5656"/>target="RFC5656" sectionFormat="of" section="4"/> to define GSS-API-authenticatedECDH Key Exchanges.</t>Elliptic Curve Diffie-Hellman (ECDH) key exchanges.</t> <t>Additionally, we also utilize the curves defined in <xreftarget="I-D.ietf-curdle-ssh-curves"/>target="RFC8731" format="default"/> to complement the three classic NIST-defined curves required by <xreftarget="RFC5656"/>.</t>target="RFC5656" format="default"/>.</t> <sectiontitle="Genericanchor="gen_gss_ecdh" numbered="true" toc="default"> <name>Generic GSS-API Key Exchange withECDH" anchor="gen_gss_ecdh">ECDH</name> <t>This section reuses much of the scheme defined inSection 2.1 of<xreftarget="RFC4462"/>target="RFC4462" sectionFormat="of" section="2.1"/> and combines it with the scheme defined inSection 4 of<xreftarget="RFC5656"/>;target="RFC5656" sectionFormat="of" section="4"/>; in particular, all checks and verification steps prescribed inSection 4 of<xreftarget="RFC5656"/>target="RFC5656" sectionFormat="of" section="4"/> apply here as well.</t><t>Key-agreement<t>The key-agreement schemesECDHE-Curve25519"ECDHE-Curve25519" andECDHE-Curve448"ECDHE-Curve448" perform theDiffie-HelmanDiffie-Hellman protocol using the functions X25519 and X448, respectively. ImplementationsMUST<bcp14>MUST</bcp14> compute these functions using the algorithms described in <xreftarget="RFC7748"/>.target="RFC7748" format="default"/>. When they do so, implementationsMUST<bcp14>MUST</bcp14> check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described inSection 6 of<xreftarget="RFC7748"/>.target="RFC7748" sectionFormat="of" section="6"/>. Alternative implementations of these functionsSHOULD<bcp14>SHOULD</bcp14> abort when either the client or the server input forces the shared secret to one of a small set of values, asdiscusseddescribed inSection 7Sections <xref target="RFC7748" section="6" sectionFormat="bare"/> and <xref target="RFC7748" section="7" sectionFormat="bare"/> of <xref target="RFC7748"/>.</t> <t>This section defers to <xreftarget="RFC7546"/>target="RFC7546" format="default"/> as the source of information on GSS-API context establishment operations, Section3<xref target="RFC7546" sectionFormat="bare" section="3"/> being the most relevant. AllSecurity Considerationssecurity considerations described in <xreftarget="RFC7546"/>target="RFC7546" format="default"/> applyherehere, too.</t> <t>The parties each generate an ephemeral key pair, according to Section 3.2.1 of <xreftarget="SEC1v2"/>.target="SEC1v2" format="default"/>. Keys are verified upon receipt by the parties according to Section 3.2.3.1 of <xreftarget="SEC1v2"/>.</t>target="SEC1v2" format="default"/>.</t> <t>For NISTCurvescurves, the keys use the uncompressed point representation andMUST<bcp14>MUST</bcp14> be converted using the algorithm in Section 2.3.4 of <xreftarget="SEC1v2"/>.target="SEC1v2" format="default"/>. If the conversion fails or the point is transmitted using the compressed representation, the key exchangeMUST<bcp14>MUST</bcp14> fail.</t> <t>A GSSContextcontext is established according toSection 4 of<xreftarget="RFC5656"/>; Thetarget="RFC5656" sectionFormat="of" section="4"/>; the client initiates the establishment usingGSS_Init_sec_context()GSS_Init_sec_context(), and the server responds to it using GSS_Accept_sec_context(). For the negotiation, the clientMUST<bcp14>MUST</bcp14> set mutual_req_flag and integ_req_flag to "true". In addition, deleg_req_flagMAY<bcp14>MAY</bcp14> 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 inSection 4 of<xreftarget="RFC4462"/>,target="RFC4462" sectionFormat="of" section="4"/>, or does not intend to use that method in conjunction with the GSS-API context established during key exchange, then anon_req_flagSHOULD<bcp14>SHOULD</bcp14> be set to "true". Otherwise, this flagMAY<bcp14>MAY</bcp14> be set totrue"true" if the client wishes to hide its identity. This key exchange process will exchange only a single message token once the context has beenestablished, thereforeestablished; therefore, the replay_det_req_flag and sequence_req_flagSHOULD<bcp14>SHOULD</bcp14> be set to "false". </t> <t>The clientMUST<bcp14>MUST</bcp14> 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 exchangeMUST<bcp14>MUST</bcp14> fail.</t> <t>During GSSContext establishmentcontext establishment, multiple tokens may be exchanged by the client and the server. When the GSSContextcontext is established (major_status isGSS_S_COMPLETE)GSS_S_COMPLETE), the parties check that mutual_state and integ_avail are both "true". Ifnotnot, the key exchangeMUST<bcp14>MUST</bcp14> fail.</t> <t>Once a party receives the peer's publickeykey, it proceeds to compute a shared secret K. For NISTCurvescurves, the computation is done according to Section 3.3.1 of <xreftarget="SEC1v2"/>target="SEC1v2" format="default"/>, and the resulting value z is converted to the octet string K using the conversion defined in Section 2.3.5 of <xreftarget="SEC1v2"/>.target="SEC1v2" format="default"/>. For curve25519 andcurve448curve448, the algorithms inSection 6 of<xreftarget="RFC7748"/>target="RFC7748" sectionFormat="of" section="6"/> are used instead.</t> <t>To verify the integrity of the handshake, peers use theHash Functionhash function defined by the selectedKey Exchangekey exchange method to calculate H: </t> <t>H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).</t> <t>The server uses the GSS_GetMIC() callis used by the serverwith H as the payloadand generatesto generate aMIC.Message Integrity Code (MIC). 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 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 exchangeMUST<bcp14>MUST</bcp14> fail. The same recommendations expressed inSection 2.1 of<xreftarget="RFC4462"/>target="RFC4462" sectionFormat="of" section="2.1"/> are followed withregardsregard to error reporting.</t> <t>The following is an overview of the key exchange process:<figure> <artwork></t> <artwork name="" type="" align="left" alt=""><![CDATA[ Client Server ------ ------GenerateGenerates ephemeral key pair. Calls GSS_Init_sec_context(). SSH_MSG_KEXGSS_INIT---------------> Verify---------------> Verifies receivedkey is valid.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().GenerateGenerates ephemeral key pair.ComputeComputes shared secret. Computes hash H. Calls GSS_GetMIC( H ) = MIC.<------------<------------ SSH_MSG_KEXGSS_COMPLETEVerifyVerifies receivedkey is valid. Computekey. Computes shared secret.ComputeComputes hash= HH. Calls GSS_VerifyMIC( MIC, H) </artwork> </figure> </t>).]]></artwork> <t>This is implemented with the following messages:</t><figure> <preamble>The<t>The clientsends:</preamble> <artwork> byte SSH_MSG_KEXGSS_INIT string output_tokensends:</t> <dl newline="false" spacing="normal" indent="12"> <dt>byte</dt> <dd>SSH_MSG_KEXGSS_INIT</dd> <dt>string</dt> <dd>output_token (fromGSS_Init_sec_context()) string Q_C,GSS_Init_sec_context())</dd> <dt>string</dt> <dd>Q_C, client's ephemeral public key octetstring </artwork> </figure> <figure> <preamble>Thestring</dd> </dl> <t>The server may respondwith:</preamble> <artwork> byte SSH_MSG_KEXGSS_HOSTKEY string serverwith:</t> <dl newline="false" spacing="normal" indent="12"> <dt>byte</dt> <dd>SSH_MSG_KEXGSS_HOSTKEY</dd> <dt>string</dt> <dd>server public host key and certificates(K_S) </artwork> </figure> <figure> <preamble>The(K_S)</dd> </dl> <t>The serversends:</preamble> <artwork> byte SSH_MSG_KEXGSS_CONTINUE string output_tokensends:</t> <dl newline="false" spacing="normal" indent="12"> <dt>byte</dt> <dd>SSH_MSG_KEXGSS_CONTINUE</dd> <dt>string</dt> <dd>output_token (fromGSS_Accept_sec_context()) </artwork> </figure>GSS_Accept_sec_context())</dd> </dl> <t>Each time the client receives the message described above, it makes another call to GSS_Init_sec_context().</t><figure> <preamble>The<t>The clientsends:</preamble> <artwork> byte SSH_MSG_KEXGSS_CONTINUE string output_tokensends:</t> <dl newline="false" spacing="normal" indent="12"> <dt>byte</dt> <dd>SSH_MSG_KEXGSS_CONTINUE</dd> <dt>string</dt> <dd>output_token (fromGSS_Init_sec_context()) </artwork> </figure> <figure> <preamble>AsGSS_Init_sec_context())</dd> </dl> <t>As the finalmessagemessage, the server sendseither:</preamble> <artwork> byte SSH_MSG_KEXGSS_COMPLETE string Q_S,the following if an 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 octetstring string mic_tokenstring</dd> <dt>string</dt> <dd>mic_token (MIC ofH) boolean TRUE string output_tokenH)</dd> <dt>boolean</dt> <dd>TRUE</dd> <dt>string</dt> <dd>output_token (fromGSS_Accept_sec_context()) </artwork> </figure> <figure> <preamble>Or the following ifGSS_Accept_sec_context())</dd> </dl> <t>If no output_token isavailable:</preamble> <artwork> byte SSH_MSG_KEXGSS_COMPLETE string Q_S,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 octetstring string mic_tokenstring</dd> <dt>string</dt> <dd>mic_token (MIC ofH) boolean FALSE </artwork> </figure> <figure> <preamble>TheH)</dd> <dt>boolean</dt> <dd>FALSE</dd> </dl> <t>The hash H is computed as the HASH hash of the concatenation of thefollowing:</preamble> <artwork> string V_C,following:</t> <dl newline="false" spacing="normal" indent="12"> <dt>string</dt> <dd>V_C, the client's version string (CR, NLexcluded) string V_S,excluded)</dd> <dt>string</dt> <dd>V_S, server's version string (CR, NLexcluded) string I_C,excluded)</dd> <dt>string</dt> <dd>I_C, payload of the client'sSSH_MSG_KEXINIT string I_S,SSH_MSG_KEXINIT</dd> <dt>string</dt> <dd>I_S, payload of the server'sSSH_MSG_KEXINIT string K_S,SSH_MSG_KEXINIT</dd> <dt>string</dt> <dd>K_S, server's public hostkey string Q_C,key</dd> <dt>string</dt> <dd>Q_C, client's ephemeral public key octetstring string Q_S,string</dd> <dt>string</dt> <dd>Q_S, server's ephemeral public key octetstring mpint K,string</dd> <dt>mpint</dt> <dd>K, sharedsecret </artwork> </figure>secret</dd> </dl> <t>This value is called theexchange hash,"exchange hash", and it is used to authenticate the key exchange. The exchange hashSHOULD<bcp14>SHOULD</bcp14> 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.</t> <t>Since this key exchange method does not require the host key to be used for any encryption operations, the SSH_MSG_KEXGSS_HOSTKEY message isOPTIONAL.<bcp14>OPTIONAL</bcp14>. If the "null" host key algorithm described inSection 5 of<xreftarget="RFC4462"/>target="RFC4462" sectionFormat="of" section="5"/> is used, this messageMUST NOT<bcp14>MUST NOT</bcp14> be sent.</t> <t>If the client receivesaan 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 hasoccurredoccurred, and the key exchangeMUST<bcp14>MUST</bcp14> fail.</t> <t>If the client receivesaan 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 hasoccurredoccurred, and the key exchangeMUST<bcp14>MUST</bcp14> fail.</t> </section> <sectiontitle="ECDHnumbered="true" toc="default"> <name>ECDH Key ExchangeMethods"> <texttableMethods</name> <table anchor="ecc_ex_alg"title="New key exchange methods"> <ttcolalign="center"> <name>New Key Exchange Methods</name> <thead> <tr> <th align="left">Key Exchange MethodName</ttcol> <ttcolName</th> <th align="left">ImplementationRecommendations</ttcol> <c>gss-nistp256-sha256-*</c><c>SHOULD/RECOMMENDED</c> <c>gss-nistp384-sha384-*</c><c>MAY/OPTIONAL</c> <c>gss-nistp521-sha512-*</c><c>MAY/OPTIONAL</c> <c>gss-curve25519-sha256-*</c><c>SHOULD/RECOMMENDED</c> <c>gss-curve448-sha512-*</c><c>MAY/OPTIONAL</c> </texttable>Recommendations</th> </tr> </thead> <tbody> <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; this does NOT imply that the IESG is considered to be in control of the corresponding GSS-API mechanism.</t> <t> Each method in any<xref target="fam_met_ecc">familyfamily ofmethods</xref>methods (<xref target="fam_met_ecc" format="default"></xref>) specifies GSS-API-authenticated Elliptic Curve Diffie-Hellman key exchanges as described in <xreftarget="gen_gss_ecdh"/>.target="gen_gss_ecdh" format="default"/>. The<xref target="ecc_ex_alg">methodmethod name for eachmethod</xref>method (<xref target="ecc_ex_alg" format="default"></xref>) is the concatenation of the family method name with theBase64base64 encoding of the MD5 hash <xreftarget="RFC1321"/>target="RFC1321" format="default"/> of the ASN.1 DER encoding <xreftarget="ISO-IEC-8825-1"/>target="ISO-IEC-8825-1" format="default"/> of the corresponding GSS-API mechanism's OID. Base64 encoding is described inSection 4 of<xreftarget="RFC4648"/>.</t> <texttabletarget="RFC4648" sectionFormat="of" section="4"/>.</t> <table anchor="fam_met_ecc"title="Family method refences"> <ttcolalign="center"> <name>Family Method References</name> <thead> <tr> <th align="left">Family Nameprefix</ttcol> <ttcolPrefix</th> <th align="left">HashFunction</ttcol> <ttcolFunction</th> <th align="left">Parameters / FunctionName</ttcol> <ttcol align="left">Definition</ttcol> <c>gss-nistp256-sha256-</c><c>SHA-256</c><c>secp256r1</c> <c>SectionName</th> <th align="left">Definition</th> </tr> </thead> <tbody> <tr> <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 <xreftarget="SEC2v2"/></c> <c>gss-nistp384-sha384-</c><c>SHA-384</c><c>secp384r1</c> <c>Sectiontarget="SEC2v2" format="default"/></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 <xreftarget="SEC2v2"/></c> <c>gss-nistp521-sha512-</c><c>SHA-512</c><c>secp521r1</c> <c>Sectiontarget="SEC2v2" format="default"/></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 <xreftarget="SEC2v2"/></c> <c>gss-curve25519-sha256-</c><c>SHA-256</c><c>X22519</c> <c>Section 5 of <xref target="RFC7748"/></c> <c>gss-curve448-sha512-</c><c>SHA-512</c><c>X448</c> <c>Section 5 of <xref target="RFC7748"/></c> </texttable>target="SEC2v2" format="default"/></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> <sectiontitle="Deprecated Algorithms">numbered="true" toc="default" anchor="sect6"> <name>Deprecated Algorithms</name> <t>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 andSHOULD NOT<bcp14>SHOULD NOT</bcp14> be used.</t><texttable> <preamble>Deprecated Algorithms</preamble> <ttcol<table align="center"> <name>Deprecated Algorithms</name> <thead> <tr> <th align="left">Key Exchange MethodName</ttcol> <ttcolName</th> <th align="left">ImplementationRecommendations</ttcol> <c>gss-group1-sha1-*</c><c>SHOULD NOT</c> <c>gss-group14-sha1-*</c><c>SHOULD NOT</c> <c>gss-gex-sha1-*</c><c>SHOULD NOT</c> </texttable>Recommendations</th> </tr> </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> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document augments the SSHKey Exchange Method Nameskey exchange message names that were defined in <xreftarget="RFC4462"/>.</t> <texttable> <preamble>IANA is requested to update thetarget="RFC4462" format="default"/> (see and <xreftarget="IANA-KEX-NAMES">SSHtarget="sect6"/>); IANA has listed this document as reference for those entries in the "SSH ProtocolParameters</xref>Parameters" <xref target="IANA-KEX-NAMES" format="default"></xref> registry.</t> <t>In addition, IANA has updated the registrywithto include thefollowing entries:</preamble> <ttcolSSH key exchange message names described in Sections <xref target="sect4" format="counter"/> and <xref target="sect5" format="counter"/>.</t> <table align="center"> <name>Additions/Changes to the Key Exchange Method Names Registry</name> <thead> <tr> <th align="left">Key Exchange MethodName</ttcol> <ttcol align="left">Reference</ttcol> <c>gss-group1-sha1-*</c><c>This draft</c> <c>gss-group14-sha1-*</c><c>This draft</c> <c>gss-gex-sha1-*</c><c>This draft</c> <c>gss-group14-sha256-*</c><c>This draft</c> <c>gss-group15-sha512-*</c><c>This draft</c> <c>gss-group16-sha512-*</c><c>This draft</c> <c>gss-group17-sha512-*</c><c>This draft</c> <c>gss-group18-sha512-*</c><c>This draft</c> <c>gss-nistp256-sha256-*</c><c>This draft</c> <c>gss-nistp384-sha384-*</c><c>This draft</c> <c>gss-nistp521-sha512-*</c><c>This draft</c> <c>gss-curve25519-sha256-*</c><c>This draft</c> <c>gss-curve448-sha512-*</c><c>This draft</c> </texttable>Name</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <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> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <sectiontitle="Newnumbered="true" toc="default"> <name>New Finite Field DHmechanisms">Mechanisms</name> <t>Except for the use of a different secure hash function and larger DH groups, no significant changeshashave been made to the protocol described by <xreftarget="RFC4462"/>; thereforetarget="RFC4462" format="default"/>; therefore, all the originalSecurity Considerationssecurity considerations apply.</t> </section> <sectiontitle="Newnumbered="true" toc="default"> <name>New Elliptic Curve DHmechanisms">Mechanisms</name> <t>Although a new cryptographic primitive is used with thesemethodsmethods, the actual key exchange closely follows the key exchange defined in <xreftarget="RFC5656"/>; thereforetarget="RFC5656" format="default"/>; therefore, all the originalSecurity Considerationssecurity considerations, as well as those expressed in <xreftarget="RFC5656"/>target="RFC5656" format="default"/>, apply.</t> </section> <sectiontitle="GSSAPI Delegation">numbered="true" toc="default"> <name>GSS-API Delegation</name> <t>SomeGSSAPIGSS-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 thesecasescases, 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.</t> </section> </section> </middle> <back><?rfc rfcedstyle="no"?> <references title="Normative References"> &RFC1321; &RFC2743;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2743.xml"/> <!--DH GROUPS-->&RFC3526;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3526.xml"/> <!--SSH GSS-API Methods-->&RFC4462; &RFC4648;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4462.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/> <!-- SSH ECC Algorithms -->&RFC5656; &RFC7546; &SSHCURVES; &RFC7748;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5656.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7546.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/> <!--Key words for use in RFCs to Indicate Requirement Levels-->&RFC2119;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <!--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 anchor="SEC1v2"> <front> <title>SEC 1: Elliptic Curve Cryptography</title> <seriesInfo name="Version" value="2.0"/> <author><organization>Certicom Research</organization><organization>Standards for Efficient Cryptography Group</organization> </author> <date month="May" year="2009"/> </front><seriesInfo name="Standards for Efficient Cryptography" value="SEC 1"/> <seriesInfo name="Version" value="2.0"/></reference> <reference anchor="SEC2v2"> <front> <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title> <seriesInfo name="Version" value="2.0"/> <author><organization>Certicom Research</organization><organization>Standards for Elliptic Cryptography Group</organization> </author> <date month="January" year="2010"/> </front><seriesInfo name="Standards for Efficient Cryptography" value="SEC 2"/> <seriesInfo name="Version" value="2.0"/></reference>&RFC8174;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references><references title="Informative References"> &RFC6194; &RFC8268;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6194.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8268.xml"/> <!--SHA-2-->&RFC6234;<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/> <reference anchor="ISO-IEC-8825-1" target="http://standards.iso.org/ittf/PubliclyAvailableStandards/c068345_ISO_IEC_8825-1_2015.zip"> <front><title>ASN.1<title>Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <seriesInfo name="ISO/IEC" value="8825-1:2015"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/> <author><organization>International Organization for Standardization / International Electrotechnical Commission</organization><organization>ITU-T</organization> </author> <dateday="15"month="November" year="2015"/> </front><seriesInfo name="ISO/IEC" value="8825-1"/></reference> <referenceanchor="NIST-SP-800-131Ar1" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf">anchor="NIST-SP-800-131Ar2" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf"> <front><title>Transitions: Recommendation for Transitioning<title>Transitioning of the Use of Cryptographic Algorithms and Key Lengths</title> <seriesInfo name="NIST Special Publication" value="800-131A Revision 2"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/> <author> <organization abbrev="NIST">National Institute of Standards and Technology </organization> </author> <date month="November" year="2015"/> </front><seriesInfo name="NIST Special Publication" value="800-131A Revision 1"/></reference> <reference anchor="IANA-KEX-NAMES"target="https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16">target="https://www.iana.org/assignments/ssh-parameters/"> <front> <title> Secure Shell (SSH) Protocol Parameters: Key Exchange Method Names</title> <author> <organizationabbrev="IANA">Internet Assigned Numbers Authorityabbrev="IANA">IANA </organization> </author><date day="2" month="June" year="2005"/></front> </reference> </references> </references> </back> </rfc>