





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


                     Telnet Data Encryption Option

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         38
       IS               0
       SUPPORT          1
       REPLY            2

       START            3
       END              4
       REQUEST-START    5
       REQUEST-END      6

       ENC_KEYID        7
       DEC_KEYID        8

       NULL             0
       DES_CFB64        1
       DES_OFB64        2

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.



Telnet Working Group                                            [Page 1]

Internet-Draft       Telnet Data Encryption Option            March 1992


   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 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 keyid 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.

      The keyid is a variable length field.  It is my be 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 sig-
      nificant byte first, and a keyid value of zero is reserved to in-
      dicate the default encryption key (this would typically be an en-
      cryption key derived during authentication, with the AUTHENTICA-
      TION option).  The keyid field must be at least one byte long.
      The only valid values for "keyid" will be those that have been re-
      ceived in a DEC_KEYID 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 keyid IAC SE



Telnet Working Group                                            [Page 2]

Internet-Draft       Telnet Data Encryption Option            March 1992


      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.  The
      keyid is only advisory, and my be omitted.

   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.

   IAC SB ENCRYPT ENC_KEYID keyid IAC SE

      The sender of this requests that the remote side verify that "key-
      id" maps to a valid key on the remote side; or verifies that the
      "keyid" received in a DEC_KEYID command is valid.  If keyid is om-
      itted, it implies that there are no more known keyids, and that
      the attempt to find a common keyid has failed.  Only the side of
      the connection that is WILL ENCRYPT may send the ENC_KEYID com-
      mand.

   IAC SB ENCRYPT DEC_KEYID keyid IAC SE

      The sender of this requests that the remote side verify that "key-
      id" maps to a valid key on the remote side; or verifies that the
      "keyid" received in a ENC_KEYID command is valid.  If keyid is om-
      itted, it implies that there are no more known keyids, and that
      the attempt to find a common keyid has failed.  Only the side of
      the connection that is DO ENCRYPT may send the DEC_KEYID command.

   IAC SB ENCRYPT KEYID_OK keyid IAC SE



3.  Default Specification

   The default specification for this option is

      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.



Telnet Working Group                                            [Page 3]

Internet-Draft       Telnet Data Encryption Option            March 1992


   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.  Implementation Rules

   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].




Telnet Working Group                                            [Page 4]

Internet-Draft       Telnet Data Encryption Option            March 1992


   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.  Because the state of
   echoing and editing are sent in two separate telnet commands, if both
   states are changing, the server side of the connection should take
   care to send the WONT ECHO before it sends the the LINEMODE MODE com-
   mand when echoing is being enabled, and when echoing is being dis-
   abled, send the WILL ECHO after it sends the LINEMODE MODE command.
   This will keep the client from needlessly turning on and off encryp-
   tion when the state of both echoing and editing are being enabled or
   disabled.

   If the LINEMODE option is not being used, then the server side may
   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:
       Host1                            Host2

       [ 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
         initialization is completed, and informs Host2 that is supports
         DES_CFB64.  ]
       IAC SB ENCRYPT REQUEST-START IAC



Telnet Working Group                                            [Page 5]

Internet-Draft       Telnet Data Encryption Option            March 1992


       SE
       IAC SB ENCRYPT SUPPORT DES_CFB64
       IAC SE
       [ Host2 sends the initial feed to Host1, Host1 decrypts,
         modifies, and returns the feed, and Host2 re-verifies the feed.
         ]
                                        IAC SB ENCRYPT IS DES_CFB64
                                        FEED_INIT  144 146 63 229 237
                                        148 81 143 IAC SE
       IAC SB ENCRYPT REPLY DES_CFB64
       FEED_VRFY  103 207 181 71 224 55
       229 98 IAC SE
                                        IAC SB ENCRYPT IS DES_CFB64
                                        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.  Security Issues

   The ENCRYPT option is intended to provide protection against passive
   attacks, not against active attacks.  In other words, the ENCRYPT op-
   tion can be used to provide protection from someone who is just
   watching the IP packets as they pass through the network, but may not
   from someone who is able to modify packets in flight.  This is not to
   say that the ENCRYPT option doesn't provide any protection against an
   active attacker, but that additional code and steps would have to be
   done in order to provide compelete protection from an active attack-
   er.  This is especially a problem when most of the telnet data is be-
   ing sent and received in the clear, and the only portion of the data
   stream that is being encrypted are sensitive portions of the data
   stream, like passwords.

6.  References


   [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



Telnet Working Group                                            [Page 6]

Internet-Draft       Telnet Data Encryption Option            March 1992


   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]







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


             Telnet Encryption: DES 64 bit Cipher Feedback

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

   Encryption Type

      DES_CFB64        1

   Suboption Commands

      CFB64_IV         1
      CFB64_IV_OK      2
      CFB64_IV_BAD     3
      CFB64_CHALLENGE  4
      CFB64_RESPONSE   5


2.  Command Meanings

   IAC SB ENCRYPT IS DES_CFB64 CFB64_IV <initial vector> IAC SE

      The sender of this command generates a random 8 byte initial vec-
      tor, and sends it to the other side of the connection using the
      CFB64_IV command.  The initial vector is sent in clear text.  Only
      the side of the connection that is WILL ENCRYPT may send the
      CFB64_IV command.

   IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_OK IAC SE
   IAC SB ENCRYPT REPLY DES_CFB64 CFB64_IV_BAD IAC SE

      The sender of these commands either accepts or rejects the initial
      vector received in a CFB64_IV command.  Only the side of the con-
      nection that is DO ENCRYPT may send the CFB64_IV_OK and
      CFB64_IV_BAD commands.



