





Network Working Group                    Internet Engineering Task Force
Internet-Draft                                      Telnet Working Group
                                                       D. Borman, Editor
                                                     Cray Research, Inc.
                                                           February 1991


                     TTeellnneett DDaattaa EEnnccrryyppttiioonn OOppttiioonn

Status of this Memo

   This draft document will be submitted to the RFC editor as a protocol
   specification.  Distribution of this memo is unlimited.  Please send
   comments to the telnet-ietf@cray.com mailing list.

1.  Command Names and Codes

   ENCRYPT        TBA
       IS               0
       SUPPORT          1
       REPLY            2
       START            3
       END              4
       REQUEST-START    5
       REQUEST-END      6

       NULL             0
       KRBDES           1

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.




Telnet Working Group                                            [Page 1]

Internet-Draft       Telnet Data Encryption Option         February 1991


   IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE

      The sender of this command is stating what 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].

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

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

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

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

   IAC SB ENCRYPT START IAC SE

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

   IAC SB ENCRYPT END IAC SE

      The sender of this command is stating that at this point in the
      data stream, all following data will no longer be encrypted.  Only
      the side of the connection that is WILL ENCRYPT may send the END
      command.

   IAC SB ENCRYPT REQUEST-START IAC SE

      The sender of this command requests that the remote side begin en-
      cryption of the telnet data stream.  Only the side of the connec-
      tion that is DO ENCRYPT may send the REQUEST-START command.

   IAC SB ENCRYPT REQUEST-END IAC SE

      The sender of this command requests that the remote side stop en-
      cryption of the telnet data stream.  Only the side of the connec-
      tion that is DO ENCRYPT may send the REQUEST-END command.


3.  Default Specification

   The default specification for this option is



Telnet Working Group                                            [Page 2]

Internet-Draft       Telnet Data Encryption Option         February 1991


      WONT ENCRYPT
      DONT ENCRYPT

   meaning there will not be any encryption of the Telnet data stream.

4.  Motivation

   The Telnet protocol has no form of protection from some intervening
   gateway looking at IP packets as they travel through the network.
   This is especially dangerous when passwords are sent as clear text
   over the network.  This option provides a method for encrypting part
   or all of the data stream.

   An entire session could be encrypted, but many times the user doesn't
   care that much about most of the data, and would rather not have to
   pay the price of encrypting and decrypting all the data.  In this si-
   tuation, usually all that needs to be protected is when the user is
   typing a password.  When the ENCRYPT option used in conjunction with
   the LINEMODE option, a very simple heuristic can be used to identify
   many instances when passwords are being typed, and automatically en-
   crypt the data stream for the duration of the password.  If the
   client has the LINEMODE option enabled, and the current mode is EDIT,
   but the client is DO ECHO, then it can safely assume that something
   is being typed that is not appearing on the screen, and should be en-
   crypted.

   The front end telnet should have commands to allow the user to turn
   on and off encryption in both directions of the data stream.

   5.  KRBDES: Kerberos DES encryption

   FEED-INIT        1
   FEED-VRFY        2
   FEED-FAIL        3
   FEED-OK          4
   FEED-VRFY-FAIL   5

   To use the ENCRYPT option with this form of DES encryption, either
   the AUTHENTICATION option with a type of KERBEROS_V4 or KERBEROS_V5
   and the NEWKEY suboption must have been done previously, to get a
   unique DES encryption key.  This value will be referred to as the
   "encrypt key" in the rest of this section.  The negotiation of the
   feeds is to ensure that a random feed is used to prime the DES en-
   cryption, and to ensure that encryption and decryption will work be-
   fore the encryption is actually enabled.  This is necessary, because
   once encryption is enabled (especially if encryption is being done in
   both directions), if the receiver is unable to do decryption for some
   reason, encryption can never be turned off and the connection would
   have to be dropped.




Telnet Working Group                                            [Page 3]

Internet-Draft       Telnet Data Encryption Option         February 1991


   There are two DES feed values in this description, feed0 and feed1.
   Feed0 is a random 8 octet value.  Feed1 is gotten by doing a bitwise
   exclusive-or with the first six octets of feed0 with the decimal
   values 75, 82, 66, 68, 69, and 83.  (These values correspond to the
   ASCII codes for the string "KRBDES".) Feed1 is used to initialize the
   encryption of the data.

   IAC SB ENCRYPT IS FEED-INIT <encrypted feed0> IAC SE

      The sender of this command generates a random feed0 value, en-
      crypts it using the encryption key, and sends it to the other side
      in a FEED-INIT command.  The sender should also compute the
      clear-text feed1 value for later use.  FEED-INIT is only sent by
      the side of the connection that is WILL ENCRYPT.

   IAC SB ENCRYPT REPLY FEED-VRFY <encrypted feed1> IAC SE

      When a FEED-INIT command is received, it should be decrypted with
      the encrypt key to get the clear-text feed0 value.  The feed1
      value should then be generated from this.  This feed1 value is
      then encrypted again using the encrypt key, and returned in the
      FEED-VRFY command.  When the other side receives the FEED-VRFY, it
      then decrypts it, and makes sure that the decrypted value matches
      the original clear-text feed1 value.

   IAC SB ENCRYPT IS FEED-FAIL [msg] IAC SE

      If the results from decrypting the data in the FEED-VRFY command
      does not match the original feed1 value that was sent across, a
      FEED-FAIL command is sent to the other side to indicate that the
      initialization failed.

   IAC SB ENCRYPT IS FEED-OK IAC SE

      If the results from decrypting the data in the FEED-VRFY command
      successfully match the original feed1 value that was sent across,
      a FEED-OK command is sent to the other side to indicate that the
      initialization succeeded.  Once this command is sent, the sender
      is then free to send an IAC SB ENCRYPT START IAC SE command at any
      time.

   IAC SB ENCRYPT REPLY FEED-VRFY-FAIL [msg] IAC SE

      If the receiver of the FEED-INIT is not able to decrypt the en-
      crypted feed1 for any reason, then this command is sent to indi-
      cate that the initialization failed.


