<?xmlversion='1.0' encoding='utf-8'?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->version="1.0" encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-yee-ssh-iana-requirements-03" number="9519" ipr="trust200902" obsoletes=""updates="4250,4716,4819,8308" submissionType="IETF"updates="4250, 4716, 4819, 8308" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"consensus="true"version="3"><!-- xml2rfc v2v3 conversion 2.38.1 --> <!-- category values: std, bcp, info, exp, and historic ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902, or pre5378Trust200902 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" --> <!-- ***** FRONT MATTER ***** --><front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><title abbrev="IANA SSH Registry Requirements">Update to the IANA SSH Protocol Parameters Registry Requirements</title> <seriesInfoname="Internet-Draft" value="draft-yee-ssh-iana-requirements-01"/>name="RFC" value="9519"/> <author fullname="Peter E. Yee" initials="P." surname="Yee"> <organization>AKAYLA</organization> <address> <postal> <street/> <!-- Reorder these if your country does things differently --> <city>Mountain View</city><region>Calif.</region><region>CA</region> <code>94043</code><country>US</country><country>United States of America</country> </postal> <phone/> <email>peter@akayla.com</email> <!-- uri and facsimile elements may also be added --> </address> </author> <dateyear="2023"/>year="2024" month="January"/> <!-- Meta-data Declarations --><area>General</area> <workgroup>Internet Engineering Task Force</workgroup> <keyword>ssh,iana,registry</keyword><area>sec</area> <keyword>ssh</keyword> <keyword>iana</keyword> <keyword>registry</keyword> <abstract><t>This<t> This specification updates therequirementsregistration policies for adding new entries to registries within the IANASecure"Secure Shell (SSH) ProtocolParameters registry.Parameters" group of registries. Currently, therequirementregistration policy is generallyfor "IETF Review",IETF Review, as defined in RFC 8126, although a fewportions of the registryregistries require"Standards Action".Standards Action. This specification will change that former requirement to"Expert Review".Expert Review. Thisdraftdocument updatesRFCRFCs 4250,RFC4716,RFC4819,RFCand 8308.</t> </abstract> </front> <middle> <section numbered="true" toc="default"> <name>Introduction</name> <t>The IANASecure"Secure Shell (SSH) ProtocolParametersParameters" registry was populated by several RFCs including <xref target="RFC4250" format="default"/>, <xref target="RFC4716" format="default"/>, <xref target="RFC4819" format="default"/>, and <xref target="RFC8308" format="default"/>. Outside of some narrow value ranges that require Standards Action in order to add new values or that are marked forprivate use, allPrivate Use, the registration policy for other portions of the registry require IETF Review <xref target="RFC8126" format="default"/>. This specification changes therequirement for sections currently requiringpolicy from IETF Review to Expert Review. This change ismadein line with similar changes undertaken for certain IPsec and TLS registries. </t> <section numbered="true" toc="default"> <name>Requirements Language</name><t>The<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 in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> <section numbered="true" toc="default"> <name>SSH Protocol Parameters Affected</name> <t>The following table lists the "Secure Shell (SSH) Protocol Parameters" registries whose registration policyishas changed from IETF Review to Expert Review. Where this changeappliesapplied to a specific range of values within the particular parameter, that range is given in the notescolumn.</t>column. Affected registries now list this document as a reference.</t> <table anchor="ssh_protocol_parameters_table" align="center"> <name>Secure Shell (SSH) Protocol Parameters Affected</name> <thead> <tr> <th align="center">Parameter Name</th> <th align="center">RFC</th> <th align="center">Notes</th> </tr> </thead> <tbody> <tr> <td align="center">Authentication Method Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Channel Connection Failure Reason Codes and Descriptions</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center">0x00000001-0xFDFFFFFF (inclusive)</td> </tr> <tr> <td align="center">Compression Algorithm Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Connection Protocol Channel Request Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Connection Protocol Channel Types</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Connection Protocol Global Request Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Connection Protocol Subsystem Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Disconnection Messages Reason Codes and Descriptions</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center">0x00000001-0xFDFFFFFF (inclusive)</td> </tr> <tr> <td align="center">Encryption Algorithm Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Extended Channel Data Transfer data_type_code and Data</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center">0x00000001-0xFDFFFFFF (inclusive)</td> </tr> <tr> <td align="center">Extension Names</td> <td align="center"><xref target="RFC8308" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Key Exchange Method Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">MAC Algorithm Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Pseudo-Terminal Encoded Terminal Modes</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Public Key Algorithm Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Publickey Subsystem Attributes</td> <td align="center"><xref target="RFC4819" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Publickey Subsystem Request Names</td> <td align="center"><xref target="RFC4819" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Publickey Subsystem Response Names</td> <td align="center"><xref target="RFC4819" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Service Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">Signal Names</td> <td align="center"><xref target="RFC4250" format="default"/></td> <td align="center"/> </tr> <tr> <td align="center">SSH Public-Key File Header Tags</td> <td align="center"><xref target="RFC4716" format="default"/></td> <td align="center">Excluding header-tags beginning with x-</td> </tr> </tbody> </table> <t>The only IANA SSH protocol parameter registries not affected are "Message Numbers" and "Publickey Subsystem Status Codes", as these remainat standard track policyStandards Action due to their limited resources as one-byte registry values.</t> </section> <section numbered="true" toc="default"> <name>Designated Expert Pool</name> <t>Expert Review <xref target="RFC8126" format="default"/> registry requests are registered after a three-week review period on the <ssh-reg-review@ietf.org> mailing list, and on the advice of one or more designated experts. However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published.</t> <t>Registration requests sent to the mailing list for reviewSHOULD<bcp14>SHOULD</bcp14> use an appropriate subject (e.g., "Request to register value in SSH protocol parameters <specific parameter> registry").</t> <t>Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA. DenialsMUST<bcp14>MUST</bcp14> include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the <iesg@ietf.org> mailing list) for resolution.</t> <t>Criteria thatSHOULD<bcp14>SHOULD</bcp14> be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality (which is not permitted), whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear.</t> <t>IANAMUST<bcp14>MUST</bcp14> only accept registry updates from the designated experts and the IESG. ItSHOULD<bcp14>SHOULD</bcp14> direct all requests for registration from otherthan thosesources to the review mailing list.</t> <t>It is suggested that multiple designated experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particularExpert,expert, thatExpert SHOULDexpert <bcp14>SHOULD</bcp14> defer to the judgment of the otherExperts.</t> </section> <section anchor="Acknowledgements" numbered="true" toc="default"> <name>Acknowledgements</name> <t>The impetus for this specification was a February 2021 discussion on the CURDLE mailing list <xref target="CURDLE-MA" format="default"/>.</t>experts.</t> </section> <section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This memo is entirely about updating the IANASSH"Secure Shell (SSH) ProtocolParametersParameters" registry.</t> </section> <section anchor="Security" numbered="true" toc="default"> <name>Security Considerations</name> <t>This memo does not change the Security Considerations for any of the updated RFCs.</t> </section> </middle> <back><!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--><references> <name>References</name> <references> <name>Normative References</name><!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <seriesInfo name="DOI" value="10.17487/RFC2119"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="BCP" value="14"/> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization/> </author> <date year="1997" month="March"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> </reference> <reference anchor="RFC4250" target="https://www.rfc-editor.org/info/rfc4250"> <front> <title>The Secure Shell (SSH) Protocol Assigned Numbers</title> <author initials="S." surname="Lehtinen" fullname="S. Lehtinen"> <organization/> </author> <author initials="C." surname="Lonvick" fullname="C. Lonvick" role="editor"> <organization/> </author> <date year="2006" month="January"/> <abstract> <t> This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. [STANDARDS-TRACK] </t> </abstract> </front> <seriesInfo name="RFC" value="4250"/> <seriesInfo name="DOI" value="10.17487/RFC4250"/> </reference> <reference anchor="RFC4819" target="https://www.rfc-editor.org/info/rfc4819"> <front> <title>Secure Shell Public Key Subsystem</title> <author initials="J." surname="Galbraith" fullname="J. Galbraith"> <organization/> </author> <author initials="J." surname="Van Dyke" fullname="J. Van Dyke"> <organization/> </author> <author initials="J." surname="Bright" fullname="J. Bright"> <organization/> </author> <date year="2007" month="March"/> <abstract> <t> Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. </t> <t> The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. </t> <t> A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS-TRACK] </t> </abstract> </front> <seriesInfo name="RFC" value="4819"/> <seriesInfo name="DOI" value="10.17487/RFC4819"/> </reference> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126"> <front> <title> Guidelines for Writing an IANA Considerations Section in RFCs </title> <author initials="M." surname="Cotton" fullname="M. Cotton"> <organization/> </author> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization/> </author> <author initials="T." surname="Narten" fullname="T. Narten"> <organization/> </author> <date year="2017" month="June"/> <abstract> <t> Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). </t> <t> To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. </t> <t> This is the third edition of this document; it obsoletes RFC 5226. </t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"> <front> <title> Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words </title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization/> </author> <date year="2017" month="May"/> <abstract> <t> RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. </t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8308" target="https://www.rfc-editor.org/info/rfc8308"> <front> <title> Extension Negotiation in the Secure Shell (SSH) Protocol </title> <author initials="D." surname="Bider" fullname="D. Bider"> <organization/> </author> <date year="2018" month="March"/> <abstract> <t> This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. </t> </abstract> </front> <seriesInfo name="RFC" value="8308"/> <seriesInfo name="DOI" value="10.17487/RFC8308"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4819.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8308.xml"/> </references> <references> <name>Informative References</name><reference anchor="RFC4716" target="https://www.rfc-editor.org/info/rfc4716"> <front> <title>The Secure Shell (SSH) Public Key File Format</title> <author initials="J." surname="Galbraith" fullname="J. Galbraith"> <organization/> </author> <author initials="R." surname="Thayer" fullname="R. Thayer"> <organization/> </author> <date year="2006" month="November"/> <abstract> <t> This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations. </t> <t> In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community. </t> </abstract> </front> <seriesInfo name="RFC" value="4716"/> <seriesInfo name="DOI" value="10.17487/RFC4716"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4716.xml"/> <reference anchor="CURDLE-MA" target="https://mailarchive.ietf.org/arch/msg/curdle/gdiOlZr9bnrZv8umVyguGG3woIM/"> <front><title>Time<title>Subject: [Curdle] Time to Review IANA SSH Registries Policies?</title> <author initials="S." surname="Turner" fullname="Sean Turner"> <organization/> </author> <date year="2021" month="February"/> </front> <refcontent>message to the Curdle mailing list</refcontent> </reference> </references> </references> <section anchor="Acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t>The impetus for this specification was a February 2021 discussion on the CURDLE mailing list <xref target="CURDLE-MA" format="default"/>.</t> </section> </back> </rfc>