[cap-talk] Abstractions that subsume capabilities

[David-Sarah Hopwood]

Jed Donnelley wrote:
> At 02:10 PM 3/6/2008, Karp, Alan H wrote:
>> Jed wrote:
>>> Hmmm.  I spent a bit of time looking around on the Web and
>>> didn't find anything that I would consider a 'taxonomy' for
>>> access control schemes.
>> I'm working on a study group for the Navy chartered with creating a 
>> position paper on SOA IA Security.  (Services Orientented 
>> Architecture Information Assurance, for you non-military types.  I 
>> usually apologize for the lack of acronyms in my notes to that 
>> group.)  They use DAC/MAC to describe who determines access and IBAC 
>> (identification), RBAC (role), ABAC (attributes) to define the 
>> authentication used to make an authorization decision.  Because of 
>> the acronym collision, we use NBAC (autheNtication) for the those 
>> three and ZBAC (authoriZation) for what I'm pushing.  That's sort of 
>> a 2-dimensional taxonomy.
> 
> Am I wrong in considering RBAC and ABAC really just forms of IBAC?

No, that's correct. So it is a hierarchical classification, not
2-dimensional:

<pre>
          access control
         /              \
      NBAC              ZBAC
    /  |  \            /    \
   /   |   \        caps   split-caps
IBAC RBAC ABAC     /  \
                   /  object-caps
           non-object-caps
</pre>

> That is, they are all properties of an identity -> an 'authentication'.
> If access is controlled for a "role" it is controlled for identities
> that (who?) have that role.  If access is controlled for an "attribute",
> it is controlled for identities with that attribute.  As you say it
> is really controlled for anybody/thing that can authenticate to
> an identity - and then for roles or attributes associated with the
> identity.
> 
> It seems to me that the relevant assumption for ZBAC is that
> all active entities must be associated with an identity
> whose roles or attributes can be used to make access control
> decisions.  In a typical market leading OS (e.g. Windows or
> Unix) processes maintain their association with an identity
> by the rule that forks retain the same identity.  This of
> course doesn't work across a network which acts more like
> sending data through a pipe or TCP to a process with a
> possible different identity.
> 
> What you refer to as NBAC (autheNtication based access control) seems
> to me an entirely different approach that goes off in another direction.
> It still requires an autheNtication to start things off - so I really
> don't see that distinction.  The key difference to me seems the way
> authorizations are controlled for which subjects (active entities that
> can make requests).  With capabilities (NBAC) it is running programs
> (with whatever "identity" or no identity) that are authorized or
> not - depending on whether they have the required capability token.

You have ZBAC and NBAC the wrong way round.

(I don't find these acronyms intuitive or memorable, either.)

-- 
David-Sarah Hopwood