> I'll go further. THIS ENTIRE PROTOCOL DUPLICATES OTHER STANDARDS TRACK
> EFFORTS. I see no reason why it should rise above Experimental and
> Informational.
>
> We already have authentication and encryption at link layer (PPP),
> network layer (IPSec), transport layer (TLS), and session layer
> (SecSHell). Why do we need application layer security, too?
>
> If this were "just" authentication, just as new authentication modes
> have been added to protocols (POP3, SMTP) that already have some form of
> authentication, it might be useful. But, Telnet has no extant
> authentication that is being improved. This is a whole new set of
> features, including encryption (not mentioned in the announcement).
> Why bother?
>
> Moreover, there is no _required_ option that must be implemented. One
> of the most important interoperability design principles is violated.
>
> Finally, the protocol itself seems insecure and subject to denial of
> service and monkey in the middle attacks. It's a bad idea.
These options have been in use for eight years and are widely
deployed. Telnet AUTH is currently RFC 1416. We are removing the
man in the middle attack that is possible with that RFC.
Please see my other postings to this thread for a discussion of TLS
and Telnet.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
