« Internet Design Opportunities for Improvement | Main | Recent Findings in Bank Security »



wait, what? You can't engineer truth and security is probabilistic? Why didn't someone tell me about this sooner?


no, the issue is that a primary principle in programming is to separate the stuff that changes frequently from the stuff that doesn't.

look at that list of authN protocols, its crazy, and that's just the names, *how* they all work is even more varigated.

whereas three part rules for authZ - associating Subjects, Rules, and Actions haven't changed since Martin Fowler was in short pants.

the Web lacks both and its much more doable to get authZ in.


My point was that A1 will always be a witty guess to some degree, and as such A2 will/should inherit the probabilistic nature of A1.

In a sense, we already engineer that now. The probability of A1 for Alice is "high" given a range of factors, so we can grant Alice a high (full) degree of A2. Alternately, if A1 does not meet "High" conditions for Alice, we can give partial A2 (this happens to me using VPN with my employer, actually).


"we're already able to engineer that now."


Andy Steingruebl

I think the point missed here is that the protocols themselves don't have any ability to even send authentication data. And, from their basic operational principles don't include basic things like preventing spoofing, etc. Almost all of the items you focus on above are about end-user authentication. They aren't necessarily about network-level authentication. IPv6 for example makes spoofing messages from off-subnet impossible, just by the nature of how the protocol works. This is, in my opinion, a step forward.


you're right there's a dependency, but the question i am trying to address is where do you deal with these concerns in a stack. software architecture has a particular focus on separation of concerns and for my money i want my guess logic separate from puzzle logic.

and again you have HTTP the cockroach of protocols which can serve as a transport for authN protocols (like Kerberos tickets), but by itself is not sufficient.

all i really want is web protocols that identify PEP/PDP with associated subject tokens, to force a policy check before accessing the resource, then we can swap in and out of the authN protocols du jour. because, hey - choice is good especially in cheese

Andy Steingruebl

Me, I'd like certain checks to happen way below that layer. If I have an intranet app, or maybe an app on my home network, it sure is nice to not allow anyone from the internet to even have a crack at exploiting it. Hence firewalls, which I know you hate. They are however a nice way to reduce attack surface. problem is, when you don't have any certainly about the veracity of the underlying protocols, you're also screwed.

The comments to this entry are closed.