From mboxrd@z Thu Jan 1 00:00:00 1970 From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] Plan 9 versus CORBA? MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20010925134207.32235199E9@mail.cse.psu.edu> Date: Tue, 25 Sep 2001 09:42:03 -0400 Topicbox-Message-UUID: f32a5db2-eac9-11e9-9e20-41e7f4b1d025 802.11's WEP was partially Lucent's fault, partially a bunch of other companies that were also on the committee. WEP stands for wired equivalent privacy. The intention was to guard against casual snooping. It was known at its inception that it was not a wonderful solution. Unfortunately, it was sold as much more than that. And even that fails after the Shamir and Stubblefield work. IEEE has a committee trying to address the situation with better encryption. After leaving Lucent, I'm no longer in the loop. The early proposals were flawed and shot down, which means that this time they're getting better review. Putting encryption in the network is like firewalls. You reject stuff before routing it around. It also provides some minimal protection for all the uncontrolled/unprotected systems on the network. However, its not a substitute for end-to-end encryption. It's also painfully hard to change when flaws are found. If they upgraded the current standard to include key distribution (there's already a Lucent product that does that over WaveLAN) then I'ld be happy to continue using it. However, I'ld also continue doing my own encryption. I don't trust the systems authorized to use our network any more than I trust the ones that aren't authorized. The upcoming Plan 9 version, tries to solve some data privacy/integrity problems by (1) taking all authentication out of the kernel and the applications and centralizing it in an authentication server on every cpu. The intent is to be able to switch algorithms with ease and to allow the simultaneous use of multiple algs and protocols. Also, you can export the server to machines you CPU to so that you don't have to depend on the current 'speaks for' relation if you don't want to. (2) encrypt all connections. At the moment the encryption keys are part of the authentication process. However, we'll probably move to just using TLS to encrypt all connections before authentication occurs. (3) secure servers using PAK or SRP to store a user's secrets. The server can be centralized or it could be personalized like a bitsy that you keep in your pocket. It's the user's choice where to keep the info; you could type it in every time if you want. We've got most of it working. All of our CPU connections have been enrypted for a while. Soon the file server ones will also. We've got to see what that does to throughput. We've already noticed that it really slows down modems that currently get some of their speed by compressing. That means we'll probably have to compress also. Luckily processors keep getting faster. All the extra cycles that Windows requires to have drop alpha blended menus can serve our encryption needs. Rob and jmk are just now converting our machines to run the new system. There's a lot of change between 9P2000 and the new security infrastructure so it'll be a while before we release it. We (ynl & ehg) have also added IPv6 to the stack. That hasn't been merged in yet but we'll do it before the release. We're currently considering what to do about IPsec. I really don't like it as a solution, partially for the same reason I don't like WEP: its done too low. However, we'll probably have to do it to be compatible. Security associations just bother me because they represent such a violation of layering. The advantage is the same as that of WEP, programs don't have to take part in the security, it can be done around them. Also, headers are also encrypted and mac'd so that a number of attacks, like the SYN one, become much harder. Anyways, that's the current plan. Rsc is doing a lot of it from MIT, I'm doing some from Avaya, and the usual suspects are working on it from Lucent. Sorry for the long message.