-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gerck Sent: 7 juillet 2004 14:46 To: [EMAIL PROTECTED] Subject: identification + Re: authentication and authorization
>I believe that a significant part of the problems discussed here is that >the three concepts named in the subject line are not well-defined. This >is not a question of semantics, it's a question of logical conditions >that are at present overlapping and inconsistent. > >For example, much of what is called "identity theft" is actually >"authentication theft" -- the stolen credentials (SSN, driver's >license number, address, etc) are used to falsely *authenticate* a >fraudster (much like a stolen password), not to identify. Yes and no. The problem is that most authentication and authorisation schemes today are actually identification and authentication and authorisation schemes. Even when you read CISSP study guides, they always describe it in 3 steps, identification, authentication and authorisation. The thing is that we can do without identification. Identification is not necessary, even if you want accountability. In Identification-authentication-authorisation schemes, identification is the process of pin-pointing an exact individual from a set of individuals (e.g. SSN allows you to define a unique united-states citizen), authentication is the process of verifying that the individual claiming to be who he identified himself as, is really that individual. But most systems don't really need identification, all they need is a proof that the individual possesses a certain attribute. It is possible to do authentication and authorisation, without doing the identification part! For example, it is possible to prove that you are a united-states citizen that has a valid SSN number, without actually giving out information about SSN. Why is identity theft a bad thing? Usually, you don't want your identity to be stolen because you could be accused of something due to accountability that is associated with your identity. The problem is not that someone can authenticate himself to a system he is not suppose to have access to, the problem is that a thief can identify himself as you and authenticate himself as you, and than do bad things (like transfer your money). The problem is not really authentication theft, its identity theft, or if you want to put it even more precisely, it's "identity theft and authenticating as the individual to whom the identity belongs to". But the latte doesn't make for a good buz-word :) Here is another way of seeing it. Consider a system where you need to authenticate yourself as a citizen, of some region, that is 18 years of age or older, in order to participate in some gambling thing say. One way to implement the authentication and authorisation in the system is to have each individual identify themselves, and then authenticate themselves. If the individual is part of a set of individuals that are known to be over 18, then the individual is given access. Another way to implement it is to have each individual prove that they are over 18 without identifying themselves, using Stefan Brands digital credentials say. If the authentication is successful, the un-identified individual is given access. In the latter case, you don't really care about authentication theft unless there is some sort of accountability (with Stefan's digital credentials, you can embed the identity in the tokens that are presented for authentication, the identity can only be revealed under certain circumstances, for example excessive use or if require by a law, it could be revealed by a third party). I do agree that stronger authentication does help, preferably authentication based on zero-knowledge protocols, since these reveal less information about the individual's identity that can be used to impersonate the individual. --Anton Once we understand this, a solution, thus, to what is called "identity theft" is to improve the *authentication mechanisms*, for example by using two-factor authentication. Which has nothing to do with identification, impersonation, or even the security of identification data. In further clarifying the issue, it seems that what we need first is a non-circular definition for identity. And, of course, we need a definition that can be applied on the Internet. Another important goal is to permit a safe automatic processing of identification, authentication and authorization [1]. Let me share with you my conclusion on this, in revisiting the concept of identification some time ago. I found it useful to ask the meta question -- what is identification, that we can identify it? In short, a useful definition of identification should also work reflexively and self-consistently [2]. In this context, what is "to identify"? I think that "to identify" is to look for connections. Thus, in identification we should look for logical and/or natural connections. For example: - between a fingerprint and the person that has it, - between a name and the person that answers by that name, - between an Internet host and a URL that connects to it, - between an idea and the way we can represent it in words, - conversely, between words and the ideas they represent, - etc. Do you, the reader, agree? If you agree you have just identified. If you do not agree, likewise you have identified! The essence of identification is thus to find connections -- where absence of connections also counts. Identification can thus be understood not only in the sense of an "identity" connection, but in the wider sense of "any" connection. Which one to use is just a matter of protocol expression, need, cost and (very importantly) privacy concerns. The word "coherence" is useful here, meaning any natural or logical connection. To identify is to look for coherence. Coherence with and between a photo, a SSN, an email address, a public-key and other attributes: *Identification is a measure of coherence*. The same ideas can be applied to define "authentication" and "authorization" in a self-consistent way, without overlapping with each other. Comments? Cheers, Ed Gerck [1] The effort should also aim to safely automate the process of reliance by a relying-party. This requires path processing and any algorithm to eliminate any violations of those policies (i.e., vulnerabilities) that might be hard to recognize or difficult to foresee, which would interfere with the goal of specifying a wholly automated process of handling identification, authentication and authorization. [2] This answer should be useful to the engineering development of all Internet protocols, to all human communication modes, to all information transfer models and anywhere one needs to reach beyond one's own point in space and time. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]