rfc2946.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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
      significant byte first, and a keyid value of zero is reserved to
      indicate the default encryption key (this would typically be an
      encryption key derived during authentication, with the
      AUTHENTICATION option).  The keyid field must be at least one byte
      long.  The only valid values for "keyid" will be those that have
      been received in a DEC_KEYID command.

   IAC SB ENCRYPT END IAC SE

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

   IAC SB ENCRYPT REQUEST-START keyid IAC SE

      The sender of this command requests that the remote side begin
      encryption of the telnet data stream.  Only the side of the
      connection that is DO ENCRYPT may send the REQUEST-START command.
      The keyid is only advisory, and my be omitted.




Ts'o                        Standards Track                     [Page 3]

RFC 2946             Telnet Data Encryption Option        September 2000


   IAC SB ENCRYPT REQUEST-END IAC SE

      The sender of this command requests that the remote side stop
      encryption of the telnet data stream.  Only the side of the
      connection 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
      "keyid" maps to a valid key; or verifies that the "keyid" received
      in a DEC_KEYID command is valid.  If keyid is omitted, 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 command.

   IAC SB ENCRYPT DEC_KEYID keyid IAC SE

      The sender of this requests that the remote side verify that
      "keyid" 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
      omitted, 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.

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 the
   data stream.

5.  Implementation Rules

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



Ts'o                        Standards Track                     [Page 4]