rfc2839.txt

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

   The three configurations are described in the following sections.

3.1. Server-Side Kermit Server

   In the Server-Side Kermit Server (SKS) configuration, the Telnet
   server is the Kermit server and the Telnet client is the Kermit
   client.  This configuration is used when both Telnet client and IKS
   support the Telnet Kermit Option and the IKS sends WILL KERMIT to the
   Telnet client and receives DO KERMIT from the Telnet client [TKO].

   In this case, the IKS immediately starts a Kermit server and reports
   this to the Telnet client with a Telnet KERMIT START-SERVER
   subnegotiation.




da Cruz & Altman             Informational                      [Page 7]

RFC 2839                Internet Kermit Service                 May 2000


   The SKS configuration is appropriate when the user wishes to interact
   only with the Telnet client's commands or menus.

   If authentication was not performed with one of the Telnet
   Authentication Option protocols, the Kermit server rejects all Kermit
   protocol operations (except REMOTE LOGIN, REMOTE HELP, REMOTE EXIT,
   BYE, or FINISH -- that is, the ones that request help, that log in,
   that close the connection, or that change the status of the
   connection) until:

   - A Kermit REMOTE LOGIN command successfully authenticates the user;

   - The login retry limit is reached;

   - A Kermit BYE or REMOTE EXIT command is received, which closes the
      connection;

   - A Kermit FINISH command or a Telnet KERMIT REQ-KERMIT-STOP
      subnegotiation is received to request the IKS exit from Kermit
      server mode.  At this point, the IKS can either exit and close the
      connection or issue an interactive login prompt, depending on how
      it was started or configured by the system administrator.

   Once the user is authenticated:

   - The Telnet client configures itself for Kermit client/server
      operation, with itself as the Kermit client, communicating with
      the server only by Kermit packets, and optionally adjusting its
      menus or commands to eliminate functions (such as terminal
      emulation) that make no sense in this context.

   - The relationship persists until the Telnet client and IKS agree to
      terminate the Kermit server via Kermit protocol commands (BYE,
      FINISH, or REMOTE EXIT), or by Telnet Kermit Option
      subnegotiation, or by closing the connection.

3.2. Client-Side Kermit Server

   In the Client-Side Kermit Server (CKS) configuration, the Telnet
   server is the Kermit client, and the Telnet client is the Kermit
   server.  This configuration is used when the IKS has sent WONT KERMIT
   or SB KERMIT STOP-SERVER, and the Telnet Client has sent WILL KERMIT
   and SB KERMIT START-SERVER, indicating that it is prepared to accept
   and process Kermit protocol packets.

   In the CKS configuration, the Telnet client assumes the role of
   Kermit server by virtue of its ability to recognize and process
   Kermit protocol packets in its terminal emulator.  Thus the Telnet



da Cruz & Altman             Informational                      [Page 8]

RFC 2839                Internet Kermit Service                 May 2000


   client must not send WILL KERMIT or the KERMIT START-SERVER
   subnegotiation unless its terminal emulator is capable of recognizing
   Kermit packets.

   If the IKS is at top command level (as opposed to executing a
   script), or when it reaches top level after finishing a script, it
   issues its interactive command prompt.

   At this point, the user may type commands or send scripted commands
   to the IKS command prompt.  When a data-transfer command (such as
   SEND) is issued by the user at the IKS prompt, a Kermit packet is
   transmitted and recognized by the Telnet client, causing it to
   automatically perform the requested action (e.g. receive a file), and
   then resume its previous mode (terminal emulation or script
   execution) when the data transfer is complete.

   Thus, in the CKS configuration, data transfers are initiated by the
   IKS rather than by the Telnet client.  This configuration is useful
   when the user prefers the command interface or repertoire of the
   server to that of the client.

   If the IKS sends a Telnet KERMIT START-SERVER subnegotiation, the
   relationship switches automatically to Server-Side Kermit Server
   (Section 3.1), in which the Telnet client is the Kermit client and
   the Telnet server is the Kermit server.

   If the Telnet client sends a KERMIT STOP-SERVER subnegotiation, the
   connection switches to No Kermit Server (Section 3.3) and the IKS
   issues its command prompt.  At this point, neither side is a Kermit
   server, and both sides may optionally disable Kermit protocol
   commands.  Subsequent user action can designate one side or the other
   as the Kermit server, as desired.

