CURRENT_MEETING_REPORT_ Reported by David A. Borman/Cray Research, Inc. TELNET Minutes Agenda o Telnet Environment Option o Telnet Authentication Option o Telnet Encryption Option o Telnet Specification Telnet Environment Option The Telnet Environment Option had been passed off for publication as a proposed Internet Protocol. However, some members of the IAB expressed some concerns about the possible misuse of the option, mainly that it might be used to create proprietary, non-interoperating telnet implementations. In May of 1990, the ``Well Known Variables'' section was removed from the draft document due to of lack of consensus on what would be the well known variables. From the minutes of that meeting: o Section 6, ``Well Known Variables'' was discussed at length. People disagreed what the user account name variable should be, USER or USERNAME (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 to strike section 6 from the document, but leave in the names in the example section. It was agreed that well known names could be added later if consensus was reached on the naming scheme. o Possible action items for this document: - Issue it as is, as an Experimental RFC. - Define a ``Well Known Variable'' list, and re-submit for a proposed standard. - Decide if non-standard variables would be allowed. Some 1 suggestions: * names of the form X-*, like mail * use a STD- prefix for standard names * use - prefix - Since the Environment option is based on UN*X environment variables, should we be blatant about a UN*X bias? - Put the well-known variable names in the assigned numbers document. - Use SNMP to manage well-known variable names? Items 1 and 2: After discussing the pros and cons of each of these, it was decided that the document would be re-submitted as is, to be published as an experimental RFC. This would allow the document to get a wider distribution. On item 3, the consensus was that non-standard variables need to be allowed; by limiting it to just well-known variable names, much of the usefulness of the option would be removed. No agreement was reached on how to name the standard vs. non-standard variable names, and the discussion was deferred to the mailing list. Item 4 was rejected; just because the option maps nicely onto the UN*X platform does not limit it to just UN*X machines, and there is no reason to perpetuate that myth. Item 5 was agreed on, once the format and names are decided upon. The list of ``Well Known Variables'' will contain the variable name, and a description of any syntax that is to be applied to the value of the variable. Item 6 was brought up as an interesting way to manage variable names, but was dismissed as not being appropriate, since SNMP deals with variables on a machine level basis, and the Telnet Environment Option deals with variables on a per-user basis. This would also open up a big can of worms with regard to security. Telnet Authentication Option 2 Several minor modifications were made to the Authentication document: 1. The user name that is being authenticated must now be passed as part of the authentication negotiation, not in the (proposed) ENVIRON option. This change has two advantages: o It makes the Authentication option self contained. o It allows the user to authenticate as one person, but have a USER variable of someone else, e.g., use the Authentication option to authenticate as ``root'', but use the ENVIRON option to set the USER variable to ``joe'', so that the user can be ``root'' with ``joe's'' environment. 2. Previously the document said that the server side SHOULD send the DO AUTH, and the client WILL AUTH. The SHOULD has been changed to MUST. If the server(client) receives (DO(WILL) AUTH), the option MUST be refused. 3. There was discussion about changing from the current (SEND/IS/REPLY) to a separate (SEND/IS) negotiation, followed by a (CLIENT_DATA/SERVER_DATA) negotiation. This idea was voted down. 4. The PRIVATE type was eliminated; this would only lead to non-interoperable implementations. 5. The type NONE was changed to type NULL, and it is the type returned by the client when it does not support any of the authentication types proposed by the server. 6. The type LOGIN was removed. 7. There was discussion about what exactly the authentication option gives the user. It does not give integrity. Once the authentication is completed, the connection could be taken over and/or modified by some intervening host. The encryption option should be used to gain data integrity. There was discussion about whether or not the ability for one side of the connection to ``challenge'' the other side would be useful; it was decided that all that that would do is make it harder for the connection to be taken over/modified, but would not eliminate that possibility. 8. The type KERBEROS was split into two type,KERBEROS/_V4 and KERBEROS/_V5. New types for SPHINX and MINK will be added. Time did not allow for the discussion of the Encryption Option or the Telnet Specification. 3 It was decided that at the next IETF meeting, the Telnet WG would meet for two sessions (a 3 hour and a 2 hour session). Attendees David Borman dab@cray.com Philip Budne phil@shiva.com Anthony Chung anthony@hls.com George Conant geconant@eng.xyplex.com Steve Crocker crocker@tis.com James Dray dray@st1.ncsl.nist.gov Peter Ford peter@lanl.gov James Galvin galvin@tis.com Robert Gilligan gilligan@eng.sun.com Russell Hobby rdhobby@ucdavis.edu Joel Jacobs jdj@mitre.org Philip Karn karn@thumper.bellcore.com Darren Kinley kinley@crim.ca John Linn linn@zendia.enet.dec.com E. Paul Love Jr. loveep@sdsc.edu Joyce Reynolds jkrey@isi.edu Kary Robertson Jeffrey Schiller jis@mit.edu Sam Sjogren sjogren@tgv.com Pat Smith psmith@merit.edu Mark Stein marks@eng.sun.com Emil Sturniolo Dean Throop throop@dg-rtp.dg.com Jesse Walker walker@eider.enet@decpa.dec.com Kathy Wilde wilde@decvax.dec.com 4