[cap-talk] Ambient authority, authentication and authorization

[Jed Donnelley]

At 08:10 PM 1/20/2007, David Hopwood wrote:
>Jed Donnelley wrote:
>[...]
> > It's true that even with capability based system there
> > seems to be a need for some sort of "bundled" authorization,
> > at least at the beginning of a "login" session.  How
> > does this differ from just a single capability to
> > something like a directory of other capabilities?
>
>It doesn't. But if identification is only used once per login, whereas
>authorization is involved every time a capability is invoked, doesn't that
>support the point that they should be distinguished?

The common understanding of the authentication/authorization
distinction is that authentication is done once to establish
identity, but then the established identity is used again
and again for authorization.  Authorizations are expressed
in terms of the established identity.  That's where I belive
the problem lies.

You see it throughout the discussion, e.g. on:

http://en.wikipedia.org/wiki/Access_control

For example:
________________
Authorization (or establishment) defines a USER's rights and 
permissions on a system. After a USER (or process) is authenticated, 
authorization determines what that user can do on the system.

Most modern operating systems define sets of permissions that are 
variations or extensions of three basic types of access:

     * Read (R): The USER can...
________________

That "USER" is the user identified by the authentication step.  It's 
that identity that's used throughout the access control mechanism in 
the future.

It's funny how somebody put that "(or process)" into the above.  It's 
almost as if you might think that a process might have it's own 
identity, but no, even there they're talking about a "user" identity.

Same with Accountability:
___________________
Accountability uses such system components as audit trails (records) 
and logs to associate a user with his actions.
___________________

Again that same identity, the "user" shows up.  That's the whole 
basis of the thinking about access control that's almost universal.

With a capability based system the capability doesn't use any notion 
of a "user" identity when it enables a permission.  An authentication 
happens in some sense with every capability access - even one like a 
"login" that might grant access to many more capabilities.  There is 
no separation between the "authentication" and the "authorization" in 
any capability access.

I really do believe that the whole "access control" model is stated 
and learned in terms of "the opposition".  That's one reason why as 
capability practitioners we're fighting an uphill battle.  Most 
people can't even really conceive of an alternative to identity based 
access control.  Get a few people to suggest now and then that POLA 
is too inefficient and/or results in user interfaces that are too 
difficult to use, and any further thought stops there:

"Law #1: If a bad guy can persuade you to run his program on
your computer, it's not your computer anymore."

The status quo.

--Jed  http://www.webstart.com/jed-signature.html