[cap-talk] Comparing models
Karp, Alan H
alan.karp at hp.com
Mon Jun 13 09:44:07 PDT 2011
I've changed the subject line to reflect the topic being discussed.
Virus Safe Computing Initiative
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
> -----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  is
> > Our work DOES support chained delegations so it is perfectly capable
> > doing what you want and it is a pity that you mis-represented our
> > 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
> > a chain of delegated credentials and/or policies falls within a
> > 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
> > on two counts (but you say there is none). Firstly the token has to
> > 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
> > to present the token, otherwise if it is a bearer credential then
> > 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
> > 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
> 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
> > 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
More information about the cap-talk