5.  Implementation Rules




Telnet Working Group                                            [Page 4]

Internet-Draft       Telnet Data Encryption Option         February 1991


   Once the Encryption option is in effect, all data, including TELNET
   options, are encrypted.  Encryption begins with the octet of data im-
   mediately following the "IAC SB ENCRYPT START encryption-type IAC SE"
   command.  Encryption ends after the "IAC SB ENCRYPT END IAC SE" com-
   mand.

   WILL and DO are used only at the beginning of the connection to ob-
   tain and grant permission for future negotiations.  If encryption is
   needed in both directions, then the ENCRYPT option must be negotiated
   in both directions.

   Once the two hosts have exchanged a WILL and a DO, the sender of the
   DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side
   know what types of encryption it is willing to accept.  In the re-
   quest, a list of supported encryption schemes is sent.  Only the
   sender of the DO may send a list of supported encryption types (IAC
   SB ENCRYPT SUPPORT encryption-type-list IAC SE).  Only the sender of
   the WILL may actually transmit encrypted data.  This is initiated via
   the "IAC SB ENCRYPT START IAC SE" command, and terminated via the
   "IAC SB ENCRYPT END IAC SE" command.  If a START is received, and
   then a second START is received before receiving an END, the second
   START is ignored.

   If the sender of the DO would like the remote side to begin sending
   encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE"
   command.  If the sender of the DO would like the remote side to stop
   sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP
   IAC SE" command.

   The current list of encryption types are listed in the current AS-
   SIGNED NUMBERS RFC [1].

   If the receiver of the SUPPORT command does not support any of the
   encryption types listed in the SUPPORT command, it should send an
   "IAC SB ENCRYPT IS NULL IAC SE" to indicate that there is not a com-
   mon encryption type.  It may also send an IAC WONT ENCRYPT command to
   turn off the ENCRYPT option.

   The order of the encryption types in a SUPPORT command must be or-
   dered to indicate a preference for different encryption types, the
   first type being the most preferred, and the last type the least pre-
   ferred.

   If this option is used in conjunction with the LINEMODE [2] option,
   then when the client side has EDIT mode on, and is DO ECHO, it can
   assume that a password has been requested, and automatically start
   encrypting the data stream until either a WONT ECHO has been re-
   ceived, or the EDIT mode has been turned off.

   If the LINEMODE option is not being used, then the server side may



Telnet Working Group                                            [Page 5]

Internet-Draft       Telnet Data Encryption Option         February 1991


   send a REQUEST-START when server side terminal driver has echo dis-
   abled and line editing enabled, and send a REQUEST-END when the ter-
   minal driver has either echo re-enabled, or line editing disabled.

   If the ENCRYPT option has been enabled, and encrypted date is is be-
   ing received, the receipt of an "IAC WONT ENCRYPT" implies the re-
   ceipt of an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream
   is no longer encrypted.

   If the COMPRESSION option is used with the ENCRYPT option, the data
   must be compressed first, and then encrypted.

   The following is an example of use of the option:
       _H_o_s_t_1                            _H_o_s_t_2

       [ Host1 requests Host2 negotiate to encrypt data that it sends to
         Host1, and Host2 verifies that it will negotiate the encryption
         of data that it sends to Host1.  ]
       DO ENCRYPT
                                        WILL ENCRYPT
       [ Host1 requests that Host2 enable encryption as soon as the ini-
         tialization is completed, and informs Host2 that is supports
         KRBDES.  ]
       IAC SB ENCRYPT REQUEST-START IAC
       SE
       IAC SB ENCRYPT SUPPORT KRBDES
       IAC SE
       [ Host2 sends the initial feed to Host1, Host1 decrypts, modi-
         fies, and returns the feed, and Host2 re-verifies the feed.  ]
                                        IAC SB ENCRYPT IS KRBDES
                                        FEED_INIT  144 146 63 229 237
                                        148 81 143 IAC SE
       IAC SB ENCRYPT REPLY KRBDES
       FEED_VRFY  103 207 181 71 224 55
       229 98 IAC SE
                                        IAC SB ENCRYPT IS KRBDES FEED_OK
                                        IAC SE
       [ Host2 is now free to start sending encrypted data, and since a
         REQUEST-START was received, it enables encryption.  ]
                                        IAC SB ENCRYPT START IAC SE
       [ All data from Host2 to Host1 is now encrypted.  ]
                                        IAC SB ENCRYPT END IAC SE
       [ All data from Host2 to Host1 is now in clear text again.  ]

   It is expected that any implementation that supports the Telnet EN-
   CRYPT option will support all of this specification.

6.  References





Telnet Working Group                                            [Page 6]

Internet-Draft       Telnet Data Encryption Option         February 1991


   [1] Reynolds, Joyce, and Postel, Jon, "Assigned Numbers", RFC 1060,
       ISI, March 1990
   [2] Internet Engineering Task Force, "Telnet Linemode Option", RFC
       1116, D. Borman, Editor, Cray Research, Inc., August 1989

Author's Address

   David A. Borman, Editor
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55123

   Phone: (612) 452-6650

   Mailing List: telnet-ietf@CRAY.COM
   EMail: dab@CRAY.COM





































Telnet Working Group                                            [Page 7]

