Minutes for "Internet Kermit Service and Outstanding Telnet Options BOF"
Prepared by Jeffrey Altman <email@example.com>
A Summary of Internet Kermit Service Drafts was given by Jeffrey Altman.
? why implement IKS on Telnet and not on a separate port?
- The IKS is implemented on a separate port allocated by IANA, 1649.
? why implement with Telnet protocol and not on raw TCP/IP socket? don't telnet clients ignore Telnet protocol when they connect to ports other than 23?
- IKS is implemented using Telnet protocol to reuse the existing work done on Telnet options to support NAWS, Authentication, Encryption, TLS, and New Environment. It is my opinion that a Telnet client should refrain from starting to send Telnet options on a port other than 23 but should respond to them if they are received.
? why not implement IKS as a service keyed to the terminal type name negotiated on port 23 telnetd?
- Telnet daemon implementors have voiced strong opposition to any proposal to add a file transfer capability to the existing telnet service on port 23. However, if a telnetd implementor wanted to implement the Telnet Kermit Option there is no reason that a Kermit file transfer capability could not be added to an existing telnetd. At least not from a protocol standpoint. There might be issues related to architecture of telnetd vs. ptys or something else.
? Is this appropriate for the IETF to handle? Does Columbia University really intend to hand control of the IKS over to the IETF?
- Yes. The IKS is a public service to be implemented on the Internet. Yes. Columbia University wants the IETF to manage a public standard which will be implemented by third parties.
Presentation by Ted T'so on the state of Telnet Auth, Encrypt Options:
Telnet Auth has been expiremental for many years. It is implemented in the Kerberos 4 and 5 distributions as well as several others.
The current Telnet Encrypt implementations are flawed. There is no integrity checking of the data which posses the ability for a man in the middle to perform data swapping or insertion. While it will most likely be caught in the CFB modes it is still a threat.
The reasons for the existing implementations were a desire to allow weak CPUs to have some form of privacy and a need to not increase the amount of data sent for each character.
The question is what should be done for the future. Should AUTH and ENCRYPT be improved and placed on standards track or should something else be used instead such as TLS or SASL?
Overview of suggested Telnet SASL integration by Chris Newman.
? SASL would use GSS-API for integrity checking. Would that result in a potential 40 bytes sent for each character being typed by the user?
Yes. That is a possibility.
Presentation by Michael Boe on Telnet START_TLS option:
Start_TLS is a product of the TN3270E WG. It has been designed for general use by regular telnet. An option negotiation is used to agree to use TLS and then TLS negotiations take place at a level below the Telnet application layer. The draft should go to WG last call by February 1999.
Topics of Open discussion:
- Why should we continue working on Telnet when we have SSH?
- Implementors are reluctant to reopen the Telnet code. Its been a long time since anyone has looked at that code.
- By the time implementors could distribute any revisions to Telnet that we would produce there is a good chance that IPSec will be shipping. Is this a waste of time?
It is unclear whether there is consensus for the formation of a working group. A proposed charter and call for working group will be made to the mailing list at firstname.lastname@example.org. To join the list send mail to email@example.com.
Something that wasn't discussed was that if Telnet Auth is not really important as some say, why have there been so many new Telnet Auth implementations over the last couple of years?