CURRENT_MEETING_REPORT_ Reported by David A. Borman/Cray Research, Inc. TELNET Minutes The Telnet Working Group met the morning of Tuesday, July 30, 1991. An initial Agenda of possible topics included: o Authentication Option o Encryption Option o Environment Option o CAT (Common Authentication Technology) o Possible Future Telnet Work - 8 bit NVT - International Characters - Option Negotiation Loop Avoidance - Compression - Terminal Types - MIB The actual discussion that followed focused only on the Authentication option. The first thing that was started was a quick walk-through of the draft Authentication option to do some final editing, before approving the draft for recommendation for being published as an RFC. Page 1: The AUTH_WHO_CLIENT and AUTH_WHO_SERVER names will be changed to AUTH_CLIENT_TO_SERVER and AUTH_SERVER_TO_CLIENT to more accurately describe who is authenticating who. The words "(TCP LISTEN state)" will be added after "...that did the passive TCP open," to clarify things. Page 2: Mid page, "authentication-type-list" will be changed to "authentication-type-pair-list" for consistentcy. The descriptions of IS and REPLY will be rewritten. Page 3: In the first sentence, "has two values" will be changed to "is two octets". This is about as much as was accomplished on the walk-through, as side discussions took us off on other more general issues. 1 A major point of discussion was: 1. Should we continue with the authentication option, and 2. Should the authentication option be providing ``negotiation'' for the type of authentication to be used? The argument for the negotiation was that it provides a mechanism for the client and server to agree upon what type of authentication will be used. The argument against it was that the client should just pick one, and it probably will only have one type, and the server would either accept or refuse it. There was also fear that having a negotiation scheme would allow a weaker form authentication to be agreed upon that the user is willing to use. After much discussion, it was decided that we would: 1. Leave the draft the way it is. 2. Add a description of the security concerns of doing negotiation of the authentication mechanism. A shorter discussion was held on whether the IS and REPLY commands could be replaced with a single DATA command. It was decided that there was no benefit in changing it, so it was left as is. Another discussion was whether we should be doing the Authentication option at all, in light of the work starting up in the Common Authentication Technology (CAT) Working Group. It was decided that since the CAT group is just starting up, and the Authentication option is already being implemented and used to get real work done, and that the Authentication option has the ability to evolve into CAT, that we would continue. The draft will be modified as stated above, and circulated for one more round of review before being sent to the IESG. Attendees Steve Alexander stevea@i88.isc.com David Bolen db3l@nis.ans.net David Borman dab@cray.com Johnny Eriksson bygg@sunet.se Barbara Fraser byf@cert.sei.cmu.edu Kenneth Goodwin goodwin@psc.edu Alton Hoover hoover@nis.ans.net Charles Kaufman kaufman@dsmail.enet.dec.com Mark Lewis mlewis@telebit.com John Linn linn@zendia.enet.dec.com Louis Mamakos louie@ni.umd.edu Matt Mathis mathis@psc.edu Greg Minshall minshall@wc.novell.com 2 Clifford Neuman bcn@isi.edu Jason Perreault perreaul@interlan.interlan.com John Pickens jrp@3com.com P. Rajaram rajaram@sun.com Jan Michael Rynning jmr@nada.kth.se Mark Saake saake@llnl.gov Emil Sturniolo emil@doe.dss.com Theodore Tso Jesse Walker walker@eider.enet@decpa.dec.com David Ward dward@chipcom.com 3