Telnet Working Group                                            [Page 1]

Internet-Draft         DES 64 bit Cipher Feedback             March 1992


3.  Implementation Rules

   Once a CFB64_IV_OK command has been received, the WILL ENCRYPT side
   of the connection should do keyid negotiation using the ENC_KEYID
   command.  Once the keyid negotiation has successfully identified a
   common keyid, then START and END commands may be sent by the side of
   the connection that is WILL ENCRYPT.  Data will be encrypted using
   the DES 64 bit Cipher Feedback algorithm.

   If encryption (decryption) is turned off and back on again, and the
   same keyid is used when re-starting the encryption (decryption), the
   intervening clear text must not change the state of the encryption
   (decryption) machine.

   If a START command is sent (received) with a different keyid, the en-
   cryption (decryption) machine must be re-initialized immediately fol-
   lowing the end of the START command with the new key and the initial
   vector sent (received) in the last CFB64_IV command.

   If a new CFB64_IV command is sent (received), and encryption (decryp-
   tion) is enabled, the encryption (decryption) machine must be re-
   initialized immediately following the end of the CFB64_IV command
   with the new initial vector, and the keyid sent (received) in the
   last START command.

   If encryption (decryption) is not enabled when a CFB64_IV command is
   sent (received), the encryption (decryption) machine must be re-
   initialized after the next START command, with the keyid sent (re-
   ceived) in that START command, and the initial vector sent (received)
   in this CFB64_IV command.

4.  Algorithm

   Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit
   vector, D[n] is the nth chunk of 64 bits of data to encrypt (de-
   crypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted)
   data, then:

      V[0] = DES(V[i], key)
      O[n] = D[n] <exclusive or> V[n]
      V[n+1] = DES(O[n], key)


Author's Address

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




Telnet Working Group                                            [Page 2]

Internet-Draft         DES 64 bit Cipher Feedback             March 1992


   Phone: (612) 452-6650

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

















































Telnet Working Group                                            [Page 3]







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


             Telnet Encryption: DES 64 bit Output Feedback

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

   Encryption Type

      DES_OFB64        2

   Suboption Commands

      OFB64_IV         1
      OFB64_IV_OK      2
      OFB64_IV_BAD     3
      OFB64_CHALLENGE  4
      OFB64_RESPONSE   5


2.  Command Meanings

   IAC SB ENCRYPT IS DES_OFB64 OFB64_IV <initial vector> IAC SE

      The sender of this command generates a random 8 byte initial vec-
      tor, and sends it to the other side of the connection using the
      OFB64_IV command.  The initial vector is sent in clear text.  Only
      the side of the connection that is WILL ENCRYPT may send the
      OFB64_IV command

   IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_OK IAC SE
   IAC SB ENCRYPT REPLY DES_OFB64 OFB64_IV_BAD IAC SE

      The sender of these commands either accepts or rejects the initial
      vector received in a OFB64_IV command.  Only the side of the con-
      nection that is DO ENCRYPT may send the OFB64_IV_OK and
      OFB64_IV_BAD commands.



Telnet Working Group                                            [Page 1]

Internet-Draft         DES 64 bit Output Feedback             March 1992


3.  Implementation Rules

   Once a OFB64_IV_OK command has been received, the WILL ENCRYPT side
   of the connection should do keyid negotiation using the ENC_KEYID
   command.  Once the keyid negotiation has successfully identified a
   common keyid, then START and END commands may be sent by the side of
   the connection that is WILL ENCRYPT.  Data will be encrypted using
   the DES 64 bit Output Feedback algorithm.

   If encryption (decryption) is turned off and back on again, and the
   same keyid is used when re-starting the encryption (decryption), the
   intervening clear text must not change the state of the encryption
   (decryption) machine.

   If a START command is sent (received) with a different keyid, the en-
   cryption (decryption) machine must be re-initialized immediately fol-
   lowing the end of the START command with the new key and the initial
   vector sent (received) in the last OFB64_IV command.

   If a new OFB64_IV command is sent (received), and encryption (decryp-
   tion) is enabled, the encryption (decryption) machine must be re-
   initialized immediately following the end of the OFB64_IV command
   with the new initial vector, and the keyid sent (received) in the
   last START command.

   If encryption (decryption) is not enabled when a OFB64_IV command is
   sent (received), the encryption (decryption) machine must be re-
   initialized after the next START command, with the keyid sent (re-
   ceived) in that START command, and the initial vector sent (received)
   in this OFB64_IV command.

4.  Algorithm

   Given that V[i] is the initial 64 bit vector, V[n] is the nth 64 bit
   vector, D[n] is the nth chunk of 64 bits of data to encrypt (de-
   crypt), and O[n] is the nth chunk of 64 bits of encrypted (decrypted)
   data, then:

      V[0] = DES(V[i], key)
      V[n+1] = DES(V[n], key)
      O[n] = D[n] <exclusive or> V[n]

Author's Address

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

   Phone: (612) 452-6650



Telnet Working Group                                            [Page 2]

Internet-Draft         DES 64 bit Output Feedback             March 1992


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



















































Telnet Working Group                                            [Page 3]

