home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / TELNET / 90DEC.MIN < prev    next >
Encoding:
Text File  |  1993-02-18  |  6.8 KB  |  197 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by David A. Borman/Cray Research, Inc.
  7.  
  8. TELNET Minutes
  9.  
  10. Agenda
  11.  
  12.  
  13.    o Telnet Environment Option
  14.    o Telnet Authentication Option
  15.    o Telnet Encryption Option
  16.    o Telnet Specification
  17.  
  18.  
  19. Telnet Environment Option
  20.  
  21. The Telnet Environment Option had been passed off for publication as a
  22. proposed Internet Protocol.  However, some members of the IAB expressed
  23. some concerns about the possible misuse of the option, mainly that it
  24. might be used to create proprietary, non-interoperating telnet
  25. implementations.
  26.  
  27. In May of 1990, the ``Well Known Variables'' section was removed from
  28. the draft document due to of lack of consensus on what would be the well
  29. known variables.  From the minutes of that meeting:
  30.  
  31.  
  32.    o Section 6, ``Well Known Variables'' was discussed at length.
  33.      People disagreed what the user account name variable should be,
  34.      USER or USERNAME (some systems use LOGNAME). The group could not
  35.      agree on what would be the best names for well known names, whether
  36.      they should have a consistent format, (e.g., a common prefix) or
  37.      whether there should be a common prefix for user-defined variables.
  38.      Because resolution was not reached, it was decided to strike
  39.      section 6 from the document, but leave in the names in the example
  40.      section.  It was agreed that well known names could be added later
  41.      if consensus was reached on the naming scheme.
  42.    o Possible action items for this document:
  43.       -  Issue it as is, as an Experimental RFC.
  44.       -  Define a ``Well Known Variable'' list, and re-submit for a
  45.          proposed standard.
  46.       -  Decide if non-standard variables would be allowed.  Some
  47.  
  48.                                    1
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.          suggestions:
  56.           * names of the form X-*, like mail
  57.           * use a STD- prefix for standard names
  58.           * use <system-type>- prefix
  59.  
  60.       -  Since the Environment option is based on UN*X environment
  61.          variables, should we be blatant about a UN*X bias?
  62.       -  Put the well-known variable names in the assigned numbers
  63.          document.
  64.       -  Use SNMP to manage well-known variable names?
  65.  
  66.  
  67.  
  68. Items 1 and 2:  After discussing the pros and cons of each of these, it
  69. was decided that the document would be re-submitted as is, to be
  70. published as an experimental RFC. This would allow the document to get a
  71. wider distribution.
  72.  
  73.  
  74. On item 3, the consensus was that non-standard variables need to be
  75. allowed; by limiting it to just well-known variable names, much of the
  76. usefulness of the option would be removed.  No agreement was reached on
  77. how to name the standard vs.  non-standard variable names, and the
  78. discussion was deferred to the mailing list.
  79.  
  80.  
  81. Item 4 was rejected; just because the option maps nicely onto the UN*X
  82. platform does not limit it to just UN*X machines, and there is no reason
  83. to perpetuate that myth.
  84.  
  85.  
  86. Item 5 was agreed on, once the format and names are decided upon.  The
  87. list of ``Well Known Variables'' will contain the variable name, and a
  88. description of any syntax that is to be applied to the value of the
  89. variable.
  90.  
  91.  
  92. Item 6 was brought up as an interesting way to manage variable names,
  93. but was dismissed as not being appropriate, since SNMP deals with
  94. variables on a machine level basis, and the Telnet Environment Option
  95. deals with variables on a per-user basis.  This would also open up a big
  96. can of worms with regard to security.
  97.  
  98.  
  99. Telnet Authentication Option
  100.  
  101.  
  102.  
  103.                                    2
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110. Several minor modifications were made to the Authentication document:
  111.  
  112.  
  113.  
  114.   1. The user name that is being authenticated must now be passed as
  115.      part of the authentication negotiation, not in the (proposed)
  116.      ENVIRON option.  This change has two advantages:
  117.  
  118.        o It makes the Authentication option self contained.
  119.        o It allows the user to authenticate as one person, but have a
  120.          USER variable of someone else, e.g., use the Authentication
  121.          option to authenticate as ``root'', but use the ENVIRON option
  122.          to set the USER variable to ``joe'', so that the user can be
  123.          ``root'' with ``joe's'' environment.
  124.   2. Previously the document said that the server side SHOULD send the
  125.      DO AUTH, and the client WILL AUTH. The SHOULD has been changed to
  126.      MUST. If the server(client) receives (DO(WILL) AUTH), the option
  127.      MUST be refused.
  128.   3. There was discussion about changing from the current
  129.      (SEND/IS/REPLY) to a separate (SEND/IS) negotiation, followed by a
  130.      (CLIENT_DATA/SERVER_DATA) negotiation.  This idea was voted down.
  131.   4. The PRIVATE type was eliminated; this would only lead to
  132.      non-interoperable implementations.
  133.   5. The type NONE was changed to type NULL, and it is the type returned
  134.      by the client when it does not support any of the authentication
  135.      types proposed by the server.
  136.   6. The type LOGIN was removed.
  137.   7. There was discussion about what exactly the authentication option
  138.      gives the user.  It does not give integrity.  Once the
  139.      authentication is completed, the connection could be taken over
  140.      and/or modified by some intervening host.  The encryption option
  141.      should be used to gain data integrity.  There was discussion about
  142.      whether or not the ability for one side of the connection to
  143.      ``challenge'' the other side would be useful; it was decided that
  144.      all that that would do is make it harder for the connection to be
  145.      taken over/modified, but would not eliminate that possibility.
  146.   8. The type KERBEROS was split into two type,KERBEROS/_V4 and
  147.      KERBEROS/_V5. New types for SPHINX and MINK will be added.
  148.  
  149.  
  150.  
  151. Time did not allow for the discussion of the Encryption Option or the
  152. Telnet Specification.
  153.  
  154.  
  155.                                    3
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162. It was decided that at the next IETF meeting, the Telnet WG would meet
  163. for two sessions (a 3 hour and a 2 hour session).
  164.  
  165.  
  166. Attendees
  167.  
  168. David Borman             dab@cray.com
  169. Philip Budne             phil@shiva.com
  170. Anthony Chung            anthony@hls.com
  171. George Conant            geconant@eng.xyplex.com
  172. Steve Crocker            crocker@tis.com
  173. James Dray               dray@st1.ncsl.nist.gov
  174. Peter Ford               peter@lanl.gov
  175. James Galvin             galvin@tis.com
  176. Robert Gilligan          gilligan@eng.sun.com
  177. Russell Hobby            rdhobby@ucdavis.edu
  178. Joel Jacobs              jdj@mitre.org
  179. Philip Karn              karn@thumper.bellcore.com
  180. Darren Kinley            kinley@crim.ca
  181. John Linn                linn@zendia.enet.dec.com
  182. E. Paul Love Jr.         loveep@sdsc.edu
  183. Joyce Reynolds           jkrey@isi.edu
  184. Kary Robertson
  185. Jeffrey Schiller         jis@mit.edu
  186. Sam Sjogren              sjogren@tgv.com
  187. Pat Smith                psmith@merit.edu
  188. Mark Stein               marks@eng.sun.com
  189. Emil Sturniolo
  190. Dean Throop              throop@dg-rtp.dg.com
  191. Jesse Walker             walker@eider.enet@decpa.dec.com
  192. Kathy Wilde              wilde@decvax.dec.com
  193.  
  194.  
  195.  
  196.                                    4
  197.