[cap-talk] What we have here is a failure to communicate

[Rob Meijer]

On Sun, December 28, 2008 06:46, Karp, Alan H wrote:
> Jed wrote:
>>
>> To me the OCap model does "conflate" authentication and authorization.
>> That is, the possession (as evidenced by communication) of a capability
>> demonstrates that the communicating subject is authentic (in that it
>> apparently possessed the communicated capability) and is authorized to
>> access (in the sense of "access control") whatever the capability
>> grants (permits) access to.
>>
> Monty Zukowski wrote:
>>
>> What would really help me is an example of authentication without
>> authorization and vice-versa.
>>
> Rob Meijer wrote:
>>
>> When defining authentication in general, I feel an important point to
>> make
>> is that what is needs to be authenticated for the sake of access
>> control
>> is the "source of authority", while what needs to be authenticated for
>> the
>> sake of auditing is the "source of accountability".
>>
> While there seems to be a single, agreed to meaning for "authorization",
> there isn't for "authentication."  For example, people talk about
> authenticating the integrity of a document and authenticating a letter of
> authorization.  That means we have to be sure to say what we mean when
> using the term.  Henceforth, I will try to use the "subject
> authentication".
>
> I divide the access control process into four steps.
>
> 1. Identification: When I started work at HP, the security office checked
> my driver's license, took my fingerprints and verified my DNA.  (OK.  Not
> the DNA part.)  That's how they know who to throw in jail if I do
> something bad.  The security office then granted me the means to
> authenticate as an HP employee who works at HP Labs.
>
> 2. Authentication: My login authenticates me as a subject who is an HP
> employee who works at HP Labs.
>
> 3. Authorization: The system knows that an HP employee is granted the
> authorization to use the Corporate portal, and an HP Labs employee gets
> the authorization to use the research library.
>
> 4. Access decision: The authorization is checked when a request is made to
> see if it is valid for the request.
>
> Not all of these is applicable for every access control mechanism.  None
> of the access control models I know deals explicitly with identification,
> but it's necessary for responsibility tracking.
>
> Consider ACLs.  Adding an account allows that user to authenticate as a
> particular subject.  Adding an ACL entry for that user for a resource is
> an act of authorization.  The access decision depends on the result of
> checking the ACL when a request is made.
>
> Ocaps don't authenticate the subject, and the access decision is implicit
> in the authorization.
>
> The last three steps are explicit with ZBAC.  A SAML assertion is an
> authorization issued to a public key.  I consider proof of knowledge of
> the corresponding private key to be an authentication.  The SAML assertion
> is checked to make an access decision.
>
> Unfortunately, I still run into statements that conflate two or more of
> these steps, such as the one that started this thread.

I think I almost completely agree with the above, but I don't quite seem
to understand why you would want to limit the discussion to 'subject
authentication'.  It would seem to me that the same description would be
perfectly valid if you state that authentication authenticates something
from what either authority or accountability flows. In ACL systems
authority and accountability both flow from subject identity.
In capability systems accountability may or may not flow from subject
identity but authority normally does not.

I feel it is important to not fall into the identity bias trap by limiting
discussion of authentication to the authentication of subject identity. We
should actualy try to make clear that authentication IS a broader concept,
and that authenticating for example your SAML assertions is just as much
an act of authentication as authentication of subject identity.

Rob