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 The Telnet Working Group met the morning of Tuesday, March 12, 1991, and the afternoon of Wednesday, March 13, at the St. Louis IETF meeting. Telnet Environment Option The first item of discussion was the ENVIRON option. Vint Cerf was present to express some of the views of the IAB on this option, and their reluctance to endorse it. The crux of the issue is the fact that the ENVIRON option allows for arbitrary environment variable information to be passed between systems and that the draft RFC has no well-defined variables in it, the lack of the latter causing even more concern about the former. Vint suggested that submitting the ENVIRON option with some well defined variables, and without the unknown variables being allowed, unless there was some good justification, could expedite the IAB accepting the ENVIRON option. A list was put together of what well known variables should be in the initial draft: The list was USER (LOGNAME), JOB, ACCT, PRINTER, SYSTEMTYPE and XDISPLAY. Dave Borman will write up a description of the format of the values for these and send them to the mailing list for discussion. Because there is a strong feeling that giving the user the ability to pass arbitrary environment variable information is very useful, discussion was held on how to continue. One item that has to be done is to identify how to differentiate between well known variables and user-defined variables. One option was to encode the information in the variable name, for example, ala the X-foo naming used in mail. The other option was to add a new code, USERVAR, that would have the same semantics as VAR, but be explicitly for non-standard variable names. A 1 vote was taken, with three options: 1. Encode information in name. 2. Add USERVAR. 3. Leave it out for now, and don't worry about it. With seven votes recorded, three voted for adding USERVAR, one voted for encoding in the name, and three voted for leaving it out for now. Hence, any future discussion for dealing with user-defined variables will use the USERVAR code. Dave Borman will look into Vint' suggestion that it might be good for someone to go to an IAB meeting and present the reasons for the user-defined variables. Telnet Authentication Option The Authentication option was next on the Agenda. The revised draft, with definitions for Kerberos Version 4, was discussed. It became apparent that the NAME subcommand in the Kerberos definitions was something that could be needed by many authentication schemes, so the NAME suboption was moved up to its own suboption: IAC SB AUTHENTICATION NAME remote user IAC SE Two new options for Kerberos were added, CHALLENGE and RESPONSE, to provide mutual authentication. After the server authenticates the client, the client sends the server a CHALLENGE, an eight octet value encrypted in the session key. The server decrypts it, adds one to it, re-encrypts it, and sends it back in a RESPONSE command. If the client can successfully decrypt it, and get the original challenge value plus 1, then the server has been authenticated to the client. As an additional step, both sides take the original encrypted challenge, and encrypt it again in the session key, and save that new value for a unique encryption key that can be used by the ENCRYPT option. Hence, the NEWKEY command isn't needed anymore, and was therefore removed. The ACCEPT command was modified to remove the optional ``authenticated principal'', as it provided no new, useful information. There was a bit of discussion about the difference between authentication and authorization. A user may be able to authenticate on the remote machine, but still not be authorized to log in as the user specified in the NAME suboption. Also, this knowledge might not be known to the telnet server. Hence, the Kerberos REJECT command may or may not 2 contain an explanation, and the client might well get an ACCEPT command, only to then later see a failure message from some other part of the remote system that failes the authorization. A decision was made that, with these changes, the authentication option is fairly stable. The changes will be incorporated into the document and distributed for review, and if there are no major objections it will be sent off to be published as an RFC. The Kerberos definitions will be removed and published as a separate document. Telnet Encryption Option One item of a rather lengthy discussion entailed the security aspects of the Encryption option. The net result was that it was decided that for now the document would state that the encryption option provides protection against a passive attacker (i.e, someone who is snooping in on the packets as they fly by), but not against an active attacker (i.e., someone who is snooping, and can also intercept/modify the packets as they fly by). The crux of the discussion was for when the encryption option is normally off, and is only being enabled in one direction when sensitive information is passing over the network, like passwords. Later versions of the option may contain information about how to provide adequate protection against an active attacker. Key exchange was also discussed. In all cases, key exchange is currently outside of the scope of the Encryption option. It is assumed that there are one or more keys available that are known to each side of the connection. It was decided that the START and REQUEST-START would have an additional argument added, a keyid. A keyid is an arbitrary length number. It is encoded with the MSB first, and the LSB last. All the bytes between the START/REQUEST-START and the IAC SE are the keyid. A one-byte keyid with a value of zero was reserved to mean ``the default key''. This will usually refer to a key derived as a side effect of authentication. For all other keyids, an algorithm is needed to do the exchange of information to decide which key name to use. David Borman agreed to write something up on this. [ Begin additional info, not part of the minutes of this meeting ] What will be in the next draft is the addition of two new commands: ENC _KEYID and DEC_KEYID. The side that is going to encrypt sends ENC_KEYID with a keyid that it understands. The decrypting side responds with a DEC_KEYID command with the same value if it accepts it, a different value if it doesn't accept it but has a different keyid to try, or an empty value if there are no more values. If the encryptor receives a different value than what it sent, it processes it in the same way, sending over one of the three possible responses. This 3 continues until both sides have sent and received (or received and sent) the same value. [ End of additional info ] The inital description on Kerberos DES encryption that was in the latest draft document was modified quite a bit. It was decided that we needed a definition for both Cipher Feed Back (which is what was already documented, more or less...) and for Output Feed Back. The Initial Vector is sent by the encryptor, and is sent as a clear text string across the network. The view was that this was probably okay, but there was some concern that it might need to be encrypted. However, for now it will just be clear text. The encrypter sends across the IV, and the decryptor sends back either an IV_OK or IV_BAD message. If IV_OK is received, then negotiation of the keyid, happens, and then encryption can be enabled/disabled as needed. The Telnet Working Group will meet at the July IETF Meeting in Atlanta. Attendees Richard Basch probe@mit.edu David Borman dab@cray.com Vinton Cerf vcerf@NRI.Reston.VA.US Tom Grant grant@xylogics.com Neil Haller nmh@bellcore.com Russ Hobby rdhobby@ucdavis.edu John Linn ULTRA::LINN David Lippke lippke@utdallas.edu George Sanderson sanderson@mdc.com Jeffrey Schiller jis@mit.edu Sam Sjogren sjogren@tgv.com Dean Throop throop@dg-rtp.dg.com William Townsend townsend@xylogics.com Kathleen Wilde wilde@decvax.dec.com 4