Beyond Identity
This is a very big topic on which I've written a lot, but I felt the need to follow up the previous post with a positive message.
1. We should set "identity" aside as a non-issue.
2. The real issue is that we need to do one of two things:
a) make a security decision
b) track someone down to punish, after the fact
Most "identity" establishment is in support of 2)b) - and is of little interest to me. Making sure that people online are identified is an attempt to get good behavior by threatening to do 2)b).
I'm interested in 2)a) - making security decisions - like whether or not to offer personal information to a web site, whether to reply to some e-mail that could be real or could be phishing, whether to open some e-mail attachment, whether to install some code on my computer, whether to share intimate secrets with some e-mail correspondent. These are all security decisions. The ability to punish someone after the fact, if that person misrepresented him-/her-self so that I made a bad security decision is nonsense. Will I be able to find that person? Will I be able to extradite that person from the former Soviet Union (or wherever they're hiding)? Will I have the money to punish the person? Will any monetary damage award compensate me for loss of some secret?
When I make a security decision, I do two things:
i) authenticate the other party
ii) make an authorization decision based on that authenticated ID
An ID mechanism that doesn't include an authenticator that I can verify or one that can be spoofed is very lame.
As I alluded to in that previous post, an ID mechanism that doesn't give me information that I need to make my security decision is completely pointless. This is where X.509 falls apart.
To use X.509 terminology, there are three parties:
CA: the certificate authority - who does the name creation and presumably identification and authentication process prior to certification
EE: the end entity - the person being named and certified
RP: the relying party - me - the person who has to make a security decision
If there's an ID mechanism that binds a person to an ID only the CA considers really meaningful, that might be used for 2)b) but it's useless for 2)a) - and therefore useless to me. As I said above, 2)b) is nonsense in today's world - especially given the Internet.
We have many mechanisms that allow us to authenticate (step (i) above), such as public key authentication. That's good. What we completely fail at is establishing identity in a way that makes sense to the RP (supporting step (ii) above).
My belief is that if we stick to the two steps of a security decision and determine how securely (accurately) we can do each of the two steps - assuming we are surrounded by active attackers looking for any way to defeat our system - then maybe we have a chance.
1. We should set "identity" aside as a non-issue.
2. The real issue is that we need to do one of two things:
a) make a security decision
b) track someone down to punish, after the fact
Most "identity" establishment is in support of 2)b) - and is of little interest to me. Making sure that people online are identified is an attempt to get good behavior by threatening to do 2)b).
I'm interested in 2)a) - making security decisions - like whether or not to offer personal information to a web site, whether to reply to some e-mail that could be real or could be phishing, whether to open some e-mail attachment, whether to install some code on my computer, whether to share intimate secrets with some e-mail correspondent. These are all security decisions. The ability to punish someone after the fact, if that person misrepresented him-/her-self so that I made a bad security decision is nonsense. Will I be able to find that person? Will I be able to extradite that person from the former Soviet Union (or wherever they're hiding)? Will I have the money to punish the person? Will any monetary damage award compensate me for loss of some secret?
When I make a security decision, I do two things:
i) authenticate the other party
ii) make an authorization decision based on that authenticated ID
An ID mechanism that doesn't include an authenticator that I can verify or one that can be spoofed is very lame.
As I alluded to in that previous post, an ID mechanism that doesn't give me information that I need to make my security decision is completely pointless. This is where X.509 falls apart.
To use X.509 terminology, there are three parties:
CA: the certificate authority - who does the name creation and presumably identification and authentication process prior to certification
EE: the end entity - the person being named and certified
RP: the relying party - me - the person who has to make a security decision
If there's an ID mechanism that binds a person to an ID only the CA considers really meaningful, that might be used for 2)b) but it's useless for 2)a) - and therefore useless to me. As I said above, 2)b) is nonsense in today's world - especially given the Internet.
We have many mechanisms that allow us to authenticate (step (i) above), such as public key authentication. That's good. What we completely fail at is establishing identity in a way that makes sense to the RP (supporting step (ii) above).
My belief is that if we stick to the two steps of a security decision and determine how securely (accurately) we can do each of the two steps - assuming we are surrounded by active attackers looking for any way to defeat our system - then maybe we have a chance.
posted by cme at 12/07/2004 08:21:00 AM
1 Comments:
Good point, Jon.
I wasn't thinking of traffic analysis (data mining; data aggregation; surveillance; ...) as part of the identity problem. Of course, it is. I was looking only at the white hat side of use of identity.
Have you read the NRC report? (linked to by Bob Blakley in his comment on my Axioms of Identity post) They intentionally covered both sides of the issue.
Post a Comment
<< Home