Internet Standards/CD1.mdf/INET/IETF/TELNET/90MAY.MIN

Text File | 1993-02-18 | 13.6 KB | 328 lines

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, <type><authenticator/authenticatee><one-way/mutual>.  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                [e-mail]
    David Borman              [e-mail]
    Bruce Crabill             [e-mail]
    Peter DiCamillo           [e-mail]
    Roger Fajman              [e-mail]
    James Galvin              [e-mail]
    Mike Horowitz             [e-mail]
    Phil Karn                 [e-mail]
    John LoVerso              [e-mail]
    Louis Mamakos             [e-mail]
    Greg Minshall             [e-mail]
    Gerard Newman             [e-mail]
    Michael Petry             [e-mail]
    Jeffrey Schiller          [e-mail]
    Frank Solensky            [e-mail]
    Ted Soo-Hoo               soo-hoo@dg_rtp.dg.com
    Peter Vinsel              farcomp![e-mail]


Participants of the dinner meeting were:


    Fred Bohle                [e-mail]
    David Borman              [e-mail]
    Bruce Crabill             [e-mail]
    Peter DiCamillo           [e-mail]
    Roger Fajman              [e-mail]
    Yakov Rekhter             [e-mail]



                                   6