Subject: Re: Last Call: Telnet Authentication Option to ProposedStandard

From: Jeffrey Altman <[email-masked]>
Date: Tue, 23 Nov 99 19:50:21 EST

> 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-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 23 Nov 99 19:50:21 EST

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 24 Nov 1999 08:26:00 -0500

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-masked] (Johan Danielsson)
To: William Allen Simpson <[email-masked]>
CC: [email-masked]

> (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

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 24 Nov 99 13:02:48 EST

> 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.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 24 Nov 99 13:02:48 EST