[cap-talk] Definition of Authentication on wiki.erights.org

[Matej Kosik]

Rob Meijer wrote:
> On Fri, September 4, 2009 00:11, Matej Kosik wrote:
>> Rob Meijer wrote:
>>> The list has been quiet lately, unfortunately some interesting
>>> discussions
>>> seem to have died out prematurely. One of them is I feel an essential
>>> one,
>>> that of the definition of authentication.
>>>
>>> As I stated in the discussion earlier, I feel that the definition in
>>> http://wiki.erights.org/wiki/Authentication (1) is overly complicating
>>> to
>>> explain, and quite possibly wrong.
>>>
>>> In any case I've been using an alternative definition in talks I've been
>>> giving, that I stated earlier in the died off discussion.
>>>
>>> I have been thinking about a clearer wording for the definition I have
>>> been using, and would like to suggest an alternative definition (2).
>>>
>>> 1) "Given one end of a communication channel, an authentication
>>> procedure
>>>     establishes which principal is probably at the other end."
>>>
>>> 2) "Authentication is the validation of a specific property of an
>>> object,
>>>     where this property must either be a source of authority, a source
>>> of
>>>     accountability, or both."
>>>
>>> I personally feel that 1 is to far detached from every day usage of the
>>> word, is to much centered around use by the identity based mechanisms,
>>> and
>>> is complicating something quit simple by doing so. Am I the only one who
>>> sees a problem with 1? And whatever the answer to that, is 2 a good
>>> definition?
>> The two definitions 1) and 2) are not equivalent. Are they?
> 
> For defining the IBAC world they seem in practice to be equivalent, for
> defining the usage of sparse capabilities in practice they might be at
> some abstraction level that you have in mind for 1, but I'm not sure, more
> on that below.
> 
>> If not, it
>> means that at least one of those definition does not define
>> authentication. I am not sure what is wrong with option 1).
>> (The word "detached from everyday" does not worry me---I am deteched :)
>>  I think you are wrong if you think that definition 1) somehow
>>  inevitably implies identity-based management.)
> 
> The fact that it implies an interest in "which principal is probably at
> the other end", makes it an identity centric definition in my view.

What do you mean by "identity centric"? How can authentication not be
identity centric? Determining identity of the principal at the other end
of the communication channel is the point.

Determining identity is useful in many cases. How can determining
identity itself be somehow a bad thing just because it is a cornerstone
of a scheme (IBAC) we all reject. Even if we are not interested in IBAC
there are still many cases where authentication is useful and it is not
connected with IBAC:
- authentication of documents
  (determining the principal that issued them)
  This makes it possible to swim in data instead of
  instead of being drowned in data noise. It is not always possible
  to scientifically verify everything yourself, most often you
  must rely on others. In this case the default trust to information
  is proportional to the credit of the principal that issued them.
- authentication of coins and bank notes
  (you want to be sure that they were issued by the central bank
   rather then printed by random person with a printer)
In both case determining of identity is essential but in none of the
cases this is related to (abused) IBAC.

IBAC itself is not bad (just abused by clueless people). Useful examples
of IBAC are:
- determining of identity of voters that came up to voting room.
  (voting commitee autheticates the ID cards---whether it was
   issued by the police---compares the information with the ID
   card with the person that showed it) and gives the person the
   authority to put a single authenticable envelope to the urn.
Capabilities would made it too easy to buy and sell votes.
(Unforgeable votes valid by delivery regardless of who delivered them).

> 
>> I can only say what I think is wrong with definition 2) ... I do not
>> understand it. What is "source of authority"? A subject that passes a
>> capability to another subject and thus raising its authority? How is
>> this connected with authenticity?
> 
> Lets look at sparse-cap based systems. In a sparse-cap system there can be
> an authentication of the string that is used as capability. Is there any
> interest in "which principal is probably at the other end"? Usually not,

I disagree. If a soldier (or a war machine) gets a command, it is very
relevant who issued that command.

Another example: If I get a scientific article, it is very relevant who
wrote it and what credibility given person has. I do not want to waste
my time to read the whole internet to find credible information.

Another example: You have a piece of software. We already know how to
follow POLA and POLA may be enforced over that software which is good
but it is always interesting (if a given software does not work as
expected) to determine its genuinity. You can blame vendor only for
genuine software not for fakes.

In all these relevant cases definition 1) makes sense whereas definition
2) does not make sense to me. It does not cover those relevant cases.

(nevertheless 2) may define some useful things I was not confronted so far.

> at least not for authentication purposes, possibly for accountability
> purposes though. There is an interest only in authenticating the property
> of the sparse-cap that makes it convey authority.

I do not understand. What kind of property?

> 
> In some cases, the sparse-cap IS

What is "IS"? Information system?

> a shared secret that by itself is the
> source of authority that needs to be authenticated.

I am sorry, what is "source of authority" (you define "authentication"
by means of "source of authority" and I do not know what it is).

How can "shared secret" (which I can imagine) be "source of authority".
What is "source of authority"?
How can the "source of authority" be "authenticated"?
Can you define "source of authority" without relying on definition of
"authentication" (because "athentication" already relies on "source of
authority").

> In other cases the
> sparse-cap holds some proof of knowledge that is cryptographically bound
> to a designation, so the knowledge of the creator of the sparse-cap would
> be she source of authority in that case.
> 
> In other cases using more elaborate certificate style cap as data
> representations, the identity of the principle at the other end may only
> be so much identifiable as that the cap-as-data defines something like:
> 
> "This cap was created by some unknown principle C (holding some private
> key for C) for private use by C as an attenuation with properties N to a
> cap Y delegated explicitly to C by an other unknown principle B (holding
> some private key for B). The cap Y was created by principle B as an
> explicit delegation of a third capability X issued by the known principle
> Alice (holding some private key)."
> 
> Now, given that Alice is our trusted and initial source of authority, this
> cap can be fully authenticated using a public key of Alice that we should
> have. Does this make Alice the principle at the other end? We are not
> interested in the fact that Alice is at some level of abstraction on the
> other side of a communication channel, we are interested in validating the
> source of authority. We are further not interested in what principle C
> might be, only possibly that the principle using the cap is the same
> principle that the authority the cap conveys should be the sole authorized
> user for this cap.
> 
> Do you agree that definition 1, while fitting at some level of abstraction
> exerts a high bias to the identity way of thinking about access control to
> people trying to understand the concept, while 2 is much more neutral but
> at the same time fits quite well with the identity as source of authority
> paradigm used in IBAC?
> 
> Rob

Sincerly
-- 
Matej Kosik