idnits 2.17.1 draft-rfced-exp-atmar-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 256 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** There are 8 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES DEC 1998 INTERNET DRAFT 2 Network Working Group 4 Wirt Atmar 5 AICS Research, Inc. 6 University Park, NM 88003 8 Jeff Bandle 9 Hewlett-Packard Company 10 Commercial Systems Division 11 Lawrence, KS 66049 13 July, 1998 15 TELNET SUPPRESS LOCAL ECHO OPTION 16 18 Status of This Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as 29 "work in progress." 31 To view the entire list of current Internet-Drafts, please check 32 the "1id-abstracts.txt" listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 34 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 35 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 36 (US West Coast). 38 Distribution of this document is unlimited. 40 1. Command Name and Code 42 SUPPRESS-LOCAL-ECHO (SLE) 45 44 2. Command Meanings 46 IAC WILL SUPRESS-LOCAL-ECHO 48 The sender of this command, generally a device operating as an NVT 49 (network virtual terminal) terminal, CONFIRMS that it will suppress the 50 local echoing of characters onto its screen. This confirmation makes 51 valid sense only when the NVT is operating in an asymmetric, half-duplex 52 communications mode with a co-operating host. 54 IAC WONT SUPPRESS-LOCAL-ECHO 56 The sender of this command, generally a device operating as an NVT 57 terminal, CONFIRMS that it will no longer suppress the echoing of 58 locally typed text onto its screen. This confirmation makes sense only 59 when the NVT is operating in a half-duplex mode with a co-operating 60 host. 62 IAC DO SUPPRESS-LOCAL-ECHO 64 The sender of this command, generally a host computer, REQUESTS that a 65 client NVT terminal suspend the local echoing of text typed on its 66 keyboard. This request makes good sense only when the NVT and host are 67 operating in an asymmetric, half-duplex terminal mode with a 68 co-operating host. The command should have no effect on an NVT terminal 69 operating in full-duplex mode. 71 IAC DONT SUPPRESS-LOCAL-ECHO 73 The sender of this command, generally a host computer, DEMANDS that a 74 client NVT terminal not suppress typed characters that would normally be 75 locally echoed onto the NVT's terminal screen when operating in an 76 asymmetric, half-duplex mode with a co-operating host. The command would 77 have no effect on an NVT terminal operating in full-duplex mode. 79 3. DEFAULT 81 WONT SUPPRESS-LOCAL-ECHO 83 DONT SUPPRESS-LOCAL-ECHO 85 As the SLE default, all typed characters at the NVT are either (i) 86 transmitted to the host when in full-duplex operation and are echoed 87 back to the NVT terminal by the host computer, or (ii), when in 88 half-duplex operation, are transmitted to the host and locally echoed 89 within the NVT itself onto the NVT's terminal screen. 91 4. MOTIVATION FOR THE OPTION 93 Telnet is a protocol that may be operated in either a peer-to-peer, 94 fully symmetric mode, or asymmetrically, in a host-terminal mode. 95 Although the original intention for the NVT mode of operation was both 96 asymmetric and half-duplex, where neither the host nor the terminal 97 echoed characters back to one another, the most common mode of usage has 98 come to be one of asymmetric full-duplex communications, where all 99 terminal characters are first transmitted to the host computer and then 100 echoed back to the terminal before being displayed. 102 Not only has full-duplex communication has proven itself to be quite 103 slow over long distances on the internet, and thus psychologically 104 difficult to tolerate, full-duplex communication is less efficient, 105 requiring twice as many packets be sent and returned. 107 Half-duplex NVT terminal operation decreases the overall packet count by 108 half. It also renders long-distance NVT terminal operation pleasant to 109 use. Characters are echoed to the terminal screen the instant they are 110 typed. However, a problem arising within half-duplex terminal operation 111 is that of passwords. Passwords, whose presence would ordinarily be 112 suppressed by a host computer when operating in a full-duplex mode, are 113 made visible in half-duplex. The SUPPRESS-LOCAL-ECHO option allows the 114 host to command the remote terminal to suspend local echoing of typed 115 text for the duration of the period of that password or other similar 116 confidential material is to be inputted. 118 A more complex method of terminal-local echo suppression is available to 119 telnet users and is described in RFC 726, "Remote Controlled 120 Transmission and Echoing Telnet Option." SUPPRESS-LOCAL-ECHO is a 121 significantly simpler option, requiring much less negiotiation between 122 the host and the client terminal, and is thus substantially easier to 123 implement. 125 5. DESCRIPTION OF THE OPTION 127 SUPPRESS-LOCAL-ECHO is among the mildest of all telnet options. The SLE 128 commands only act as an advisory flag to synchronize the behavior of a a 129 remote NVT terminal client with a host computer. 131 SUPPRESS-LOCAL-ECHO only has valid meaning when telnet communication has 132 been established in an asymmetric, half-duplex mode of operation between 133 a co-operating host and a client NVT terminal. In a half-duplex mode of 134 host-terminal operation, the host commands the terminal to perform no 135 echoes. Similarly, the terminal also commands the host to perform no 136 echoes and places itself in such a mode that all typed characters are 137 locally echoed to its screen. All subsequent communications between the 138 host and the terminal are one-way. 140 A host computer program inherently "knows" when confidential information 141 such as passwords are to be suppressed. At the beginning of such 142 password entry, when in half-duplex operation with a co-operating NVT 143 terminal, the host computer should issue a DO SLE to the remote client 144 terminal. 146 The remote terminal then suspends all local echoing of text until the 147 password entry has been completed, a process monitored by the host 148 computer. Once password entry has been completed, the host computer 149 issues a DONT SLE, at which point local echoing of text on the remote 150 NVT must resume. 152 If the remote client NVT terminal is operating in full-duplex mode, the 153 receipt of DO and DONT SLE commands would have no meaning and therefore 154 must have no effect. 156 6. IMPLEMENTATION SUGGESTIONS 158 To fully utilize the internet and communicate with all available host 159 computers, an NVT client terminal almost certainly should have two modes 160 of operation: full- and half-duplex. 162 Full-duplex communication requires a round-trip circuit for each packet 163 sent from the client NVT terminal to the host computer and back again 164 before those characters are displayed on the terminal's screen, thus 165 perceived transit times that are many times that of half-duplex 166 communications. Further, twice the number of packets must be sent and 167 received in full-duplex as in half-duplex. Nonetheless, full-duplex 168 communication has become the defacto standard of the telnet-based NVTs 169 and therefore must be supported. 171 In order to properly support both full- and half-duplex communications, 172 a mode status flag must be present in the NVT terminal. When in a 173 full-duplex mode, an NVT should respond do both a DO SLE and a DONT SLE 174 with a WONT SLE and do nothing otherwise. 176 In contrast, when an NVT is switched to half-duplex mode, the NVT must 177 first send a DONT ECHO command to the host computer. Only when the host 178 computer responds with a WONT ECHO should the NVT set its internal flag 179 to half-duplex mode and begin locally echoing all characters typed at 180 its keyboard to its screen. 182 When in the half-duplex mode of operation, upon receipt of a DO SLE 183 command, the NVT terminal should suspend local echoing. It otherwise 184 must continue to transmit all typed text to the host computer. 185 Similarly, the NVT terminal must resume local echoing of characters when 186 a DONT SLE command is received from the host. 188 Because the DO/DONT SLE commands are advisory only, the NVT terminal 189 need not return WILL/WONT SLE acknowledgements to the host, although 190 such acknowledgements are recommended. However, the acknowledgements 191 cannot have any effect on the behavior of the host computer. The host 192 must continue to receive text from the remote NVT under any 193 circumstance, thus such acknowledgements must effectively be ignored by 194 the host. 196 Further, the host computer can use its current echoing status as an 197 indication of whether or not it should be issuing DO/DONT SLE commands. 198 If the host is in an echoing state, where all incoming characters are 199 echoed back to the remote NVT terminal, there is no valid reason for the 200 host computer to be issuing DO/DONT SLE commands to the remote NVT 201 terminal. The only time that the SLE commands will carry meaning is when 202 the remote NVT terminal is in a half-duplex mode of operation and the 203 remote NVT has requested and received acknowledgement of echo 204 suppression in the host. 206 7. SECURITY CONSIDERATIONS 208 The negative impact of the SLE option on overall telnet use security is 209 quite minimal, but not completely non-existent. Almost all current 210 telnet transmissions are performed in clear text and are thus highly 211 susceptible to "sniffer" interceptions. 213 The DO/DONT SLE command transmissions from the host will inherently tend 214 to be transmitted just before and after passwords are typed in at the 215 remote NVT client. Because of this, a surreptitious automatic procedure 216 could be programmed to seek out the DO/DONT SLE commands and 217 automatically extract passwords from the reverse data flow. 219 If the text transmission were performed in cleartext, nothing would be 220 learned that could not be deduced otherwise. Only the possibility of 221 automatically bracketing and extracting passwords would be new. 222 Similarly, and perhaps much worse, if the entire text transmission were 223 encrypted, the location and length of passwords could be identified 224 within the reverse flow from the timing of the DO/DONT SLE command 225 transmissions. 227 However, conversely, because the DO/DONT SLE commands will inherently 228 bracket password entry on the NVT terminal, the DO/DONT SLE commands 229 could be faithfully used to cause a remote NVT client to fall into a 230 special (or alternate) encryption mode that lasts only for the duration 231 of password entry, actually augmenting overall security. 233 =================================================== 235 INTERNET DRAFT EXPIRES DEC 1998 INTERNET DRAFT