3.3. No Kermit Server

   If both Telnet client and IKS send WONT KERMIT or SB KERMIT STOP-
   SERVER, or if the Kermit client and server are connected across
   multiple hosts or transports, thus precluding end-to-end Telnet
   negotiation, a Kermit server is not known to be available.  In the
   KERMIT STOP-SERVER case, the Kermit partners can later switch back to
   SKS or CKS, but in the other two cases, there is no such signaling
   and loose coupling characterizes the entire session.

   In the No Kermit Server (NKS) configuration, the IKS presents a
   command prompt to the Telnet client.  As in the Client-Side Kermit
   Server configuration, plain-text commands are issued to the IKS.





da Cruz & Altman             Informational                      [Page 9]

RFC 2839                Internet Kermit Service                 May 2000


   In the loosely coupled NKS configuration, the Telnet client does not
   know the state of the Telnet server, and so can not automatically
   adjust its commands and menus to present only valid choices, or
   automatically change its state to complement the server's; it is the
   user's responsibility to assure that the "mode" (command prompt,
   terminal emulation, server command wait) of each Kermit partner is
   appropriate for each action.  Thus an Internet Kermit Server appears
   as an ordinary remote Kermit program to any Telnet client that does
   not implement the Telnet Kermit Option, or in which this feature is
   disabled or can not be used.

   The NKS configuration allows successful manual operation of the IKS
   through Telnet clients that do not support the Telnet Kermit Option.
   The Telnet client might or might not support Kermit "autodownload"
   and "autoupload"; if it does not, then the user is forced to manually
   issue command on both sides of the connection in the traditional and
   familiar manner [CKB,CMG,K95].

4. SECURITY CONSIDERATIONS

4.1. AUTHENTICATION

   Authentication is provided via one or more of the following methods:

    - The Telnet AUTHENTICATION option;

    - The Telnet START_TLS option;

    - Plaintext userid/password verification.

4.1.1. Telnet Authentication option

   The use of one of the many Telnet authentication option methods
   removes the need to transmit passwords in plaintext across public
   networks.  In addition, the exchange of user authentication
   information often provides a shared secret that can be used with the
   Telnet Encryption Option protocols to encrypt the connection in one
   or both directions.

   Telnet authentication may also be used in conjunction with the Telnet
   START_TLS option to negotiate end user identity over the encrypted
   and host authenticated TLS channel.

   The IKS currently supports Kerberos 4, Kerberos 5, Secure Remote
   Password and Microsoft NTLM authentication methods via the Telnet
   AUTH option.





da Cruz & Altman             Informational                     [Page 10]

RFC 2839                Internet Kermit Service                 May 2000


4.1.2. Telnet over TLS option

   The Telnet START_TLS option provides for the negotiation and
   establishment of a TLS version 1 session after the initial telnet
   connection.  The TLS connection provides host to client
   authentication via the use of X.509 certificate chains.  TLS also
   supports optional client to host authentication using host verified
   X.509 certificates which may be used to authenticate a userid
   provided by the client or be mapped to a userid based upon properties
   of the certificate.

4.1.3. Plaintext Authentication via Kermit REMOTE LOGIN

   In the Server-Side Kermit Server configuration, if the client is not
   yet authenticated, the client must log in using a REMOTE LOGIN
   command, in which a Kermit packet containing user ID and password in
   clear text is sent from the Telnet client to the Telnet server, which
   then calls upon local mechanisms to authenticate the user.  Any
   packets other than login (or REMOTE HELP, REMOTE EXIT, FINISH, or
   BYE) packets are rejected (returned with an error message) until the
   user is authenticated.  If the number of unsuccessful login attempts
   exceeds the limit, the connection is closed.  Many Kermit client
   programs support this login method already.

   This method should be avoided whenever possible.  If plaintext
   passwords are used, they should only be sent after the Telnet START-
   TLS option has been negotiated (see 4.2.2).  Otherwise, passwords are
   open to packet sniffing.

