[cap-talk] Comparing models

[Karp, Alan H]

I've changed the subject line to reflect the topic being discussed.

________________________
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: Karp, Alan H
> Sent: Thursday, June 09, 2011 2:54 PM
> To: 'David Chadwick'
> Subject: RE: We met at the Cornerstones of Trust conference and...
> 
> David Chadwick wrote:
> >
> > that's fine. I would like to have exploratory discussions with them
> > please.
> >
> I've sent a note to a mailing list with people who might be interested.
> >
> > One point about your paper, your reference to my paper [5] is
> incorrect.
> > Our work DOES support chained delegations so it is perfectly capable
> of
> > doing what you want and it is a pity that you mis-represented our
> work
> > in your paper in such a way. If you read section 3.2 again there is a
> > part entitled "a description (schema) of the valid delegation trees.
> > This delegation policy component describes how the CVS can determine
> if
> > a chain of delegated credentials and/or policies falls within a
> trusted
> > tree or not". Now if that is not an explicit reference to chained
> > delegations I dont know what is.
> >
> I just re-read the section and fortunately made the same mistake this
> time, so I know why I got it wrong before.  I read the third bullet as
> saying that the delegation tree is something defined ahead of time by
> the administrator.  That's a different definition of chained delegation
> than we use, so we said you don't support it.  That's a gross
> overstatement.  I apologize.
> >
> > There are a number of other points in your paper that I take issue
> > with.
> >
> > 1. Concerning ZBAC tokens, there still has to be authentication of
> them
> > on two counts (but you say there is none). Firstly the token has to
> be
> > validated that it is not a forgery or been tampered with, secondly it
> > has to be validated that the entity presenting the token has the
> right
> > to present the token, otherwise if it is a bearer credential then
> anyone
> > can copy or steal it and use it successfully. In which case this is a
> > big security hole in ZBAC.
> 
> The first step in the validation checks that the entire request is
> signed by the private key corresponding to the public key in the
> outermost authorization assertion.  Then it walks the delegation chain
> to make sure that each step is valid and a legal subset of the rights
> of the delegator.
> 
> Sorry for the confusion on the word "authentication."  At that time, we
> were using the word to mean what we now call "subject authentication."
> We weren't aware of the confusion that caused with the use of the word
> to mean "checking authenticity."  We use the term "validation" for that
> process.  What we meant by saying there is no authentication is that
> the identity, role, or attributes of the party holding the private key
> is irrelevant to deciding whether or not to honor the request.  Those
> properties are used only by the delegator to decide whether or not to
> grant the rights.
> >
> > 2. Concerning ABAC and RBAC, these tokens are perfectly easy to
> > delegate. Consider, David has attribute A issued by C, and David
> > delegates to Alan so that Alan has attribute A issued by David.
> > Providing that C said that David can delegate his credential then
> anyone
> > that trusts C to issue A, will trust that Alan has A through the
> > delegation chain. You dont recognise this in your paper but you
> should.
> 
> The systems I'm familiar with don't support such delegation.  They
> accept attribute assertions only if issued by a trusted third party.
> Your work does support attribute delegation, which makes it more
> interesting to me.
> >
> > Its late now, so I will look at your example in more details tomorrow
> or
> > over the weekend to tell you what the solution is, but I know already
> > that there is one using delegated attribute/role credentials.
> >
> No rush.  I know it's just a matter of turning my brain inside out, but
> a patient tutor can speed the process.
> 
> ________________________
> 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
> *