low-overhead encrypted telnet
I've been talking about entrypted telnet with Craig Leres lately, and he came up with an interesting idea. The background is, sysadmins want encrypted telnet so that passwords don't fly around in the clear, but at the same time, they don't want to spend too many extra CPU cycles. I figured at least some sysadmins would resist installing an encryption-capable telnetd because of this concern about overhead. What you'd really like to do so satisfy these people is encrypt only when actually transmitting passwords. Problem is, that's hard to implement. Kerberos does it by supplying new versions of a dozen different programs, and it still only works within your organization, and even there it doesn't handle chained logins (telnet from host A to host B, then from host B to host C, etc.). It's hard because you have different levels of software trying to talk to each other. A solution that worked entirely within telnet would be a lot simpler. A compromise I thought of a while back is to encrypt the first few kilobytes and then switch to cleartext. This lets you log in securely, the average overhead for the session remains low, and there's no interaction between different software levels. But this also doesn't handle chained logins, if the second login comes later in your session. So here's Craig's idea: only encrypt the client-to-server direction. That's the only direction that passwords go, so it's secure; and it's low overhead because you generally type far fewer characters than you read. Just a tidbit for anyone working on encrypted logins. --- Jef
On Tue, 1 Mar 1994, Jef Poskanzer wrote:
I've been talking about entrypted telnet with Craig Leres lately, and he came up with an interesting idea. The background is, sysadmins want encrypted telnet so that passwords don't fly around in the clear, but at the same time, they don't want to spend too many extra CPU cycles. I figured at least some sysadmins would resist installing an encryption-capable telnetd because of this concern about overhead.
[Some text deleted] Have you seen the proposals for an encryption option for TELNET? There are at least two proposals. The first is by David Borman dated April 1990 and the second by Lawrence Brown and Gilje Jaatun dated December 1991. Borman's proposal focuses on the possibility of encryption of passwords only. Unfortunately I don't have a pointer to an electronic copy of these proposals -- perhaps someone else on this list has? I am currently working on a project which requires encrypted TELNET. We will be encrypting *all* transmitted data to protect sensitive information -- not just passwords. Does anybody know the current status of standardization of an encryption option for TELNET? -- Rolf ---------------------------------------------------------------------- Rolf Michelsen Phone: +47 73 59 87 33 SINTEF DELAB Email: rolf.michelsen@delab.sintef.no 7034 Trondheim Office: C339 Norway ----------------------------------------------------------------------
Rolf wrote: | I am currently working on a project which requires encrypted TELNET. We | will be encrypting *all* transmitted data to protect sensitive | information -- not just passwords. Does anybody know the current status | of standardization of an encryption option for TELNET? I don't, but I would question the wisdom of putting lots of effort into a telnet encryption scheme. I would think it would be much more productive to build an encryption scheme at the network level, say, as packets are being encapsulated, so that users can specify that they want an encrypted session for telnet or ftp, or even sendmail could encrypt automatically when sending to certain hosts. By using a public key scheme to exchange session keys (much like PGP), you could obtain the public key affiliated with your destination IP, and know your packets are getting to the right place. A general framework, based on public key encryption would be a far more flexible, powerful and useful tool for generating security on the net than simply securing TELNET. Adam -- Adam Shostack adam@bwh.harvard.edu Politics. From the greek "poly," meaning many, and ticks, a small, annoying bloodsucker. Have you signed the anti-Clipper petition?
I don't, but I would question the wisdom of putting lots of effort into a telnet encryption scheme. I would think it would be much more productive to build an encryption scheme at the network level
The reason that encrypted telnet is a good thing is that modification at the network level requires kernel modification, and encrypting a telnet does not. Installing an encrypted telnet daemon does require sysadmin cooperation, but it doesn't mean recompiling the kernel. As such, encrypted telnet is a good intermediate while the long term solution of encrypted IP gets developed and deployed. Eric
Eric Hughes says:
The reason that encrypted telnet is a good thing is that modification at the network level requires kernel modification, and encrypting a telnet does not. Installing an encrypted telnet daemon does require sysadmin cooperation, but it doesn't mean recompiling the kernel.
Although running an encrypted IP stack does require sysadmin cooperation, it does not require a kernel rebuild -- John Ioannidis has built modloadable versions of most of the swIPe software.
As such, encrypted telnet is a good intermediate while the long term solution of encrypted IP gets developed and deployed.
Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a standards-compliant encrypted telnet implementation, however. Perry
In message <9403021619.AA10508@ah.com>, Eric Hughes writes:
The reason that encrypted telnet is a good thing is that modification at the network level requires kernel modification, and encrypting a telnet does not. Installing an encrypted telnet daemon does require sysadmin cooperation, but it doesn't mean recompiling the kernel.
As such, encrypted telnet is a good intermediate while the long term solution of encrypted IP gets developed and deployed.
Has anyone (other than me that is :) thought of changing just the library routines for setsockopt/getsockopt/send/recv ? It wouldnt be too hard (me thinks) to do it, but i dont know where to find the sockets library. -Aggelos ----------------------------------------------------------------------------- Aggelos Keromitis kermit@csd.uch.gr Heraclion, Greece kermit@ics.forth.gr Finger kermit@calliope.ics.forth.gr for public PGP key -----------------------------------------------------------------------------
On Wed, 2 Mar 1994, Adam Shostack wrote:
I don't, but I would question the wisdom of putting lots of effort into a telnet encryption scheme. I would think it would be much more productive to build an encryption scheme at the network level, say, as packets are being encapsulated, so that users can specify that they want an encrypted session for telnet or ftp, or even sendmail could encrypt automatically when sending to certain hosts.
I agree with your observation. The Telnet protocol is however independent of any underlying network protocol. In our application the Telnet connection can be established over a lot of different types of networks. Implementing secure IP will not give us much since it does not cover the other possibilities for a Telnet connection. It is also a question of resources (read "time") -- we require a solution *now* (and preferable yesterday :-) No flame, just an observation that what seems to be a better solution is not always suitable... -- Rolf ---------------------------------------------------------------------- Rolf Michelsen Phone: +47 73 59 87 33 SINTEF DELAB Email: rolf.michelsen@delab.sintef.no 7034 Trondheim Office: C339 Norway ----------------------------------------------------------------------
The IP security program I have been working on (slowly) is a packet redirector and cryptdec. You ask it to encrypt packets comming in on one socket, and pass them out to another socket (also to decrypt those comming in on the second socket and pass them out the first socket). Thus you can run one of these on the X server, and one on the X client, and all the X trafic becomes encrypted over the net. You can telnet to the local redirector, to the forign redirector, and then to the standard telnet port. Or FTP, or whatever. I am still learning about net software, and this vision may not be easly implemented, or sockets may be the wrong level of interface to the net, I dunno. But I do know that my unix (SCO) and my X server (WINDOWS) both support this stratagy. j'
Adam Shostack <adam@bwh.harvard.edu> writes:
A general framework, based on public key encryption would be a far more flexible, powerful and useful tool for generating security on the net than simply securing TELNET.
I sincerely doubt that such a system would be designed or implemented before the turn of the century. All one needs to do is take a look at the PEM key certification authority clusterfuck to see just how difficult it can be to implment something like this. The additional benefits that adding encryption to telnet offer is that the telnet protocol is used in more areas than telnet. Many programs and protocols use the telnet system for control channels and other bits so that a significant change to telnet can have ramifications beyond just the obvious ones... jim
Couple of comments: 1) Kerberos *does* work between corporate entities. I can, for example, go to Iastate (ISU) and get MIT Kerberos tickets, and then rlogin -x to MIT, encrypting the session (I can, and I have). Also, it is possible (and I know someone who is doing it at this moment) for someone from ISU, with ISU tickets, to log into an account here at MIT. 2) Using your example, a user on host A telnets to host B, and from host B they telnet to host C, if the A<->B link is encrypted, then so long as the user trusts host B, then A<->C is secure as well (assuming B<->C is encrypted). 3) Just encrypting from client->server will not necessarily reduce the load on the server. Also, doing something like DES is really not a very high CPU operation, IMHO. Maybe a better protocol than the one done in rlogin -x is in order (this sends 8 characters over the link for every successful "read", which means you can be getting anywhere from 100% down to 12% throughput of plaintext in the cyphertext!) 4) Charon, which is based upon Kerberos, was developed exactly for this type of problem: you want to authenticate securely over links which may not otherwise be secure, but you trust the CPU in front of you! The paper describing Charon is available via anonymous ftp: ftp://toxicwaste.mit.edu/pub/charon/thesis.ps.Z Enjoy! -derek
participants (9)
-
Adam Shostack -
Aggelos D. Keromitis -
Derek Atkins -
hughes＠ah.com -
Jef Poskanzer -
Jim McCoy -
jpp＠markv.com -
Perry E. Metzger -
Rolf Michelsen