Telnet Data Encryption Option
RFC 2946

Document Type RFC - Proposed Standard (September 2000; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2946 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           T. Ts'o
Request for Comments: 2946                             VA Linux Systems
Category: Standards Track                                September 2000

                     Telnet Data Encryption Option

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document describes a the telnet encryption option as a generic
   method of providing data confidentiality services for the telnet data
   stream.  While this document summarizes currently utilized encryption
   types and codes, it does not define a specific encryption algorithm.
   Separate documents are to be published defining implementations of
   this option for each encryption algorithm.

1.  Command Names and Codes

   ENCRYPT         38

       Encryption Commands
       IS               0
       SUPPORT          1
       REPLY            2
       START            3
       END              4
       REQUEST-START    5
       REQUEST-END      6
       ENC_KEYID        7
       DEC_KEYID        8

       Encryption Types
       NULL             0
       DES_CFB64        1
       DES_OFB64        2

Ts'o                        Standards Track                     [Page 1]
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                     [Page 2]
RFC 2946             Telnet Data Encryption Option        September 2000

      it is impossible to know if the selected encryption type can be
      properly initialized based upon the type and length of the key
      that is available."

   IAC SB ENCRYPT IS encryption-type ... IAC SE

      The sender of this command is stating which type of encryption to
      use, and any initial data that is needed.  Only the side of the
      connection that is WILL ENCRYPT may send the IS command to
      initialize the encryption-type scheme.

   IAC SB ENCRYPT REPLY encryption-type ... IAC SE

      The sender of this command is continuing the initial data exchange
      in order to initialize the encryption-type scheme.  Only the side
      of the connection that is DO ENCRYPT may send the REPLY command.

   IAC SB ENCRYPT START keyid IAC SE

      The sender of this command is stating that all data following the
      command in the data stream will be be encrypted via the previously
      negotiated method of data encryption.  Only the side of the
      connection that is WILL ENCRYPT may send the START command.

      The keyid is a variable length field.  It is used by various
      encryption mechanisms to identify which encryption key is to be
      used, when multiple encryption keys might be known on either side
      of the connection.  The keyid field is encoded with the most
Show full document text