Crypto synchronization seems to be a problem mainly in real-time appliations like digital voice, where you don't have a reliable protocol underneath you. I advocate two approaches that don't seem to have been pursued much yet, at least in the Internet: per-packet encryption (and possibly) authentication) just above the IP layer, and stream encryption just above TCP. The former technique has the advantage of denying your adversary the maximum amount of information, because only the IP header is in the clear. The transport header and all user data is protected, so an eavesdropper can't tell which applications are communicating. And with IP-in-IP encapsulation, you can even deny him knowledge about which machines are actually communicating - a network-level service analogous to anonymous remailers. With authentication, network level security also provides good protection against replay attacks. The latter technique (encrypting above TCP) has the advantage of being more efficient (it doesn't break Van Jacobson TCP/IP header compression), which may make it desirable for some interactive sessions. This is essentially how encrypted Kerberos Telnet works now, although I would like to generalize the service to work with any TCP client. Phil
-----BEGIN PGP SIGNED MESSAGE-----
Crypto synchronization seems to be a problem mainly in real-time appliations like digital voice, where you don't have a reliable protocol underneath you.
Phil, there is more to this than meets the eye. What happens if I, as an attacker, start feeding extra characters onto the modem line? Granted, I wont know what you are saying, since the link is encrypted, but if I can get an extra character on there, then the decryption will lose sync, and wont return the proper value... For example... Sender: more foo Encrypted data: HaoVwAog Received data: HaooVwAog Decrypted: morOmf&sm Now what? The sender and receiver are out of sync.... I believe this was what Nickey was talking about.. I was discussing this problem with a few people and haven't come up with a good, viable solution... yet.
This is essentially how encrypted Kerberos Telnet works now, although I would like to generalize the service to work with any TCP client.
Uhh, there is a kstream package somewhere (or am I thinking of vapor-ware, it's late and I'm tried). This wouldn't be very hard to create. In fact, I was hoping to do something like this with my Thesis... Although it might get left for "future work". This depends upon having a clearly denoted stream, which neither telnet nor kermit provide a good interface. (Trust me on this -- it took me a while to try to create one for the little I've hacked them for my Thesis). - -derek PGP 2 key available upon request on the key-server: pgp-public-keys@toxicwaste.mit.edu - -- Derek Atkins, MIT '93, Electrical Engineering and Computer Science Secretary, MIT Student Information Processing Board (SIPB) MIT Media Laboratory, Speech Research Group warlord@MIT.EDU PP-ASEL N1NWH -----BEGIN PGP SIGNATURE----- Version: 2.2 iQBuAgUBK8qLvTh0K1zBsGrxAQG39QLFFn0/Nz1zVRi6kHp+j+R0KAQQlEL6588d RfSshGGFhuXIJE/S8BP8kqLrKeSeRgSbil3zBLQZNeconnExaq6VUeO5Yvn9U/0S cHggKYBTlcz1zqjp7BLxLz8= =TBaq -----END PGP SIGNATURE-----
Uhh, there is a kstream package somewhere (or am I thinking of vapor-ware, it's late and I'm tried). This wouldn't be very hard to kstream was written by Ken Raeburn of Cygnus as part of our Cygnus Network Security work (support for Kerberos V4) and was included in the MIT Kerberos V4 patchlevel 10 "final" release. Our kerberized rlogin and rcp use it to handle encryption, it cleans up
the code a bit and makes it easier to modify other programs. _Mark_ <eichin@athena.mit.edu> MIT Student Information Processing Board Cygnus Support <eichin@cygnus.com>
participants (3)
-
Derek Atkins -
eichin＠cygnus.com -
karn＠qualcomm.com