<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!--<!ENTITY RFC5226 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"> -->

<!ENTITY RFC4345 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4345.xml">
<!ENTITY RFC4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY RFC7465 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7465.xml">
<!ENTITY RFC8429 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8429.xml">
]> "rfc2629-xhtml.ent">
<?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. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" updates="4253"
     docName="draft-ietf-curdle-rc4-die-die-die-18" ipr="trust200902"> ipr="trust200902"
     obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true"
     tocDepth="4" symRefs="true" sortRefs="true" version="3" number="8758" consensus="true" >

<!-- 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 ***** xml2rfc v2v3 conversion 2.40.1 -->
  <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="draft-ietf-curdle-rc4-die-die-die">Deprecating abbrev="Deprecating RC4 in SSH">Deprecating RC4 in Secure Shell (SSH)</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor -->
    <seriesInfo name="RFC" value="8758"/>
    <seriesInfo name="BCP" value="227"/>

   <author fullname="Loganaden Velvindron" initials="L.V." initials="L." surname="Velvindron">
      <organization>cyberstorm.mu</organization>
      <address>
        <postal>
         <street></street>

         <!-- Reorder these if your country does things differently -->

         <city></city>

         <region></region>

         <code></code>
          <street/>
         <city/>
          <region/>
          <code/>
          <country>Mauritius</country>
        </postal>

       <phone></phone>
        <phone/>
        <email>logan@cyberstorm.mu</email>

       <!-- uri and facsimile elements may also be added -->

     </address>
    </author>
    <date year="2019" />

   <!-- Meta-data Declarations year="2020" month="April"/>

   <area>Security</area>
    <workgroup>curdle</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

   <area>General</area>

   <workgroup>Internet Engineering Task Force</workgroup>

<keyword>example</keyword>

<!-- WG name at [rfced] When version 16 was approved, the upperleft corner of authors indicated there might
be some updates needed to address IESG comments.  We assume these have been
addressed in the doc,
        IETF is fine for individual submissions. updated versions.  If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>template</keyword>

   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text incorrect, please either send
along changes or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for update the search engine. XML file.
-->

   <abstract>
     <t>   This
      <t>This document deprecates RC4 in Secure Shell (SSH).  Therefore, this
   document formally moves RFC4345 RFC 4345 to historic Historic status.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The usage of RC4 suites ( also (also designated as arcfour ) "arcfour") for SSH are is
      specified in <xref target="RFC4253"></xref> target="RFC4253" format="default"/> and <xref target="RFC4345"></xref>.
      target="RFC4345" format="default"/>.
     <xref target="RFC4253"></xref> target="RFC4253" format="default"/> specifies the allocation of the "arcfour" cipher for SSH. <xref target="RFC4345"></xref> target="RFC4345" format="default"/> specifies and allocates
     the "arcfour128" and "arcfour256" ciphers for SSH.
     RC4 encryption has known weaknesses <xref target="RFC7465"></xref> target="RFC7465"
     format="default"/> <xref target="RFC8429"></xref>,
     and target="RFC8429" format="default"/>; therefore,
     this document starts the deprecation process should be begun for their use in Secure Shell
     (SSH) <xref target="RFC4253"></xref>. target="RFC4253" format="default"/>. Accordingly, <xref target="RFC4253"></xref>
     target="RFC4253" format="default"/> is
     updated to note the deprecation of the RC4 ciphers ciphers, and <xref target="RFC4345"></xref>
     target="RFC4345" format="default"/> is moved to Historic status, as all ciphers
      it specifies MUST NOT <bcp14>MUST NOT</bcp14> be used.  </t>
      <section title="Requirements Language">
       <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD 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&nbsp;14 <xref target="RFC2119"/>
    <xref
       target="RFC2119">RFC 2119</xref><xref
       target="RFC8174">RFC 8174</xref> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

      </section>
    </section>
    <section title="Updates numbered="true" toc="default">
      <name>Updates to RFC 4253"> 4253</name>
      <t>
<xref target="RFC4253"></xref> target="RFC4253" format="default"/> is updated to prohibit arcfour's use in SSH.
<xref target="RFC4253"></xref> target="RFC4253" sectionFormat="comma" section="6.3"/> allocates the
"arcfour" cipher in Section 6.3 by defining a list of defined ciphers where in which the "arcfour"
cipher appears as optional optional, as mentioned below: shown in <xref target="OPTIONAL" />.
</t>
<texttable>
        <ttcol ></ttcol>
        <ttcol ></ttcol>
        <ttcol ></ttcol>

    <c>arcfour           </c>
    <c>OPTIONAL            </c>
     <c>the
      <table align="center" anchor="OPTIONAL">
        <tbody>
          <tr>
            <td align="left">arcfour</td>
            <td align="left"><bcp14>OPTIONAL</bcp14></td>
            <td align="left">the ARCFOUR stream cipher with a 128-bit key </c>
</texttable> key</td>
          </tr>
        </tbody>
      </table>
      <t>
This current document updates the status of the "arcfour" ciphers in the list of
found in <xref target="RFC4253"></xref> Section 6.3 target="RFC4253" sectionFormat="comma" section="6.3"/> by moving it
from OPTIONAL <bcp14>OPTIONAL</bcp14> to MUST NOT. <bcp14>MUST NOT</bcp14>.
</t>
<texttable>
        <ttcol ></ttcol>
        <ttcol ></ttcol>
        <ttcol ></ttcol>
 <c>
      <table align="center">
        <tbody>
          <tr>
            <td align="left"> arcfour </c>       <c>MUST NOT </c>        <c> </td>
            <td align="left"><bcp14>MUST NOT</bcp14> </td>
            <td align="left"> the ARCFOUR stream cipher with a 128-bit key</c>
