> Any ipsec system takes care of the eavesdropping problem; the harder > part is deciding how to do authorization. If you're trying to keep > the system open for public use, but also keep your intranet private, > you've got a more complex problem.
The Linux FreeS/WAN ipsec implementation has been working on this issue. The fundamental problem is that as specified, IPSEC requires manual setup of each tunnel at both ends. If N parties all want to communicate securely, this takes (N-1)**2 tunnels and (N-1)**2 effort. In the existing 1.91 release at www.freeswan.org, we added another layer above the standard IPSEC (which continues to work and interoperate fine). This new "opportunistic encryption" layer delays outgoing plaintext packets, and lets the IPSEC daemon look up their destination in the DNS. If it finds an authentication key there, the daemon sets up an IPSEC tunnel to the destination, and redirects the plaintext down that tunnel. If it finds no authentication key, it just forwards on the plaintext packet in the clear. Thus it takes advantage of 'opportunities to encrypt' while not impeding communication with unencrypted endpoints. This reduces the work of securing N sites to a factor of N (each site needs to publish its authentication key and install the opportunistic software), rather than (N-1)**2. The software sets up whatever subset is active of the (N-1)**2 tunnels, automatically. This not only makes IPSEC administration scale to the size of the Internet, but also introduces the 'fax effect' which encourages newcomers to adopt the same method because it means they can talk securely and effortlessly with an existing and growing population. This software is working well in testbeds, and the support will continue to be improved in upcoming software releases. The protocol is documented in an Internet-Draft. Both the software and the I-D are available at http://www.freeswan.org . This method protects us today against passive attacks. As Secure DNS is more widely deployed and operated, it will also protect us against active attacks, by making it impossible to spoof the keys provided in the DNS. > One interesting issue with radio networks is Man-in-the-middle attacks, > because nobody can intercept a request and forward it > faster than you can receive it directly, unless there are > distances that are too far for the two parties to reach each other > but still let the MITM contact both. There's almost certainly an Ethernet hop or a wireless repeater somewhere between the two ends of the IPSEC tunnel (or the TCP connections from your mobile node), where a mere wiring change or firmware patch will insert a black box in the middle. And there are also the techniques of listening to most of the packet, and then garbling its epilogue by jumping a conflicting transmission into the ether, making the real recipient decide that they didn't get a good copy. John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
