Re: low-overhead encrypted telnet
Eric Hughes says: > The reason that encrypted telnet is a good thing is that modificatio n > 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. Assuming, of course, that you're running a system that has modload. (Ironically, CERT has recommended that you delete loadable device drivers from systems that don't need them, as a way to guard against password- sniffers.) > 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. What standards? There are no RFCs, nor any current drafts, that define a telnet encryption option. The last draft I saw was from 1991, and Internet drafts expire after 6 months. As I recall, the idea that was being pushed then was to integrate encryption more closely with authentication.
smb@research.att.com writes:
Agreed -- sadly its arriving VERY slowly. 4.4BSD Lite comes with a standards-compliant encrypted telnet implementation, however.
What standards? There are no RFCs, nor any current drafts, that define a telnet encryption option. The last draft I saw was from 1991, and Internet drafts expire after 6 months. As I recall, the idea that was being pushed then was to integrate encryption more closely with authentication.
There is currently a chunk of code in the standard 4.3/4 telnet ref implementation that does encryption (DES in OFB, CFB, and ECB modes) It is a part of the AUTH-ENCRYPT module that is part of the telnet option specifications. There is work being done by the AUTH-ENCRYPT working group to try to get authorization tied more closely to the encryption options (last I heard they were slowing down and had hit a problem exchanging IVs for the encryption.) This work is using authorization methods (Kerberos, SPC, RSA) to drop in the key for the encryption. There is work being done by the IPSEC working group to add encryption to the IP layer of the protocol stack (telnet et al work at higher levels) but I have not read anything recent from this group in a while and last I checked they were still hashing out design details so I would not expect anything on this front for a while. There are a couple of people in Austin who have a version of the telnet ref implementation that will do a D-H exchange of 688 bits which can then be used by the ENCRYPT option and are trying to figure out which direction the AUTH-ENCRYPT people are going so that they can make the DHX option fit in seamlessly with the AUTH-ENC stuff (the DHX exchange tries to be first and start up an encrypted stream and if the AUTH-ENC option is invoked after the DHX exchange we want to switch to the new key without disruption.) Unfortunately 1994 has been a busy year, but hopefully there will be an alpha or beta for CPs to test next week... jim
smb@research.att.com says:
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.
Assuming, of course, that you're running a system that has modload. (Ironically, CERT has recommended that you delete loadable device drivers from systems that don't need them, as a way to guard against password- sniffers.)
A short sighted view. You can't stop line monitoring -- you should defend against it with encryption instead. In an environment like mine, there are literally thousands of potential line monitoring points that I cannot defend, but encryption gives me real security. Perry
participants (3)
-
Jim McCoy -
Perry E. Metzger -
smb＠research.att.com