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

[Rob Meijer]

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 ?

- - -

>>
>> 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. It does however need to authenticate the cap
as data to validate it as a source of authority.

- -

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

Rob.