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

[David-Sarah Hopwood]

Karp, Alan H wrote:
> David-Sarah Hopwood wrote:
>> The gist of the above argument is that we can't really do
>> *identification* -- or at the very least, we are not actually
>> doing identification in most of the protocols that claim to be
>> doing it. So, we probably don't need the term "identification"
>> very much, and in any case it is not what is defined by
>> definition 1).
>>
> I divide the access control process into four steps.
> 
> Identification: Knowing who to throw in jail.  Often requires physical presence.
> Subject Authentication: Used to grant the authorizations associated with an identity.
> Authorization: The right to carry out some action.
> Access Check: Verifying that a request is authorized.
> 
> People tend to conflate these steps, particularly identification and authentication,
> but also authentication, authorization, and the access check.

I agree with most of this, but I find both the term and the definition
of "subject authentication" a bit imprecise.

When using authentication for access control, typically we
have a program, such as a shell, that is designed to act on
behalf of a principal. The local login procedure involves some
part of the system TCB displaying a login prompt; there is also a
channel from the computer's keyboard, or some other authentication
device such as a smartcard reader, to that part of the TCB. A
principal name (called a "username") is typed in, followed by a
password, and/or a smartcard is inserted. If that is sufficient
to authenticate the named principal, then the TCB creates a new
subject that is an instance of the shell program, and grants it
the permissions associated with the named principal, which results
in it having the authority derived from those permissions.

Notice that nothing here established anyone's identity. We do not
know who to throw in jail; we *only* know which username/password or
smartcard was used (and we don't know whether whoever used it was
still at the computer when some subject associated with the login
session did something jailworthy, or whether whoever was at the
computer, if anyone, should be held responsible for the actions of
that subject).

Also notice that we didn't grant permissions or authority to any
principal, nor did we authenticate any subject. Those would be
type errors, or category mistakes, in our modelling of the system.
We can only grant permissions (and hence authority) to subjects,
and we can only authenticate principals. The granting of the
permissions associated with the principal to the shell subject
on the basis of the principal having been authenticated, is an
*authorization* step performed by the TCB; it is not itself
authentication.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com