[cap-talk] Ambient authority, authentication and authorization

[Jed Donnelley]

At 08:44 AM 1/21/2007, David Hopwood wrote:
>Jed Donnelley wrote:
> > 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
>
>I've made an attempt to fix that; see what you think.

Looks like you made a pretty thorough pass through that document.

At the detail level, did you miss the "users" reference in the second
bullet under DAC:

"Access rights and permissions: These are the controls that an owner 
can assign to individual users or groups for specific resources."

or did you leave that intentionally as "users"?  It seems to me the "subject"
term should also appear there.

And then there's this at the end of that DAC section:

"Access rights and permissions for objects are assigned any group or, 
in addition to, individuals. Individuals may belong to one or many 
groups. Individuals can be designated to acquire cumulative 
permissions (every permission of any group they are in) or 
disqualified from any permission that isn't part of every group they are in."

Besides the apparently missing "to" in "are assigned any group" (?) 
it seems the use of the term "individual" in the above is standing in 
for user.  Perhaps you did a global search for "user" and missed that one?

This one is less important I think, but one could imagine RBAC 
applied to subjects rather than users, though I won't quibble that one.


Raising up one level, is it just me or is the section in that "access 
control" page on 'Telecommunication' thoroughly muddled?


Now back to the top level discussion of "the opposition":

Good effort David.  Still, aren't people just going to map subject to 
user and ignore the suggesting that subjects can be otherwise (e.g. 
processes or active objects)?

Consider the section on DAC where it says:
___________________________________________
Discretionary access controls can be applied through the following techniques:

     * Access control lists (ACLs) name the specific rights and 
permissions that are assigned to a subject for a given object. Access 
control lists provide a flexible method for applying discretionary 
access controls.
     * Role-based access control assigns group membership based on 
organizational or functional roles. This strategy greatly simplifies 
the management of access rights and permissions:
___________________________________________

Should we add a clause there on capability access control?  Perhaps 
also generalize the heading to something like "Discretionary access 
controls can be applied through the following techniques" to 
"Discretionary access controls can be applied through techniques such 
as the following"?

I made that change.

Maybe the addition of capability access control as an option will get 
people's attention?  That would be nice.  If we can keep pushing on 
things from all directions - network, OS, language - object, 
capabilities.  Maybe we'll get there in the end.

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