<?xml version="1.0" encoding="US-ASCII"?>
<!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 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">
]>
<?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 category="bcp" obsoletes="4325" docName="draft-ietf-curdle-rc4-die-die-die-11" ipr="trust200902">
 <!-- 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="draft-ietf-curdle-rc4-die-die-die">Deprecating RC4 in Secure Shell (SSH)</title>

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

   <!-- Another author who claims to be an editor -->

   <author fullname="Luis Camara" initials="L.C." 
           surname="Camara">
     <organization></organization>

     <address>
       <postal>
         <street></street>

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

         <city></city>

         <region></region>

         <code></code>

         <country></country>
       </postal>

       <phone></phone>

       <email>luis.camara@live.com.pt</email>

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

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

     <address>
       <postal>
         <street></street>

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

         <city></city>

         <region></region>

         <code></code>

         <country>Mauritius</country>
       </postal>

       <phone></phone>

       <email>loganaden@gmail.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>
   <date year="2018" />



   <!-- Meta-data Declarations -->

   <area>General</area>

   <workgroup>Internet Engineering Task Force</workgroup>

   <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 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 or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
     <t>   This document deprecates RC4 in Secure Shell (SSH).  Therefore, this
   document formally obsoletes and moves to Historic <xref target="RFC4345"></xref>.
 </t>
   </abstract>
 </front>

 <middle>
   <section title="Introduction">
     <t>The usage of RC4 suites ( also designated as arcfour ) for SSH are specified in <xref target="RFC4253"></xref> and <xref target="RFC4345"></xref>. 
     <xref target="RFC4253"></xref> specifies the allocation of the "arcfour" cipher for SSH. <xref target="RFC4345"></xref> specifies and allocates the 
     the "arcfour-128" and "arcfour-256" ciphers for SSH. 

     RC4 encryption is steadily weakening in cryptographic strength <xref target="RFC7465"></xref> <xref target="I-D.ietf-curdle-des-des-des-die-die-die"></xref>, 
     and the deprecation process should be begun for their use in Secure Shell (SSH) <xref target="RFC4253"></xref>. Accordingly, <xref target="RFC4253"></xref> is 
     updated to note the deprecation of the RC4 ciphers and <xref target="RFC4345"></xref> is moved to Historic as all ciphers it specifies MUST NOT be used.  </t>

     <section title="Requirements Language">
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref
       target="RFC2119">RFC 2119</xref>.</t>
     </section>
   </section>

<section title="Updates to RFC 4253">
<t>
<xref target="RFC4253"></xref> is updated to prohibit arcfour's use in SSH.
<xref target="RFC4253"></xref> allocates the "arcfour" cipher in Section 6.3 by defining a list of defined ciphers where the "arcfour" cipher appears as optional as mentioned below: 
</t>
<texttable>
        <ttcol ></ttcol>
        <ttcol ></ttcol>
        <ttcol ></ttcol>

    <c>arcfour           </c>  
    <c>OPTIONAL            </c>
     <c>the ARCFOUR stream cipher with a 128-bit key </c> 
</texttable>
<t>
The current document updates the status of the "arcfour" ciphers in the list of <xref target="RFC4253"></xref> Section 6.3 by moving it from OPTIONAL to MUST NOT. 
</t>
<texttable>
        <ttcol ></ttcol>
        <ttcol ></ttcol>
        <ttcol ></ttcol>
 <c> arcfour </c>       <c>MUST NOT </c>        <c> the ARCFOUR stream cipher with a 128-bit key</c>
</texttable>

<t>
<xref target="RFC4253"></xref> defines the "arcfour" ciphers with the text mentioned below: 
</t>
<t>
   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>.  Arcfour (and RC4) has problems with weak keys, and
   should be used with caution.
</t>  
<t>
The current document updates <xref target="RFC4253"></xref> Section 6.3 by replacing the text above with the following text:
</t>
<t> 
  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>.  Arcfour (and RC4) is steadily weakening in cryptographic strength <xref target="RFC7465"></xref> <xref target="I-D.ietf-curdle-des-des-des-die-die-die"></xref>, and
   MUST NOT be used.
</t>
</section>
 


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

   <section anchor="IANA" title="IANA Considerations">
     <t>The IANA is requested to update the Encryption Algorithm Name  Registry of the Secure Shell (SSH) Protocol Parameters [IANA]. 
The Registration procedure is IETF Review which is achieved by this document. The registry should be updated as follows:</t>
<texttable>
<ttcol>Encryption </ttcol> <ttcol>Algorithm  Name   Reference   Note</ttcol> 
<c>arcfour</c>                         <c> [RFC-TBD]</c>     
<c>arcfour128 </c>                 <c>   [RFC-TBD] </c>    
<c>arcfour256 </c>                  <c>   [RFC-TBD] </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 Daniel Migault and Rich Salz. </t>

   </section>
   <section anchor="Security" title="Security Considerations">
     <t>This document only prohibits the use of RC4 in SSH, and 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;
   <reference anchor="SCHNEIER" target="SCHNEIER">
        <front>
            <title>Applied Cryptography Second Edition:
                  protocols algorithms and source in code in C </title>
            <author initials="B.S" surname="Schneier" fullname="Bruce Schneier">
                <organization />
            </author>
            <date month="" year="1996" />
        </front>
        <seriesInfo name="" value="" />
    </reference>

 
   </references>

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


     &RFC5226;

     &RFC4345;

     &RFC4253;

    &RFC7465;

   <reference anchor='I-D.ietf-curdle-des-des-des-die-die-die'>
<front>
<title>Deprecate 3DES and RC4 in Kerberos</title>

<author initials='B' surname='Kaduk' fullname='Benjamin Kaduk'>
    <organization />
</author>

<author initials='M' surname='Short' fullname='Michiko Short'>
    <organization />
</author>

<date month='September' day='18' year='2017' />

<abstract><t>The 3DES and RC4 encryption types are steadily weakening in cryptographic strength, and the deprecation process should be begun for their use in Kerberos.  Accordingly, RFC 4757 is moved to Historic status, as none of the encryption types it specifies should be used, and RFC 3961 is updated to note the deprecation of the triple-DES encryption types.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-curdle-des-des-des-die-die-die-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-curdle-des-des-des-die-die-die-05.txt' />
</reference>



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

   </references>


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

 -->
 </back>
</rfc>
