rfc9519.original.xml   rfc9519.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<!-- For a complete list and description of processing instructions (PIs), submissionType="IETF"
please see http://xml.resource.org/authoring/README.html. -->
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="std" category="std"
consensus="true"
docName="draft-yee-ssh-iana-requirements-03" docName="draft-yee-ssh-iana-requirements-03"
number="9519"
ipr="trust200902" ipr="trust200902"
obsoletes="" obsoletes=""
updates="4250,4716,4819,8308" updates="4250, 4716, 4819, 8308"
submissionType="IETF"
xml:lang="en" xml:lang="en"
tocInclude="true" tocInclude="true"
tocDepth="4" tocDepth="4"
symRefs="true" symRefs="true"
sortRefs="true" sortRefs="true"
consensus="true"
version="3"> 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> <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 Protoco l Parameters Registry Requirements</title> <title abbrev="IANA SSH Registry Requirements">Update to the IANA SSH Protoco l Parameters Registry Requirements</title>
<seriesInfo name="Internet-Draft" value="draft-yee-ssh-iana-requirements-01" /> <seriesInfo name="RFC" value="9519"/>
<author fullname="Peter E. Yee" initials="P." surname="Yee"> <author fullname="Peter E. Yee" initials="P." surname="Yee">
<organization>AKAYLA</organization> <organization>AKAYLA</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently --> <!-- Reorder these if your country does things differently -->
<city>Mountain View</city> <city>Mountain View</city>
<region>Calif.</region> <region>CA</region>
<code>94043</code> <code>94043</code>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<phone/> <phone/>
<email>peter@akayla.com</email> <email>peter@akayla.com</email>
<!-- uri and facsimile elements may also be added --> <!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2023"/> <date year="2024" month="January"/>
<!-- Meta-data Declarations --> <!-- Meta-data Declarations -->
<area>General</area> <area>sec</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>ssh,iana,registry</keyword> <keyword>ssh</keyword>
<keyword>iana</keyword>
<keyword>registry</keyword>
<abstract> <abstract>
<t>This specification updates the requirements for adding new entries to t <t>
he IANA Secure Shell (SSH) Protocol Parameters registry. This specification updates the registration policies for adding new entries t
Currently, the requirement is generally for "IETF Review", as defined in o
RFC 8126, although a few portions of the registry require "Standards Action". T registries within the IANA "Secure Shell (SSH) Protocol Parameters" group of
his specification will change that former requirement to "Expert Review". This d registries. Currently, the registration policy is generally IETF Review, as def
raft updates RFC 4250, RFC 4716, RFC 4819, RFC 8308.</t> ined in RFC
8126, although a few registries require Standards Action. This specification
will change that former requirement to Expert Review. This document updates RFCs
4250, 4716, 4819, and 8308.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>The IANA Secure Shell (SSH) Protocol Parameters registry was populated by several RFCs including <xref target="RFC4250" format="default"/>, <xref targe t="RFC4716" format="default"/>, <xref target="RFC4819" format="default"/>, and < xref target="RFC8308" format="default"/>. Outside of some narrow value ranges th at require Standards Action in order to add new values or are marked for private use, all other portions of the registry require IETF Review <xref target="RFC81 26" format="default"/>. This specification changes the requirement for sections currently requiring IETF Review to Expert Review. This change is made in line wi th similar changes undertaken for certain IPsec and TLS registries. <t>The IANA "Secure Shell (SSH) Protocol Parameters" registry was populate d by several RFCs including <xref target="RFC4250" format="default"/>, <xref tar get="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 for Private Use, the registration policy for other portions of the registry require IETF Review <xref target="RFC8126" format="default"/>. This specification change s the policy from IETF Review to Expert Review. This change is in line with simi lar changes undertaken for certain IPsec and TLS registries.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, ",
and only when, they appear in all capitals, as shown here.</t> "<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> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>SSH Protocol Parameters Affected</name> <name>SSH Protocol Parameters Affected</name>
<t>The following table lists the "Secure Shell (SSH) Protocol Parameters" <t>The following table lists the "Secure Shell (SSH) Protocol Parameters"
registries whose registration policy is changed from IETF Review to Expert Revie registries whose registration policy has changed from IETF Review to Expert Revi
w. Where this change applies to a specific range of values within the particular ew. Where this change applied to a specific range of values within the particula
parameter, that range is given in the notes column.</t> r parameter, that range is given in the notes column. Affected registries now l
ist this document as a reference.</t>
<table anchor="ssh_protocol_parameters_table" align="center"> <table anchor="ssh_protocol_parameters_table" align="center">
<name>Secure Shell (SSH) Protocol Parameters Affected</name> <name>Secure Shell (SSH) Protocol Parameters Affected</name>
<thead> <thead>
<tr> <tr>
<th align="center">Parameter Name</th> <th align="center">Parameter Name</th>
<th align="center">RFC</th> <th align="center">RFC</th>
<th align="center">Notes</th> <th align="center">Notes</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 212 skipping to change at line 207
</tr> </tr>
<tr> <tr>
<td align="center">SSH Public-Key File Header Tags</td> <td align="center">SSH Public-Key File Header Tags</td>
<td align="center"><xref target="RFC4716" format="default"/></td> <td align="center"><xref target="RFC4716" format="default"/></td>
<td align="center">Excluding header-tags beginning with x-</td> <td align="center">Excluding header-tags beginning with x-</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The only IANA SSH protocol parameter registries not affected are <t>The only IANA SSH protocol parameter registries not affected are
"Message Numbers" and "Publickey Subsystem Status Codes", as these "Message Numbers" and "Publickey Subsystem Status Codes", as these
remain at standard track policy due to their limited resources as remain Standards Action due to their limited resources as
one-byte registry values.</t> one-byte registry values.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Designated Expert Pool</name> <name>Designated Expert Pool</name>
<t>Expert Review <xref target="RFC8126" format="default"/> registry reques ts <t>Expert Review <xref target="RFC8126" format="default"/> registry reques ts
are registered after a three-week review period on the are registered after a three-week review period on the
&lt;ssh-reg-review@ietf.org&gt; mailing list, and on the advice of one or more &lt;ssh-reg-review@ietf.org&gt; mailing list, and on the advice of one or more
designated experts. However, to allow for the allocation of values prior to designated experts. However, to allow for the allocation of values prior to
publication, the designated experts may approve registration once they ar e publication, the designated experts may approve registration once they ar e
satisfied that such a specification will be published.</t> satisfied that such a specification will be published.</t>
<t>Registration requests sent to the mailing list for review SHOULD use <t>Registration requests sent to the mailing list for review <bcp14>SHOUL D</bcp14> use
an appropriate subject (e.g., "Request to register value in SSH protocol an appropriate subject (e.g., "Request to register value in SSH protocol
parameters &lt;specific parameter&gt; registry").</t> parameters &lt;specific parameter&gt; registry").</t>
<t>Within the review period, the designated experts will either approve <t>Within the review period, the designated experts will either approve
or deny the registration request, communicating this decision to the or deny the registration request, communicating this decision to the
review list and IANA. Denials MUST include an explanation and, if review list and IANA. Denials <bcp14>MUST</bcp14> include an explanation and, if
applicable, suggestions as to how to make the request successful. applicable, suggestions as to how to make the request successful.
Registration requests that are undetermined for a period longer than Registration requests that are undetermined for a period longer than
21 days can be brought to the IESG's attention (using the 21 days can be brought to the IESG's attention (using the
&lt;iesg@ietf.org&gt; mailing list) for resolution.</t> &lt;iesg@ietf.org&gt; mailing list) for resolution.</t>
<t>Criteria that SHOULD be applied by the designated experts includes <t>Criteria that <bcp14>SHOULD</bcp14> be applied by the designated exper ts includes
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
functionality (which is not permitted), whether it is likely to be of functionality (which is not permitted), whether it is likely to be of
general applicability or useful only for a single application, and general applicability or useful only for a single application, and
whether the registration description is clear.</t> whether the registration description is clear.</t>
<t>IANA MUST only accept registry updates from the designated experts <t>IANA <bcp14>MUST</bcp14> only accept registry updates from the designa
and the IESG. It SHOULD direct all requests for registration from other ted experts
than those sources to the review mailing list.</t> and the IESG. It <bcp14>SHOULD</bcp14> direct all requests for registrati
on from other sources to the review mailing list.</t>
<t>It is suggested that multiple designated experts be appointed who are <t>It is suggested that multiple designated experts be appointed who are
able to represent the perspectives of different applications using able to represent the perspectives of different applications using
this specification, in order to enable broadly informed review of this specification, in order to enable broadly informed review of
registration decisions. In cases where a registration decision could registration decisions. In cases where a registration decision could
be perceived as creating a conflict of interest for a particular be perceived as creating a conflict of interest for a particular
Expert, that Expert SHOULD defer to the judgment of the other expert, that expert <bcp14>SHOULD</bcp14> defer to the judgment of the ot
Experts.</t> her
</section> experts.</t>
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The impetus for this specification was a February 2021 discussion on th
e CURDLE mailing list <xref target="CURDLE-MA" format="default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo is entirely about updating the IANA SSH Protocol Parameters r egistry.</t> <t>This memo is entirely about updating the IANA "Secure Shell (SSH) Proto col Parameters" registry.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This memo does not change the Security Considerations for any of the up dated RFCs.</t> <t>This memo does not change the Security Considerations for any of the up dated RFCs.</t>
</section> </section>
</middle> </middle>
<back> <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.x
ml")
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 fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment 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> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
C.2119.xml"?--> />
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4250.xml"
9" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119 />
.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4819.xml"
<front> />
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
le> />
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<seriesInfo name="RFC" value="2119"/> />
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8308.xml"
<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 sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. 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/rfc4
250">
<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 initi
al 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 s
et 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/rfc4
819">
<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 bas
ed on public keys, but does not define any mechanism for key distribution. No co
mmon key management solution exists in current implementations. This document de
scribes a protocol that can be used to configure public keys in an implementatio
n-independent fashion, allowing client software to take on the burden of this co
nfiguration.
</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, i
ncluding 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/rfc8
126">
<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 cons
tants to identify various protocol parameters. To ensure that the values in thes
e fields do not have conflicting uses and to promote interoperability, their all
ocations are often coordinated by a central record keeper. For IETF protocols, t
hat role is filled by the Internet Assigned Numbers Authority (IANA).
</t>
<t>
To make assignments in a given registry prudently, guidance desc
ribing 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 a
uthors, in order to assure that the provided guidance for the IANA Consideration
s 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 522
6.
</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/rfc8
174">
<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 o
nly 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/rfc8
308">
<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 abo
ut supported protocol extensions confidentially after SSH key exchange.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8308"/>
<seriesInfo name="DOI" value="10.17487/RFC8308"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4716" target="https://www.rfc-editor.org/info/rf
c4716"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4716.xml"
<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 for
mat in use for exchanging public keys between different Secure Shell (SSH) imple
mentations.
</t>
<t>
In addition, this document defines a standard textual representa
tion for SSH public key fingerprints. This memo provides information for the Int
ernet community.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4716"/>
<seriesInfo name="DOI" value="10.17487/RFC4716"/>
</reference>
<reference anchor="CURDLE-MA" target="https://mailarchive.ietf.org/arch/ msg/curdle/gdiOlZr9bnrZv8umVyguGG3woIM/"> <reference anchor="CURDLE-MA" target="https://mailarchive.ietf.org/arch/ msg/curdle/gdiOlZr9bnrZv8umVyguGG3woIM/">
<front> <front>
<title>Time to Review IANA SSH Registries Policies?</title> <title>Subject: [Curdle] Time to Review IANA SSH Registries Policies ?</title>
<author initials="S." surname="Turner" fullname="Sean Turner"> <author initials="S." surname="Turner" fullname="Sean Turner">
<organization/> <organization/>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
<refcontent>message to the Curdle mailing list</refcontent>
</reference> </reference>
</references> </references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The impetus for this specification was a February 2021 discussion on th
e CURDLE mailing list <xref target="CURDLE-MA" format="default"/>.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 30 change blocks. 
283 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.48.