</texttable> key</td>
          </tr>
        </tbody>
      </table>
      <t>
<xref target="RFC4253"></xref> target="RFC4253" format="default"/> defines the "arcfour" ciphers with
the text mentioned below: following text:
</t>
<t>
<blockquote>
   The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. The
   Arcfour cipher is believed to be compatible with the RC4 cipher <xref target= "SCHNEIER"></xref>. target="SCHNEIER"
   format="default"/>.  Arcfour (and RC4) has problems with weak keys, and
   should be used with caution.
</t> caution.</blockquote>

      <t>
This current document updates <xref target="RFC4253"></xref> Section 6.3 target="RFC4253" sectionFormat="comma"
section="6.3"/> by replacing the text above with the following text:
</t>
<t>
<blockquote>
  The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys.
   The Arcfour cipher is compatible with the RC4 cipher
   <xref target= "SCHNEIER"></xref>. target="SCHNEIER" format="default"/>.  Arcfour (and RC4) has known weaknesses <xref target="RFC7465"></xref> target="RFC7465" format="default"/> <xref target="RFC8429"></xref>, target="RFC8429" format="default"/> and
   MUST NOT
   <bcp14>MUST NOT</bcp14> be used.
</t>
</blockquote>
    </section>

   <!-- Possibly a 'Contributors' section ... -->

   <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>The IANA is requested to update has updated the Encryption "Encryption Algorithm Name  Registry of Names"
      subregistry in the Secure "Secure Shell (SSH) Protocol Parameters Parameters" registry <xref target="IANA"/>.
      target="IANA" format="default"/>. The Registration registration procedure is IETF Review
      review, which is achieved by this document. The registry should be has been
      updated as follows:</t>
<texttable>
<ttcol>Encryption
      <table align="center">
        <thead>
          <tr>
            <th align="left">Encryption Algorithm  Name </ttcol> <ttcol> Reference</ttcol> <ttcol>   Note</ttcol>
<c>arcfour</c>                         <c> [RFC-TBD]</c>   <c> </c>
<c>arcfour128 </c>                 <c>   [RFC-TBD] </c>  <c> </c>
<c>arcfour256 </c>                  <c>   [RFC-TBD] </c>  <c> </c>
</texttable>

<t>Where TBD is the RFC number assigned to the document. </t>

<!--
     <t>All drafts are required to have an IANA considerations section (see
     <xref target="RFC5226">Guidelines for Writing an IANA Considerations Section in RFCs</xref> for a guide). If the draft does not require IANA to do
     anything, the section contains an explicit statement that this is the
     case (as above). If there are no requirements for IANA, the section will
     be removed during conversion into an RFC by the RFC Editor.</t>
-->

</section>

   <section anchor="Acknowledgements" title="Acknowledgements">
     <t>The authors would like to thank Eric Rescorla, Daniel Migault and Rich Salz. </t> Name</th>
            <th align="left">Reference</th>
            <th align="left">Note</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">arcfour</td>
            <td align="left">RFC 8758</td>
            <td align="left">HISTORIC</td>
          </tr>
          <tr>
            <td align="left">arcfour128 </td>
            <td align="left">RFC 8758</td>
            <td align="left">HISTORIC</td>
          </tr>
          <tr>
            <td align="left">arcfour256 </td>
            <td align="left">RFC 8758</td>
            <td align="left">HISTORIC</td>
          </tr>
        </tbody>
      </table>

</section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document only prohibits the use of RC4 in SSH, and SSH; it introduces no
   new security considerations.</t>
    </section>

  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>
   <!-- References split into informative and normative -->

   <references title="Normative References">
     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC2119;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?-->
     &RFC8174;
   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

     <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
     <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->

<!--&RFC5226;-->

     &RFC4345;

     &RFC4253;

    &RFC7465;

    &RFC8429;

     <!-- A reference written by by an organization not a person. -->
      <references>

        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4345.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4253.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7465.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8429.xml"/>

   <reference anchor="SCHNEIER" target="SCHNEIER"> target="">
          <front>
            <title>Applied Cryptography Second Edition:
                  protocols algorithms Protocols, Algorithms,
	    and source Source in code Code in C </title>
            <seriesInfo name="John Wiley and Sons" value="New York, NY"/>
            <author initials="B.S" initials="B." surname="Schneier" fullname="Bruce Schneier">
                <organization />
              <organization/>
            </author>
            <date month="" year="1996" /> year="1996"/>
          </front>
        <seriesInfo name="" value="" />
        </reference>

        <reference anchor="IANA" target="https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-17">
		   target="https://www.iana.org/assignments/ssh-parameters">
          <front>
            <title>Secure Shell (SSH) Protocol Parameters: Encryption Algorithm Names</title> Parameters</title>
            <author/>
    <date/>
          </front>
        </reference>
      </references>

   <!-- Change Log
v08 update email address.
v07 reproduce -06 of luis' draft + update with daniel's comments

 -->
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The author would like to thank <contact fullname="Eric Rescorla"/>,
      <contact fullname="Daniel Migault"/>, and <contact fullname="Rich Salz"/>.</t>
    </section>

 </back>
</rfc>