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

[Matej Kosik]

Rob Meijer wrote:
> On Fri, September 4, 2009 11:59, Matej Kosik wrote:
>> Rob Meijer wrote:
>>> On Fri, September 4, 2009 00:11, Matej Kosik wrote:
>>>> Rob Meijer wrote:
>>>>> 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."
>>>>>
> 
> - - -
> 
>>> 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.
> 
> I disagree. IBAC just combines the two types of authentication in such a
> way that both authority and accountability flow from the identity of the
> principal at the other end. It is easy from this premise to come to IMO
> false conclusion that authentication by itself is about identity. IMHO it
> is not, I think it is about authority and/or accountability for what a
> property . Does this view make any sense to you ?

I agree that in case of IBAC:
- identity (revealed by authentication) determines authority
- identity helps people to determine accountability of actions

It helps administrators to manage users but it does not help users to
manage untrusted code. This is why I am not interested in IBAC (although
I can see that it is perhaps useful for administrators).

> 
> - - -
> 
>>> 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.
> 
> Let me restate my point in a hopefully more complete way:
> 
> In a sparse-cap system there can be an authentication of the string that
> is used as capability. Is a system using a setup like this implementing
> anything that represents an interest in "which principal is probably at
> the other end"? Usually not.

I agree. Although this does not contract to what I have said earlier or
what is said here:

http://wiki.erights.org/wiki/Authentication

E.g., I do not claim that authentication is essential for building
robust software systems. Authentication is useful for other things (you
have mentioned some; I have mentioned some other).

E.g., I do not claim that security model must uncondictionally involve
authentication. There are cases when authentication is indeed essential
and there are cases when it is superfluous.

> It does however need to authenticate the cap
> as data to validate it as a source of authority.

I think this is an abuse of the term "authentication" because mere fact
that someone holds this sparse capability is a proof that given subject
can access designated object. Unforgeability (or infeasible
forgeability) of capabilities was alredy stated in their basic definition

http://wiki.erights.org/wiki/Capability

and we do not have and thus should not reiterate this point. It is
redundant. It would indicate that the original definition of capability
is somehow flawed and must be amended.

> 
> - -
> 
>>> 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").
> 
> Again I was a bit careless in my wording.
> 
> Authentication (general) = Validation of a specific property of an object.
> Authentication (infosec) = Authentication (general), where the property
>   being validated is either a 'source of accountability' or a 'source of
> authority' or both.
> 
> Source of accountability = A property from what an accountable
> person/system/subsystem can 'eventually' be inferred.
> 
> Source of authority = A property from what authorization can directly be
> inferred.
> 
> The below I feel addresses the essential differences between 1 and 2.
> 
>>> 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.

I think I roughly understand what you mean. But it pushes my mind on the
wrong track. You do not discriminate among permission and authority or
you use authority in place of permission.

I also do not like the fact that you reintroduce the concept that was
already introduced. Capabilities by definition give their holder the
permission to operate on a designated object:

http://wiki.erights.org/wiki/Capability

I am against in defining new term "source of authority". According to
you definition, it would support nondiscrimination between permission
and authority which is bad.

>>>
>>> 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,

If the single security model these people know is IBAC, then they will
perhaps see "high bias to IBAC". Is this our problem?

If other people know IBAC, and e.g. object-capability security model,
they will not see "high bias to IBAC".

So I do not view definition 1 as inherently flawed.

>>> 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?

I think that definition 2 covers a subset of things that are
(rightfully) covered by definition 1.

So I am for version 1. On the other hand, it is wise to highlight
specific motivations why we may in certain situations want to "which
principal is is probably at the other end of the communication channel".
Your definition (definition 2) mentions two points:
- in case of IBAC, identity of the subject at the other end
  determines its permissions
  (NOTE: I have replaced your word `authority' with `permission')
- being able to determine identity of the person at the other end
  is very useful in cases when we want to determine accountability
  of certain actions
  (e.g. who transfered given amount of money to a given account)
I have mentioned other uses of authentication.
- 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)
- 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).
- If a soldier (or a war machine) gets a command,
  it is very relevant who issued that command.
- 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.
- 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.
- There are many unexplored uses of authentication. For example,
  lack of identity hinders fruitful discussions in discussion
  forums. People can spread false statements without any penalty.
  For those who do not have deep knowledge about the discussed
  topic it is hard to distinguish between credible and incredible
  posts because there is no record of credibility of posters.

If it is not clear why definition 1 is good, it may be perhaps a good
idea to add examples of useful things (listed above) it covers to the page:

http://wiki.erights.org/wiki/Authentication

Sincerely.
-- 
Matej Kosik