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