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

[Karp, Alan H]

Rob Meijer wrote:
>
> 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.
>
I agree, but I think we need to be explicit.  When I use the term "subject authentication", I am making it clear what aspect of authentication I mean.  It's why we use the term "object capabilities" (a term first used only recently), to make it clear that we're not talking about special hardware registers or some other form of capabilities.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp


> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
> bounces at mail.eros-os.org] On Behalf Of Rob Meijer
> Sent: Monday, December 29, 2008 2:17 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] What we have here is a failure to communicate
>
> 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
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk