Re: Last Call: Telnet Authentication Option to ProposedStandard
> Johan Danielsson opined: > > Another layer to what? What other security is there that I have > > control over? Please enlighten me about this mysterious security that > > works by magic, and that nobody talks about. > > > Maybe you aren't talking to the right folks > > I use Nifty Telnet with SSH, and OpenSSH is on the other end. SSL (TLS) > is incorporated in my Navigator browser, and OpenSSL is on the other end. > NAI PGPnet is in my menu bar, and OpenBSD or Linux FreeSWAN is on the > other end. SSH is not equal to Telnet. The SSH you are talking about is not even being discussed in the IETF. OpenSSH and Nifty Telnet are the SSH v1 protocol and it provides no reliable form of host authentication. Besides it opens up more security holes when a root breakin occurs. SSL/TLS is an IETF standard AND as I said in another posting we are working on an IETF Telnet Option to support it. But it does not provide for client authentication and requires a great deal more effort to provide server authentication than the existing (in general use) Telnet Auth methods. RFC 1416 (Telnet Authentication) provides a hole that allows a Mack truck to disable the use of encryption. The new draft fixes it and provides backwards compatibility for the Telnet Encryption option which never was published as an RFC. Not because it wasn't being used but because at the time there were a lot of questions about whether it even could be due to U.S. law. > > Historic implies that it isn't in general use. Telnet encryption is, > > no matter what you think about it. > > > 4.2.4 Historic > >A specification that has been superseded by a more recent >specification or is for any other reason considered to be obsolete is >assigned to the "Historic" level. (Purists have suggested that the >word should be "Historical"; however, at this point the use of >"Historic" is historical.) Since we do not at the present time have anything in Telnet that is ready to go standards track to replace telnet encryption it would be inappropriate to issue it as Historical. When Telnet over TLS is Proposed Standard we can re-examine the issue. 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]
Re: Last Call: Telnet Authentication Option to ProposedStandard
Johan Danielsson opined: > Another layer to what? What other security is there that I have > control over? Please enlighten me about this mysterious security that > works by magic, and that nobody talks about. > Maybe you aren't talking to the right folks I use Nifty Telnet with SSH, and OpenSSH is on the other end. SSL (TLS) is incorporated in my Navigator browser, and OpenSSL is on the other end. NAI PGPnet is in my menu bar, and OpenBSD or Linux FreeSWAN is on the other end. "Any sufficiently advanced technology is indistinguishable from magic." (Niven?) > Historic implies that it isn't in general use. Telnet encryption is, > no matter what you think about it. > 4.2.4 Historic A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) [EMAIL PROTECTED] Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: Last Call: Telnet Authentication Option to ProposedStandard
William Allen Simpson <[EMAIL PROTECTED]> writes: > The poster forgot to include the only list that counts, the IETF > where Last Calls are discussed. I explicitly removed it because my last post didn't have much to do with the standardisation process. > This is not mail, where Application level security makes sense. > This is Telnet, a service that is explicitly and only an on-line, > connected, end-to-end protocol. Another layer of security adds no > value. Another layer to what? What other security is there that I have control over? Please enlighten me about this mysterious security that works by magic, and that nobody talks about. > If nobody would suggest a similar design today, then publishing them > with Historic designation might be appropriate. Historic implies that it isn't in general use. Telnet encryption is, no matter what you think about it. /Johan
Re: Last Call: Telnet Authentication Option to ProposedStandard
The poster forgot to include the only list that counts, the IETF where Last Calls are discussed. This is not mail, where Application level security makes sense. This is Telnet, a service that is explicitly and only an on-line, connected, end-to-end protocol. Another layer of security adds no value. Especially as this has admitted security problems! I have no stomach for "blessing" bad ideas, just because they've been used for a long time If nobody would suggest a similar design today, then publishing them with Historic designation might be appropriate. Original Message ---- Subject: Re: Last Call: Telnet Authentication Option to ProposedStandard Date: 24 Nov 1999 10:21:09 +0100 From: [EMAIL PROTECTED] (Johan Danielsson) To: William Allen Simpson <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] William Allen Simpson <[EMAIL PROTECTED]> writes: > 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? This is another debate, but I would argue that it's *only* at the `application layer' that encryption and authentication makes sense. How can I trust IPsec when I don't know who's controlling the keys? Encryption at other levels might have their own applications, but it doesn't necessarily provide any explicit security to the end user. Anyway, the telnet encryption stuff has been in use for many years, and this is just revival of some old drafts. They do have security problems, and nobody would suggest a similar design today. /Johan
Re: Last Call: Telnet Authentication Option to ProposedStandard
> 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]
Re: Last Call: Telnet Authentication Option to ProposedStandard
Harald Tveit Alvestrand wrote: > > Protocols that offer increased complexity but no gain in security or > efficiency over other standards-track efforts, but are in use today, are > IMHO excellent candidates for Informational publication. > > Not for the standards track. > 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. [EMAIL PROTECTED] Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