4.1.4. Plaintext Authentication via Command Prompt

   In the Client-Side Kermit Server and No Kermit Server configurations,
   the server presents the user with a plain-text interactive interface
   that begins with the server issuing "Username:" and "Password:"
   prompts, just as if the user were logging in to a multiuser
   timesharing system such as VMS or UNIX.  When a password is not
   required an empty response can be given.  Invalid username-password
   combinations result in a new series of prompts up to the login retry
   limit, and then disconnection.

   This method should be avoided whenever possible.  If plaintext
   passwords are used, they should only be sent after the Telnet START-
   TLS option has been negotiated (see 4.2.2).  Otherwise, passwords are
   open to packet sniffing.







da Cruz & Altman             Informational                     [Page 11]

RFC 2839                Internet Kermit Service                 May 2000


4.1.5. Anonymous Login

   When the username is "anonymous" or "ftp", the IKS behaves like an
   anonymous ftp server, in a manner appropriate to the underlying
   platform.  In UNIX, for example, access is restricted to a designated
   area of the file system.  A password might or might not be required,
   according to the preference of the site administrator.

   If privacy is desired the Telnet START-TLS option should be used (see
   4.2.2).

4.2.  ENCRYPTION (PRIVACY)

   As the Internet becomes ever more public and susceptible to
   eavesdropping, it becomes increasingly necessary to provide methods
   for private access to services.  Telnet provides two such mechanisms:

    . Telnet Encryption option
    . Telnet START-TLS option

4.2.1.  Telnet Encryption option

   The Telnet Encryption option, although it has never achieved RFC
   status, has been used for years in conjunction with the Telnet Auth
   option in Telnet clients and servers that support Kerberos 4,
   Kerberos 5, Secure Remote Password, and others.  The IKS currently
   supports the following encryption methods under the Telnet Encryption
   option:

    .  cast128_ofb64
    .  cast5_40_ofb64
    .  des_ofb64
    .  cast128_cfb64
    .  cast5_40_cfb64
    .  des_cfb64

4.2.2. Telnet over TLS option

   Transport Layer Security (TLS), the successor to Secure Sockets Layer
   (SSL), provides methods to implement Server authentication, Client
   authentication, and Transport Layer encryption.  Unlike Telnet
   Encryption, Start-TLS does not require the use of Telnet
   Authentication in order to provide a private channel.  This means
   that it can be used in conjunction with plaintext passwords and
   anonymous connections.






da Cruz & Altman             Informational                     [Page 12]

RFC 2839                Internet Kermit Service                 May 2000


5. SERVICES

   The Internet Kermit Service includes features for both users and
   system administrators.  The IKS is incorporated into  the 7.0 release
   of Columbia University's C-Kermit software, which is the "master"
   Kermit software program in terms of features and command language.
   An overview of C-Kermit can be found at:

     http://www.columbia.edu/kermit/ckermit.html
     http://www.kermit-project.org/ckermit.html

   When C-Kermit is employed as an Internet Kermit Service, it may offer
   all its functions to "real" users (those who are authenticated as
   specific users), and a safe subset of its functions to anonymous
   users.

   The Internet Kermit Service resembles an FTP server in that it
   performs its own authentication and uses a well-defined protocol to
   communicate with its client, but differs from the FTP server by also
   offering (at the system manager's discretion) an interactive user
   interface to the Telnet client when it is in terminal mode.  It also
   differs from FTP in restricting all protocol messages and data
   transfer to a single socket connection.

   An IKS has been deployed at Columbia University for worldwide public
   access to the Kermit FTP site:

     telnet://kermit.columbia.edu:1649/
     telnet://ftp.kermit-project.org:1649/

5.1. Features for System Administrators

   The system administrator can supply IKS configuration parameters as
   command-line options or in a configuration file, or both in
   combination.  Such parameters include:

    . Whether anonymous logins are allowed.

    . The file system or root directory to which anonymous users are
      restricted.

    . Specification of permissions and other attributes to be assigned
      to files uploaded by anonymous users.

    . Whether to make session entries in system logs.






da Cruz & Altman             Informational                     [Page 13]

RFC 2839                Internet Kermit Service                 May 2000


    . Specific services to disable: reception of files, sending of
      files, sending of email, printing, changing of directories,
      getting directory listings, deleting files, etc (see next
      section).

    . Whether access to the interactive command prompt is allowed.

5.2. Features for Users

   The IKS supports a wide range of services, including, but not limited
   to, the following:

    . Authentication as a real user or anonymously.

    . Transmission of files to which read access is allowed.