RFC 2946 (rfc2946) - Page 2 of 8

Telnet Data Encryption Option

RFC 2946             Telnet Data Encryption Option        September 2000


       DES3_CFB64       3
       DES3_OFB64       4
       CAST5_40_CFB64   8
       CAST5_40_OFB64   9
       CAST128_CFB64   10
       CAST128_OFB64   11

       Following historical practice, future encryption type numbers
       will be assigned by the IANA under a First Come First Served
       policy as outlined by RFC 2434 [3].  Despite the fact that
       authentication type numbers are allocated out of an 8-bit number
       space (as are most values in the telnet specification) it is not
       anticipated that the number space is or will become in danger of
       being exhausted.  However, if this should become an issue, when
       over 50% of the number space becomes allocated, the IANA shall
       refer allocation requests to either the IESG or a designated
       expert for approval.

2.  Command Meanings

   IAC WILL ENCRYPT

      The sender of this command is willing to send encrypted data.

   IAC WONT ENCRYPT

      The sender of this command refuses to send encrypted data.

   IAC DO ENCRYPT

      The sender of this command is willing to receive encrypted data.

   IAC DONT ENCRYPT

      The sender of this command refuses to accept encrypted data.

   IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE

      The sender of this command is stating which types of encryption it
      will support.  Only the side of the connection that is DO ENCRYPT
      may send the SUPPORT command.  The current types of encryption are
      listed in the current version of the Assigned Numbers document
      [1].

      The encryption-type-list may only include types which can actually
      be supported during the current session.  If ENCRYPT is negotiated
      in conjunction with AUTH the SUPPORT message MUST NOT be sent
      until after the session key has been determined.  Otherwise,



Ts'o                        Standards Track