Via Bruce Schneier’s blog. Read it first.
When you reduce “admissibility” to a more simple and general form, it becomes the question “What happens to the data after it changes hands from the provider to the user?”. At some point, the handoff must occur, and beyond that point the server can have no knowledge or influence on the data’s further disposition. A few technologies, such as end-to-end encryption (SSL, etc) can help move the handoff to the client endpoint’s network stack, but at some point the data is decrypted, and it becomes accessible to the user’s code and eyeballs. This is the intention of a good secure system — to give the right data to the right users.
With that, necessarily, is the risk that other code and eyeballs will steal that data from the intended recipient – and that is a completely separate security problem that can only be solved on the client side. The parameters of the problem are the same “Four As” (or “CIA”) we already know. The security of the entire system scales like a fractal, to smaller and smaller scopes, until at last we have CRT to eyeball and fingers to keyboard (which leaves the realm of computer security and becomes an old-fashioned physical security problem) ((I’m not trying to minimize the value of physical security; if anything, it’s a lot harder than computer security. It’s merely a different kind of problem, and a different set of people need to work on it once it reaches that level.))
The security of the client is a problem; but it is neither the server’s problem nor a problem the server can solve at all. A server can never have any assurance whatsoever that its client is not vulnerable to attack. There are two ways for the server to obtain an answer to that question: the server can invasively investigate the client, or the client can claim to the server that it is secure. If the server invasively investigates the client, it can be tricked into investigating a clean-looking virtual machine. If the client claims it is secure, or rather, that some sort of configuration-management software running on the client claims the client is secure, that response can be spoofed by an attacker, or the configuration-management software can be compromised.
If this whole server-trusting-the-client’s-configuration sounds vaguely familiar, it’s exactly the same problem that ruins identd: the trust isn’t placed in identd, the trust is placed on the sysadmin of the remote machine. But how do you know to trust them? How do you know their machine is not lying and has not been hijacked? You cannot, and that is why identd is not a usable authentication system. ((So why do most IRC networks still require it, or make you wait thirty seconds until the request times out?))
Ultimately, the admissibility question reduces to “What are you going to do with this data after I give it to you?” This is not a new question, nor is it an easy one to ask and answer. Some of its unhappier answers include users taking laptops home after work where they can be burgled, or users deliberately giving or selling data to third parties. These are all completely outside the design of the security system. ((This problem of “what are you going to do with the data, now that you have it?” applies at all levels, including within the server as requests are processed, an area I think may be overlooked too often. This is the level at which you ask questions like “Do I trust that this data will not be snooped out of the kernel’s networking stack, before it’s sent out the ethernet port?”—don’t laugh, it’s happened!))
Until the day when data itself grows teeth and can defend itself against misuse, we have to carefully limit who we authorize, do our best to teach how to secure their own environments, and finally, trust those authorized users and their environments. That’s the way we do things now, and it’s not always a very fun way (especially that second part), but it’s the only way.
I hope somebody’s working on that teeth thing, though.
A final word: One-time passwords and time-based credentials (Opie, SecurID…), properly implemented, can make all forms of sniffing a LOT less profitable. The first credit card company that uses rotating card numbers based on a SecurID-style token is going to get my business. Alternatively, I’ve heard some European banks give customers scratch-and-sniff cards with a few dozen one-transaction authorization codes. That’s a nice low-tech solution that’s just as good at the end of the day.