CURRENT_MEETING_REPORT_ Reported by David A. Borman/ Cray Research, Inc. AGENDA 1. LINEMODE 2. ENVIRON 3. AUTHENTICATION 4. ENCRYPTION 5. COMPRESSION 6. TN3270 The TN3270 option were not discussed. A discussion of TN3270 over Telnet was held Wednesday evening over supper by the interested parties, the minutes of that meeting are attached to the end of this report. MINUTES The COMPRESSION option was only briefly mentioned. When doing both encryption and compression, it is important that the sender apply the compression option before the encryption option, and that the receiver decrypt and then decompress. Both the ENCRYPTION and COMPRESSION documents will be modified to reflect this. The LINEMODE option is currently a ``proposed standard'', RFC 1116. We discussed some additions to the option, two new mode bits and eight new special character definitions. After a brief explanation and minimal discussion, the two new mode bits (SOFT_TAB and LIT_ECHO) were accepted. SOFT_TAB When set, the client side should expand the Horizontal Tab (HT) code, USASCII 9, into the appropriate number of spaces to move the printer to the next horizontal tab stop. When unset, the client side should allow the Hor- izontal Tab code to pass through un-modified. LIT_ECHO When set, if the client side is echoing a non-printable character that the user has typed to the users screen, the character should be echoed as the literal character. If the LIT_ECHO bit is not set, then the client side may echo the character in any manner that it desires. (Many systems echo unprintable characters as two character se- quences, for example, they will echo ``^A'' for an ASCII 1 value.) Several new special characters, for systems that support in-line display editing of the command line, were proposed. 1 SLC_MCL Move cursor one character left. When visual editing is supported, this is the character that, when typed, will move the cursor one character to the left in the display. SLC_MCR Move cursor one character right. When visual editing is supported, this is the character that, when typed, will move the cursor one character to the right in the display. SLC_MCWL Move cursor one word left. When visual editing is sup- ported, this is the character that, when typed, will move the cursor one word to the left in the display. SLC_MCWR Move cursor one word right. When visual editing is sup- ported, this is the character that, when typed, will move the cursor one word to the right in the display. SLC_MCBOL Move cursor to the begining of the line. When visual editing is supported, this is the character that, when typed, will move the cursor to the begining of the line that is being edited. SLC_MCEOL Move cursor to the end of the line. When visual editing is supported, this is the character that, when typed, will move the cursor to the end of the line that is be- ing edited. SLC_INSRT Toggel insert versus overstrike mode. When visual edit- ing is supported, this is the character that, when typed, will toggle whether normal characters should be inserted into the display, or should overwrite charac- ters the current display. SLC_EWR Erase word to the right. When visual editing is sup- ported, this is the character that, when typed, will erase one word to the right of the cursor. It was decided SLC_INSRT would be split into two values: SLC_INSRT Enter character insert mode. When visual editing is supported, this is the character that, when typed, indicate that normal characters should be inserted into the display at the current cursor position. SLC_OVER Enter character overstrike mode. When visual editing is supported, this is the character that, when typed, will indicate that normal characters should overwrite characters the current display. If the SLC_INSRT and SLC_OVER values are set to the same value, than that value is to act as a toggle between insert and overstrike mode. 2 Three other special characters were added to round out the set: SLC_ECR Erase one character to the right. SLC_EBOL Erase from the current cursor position to the beginning of the line. SLC_EEOL Erease from the current cursor position to the end of the line. Also, in the current document, the SLC_EW description states what a ``word'' is: ``... a word is defined to be (optionally) whitespace (tab or space characters), and a string of characters up to, but not including, whitespace or line delimiters.'' With the addition of SLC_EWR, SLC_MCWL and SLC_MCWR, it was felt that this definition of ``word'' was no longer accurate. Rather than try to define what a "word" is, it was decided that we would remove this definition from the document, and put in some comments on why a ``word'' is not defined (to allow dissimilar systems to interoperate). With this changes, it was recommended by the group that the LINEMODE option be re-issued as a ``Draft Standard''. The ENVIRON option was discussed. A proposal was put forward to have the ENVIRON option issued as an RFC, as a ``proposed standard''. Section 6, ``Well Known Variables'' was discussed at length. People disagreed what the user account name variable should be, USER or USERNAME (and some systems use LOGNAME). The group could not agree on what would be the best names for well known names, whether they should have a consistent format, (e.g, a common prefix) or whether there should be a common prefix for user-defined variables. Because resolution was not reached, it was decided that we would strike section 6 from the document, but leave in the names in the example section. We agreed that well known names could be added later if consensus was reached on the naming scheme. Other changes: Explicitly state that the default set of variables is implementation dependent. Reword the motivation section to not be so ``environment variabable'' biased, since this option is used to pass arbitrary information, which happens to include environment variables. A ``Security Considerations'' section will be added, Jeff Schiller has agreed to write this. The ENCRYPT option was briefly discussed. Comments that Steve Bellovin had made were touched upon. It was agreed that 1) When encryption is 3 being done, telnet options will be inserted BEFORE encrypting. We also need to add some comments about key managment, and provide suboptions to allow for any initial negotiation that a particular encryption scheme may need. The rest of the meeting focused on the AUTHENTICATION option. There was some major re-structuring of how the option works. Previously, DO/WILL AUTHENTICATION was sent in each direction for each direction that authentication was desired. Unfortunatly, this breaks down if the authentication scheme has a third method; mutual authentication. So, it was decided that enabling the AUTHENTICATION option in either direction enables authentication. A definition of ``server'' and ``client'' will be added (``server" is the side that did the passive TCP open, and client is the side that did the ``active'' TCP open). The ``server'' sends the ``IAC SB AUTHENTICATION SEND ... IAC SE'' command, and the client sends the ``... IS ...'' command. The server my optionally respond to the IS with a REPLY, and the client may optionally respond to a REPLY with another IS. This way, the client and server may do as many exchanges of information as necessary for the particular authentication scheme being used. The ``authentication-type'' sent in SEND, IS and REPLY commands is now a triplet, . Several things need to be decided: what role each side will be (who will initiate the authentication), who is being authenticated, and what direction. (server authenticate client, client authenticate server, client and server authenticate each other). We decided that the server side always initiates the authentication procedure (only the server can send a SEND command). The other two parts indicate how the authentication is being done. Authenticator/authenticatee indicates whether the server is is authenticating the client, or the client authenticating the server. One-way/mutual is whether the authentication is only happening on one side, or whether both sides authenticate each other. (Authenticator-mutual and authenticatee-mutual allows to the authentication scheme to distinguish who authenticates who first.) The list of authentication-types sent with the SEND command MUST be an ordered list of preferences of the server, so that the client can reliably know which authentication scheme is prefered. There was also some discussion about what to do with normal data that comes across the telnet data stream before the authentication is completed. It will be implementation dependent what happens to this data. Telnet options received during authentication must be processed in the normal manner, but an implementation might choose to refuse or delay the effect of certain options until the authentication has completed. It was also decided to add a generic LOGIN authentication type, which is the normal login:/password: prompting. 4 A Security consideration section will be added. It will state that successfully authentication does not imply that the entire session is secure; the connection might still be taken over after the authentication is done. There is a reference to the ``Assigned Numbers'' RFC that will be removed. For action items, Dave Borman will integrate these changes into the Option drafts, and get them sent off to the internet-drafts directory; Russ Hobby will be notified when the LINEMODE and ENVIRON options are ready, so that they can be pushed on to being issued as RFCs. Minutes of Dinner Meeting Minutes of the special interest group/dinner that met at the Holiday Inn at 7:00 PM on 5/2/90. Talked about the current mechanism for specifying the use of 3270 data streams within a TELNET session and problems with it. After some discussion, it was decided to write a new RFC for specifying 3270 mode. Features of this RFC include: o Single option for negotiating 3270 mode. o Information about terminal characteristics (size, color support, etc.) is defined within the 3270 Data Stream using the Write Structured Field Query Reply facility. This negates the need for the use of the TERMINAL-TYPE option. o New option implies TRANSMIT-BINARY, which does not need to be seperately negotiated. o Uses a TLV type structure to encapsulate the 3270 Data Stream. This allows optional items to be sent and received. Examples of this include an indicator that the following data has a READ command chained to it, and for being able for 3270 type printers to be able to send their completion status back to the server. This mechanism also allows for future extensions. o Within a given TLV (Type, Length, Value) structure, the data is not IAC stuffed. TELNET commands and options may occur between individual TLV structures. o The new option is negotiated only by the server. Since 3270 Data Streams require both directions to be in the mode, it didn't seem necessary to require it to be negotiated in both directions. This will simplify server and client implementations. o Allow the 3270 Data Stream to be unnegotiated and renegotiated as needed by the server. o Require clients to support SNA and non-SNA commands. o No longer requires the EOR option or the use of the EOF TELNET command. o Discussed printing issues. Spent significant time discussing this. Decided to write a seperate RFC on this issue since there appear to be several ideas on how this could be solved. 5 ATTENDEES Fred Bohle fab@saturn.acc.com David Borman dab@cray.com Bruce Crabill bruce@umdd.umd.edu Peter DiCamillo cmsmaint@brownvm.brown.edu Roger Fajman raf@cu.nih.gov James Galvin galvin@tis.com Mike Horowitz mah@shiva.com Phil Karn Karn@Thumper.Bellcore.Com John LoVerso loverso@xylogics.com Louis Mamakos louie@trantor.umd.edu Greg Minshall minshall@kinetics.kinetics.com Gerard Newman gkn@sds.sdsc.edu Michael Petry petry@trantor.umd.edu Jeffrey Schiller jis@athena.mit.edu Frank Solensky solensky@interlan.interlan.com Ted Soo-Hoo soo-hoo@dg_rtp.dg.com Peter Vinsel farcomp!pcv@apple.com Participants of the dinner meeting were: Fred Bohle fab@saturn.acc.com David Borman dab@cray.com Bruce Crabill bruce@umdd.umd.edu Peter DiCamillo cmsmaint@brownvm.brown.edu Roger Fajman raf@cu.nih.gov Yakov Rekhter yackov@ibm.com 6