home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / id-enc-03.txt < prev    next >
Text File  |  2020-01-01  |  15KB  |  401 lines
  1. Network Working Group                                    T. Ts'o, Editor
  2. Internet-Draft                                          VA Linux Systems
  3. draft-tso-telnet-encryption-03.txt                           August 1999
  4.  
  5.  
  6.                      Telnet Data Encryption Option
  7.  
  8. Status of this Memo
  9.  
  10.    This document is an Internet-Draft and is in full conformance with
  11.    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
  12.    documents of the Internet Engineering Task Force (IETF), its areas,
  13.    and its working groups.  Note that other groups may also distribute
  14.    working documents as Internet-Drafts.
  15.  
  16.    Internet-Drafts are draft documents valid for a maximum of six months
  17.    and may be updated, replaced, or obsoleted by other documents at any
  18.    time.  It is inappropriate to use Internet-Drafts as reference
  19.    material or to cite them other than as "work in progress."
  20.  
  21.    The list of current Internet-Drafts can be accessed at
  22.    http://www.ietf.org/ietf/1id-abstracts.txt
  23.  
  24.    The list of Internet-Draft Shadow Directories can be accessed at
  25.    http://www.ietf.org/shadow.html.
  26.  
  27.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  28.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  29.    document are to be interpreted as described in RFC 2119.
  30.  
  31. 0.  Abstract
  32.  
  33.    This document describes a the telnet encryption option as a generic
  34.    method of providing data confidentiaility services of the telnet data
  35.    stream.   While this document summarizes currently utilized encrytion
  36.    types and codesit does not define a specific encryption algorithm.
  37.    Separate documents are to be published defining each encryption algo-
  38.    rithms.
  39.  
  40. 1.  Command Names and Codes
  41.  
  42.    ENCRYPT         38
  43.  
  44.        Encryption Commands
  45.        IS               0
  46.        SUPPORT          1
  47.        REPLY            2
  48.  
  49.  
  50.  
  51.                          Expires February 19100                 [Page 1]
  52.  
  53. Internet-Draft        Telnet Data Encryption Option          August 1999
  54.  
  55.  
  56.        START            3
  57.        END              4
  58.        REQUEST-START    5
  59.        REQUEST-END      6
  60.  
  61.        ENC_KEYID        7
  62.        DEC_KEYID        8
  63.  
  64.        Encryption Types
  65.        NULL             0
  66.        DES_CFB64        1
  67.        DES_OFB64        2
  68.        DES3_CFB64       3
  69.        DES3_OFB64       4
  70.        CAST5_40_CFB64   8
  71.        CAST5_40_OFB64   9
  72.        CAST128_CFB64   10
  73.        CAST128_OFB64   11
  74.  
  75.        Following historical practice, future encryption type numbers
  76.        will be assigned by the IANA under a First Come First Served pol-
  77.        icy as outlined by RFC 2434 [3].  Despite the fact that authenti-
  78.        cation type numbers are allocated out of an 8-bit number space
  79.        (as are most values in the telnet specification) it is not antic-
  80.        ipated that the number space is or will become in danger of being
  81.        exhausted.  However, if this should become an issue, when over
  82.        50% of the number space becomes allocated, the IANA shall refer
  83.        allocation requests to either the IESG or a designated expert for
  84.        approval.
  85.  
  86.        The current list of encryption types is listed in
  87.        http://www.isi.edu/in-notes/iana/assignments/telnet-options.
  88.  
  89. 2.  Command Meanings
  90.  
  91.    IAC WILL ENCRYPT
  92.  
  93.       The sender of this command is willing to send encrypted data.
  94.  
  95.    IAC WONT ENCRYPT
  96.  
  97.       The sender of this command refuses to send encrypted data.
  98.  
  99.    IAC DO ENCRYPT
  100.  
  101.       The sender of this command is willing to receive encrypted data.
  102.  
  103.    IAC DONT ENCRYPT
  104.  
  105.       The sender of this command refuses to accept encrypted data.
  106.  
  107.  
  108.  
  109.                          Expires February 19100                 [Page 2]
  110.  
  111. Internet-Draft        Telnet Data Encryption Option          August 1999
  112.  
  113.  
  114.    IAC SB ENCRYPT SUPPORT encryption-type-list IAC SE
  115.  
  116.       The sender of this command is stating what types of encryption it
  117.       will support.  Only the side of the connection that is DO ENCRYPT
  118.       may send the SUPPORT command.  The current types of encryption are
  119.       listed in the current version of the Assigned Numbers document[1].
  120.  
  121.    IAC SB ENCRYPT IS encryption-type ... IAC SE
  122.  
  123.       The sender of this command is stating what type of encryption to
  124.       use, and any initial data that is needed.  Only the side of the
  125.       connection that is WILL ENCRYPT may send the IS command.  to ini-
  126.       tialize the encryption-type scheme.
  127.  
  128.    IAC SB ENCRYPT REPLY encryption-type ... IAC SE
  129.  
  130.       The sender of this command is continuing the initial data exchange
  131.       that is needed to initialize the encryption-type scheme.  Only the
  132.       side of the connection that is DO ENCRYPT may send the REPLY com-
  133.       mand.
  134.  
  135.    IAC SB ENCRYPT START keyid IAC SE
  136.  
  137.       The sender of this command is stating that at this point in the
  138.       data stream, all following data will be encrypted, via the previ-
  139.       ously negotiated method of data encryption.  Only the side of the
  140.       connection that is WILL ENCRYPT may send the START command.
  141.  
  142.       The keyid is a variable length field.  It is my be used by various
  143.       encryption mechanisms to identify which encryption key is to be
  144.       used, when multiple encryption keys might be known on either side
  145.       of the connection.  The keyid field is encoded with the most sig-
  146.       nificant byte first, and a keyid value of zero is reserved to in-
  147.       dicate the default encryption key (this would typically be an en-
  148.       cryption key derived during authentication, with the AUTHENTICA-
  149.       TION option).  The keyid field must be at least one byte long.
  150.       The only valid values for "keyid" will be those that have been re-
  151.       ceived in a DEC_KEYID command.
  152.  
  153.    IAC SB ENCRYPT END IAC SE
  154.  
  155.       The sender of this command is stating that at this point in the
  156.       data stream, all following data will no longer be encrypted.  Only
  157.       the side of the connection that is WILL ENCRYPT may send the END
  158.       command.
  159.  
  160.    IAC SB ENCRYPT REQUEST-START keyid IAC SE
  161.  
  162.       The sender of this command requests that the remote side begin en-
  163.       cryption of the telnet data stream.  Only the side of the connec-
  164.  
  165.  
  166.  
  167.                          Expires February 19100                 [Page 3]
  168.  
  169. Internet-Draft        Telnet Data Encryption Option          August 1999
  170.  
  171.  
  172.       tion that is DO ENCRYPT may send the REQUEST-START command.  The
  173.       keyid is only advisory, and my be omitted.
  174.  
  175.    IAC SB ENCRYPT REQUEST-END IAC SE
  176.  
  177.       The sender of this command requests that the remote side stop en-
  178.       cryption of the telnet data stream.  Only the side of the connec-
  179.       tion that is DO ENCRYPT may send the REQUEST-END command.
  180.  
  181.    IAC SB ENCRYPT ENC_KEYID keyid IAC SE
  182.  
  183.       The sender of this requests that the remote side verify that
  184.       "keyid" maps to a valid key on the remote side; or verifies that
  185.       the "keyid" received in a DEC_KEYID command is valid.  If keyid is
  186.       omitted, it implies that there are no more known keyids, and that
  187.       the attempt to find a common keyid has failed.  Only the side of
  188.       the connection that is WILL ENCRYPT may send the ENC_KEYID com-
  189.       mand.
  190.  
  191.    IAC SB ENCRYPT DEC_KEYID keyid IAC SE
  192.  
  193.       The sender of this requests that the remote side verify that
  194.       "keyid" maps to a valid key on the remote side; or verifies that
  195.       the "keyid" received in a ENC_KEYID command is valid.  If keyid is
  196.       omitted, it implies that there are no more known keyids, and that
  197.       the attempt to find a common keyid has failed.  Only the side of
  198.       the connection that is DO ENCRYPT may send the DEC_KEYID command.
  199.  
  200.  
  201. 3.  Default Specification
  202.  
  203.    The default specification for this option is
  204.  
  205.       WONT ENCRYPT
  206.       DONT ENCRYPT
  207.  
  208.    meaning there will not be any encryption of the Telnet data stream.
  209.  
  210. 4.  Motivation
  211.  
  212.    The Telnet protocol has no form of protection from some intervening
  213.    gateway looking at IP packets as they travel through the network.
  214.    This is especially dangerous when passwords are sent as clear text
  215.    over the network.  This option provides a method for encrypting the
  216.    data stream.
  217.  
  218. 5.  Implementation Rules
  219.  
  220.    Once the Encryption option is in effect, all data in the negotiated
  221.    direction, including TELNET options, is encrypted.  Encryption begins
  222.  
  223.  
  224.  
  225.                          Expires February 19100                 [Page 4]
  226.  
  227. Internet-Draft        Telnet Data Encryption Option          August 1999
  228.  
  229.  
  230.    with the octet of data immediately following the "IAC SB ENCRYPT
  231.    START encryption-type IAC SE" command.  Encryption ends after the
  232.    "IAC SB ENCRYPT END IAC SE" command.
  233.  
  234.    WILL and DO are used only at the beginning of the connection to ob-
  235.    tain and grant permission for future negotiations.  The ENCRYPT op-
  236.    tion must be negotiated in both directions.
  237.  
  238.    Once the two hosts have exchanged a WILL and a DO, the sender of the
  239.    DO ENCRYPT must send a ENCRYPT SUPPORT command to let the remote side
  240.    know what types of encryption it is willing to accept.  In the re-
  241.    quest, a list of supported encryption schemes is sent.  Only the
  242.    sender of the DO may send a list of supported encryption types (IAC
  243.    SB ENCRYPT SUPPORT encryption-type-list IAC SE).  Only the sender of
  244.    the WILL may actually transmit encrypted data.  This is initiated via
  245.    the "IAC SB ENCRYPT START IAC SE" command, and terminated via the
  246.    "IAC SB ENCRYPT END IAC SE" command.  If a START is received, and
  247.    then a second START is received before receiving an END, the second
  248.    START is ignored.
  249.  
  250.    If the sender of the DO would like the remote side to begin sending
  251.    encrypted data, it can send the "IAC SB ENCRYPT REQUEST-START IAC SE"
  252.    command.  If the sender of the DO would like the remote side to stop
  253.    sending encrypted data, it can send the "IAC SB ENCRYPT REQUEST-STOP
  254.    IAC SE" command.
  255.  
  256.    If the receiver of the SUPPORT command does not support any of the
  257.    encryption types listed in the SUPPORT command, it should send an
  258.    "IAC SB ENCRYPT IS NULL IAC SE" to indicate that there is not a com-
  259.    mon encryption type.  It may also send an IAC WONT ENCRYPT command to
  260.    turn off the ENCRYPT option.
  261.  
  262.    The order of the encryption types in a SUPPORT command must be or-
  263.    dered to indicate a preference for different encryption types, the
  264.    first type being the most preferred, and the last type the least pre-
  265.    ferred.
  266.  
  267.    If the ENCRYPT option has been enabled, and encrypted data is being
  268.    received, the receipt of an "IAC WONT ENCRYPT" implies the receipt of
  269.    an "IAC SB ENCRYPT END IAC SE", e.g., the Telnet data stream is no
  270.    longer encrypted.
  271.  
  272.    The following is an example of use of the option:
  273.        Host1                            Host2
  274.  
  275.        [ Host1 requests Host2 negotiate to encrypt data that it sends to
  276.          Host1, and Host2 verifies that it will negotiate the encryption
  277.          of data that it sends to Host1.  ]
  278.        DO ENCRYPT
  279.                                         WILL ENCRYPT
  280.  
  281.  
  282.  
  283.                          Expires February 19100                 [Page 5]
  284.  
  285. Internet-Draft        Telnet Data Encryption Option          August 1999
  286.  
  287.  
  288.        [ Host1 requests that Host2 enable encryption as soon as the
  289.          initialization is completed, and informs Host2 that is supports
  290.          DES_CFB64.  ]
  291.        IAC SB ENCRYPT REQUEST-START IAC
  292.        SE
  293.        IAC SB ENCRYPT SUPPORT DES_CFB64
  294.        IAC SE
  295.        [ Host2 sends the initial feed to Host1, and Host1 acknowledges
  296.          receipt of the IV.  ]
  297.                                         IAC SB ENCRYPT IS DES_CFB64
  298.                                         CFB64_IV  144 146 63 229 237 148
  299.                                         81 143 IAC SE
  300.        IAC SB ENCRYPT REPLY DES_CFB64
  301.        CFB64_IV_OK  103 207 181 71 224
  302.        55 229 98 IAC SE
  303.        [ Host2 is now free to start sending encrypted data, and since a
  304.          REQUEST-START was received, it enables encryption.  ]
  305.                                         IAC SB ENCRYPT START IAC SE
  306.        [ All data from Host2 to Host1 is now encrypted.  ]
  307.                                         IAC SB ENCRYPT END IAC SE
  308.        [ All data from Host2 to Host1 is now in clear text again.  ]
  309.  
  310.    It is expected that any implementation that supports the Telnet EN-
  311.    CRYPT option will support all of this specification.
  312.  
  313. 6.  Security Considerations
  314.  
  315.    The ENCRYPT option used in isolation provides protection against pas-
  316.    sive attacks, but not against active attacks.  In other words, it
  317.    will  provide protection from someone who is just watching the IP
  318.    packets as they pass through the network.  However, an attacker who
  319.    is able to modify packets in flight could prevent the ENCRYPT option
  320.    from being negotiated.
  321.  
  322.    This flaw can be remedied by using the Telnet Authentication option
  323.    alongside the ENCRYPT option.  Specifically, setting ENCRYPT_US-
  324.    ING_TELOPT in the authentication-type-pair can be used to force that
  325.    Encryption be negotiated even in the face of active attacks.
  326.  
  327.    In addition, an active attacker can interfere with attempts to start
  328.    or restart encryption.  If encryption is requested by the user, and
  329.    the client is unable to negotiate enabling or re-enabling encryption,
  330.    the client must assume that it is being attacked, and MUST immediate-
  331.    ly terminate the telnet connection.
  332.  
  333. 6. TFhuetusrpeecdiifrieccattiioonnsdfeofrinTeeslnaetmeEtnhcordypftoironproviding data confidentiality
  334.    to the telnet data stream.  Unfortunately all of the encryption mech-
  335.    anism provided under this option do not provide data integrity, be-
  336.    cause of the complexity of specifying a protocol which provided in-
  337.    tegrity services efficiently in a stream-oriented protocol.
  338.  
  339.  
  340.  
  341.                          Expires February 19100                 [Page 6]
  342.  
  343. Internet-Draft        Telnet Data Encryption Option          August 1999
  344.  
  345.  
  346.    The TELNET_OVER_TLS specification provides a scheme which provides
  347.    confidentiality, integrity, and compression, and future work for tel-
  348.    net encryption should closely examine using this specification.  One
  349.    promising approach would use the anonymous Diffie-Hellman mode of
  350.    TLS, followed by the telnet AUTHENTICATION option where the authenti-
  351.    cation mechanism would include a signed hash of the Diffie-Hellman
  352.    keying material negotiated by the TLS layer.
  353.  
  354. 7.  Acknowledgments
  355.  
  356.    This document was originally written by Dave Borman of Cray Research,
  357.    with the assistance of Theodore Ts'o of MIT and the IETF Telnet Work-
  358.    ing Group.
  359.  
  360. 8.  References
  361.  
  362.  
  363.    [1] Reynolds, Joyce, and Postel, Jon, "Telnet Protocol Specifica-
  364.        tion", RFC 854, May 1983.
  365.    [2] Internet Engineering Task Force, "Telnet Authentication", draft-
  366.        tso-telnet-auth-enc-03.txt, T. Ts'o, Editor, VA Linux Systems,
  367.        August 1999.
  368.    [3] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
  369.        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  370.  
  371. Author's Address
  372.  
  373.    Theodore Ts'o, Editor
  374.    VA Linux Systems
  375.    43 Pleasant St.
  376.    Medford, MA 02155
  377.  
  378.    Phone: (781) 391-3464
  379.  
  380.    EMail: tytso@mit.edu
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.                                                                 [Page 7]
  400.  
  401.