idnits 2.17.1 draft-columbia-kermit-service-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 867 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 571 has weird spacing: '...ed into the 7...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 January 2000) is 8858 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'FTP' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'IAN' is defined on line 828, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TKO' -- Possible downref: Non-RFC (?) normative reference: ref. 'KER' -- Possible downref: Non-RFC (?) normative reference: ref. 'CKB' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMG' -- Possible downref: Non-RFC (?) normative reference: ref. 'K95' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRF' -- Possible downref: Non-RFC (?) normative reference: ref. 'IAN' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Frank da Cruz 2 INTERNET-DRAFT Jeffrey E. Altman 3 Columbia University 4 25 January 2000 5 Expires: 25 July 2000 7 INTERNET KERMIT SERVICE 9 DRAFT 02 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference mate- 22 rial or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119. 34 ABSTRACT 36 This document describes a new file transfer service for the Internet 37 based on Telnet Protocol for option negotiation and Kermit Protocol for 38 file transfer and management. The Internet Kermit Service provides 39 access to both authenticated and anonymous users. The use of Kermit 40 protocol over a Telnet connection provides several advantages over FTP, 41 including easy traversal of firewalls, transfers over multiple 42 transports, and security via a combination of supported Telnet 43 authentication and encryption option negotiations, plus significant 44 functional benefits. While this document describes a new service for 45 the Internet, the clients for this service already exist on most 46 platforms in the form of Telnet clients that support the Kermit file 47 transfer protocol. These clients are available not only from Columbia 48 University's Kermit Project but also numerous third parties. 50 CONTENTS 52 0. PREFACE 53 1. INTRODUCTION 54 2. BACKGROUND 55 2.1. History 56 2.2. Motivation 57 3. THE INTERNET KERMIT SERVICE MODEL 58 3.1. Server-Side Kermit Server 59 3.2. Client-Side Kermit Server 60 3.3. Loosely Coupled Operation 61 4. SECURITY CONSIDERATIONS 62 4.1. AUTHENTICATION 63 4.1.1. Telnet Authentication 64 4.1.2. Plaintext Authentication via Kermit REMOTE LOGIN 65 4.1.3. Plaintext Authentication via Command Prompt 66 4.1.4. Anonymous Login 67 4.2. ENCRYPTION (PRIVACY) 68 4.2.1 Telnet Encryption 69 4.2.2 Telnet Start_TLS 70 5. SERVICES 71 5.1. Features for System Administrators 72 5.2. Features for Users 73 5.3. User Interface 74 6. REFERENCES 75 7. AUTHORS' ADDRESS 77 0. PREFACE 79 This Internet-Draft is meant to be used as reference material for the 80 Kermit/Telnet Birds of a Feather session which will be held at the 43rd 81 IETF meeting in Orlando, Florida, USA during the week of 7 December 82 1998. It is hoped that this document will provide necessary background 83 material for serious discussion of this proposed service. Future 84 revisions of this draft will become the standards document after the 85 formation of an appropriate working group. 87 1. INTRODUCTION 89 The Internet Kermit Service is intended to: 91 1. Provide direct access to Kermit file transfer and management 92 services without requiring the user to first login to a shell 93 account; 95 2. Provide Kermit file transfer and management services to anonymous 96 users; 98 3. Provide services to all Telnet clients that support Kermit file 99 transfer protocol via a simple, predictable, scriptable, and 100 well-documented textual interface; 102 4. Provide direct and tightly-coupled access to a Kermit server 103 when requested via the Telnet Kermit Option [TKO]. 105 This draft assumes knowledge of Transmission Control Protocol, the 106 Telnet Protocol [TEL], the Kermit File Transfer Protocol [KER,PRF], 107 Telnet Kermit Option [TKO], and the commands and features of Kermit 108 software [CKB,CMG,K95]. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [BCP]. 114 Definitions: 116 Kermit server 117 A software program that is ready to accept and act upon commands in 118 the form of well-defined Kermit packets [KER]. 120 Kermit client 121 A software program that receives requests through its user interface 122 from a human user (or a script or other source) and translates them 123 to command packets, which it sends to a Kermit server, thus 124 initiating a Kermit protocol transaction such as the transfer of one 125 or more files. 127 2. BACKGROUND 129 2.1. History 131 "Kermit" is the name of an extensible platform- and medium-independent 132 file transfer and management protocol [KER,PRF] and of a suite of 133 communications software programs that implement it and integrate it with 134 other communications functions [CMG,CKB,K95]. 136 The Kermit protocol was first developed at Columbia University in New 137 York City in 1981 for transferring files without errors between diverse 138 types of computers over potentially hostile communication links. Since 139 1981, the Kermit Project at Columbia University has expanded the 140 protocol, developed communications software that implements it upon key 141 platforms, and worked with volunteer programmers at other sites adapting 142 Kermit protocol to other platforms or communication methods. The Kermit 143 Project also serves as the central point of Kermit software development, 144 support, information, and distribution throughout the world. 146 Kermit software is now available for nearly every computer and operating 147 system in existence. The major features of the most popular Kermit 148 programs are: 150 . Connection establishment and maintenance for a variety of connection 151 methods including direct serial, dialup, TCP/IP, X.25, DECnet, and 152 NETBIOS. 154 . Terminal emulation. 156 . Error-free transfer of both text and binary files, individually or 157 in groups. 159 . Character-set translation during both terminal emulation and 160 text-mode file transfer -- a unique feature of Kermit software. 162 . Remote file management through the client/server protocol. 164 . A powerful and portable scripting language allowing complete 165 automation of any task that can be performed manually. 167 Kermit's command and script language is consistent across all platforms 168 and communication methods, thus offering a unified method for 169 accomplishing a wide range of communication tasks manually or under 170 script control. 172 A single Kermit program combines the functions of many different 173 programs such as uucp, cu, tip, telnet, rlogin, ftp, iconv, and expect: 174 it is a Telnet and Rlogin client that can also transfer files; it is a 175 file transfer program that can also convert character sets; it is a 176 dialout program that can use dialing directories and understands country 177 codes and area codes; it is fully scriptable; it offers both 178 client/server and interactive modes of operation. In its desktop 179 versions (particularly for DOS, Windows, and OS/2) it offers all the 180 features of communications software that are usually lacking from 181 Internet client software (key mapping, colors, scrollback, mouse 182 functions, printer control, etc) 184 Kermit software is widely used throughout the academic, government, and 185 corporate spheres, both in the USA and internationally. 187 In addition to the Kermit software developed and/or distributed by the 188 Kermit Project at Columbia University, hundreds of other software 189 products -- commercial, shareware, and freeware -- also include some 190 level of support for the Kermit protocol. Thus there are hundreds, 191 perhaps thousands, of independent and interoperable Kermit protocol 192 implementations based upon the open Kermit protocol specification [KER]. 194 The Internet has formed the primary mechanism by which users and 195 developers of Kermit software have collaborated to produce feature and 196 command sets that continually evolve to meet their needs as technology 197 changes. 199 2.2. Motivation. 201 Kermit protocol and software makes connections from one computer to 202 another and transfers data between them. Countless people "live" in 203 Kermit all day long; as a customizable Telnet or Rlogin (or serial 204 communication) client with a wide selection of terminal emulations and 205 convenience features, it is their window onto the Internet. 207 Others use it in more creative ways, including some that involve key 208 parts of the Internet, e.g. in batch or cron jobs that update news or 209 Web servers or fetch email, or to monitor routers, terminal servers, and 210 hubs and dial pagers when faults are detected. It is used by vendors of 211 telecommunications equipment for remote diagnosis, patching, and 212 updates. Telecom managers often use Kermit scripts to configure PBXs, 213 muxes, routers, or terminal servers. In the world of commerce, Kermit 214 is widely used for financial transactions, EDI, medical claim 215 submission, and so forth. It is used with mobile barcode readers in 216 warehousing and inventory applications. It is found in US Postal 217 Service sorting and scanning equipment. It connects many of the 218 logistics and supply systems throughout the military. It is found in 219 fast-food restaurant cash registers, milling and die-cutting machines, 220 textile looms and cutters, printing presses, and medical diagnostic 221 equipment. It was the communications backbone of the 1994 Brazilian 222 national election -- the largest in history. 224 And yet there has never been a strong, explicit connection of Kermit 225 with the Internet. In the early years, Kermit acted as a kind of 226 do-it-yourself network, enabling ordinary users to make connections that 227 were not already there, and for some years was the predominant method of 228 connecting a personal computer to the ARPAnet (e.g. by dialing a TAC). 230 Nowadays, however, with so many of the world's computers on the 231 Internet, the role of Kermit software and protocol is changing. Kermit 232 users on the network would like to have the features, functions, and 233 interface they are accustomed to -- especially the automation features 234 -- available for use in settings where presently only tools like FTP are 235 available -- and even more so in situations where standard software like 236 FTP can't be used. 238 An Internet Kermit Service can fill this role, and augment the data 239 transfer power and flexibity of other Internet applications such as Web 240 browsers: 242 . Like FTP, Kermit provides a service that can be accessed from many 243 different platforms with a consistent set of commands, but unlike 244 FTP, these commands include programming constructions such as 245 variables, arrays, looping and selection mechanisms, and local and 246 remote procedure calls. 248 . Like FTP, Kermit provides both text- and binary-mode data transfer, 249 as well as file management capabilities. But Kermit also offers 250 numerous features lacking from FTP, such as character-set 251 translation, flexible file selection mechanisms, attribute 252 preservation, and so on (see Section 5.3 for a longer list). 254 . Unlike standard FTP, Kermit can transfer data through multiple 255 firewalls, proxies, and network address translators (NATs) on a 256 single port. 258 . Unlike FTP, Kermit can transfer data across a combination of 259 transports (e.g. dial-up to a terminal server and thence to an 260 Internet host). 262 . Authentication and data transfer can take place over secure 263 connections (mutually authenticated and encrypted) using established 264 Telnet authentication and encryption options. 266 . Unlike traditional Kermit use over Telnet, anonymous access is 267 possible, and the considerable overhead of the intervening Telnet 268 server and pseudoterminal service is eliminated. 270 Until now the primary obstacles to an Internet Kermit Service have been: 272 . Issues of authentication, privacy, and anonymous access. These have 273 been addressed in our implementation, as described Section 4 of this 274 document. 276 . Issues of coordination and control. A Kermit software program can be 277 in any of several "modes": at its command prompt or menu, awaiting 278 commands from the user; in terminal mode, in which the user's 279 keystrokes are sent to the remote computer or service; or in protocol 280 mode, in which two Kermit programs communicate via well-defined 281 Kermit packets [KER]. Commands or operations valid in one mode do 282 not necessarily work in another. Until now, it has been the user's 283 responsibility to switch modes at one or both ends of the connection 284 as needed. A companion draft [TKO] to this one specifies a mechanism 285 to closely couple the client and server via Telnet protocol 286 negotiations, allowing each to know the other's state and to switch 287 to the appropriate mode automatically so a valid and useful 288 relationship obtains at all times. 290 . Lack of a standard TCP port. The "registered" port 1649 was assigned 291 by IANA for this purpose (27 September 1995) and is named "Kermit". 292 (renamed from "Inspect".) 294 3. THE INTERNET KERMIT SERVICE MODEL 296 The Internet Kermit Service (IKS) uses a standard Telnet [TEL] 297 connection, in which all Telnet rules apply. Unlike FTP, which requires 298 additional TCP connections, IKS uses a single channel for both signaling 299 and data transfer. The connection is multiplexed via (a) Telnet 300 options, and (b) Kermit protocol messages. This allows existing Telnet 301 clients that also support the Kermit protocol, whether or not they 302 support the Telnet Kermit Option [TKO], to use the IKS and take 303 advantage of all relevant Telnet options including authentication and 304 encryption. 306 The system Internet services daemon (e.g. inetd) waits for a connection 307 on the Kermit socket (1649) and then starts the IKS on the new 308 connection. The IKS performs the familiar Telnet negotiations including 309 the Telnet Kermit option. Unlike a standard Telnet server, the IKS does 310 not support the ability to present the user with an interactive system 311 shell. The Kermit socket is used only for file transfer and management 312 functions provided by Kermit file transfer protocol and the Kermit 313 script language. 315 Once the connection is established, the Telnet Kermit Option is 316 negotiated in both directions. The results determine which of the 317 following configurations is used by the Telnet client and Server: 319 . Server-side Kermit Server (SKS) 320 . Client-side Kermit Server (CKS) 321 . No Kermit Server (NKS) 323 Different procedures and functions apply to each configuration. The 324 configuration may be changed at any time by Telnet Kermit Option 325 subnegotiations, which assure that the Telnet client and server are 326 always in compatible states. 328 The three configurations are described in the following sections. 330 3.1. Server-Side Kermit Server 332 In the Server-Side Kermit Server (SKS) configuration, the Telnet server 333 is the Kermit server and the Telnet client is the Kermit client. This 334 configuration is used when both Telnet client and IKS support the Telnet 335 Kermit Option and the IKS sends WILL KERMIT to the Telnet client and 336 receives DO KERMIT from the Telnet client [TKO]. 338 In this case, the IKS immediately starts a Kermit server and reports 339 this to the Telnet client with a Telnet KERMIT START-SERVER 340 subnegotiation. 342 The SKS configuration is appropriate when the user wishes to interact 343 only with the Telnet client's commands or menus. 345 If authentication was not performed with one of the Telnet 346 Authentication Option protocols, the Kermit server rejects all Kermit 347 protocol operations (except REMOTE LOGIN, REMOTE HELP, REMOTE EXIT, BYE, 348 or FINISH -- that is, the ones that request help, that log in, that 349 close the connection, or that change the status of the connection) 350 until: 352 . A Kermit REMOTE LOGIN command successfully authenticates the user; 354 . The login retry limit is reached; 356 . A Kermit BYE or REMOTE EXIT command is received, which closes 357 the connection; 359 . A Kermit FINISH command or a Telnet KERMIT REQ-KERMIT-STOP 360 subnegotiation is received to request the IKS exit from Kermit 361 server mode. At this point, the IKS can either exit and close 362 the connection or issue an interactive login prompt, depending 363 on how it was started or configured by the system administrator. 365 Once the user is authenticated: 367 . The Telnet client configures itself for Kermit client/server 368 operation, with itself as the Kermit client, communicating with the 369 server only by Kermit packets, and optionally adjusting its menus or 370 commands to eliminate functions (such as terminal emulation) that 371 make no sense in this context. 373 . The relationship persists until the Telnet client and IKS agree to 374 terminate the Kermit server via Kermit protocol commands (BYE, 375 FINISH, or REMOTE EXIT), or by Telnet Kermit Option subnegotiation, 376 or by closing the connection. 378 3.2. Client-Side Kermit Server 380 In the Client-Side Kermit Server (CKS) configuration, the Telnet server 381 is the Kermit client, and the Telnet client is the Kermit server. This 382 configuration is used when the IKS has sent WONT KERMIT or SB KERMIT 383 STOP-SERVER, and the Telnet Client has sent WILL KERMIT and SB KERMIT 384 START-SERVER, indicating that it is prepared to accept and process 385 Kermit protocol packets. 387 In the CKS configuration, the Telnet client assumes the role of Kermit 388 server by virtue of its ability to recognize and process Kermit protocol 389 packets in its terminal emulator. Thus the Telnet client must not send 390 WILL KERMIT or the KERMIT START-SERVER subnegotiation unless its 391 terminal emulator is capable of recognizing Kermit packets. 393 If the IKS is at top command level (as opposed to executing a script), 394 or when it reaches top level after finishing a script, it issues its 395 interactive command prompt. 397 At the point, the user may type commands or send scripted commands to 398 the IKS command prompt. When a data-transfer command (such as SEND) is 399 issued by the user at the IKS prompt, a Kermit packet is transmitted and 400 recognized by the Telnet client, causing it to automatically perform the 401 requested action (e.g. receive a file), and then resume its previous 402 mode (terminal emulation or script execution) when the data transfer is 403 complete. 405 Thus, in the CKS configuration, data transfers are initiated by the IKS 406 rather than by the Telnet client. This configuration is useful when the 407 user prefers the command interface or repertoire of the server to that 408 of the client. 410 If the IKS sends a Telnet KERMIT START-SERVER subnegotiation, the 411 relationship switches automatically to Server-Side Kermit Server 412 (Section 3.1), in which the Telnet client is the Kermit client and the 413 Telnet server is the Kermit server. 415 If the Telnet client sends a KERMIT STOP-SERVER subnegotiation, the 416 connection switches to No Kermit Server (Section 3.3) and the IKS issues 417 its command prompt. At this point, neither side is a Kermit server, and 418 both sides may optionally disable Kermit protocol commands. Subsequent 419 user action can designate one side or the other as the Kermit server, as 420 desired. 422 3.3. No Kermit Server 424 If both Telnet client and IKS send WONT KERMIT or SB KERMIT STOP-SERVER, 425 or if the Kermit client and server are connected across multiple hosts 426 or transports, thus precluding end-to-end Telnet negotiation, a Kermit 427 server is not known to be available. In the KERMIT STOP-SERVER case, 428 the Kermit partners can later switch back to SKS or CKS, but in the 429 other two cases, there is no such signaling and loose coupling 430 characterizes the entire session. 432 In the No Kermit Server (NKS) configuration, the IKS presents a command 433 prompt to the Telnet client. As in the Client-Side Kermit Server 434 configuration, plain-text commands are issued to the IKS. 436 In the loosely coupled NKS configuration, the Telnet client does not 437 know the state of the Telnet server, and so can not automatically adjust 438 its commands and menus to present only valid choices, or automatically 439 change its state to complement the server's; it is the user's 440 responsibility to assure that the "mode" (command prompt, terminal 441 emulation, server command wait) of each Kermit partner is appropriate 442 for each action. Thus an Internet Kermit Server appears as an ordinary 443 remote Kermit program to any Telnet client that does not implement the 444 Telnet Kermit Option, or in which this feature is disabled or can not be 445 used. 447 The NKS configuration allows successful manual operation of the IKS 448 through Telnet clients that do not support the Telnet Kermit Option. 449 The Telnet client might or might not support Kermit "autodownload" and 450 "autoupload"; if it does not, then the user is forced to manually issue 451 command on both sides of the connection in the traditional and familiar 452 manner [CKB,CMG,K95]. 454 4. SECURITY CONSIDERATIONS 456 4.1. AUTHENTICATION 458 Authentication is provided via one or more of the following methods: 460 . The Telnet AUTHENTICATION option; 462 . The Telnet START_TLS option; 464 . Plaintext userid/password verification. 466 4.1.1. Telnet Authentication option 468 The use of one of the many Telnet authentication option methods removes 469 the need to transmit passwords in plaintext across public networks. In 470 addition, the exchange of user authentication information often provides 471 a shared secret that can be used with the Telnet Encryption Option 472 protocols to encrypt the connection in one or both directions. 474 Telnet authentication may also be used in conjunction with the Telnet 475 START_TLS option to negotiate end user identity over the encrypted and 476 host authenticated TLS channel. 478 The IKS currently supports Kerberos 4, Kerberos 5, Secure Remote Password 479 and Microsoft NTLM authentication methods via the Telnet AUTH option. 481 4.1.2. Telnet over TLS option 483 The Telnet START_TLS option provides for the negotiation and establishment 484 of a TLS version 1 session after the initial telnet connection. The TLS 485 connection provides host to client authentication via the use and X.509 486 certificate chains. TLS also supports optional client to host 487 authentication using host verified X.509 certificates which may be used 488 to authenticate a userid provided by the client or be mapped to a userid 489 based upon properties of the certificate. 491 4.1.3. Plaintext Authentication via Kermit REMOTE LOGIN 493 In the Server-Side Kermit Server configuration, if the client is not yet 494 authenticated, the client must log in using a REMOTE LOGIN command, in 495 which a Kermit packet containing user ID and password in clear text is 496 sent from the Telnet client to the Telnet server, which then calls upon 497 local mechanisms to authenticate the user. Any packets other than login 498 (or REMOTE HELP, REMOTE EXIT, FINISH, or BYE) packets are rejected 499 (returned with an error message) until the user is authenticated. If 500 the number of unsuccessful login attempts exceeds the limit, the 501 connection is closed. Many Kermit client programs support this login 502 method already. 504 This method should be avoided whenever possible. If plaintext passwords 505 are used, they should only be sent after the Telnet START-TLS option has 506 been negotiated. (see 4.2.2) Otherwise, passwords are open to packet 507 sniffing. 509 4.1.4. Plaintext Authentication via Command Prompt 511 In the Client-Side Kermit Server and No Kermit Server configurations, 512 the server presents the user with a plain-text interactive interface 513 that begins with the server issuing "Username:" and "Password:" prompts, 514 just as if the user were logging in to a multiuser timesharing system 515 such as VMS or UNIX. When a password is not required an empty response 516 can be given. Invalid username-password combinations result in a new 517 series of prompts up to the login retry limit, and then disconnection. 519 This method should be avoided whenever possible. If plaintext passwords 520 are used, they should only be sent after the Telnet START-TLS option has 521 been negotiated. (see 4.2.2) Otherwise, passwords are open to packet 522 sniffing. 524 4.1.5. Anonymous Login 526 When the username is "anonymous" or "ftp", the IKS behaves like an 527 anonymous ftp server, in a manner appropriate to the underlying 528 platform. In UNIX, for example, access is restricted to a designated 529 area of the file system. A password might or might not be required, 530 according to the preference of the site administrator. 532 If privacy is desired the Telnet START-TLS option should be used. (see 533 4.2.2) 535 4.2. ENCRYPTION (PRIVACY) 537 As the Internet becomes ever more public and susceptible to 538 eavesdropping, it becomes increasingly necessary to provide methods for 539 private access to services. Telnet provides two such mechansims: 541 . Telnet Encryption option 542 . Telnet START-TLS option 544 4.2.1. Telnet Encryption option 546 The Telnet Encryption option, although it has never achieved RFC status, 547 has been used for years in conjunction with the Telnet Auth option in 548 Telnet clients and servers that support Kerberos 4, Kerberos 5, Secure 549 Remote Password, and others. The IKS currently supports the following 550 encryption methods under the Telnet Encryption option: 552 . cast128_ofb64 553 . cast5_40_ofb64 554 . des_ofb64 555 . cast128_cfb64 556 . cast5_40_cfb64 557 . des_cfb64 559 4.2.2. Telnet over TLS option 561 Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), 562 provides methods to implement Server authentication, Client authentication, 563 and Transport Layer encryption. Unlike Telnet Encryption, Start-TLS does 564 require the use of Telnet Authentication in order to provide a private 565 channel. This means that it can be used in conjunction with plaintext 566 passwords and anonymous connections. 568 5. SERVICES 570 The Internet Kermit Service includes features for both users and system 571 administrators. The IKS is incorporated into the 7.0 release of 572 Columbia University's C-Kermit software, which is the "master" Kermit 573 software program in terms of features and command language. An overview 574 of C-Kermit can be found at: 576 http://www.columbia.edu/kermit/ckermit.html 577 http://www.kermit-project.org/ckermit.html 579 When C-Kermit is employed as an Internet Kermit Service, it may offer 580 all its functions to "real" users (those who are authenticated as 581 specific users), and a safe subset of its functions to anonymous users. 583 The Internet Kermit Service resembles an FTP server in that it performs 584 its own authentication and uses a well-defined protocol to communicate 585 with its client, but differs from the FTP server by also offering (at 586 the system manager's discretion) an interactive user interface to the 587 Telnet client when it is in terminal mode. It also differs from FTP in 588 restricting all protocol messages and data transfer to a single socket 589 connection. 591 An IKS has been deployed at Columbia University for worldwide public access 592 to the Kermit FTP site: 594 telnet://kermit.columbia.edu:1649/ 595 telnet://ftp.kermit-project.org:1649/ 597 5.1. Features for System Administrators 599 The system administrator can supply IKS configuration parameters as 600 command-line options or in a configuration file, or both in combination. 601 Such parameters include: 603 . Whether anonymous logins are allowed. 605 . The file system or root directory to which anonymous users are 606 restricted. 608 . Specification of permissions and other attributes to be assigned to 609 files uploaded by anonymous users. 611 . Whether to make session entries in system logs. 613 . Specific services to disable: reception of files, sending of files, 614 sending of email, printing, changing of directories, getting 615 directory listings, deleting files, etc (see next section). 617 . Whether access to the interactive command prompt is allowed. 619 5.2. Features for Users 621 The IKS supports a wide range of services, including, but not limited 622 to, the following: 624 . Authentication as a real user or anonymously. 626 . Transmission of files to which read access is allowed. 628 . Reception of files into directories or devices to which write access 629 is allowed. 631 . The ability to display a file on the client's screen. 633 . Ability to list files. 635 . Ability to change its working (default) directory. 637 . Ability to delete files to which write or delete access is allowed. 639 . Ability to rename and copy files 641 . Ability to create and remove directories. 643 . The ability to route received files to a specified printer, or to 644 send them as email to a specified address list. 646 . Client control of server parameter settings, within limits 647 established by the server system administrator. 649 . Transmission of variables from client to server or vice versa. 651 . Remote and local script execution. 653 . Remote and local procedure execution. 655 File transfer features include: 657 . Kermit text-mode transfers incorporate not only record-format 658 conversion, but also character-set translation; 660 . Kermit can switch automatically between text and binary mode on a 661 per-file basis when sending groups of files by matching each file's 662 name with a pattern list. 664 . A selection of file collision options, including "make backup copy 665 of existing file and accept incoming file", "reject incoming file", 666 "accept incoming file only if newer than existing file", etc. 668 . Numerous methods for selecting the files to be transferred, including 669 pattern matching, lists of filenames (or patterns), exception lists, 670 date and/or size ranges, etc. 672 . Filename conversion and file renaming. 674 . Automatic directory creation if elected and enabled. 676 . Standard mechanisms for directory traversal, allowing transmission of 677 entire directory trees or other file hierarchies even between unlike 678 file systems such as VMS, UNIX, and Windows. 680 . Atomic file movement: optionally, the source file can be deleted 681 (or renamed, or moved) when and only when it has been transferred 682 successfully. 684 . Kermit can retain file attributes including time stamps and 685 permissions (at the user's or system administrator's discretion), 686 even between unlike platforms; 688 . Recovery of interrupted transfers from the point of failure. 690 . File-transfer pipes and filters. 692 Script programming features include: 694 . Macros with parameter substitution. 696 . Built-in and user-defined variables and arrays, with global 697 or local scope. 699 . Built-in and user-defined functions. Built-in functions include: 700 - String functions 701 - Arithmetic functions 702 - Date / time functions 703 - File functions 705 . Input search for multiple simultaneous targets. 707 . IF-ELSE, WHILE, FOR, SWITCH, GOTO, C-like block structure. 709 . Every command returns a completion status that may be tested 710 and used as a basis for subsequent actions. 712 5.3. User Interface 714 The Internet Kermit Service uses the Kermit command and script language, 715 as implemented in Columbia University's C-Kermit communication software 716 [CKB]. This program and its command language are portable to all known 717 varieties of UNIX, as well as to Windows 95/98/NT, OS/2, Digital 718 (Open)VMS, Stratus VOS, Data General AOS/VS, Plan 9, OS-9, QNX, the 719 Commodore Amiga, and other platforms. The C-Kermit command language is 720 a superset of that of other Kermit software programs including MS-DOS 721 Kermit for DOS and Windows 3.x, IBM Mainframe Kermit for VM/CMS, 722 MVS/TSO, CICS, and MUSIC, PDP-11 Kermit for RT-11, RSTS/E, RSX-11, and 723 IAS, and dozens of other Kermit programs. 725 It is far beyond the scope of this document to enumerate, let alone 726 describe, the commands and services of C-Kermit; this is the subject of 727 a 600-page book [CKB], augmented by hundreds of pages of online 728 material. A brief overview is included here. 730 Commands are based on English words. There is no plan at present to 731 support other natural languages (Italian, Portuguese, Norwegian, 732 Russian, Hebrew, Japanese, Cherokee, etc) as alternative bases for 733 command words, since this would reduce the portability of scripts. 734 However, since the command language includes a macro capability, macros 735 may be defined to provide selected commands in different languages if 736 desired. 738 Certain commands can apply either locally or remotely, for example "CD" 739 (Change Directory). The convention is to prefix the command with the 740 word REMOTE if it is to apply remotely. Example: "cd foo" changes to 741 the "foo" directory on the computer where the command was given; "remote 742 cd foo" sends a Kermit packet to the Kermit server requesting it to 743 change its directory to "foo". The commands in this category include: 745 ASSIGN Assign a value to a variable. 746 CD Change working directory. 747 COPY Copy file(s) 748 DELETE Delete file(s) 749 DIRECTORY [ ] List file(s) 750 EXIT Exit 751 HELP [ ] Display help text 752 MKDIR Create a directory 753 PRINT Print file(s) 754 PWD Print working directory 755 RENAME Rename file(s) 756 RMDIR Remove a directory 757 SET Change a parameter's value 758 TYPE Display the contents of a file 760 As a convenience, REMOTE commands also have short synonyms: RASSIGN, 761 RCD, RCOPY, RDELETE, and so forth. 763 The basic file transfer commands are: 765 SEND [ modifiers ] Send file(s) (to server) 766 GET [ modifiers ] Get file(s) (from server) 768 These commands take a file name, pattern, or list, plus various optional 769 modifiers, including transfer mode specifiers (text, binary), file 770 selectors (date, size, exception list), aliasing, name and path options, 771 disposition specifiers, and so on. 773 In addition to the commands listed above, the following commands are 774 sent by the client to the server: 776 REMOTE QUERY Get value of variable or procedure 777 BYE Log out and close the connection 778 FINISH Request the server leave server mode 780 Like all Kermit client/server commands, these can be disabled if 781 desired. 783 Of course there are numerous other commands with purely local effect, 784 such as the many scripting commands. These, plus all the commands 785 above, are fully documented in [CKB]. The repertoire grows over time, 786 but never in a way that invalidates existing scripts. 788 The system administrator can allow or forbid access to any of these 789 features, and to the command language as a whole. In the latter case, 790 the IKS may be accessed only as a Kermit server, by giving commands to 791 the client. 793 6. REFERENCES 795 [TKO] Altman, Jeffrey E., and Frank da Cruz, 796 Telnet Kermit Option, 797 Internet Draft , 798 August 1998. 800 [BCP] Bradner, Scott, RFC 2119, "Best Current Practice", March 1997. 802 [KER] da Cruz, Frank, "Kermit, A File Transfer Protocol", Digital Press/ 803 Butterworth Heinemann, Newton, MA (1987). 379 pages, 804 ISBN 0-932376-88-6. 806 [CKB] da Cruz, Frank, and Christine M. Gianone, "Using C-Kermit", Second 807 Edition, Digital Press / Butterworth-Heinemann, Woburn, MA (1997). 808 622 pages, ISBN 1-55558-164-1. 810 [CMG] Gianone, Christine M., "Using MS-DOS Kermit", Second Edition, 811 Digital Press / Butterworth-Heinemann, Woburn, MA (1992). 345 812 pages, ISBN 1-55558-082-3. 814 [K95] Gianone, Christine M., and Frank da Cruz, "Kermit 95", Manning 815 Publications, Greenwich CT, (1996). 88 pages, ISBN 1-884777-14-7. 817 [PRF] Huggins, James K., "Kermit Protocol - Formal Specification and 818 Verification", in Boerger, E., "Specification and Validation 819 Methods", Oxford University Press (1995). ISBN 0-19-853854-5. 821 [FTP] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", 822 RFC959, October 1985. 824 [TEL] Postel, J., and J. Reynolds, "Telnet Protocol Specification", 825 RFC854, May 1983, et seq.; "Telnet Option Specification", 826 RFC855, May 1983, et seq. 828 [IAN] Internet Assigned Numbers Authority: 829 http://www.iana.org/numbers.html 830 http://www.iana.org/assignment/port-numbers 832 7. AUTHORS' ADDRESS 834 Frank da Cruz 835 fdc@columbia.edu 837 Jeffrey E. Altman 838 jaltman@columbia.edu 840 The Kermit Project 841 Columbia University 842 612 West 115th Street 843 New York NY 10025-7799 844 USA 845 http://www.columbia.edu/kermit/ 846 http://www.kermit-project.org/ 848 (end) 850 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 851 The Kermit Project * Columbia University 852 612 West 115th St #716 * New York, NY * 10025 853 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org