Re: Funded Deployments of Verifiable Credentials - framework for meta-credentials

On Mon, Sep 12, 2022 at 9:55 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> On 12/09/2022 17:34, Alan Karp wrote:
>
> I just popped out to pick up some bagels.  While standing in line I
> realized why I've been missing your point.  (Something about the smell of
> onion bagels?)
>
> I hope they tasted good :-)
>
Izzy's Brooklyn Bagels are the best.

> You are saying that the deputy submits the request with the user's VC.  Is
> that right?
>
> In ABAC the entity is called the PEP (policy enforcement point). But in
> your terminology it is a deputy since the user asks it to do something on
> its behalf.
>

I believe you are talking about 2 parties, the user and the PEP acting as
deputy.  I am talking about 3 parties, the user, the deputy, and the PEP.

>
> There are two problems with that.  First,  it's a gross violation of the
> Principle of Least Privilege,
>
> No its not, because prior to this step, the user requested to do
> something, and the PEP returned its LP policy, saying if you want to do
> this, then I need the following VCs from you. So LP has already been
> enforced because the PEP is required (in Europe at least due to GDPR) to
> only request those claims that are needed for the task in hand. (DIF has
> produced a draft spec for this request, called Presentation Exchange, to
> which the user returns a VP).
>
The problem is that a claim can authorize many permissions, not just the
one needed for a given request.

>
> because the deputy can use any of the user's permissions.
>
> Again you are missing the point that the PEP is a trusted component of the
> resource site. So it would not request the wrong action on behalf of the
> user, and it could not use the user's VCs itself because it cannot prove
> possession of them.
>
See above.  There is a third party acting as the deputy.

> Second, it only avoids confused deputy in the simplest case where there is
> only one argument.  You can still have a confused deputy when there are
> multiple arguments, and some need the permissions of the user and the
> others the permissions of the deputy.
>
> Now you are confusing me, because in the ABAC model the deputy never uses
> its own permissions to enact the task requested by the user (other than the
> ambient authority as we have agreed). If the user wants to perform a series
> of tasks, then the entire process is repeated so that least privileges is
> ensured for each action through the different VCs that the user presents to
> the PEP each time.
>
In the classic confused deputy described by Norm Hardy, there are two
arguments in the call.  One should use the permissions of the user; the
other, the permissions of the deputy.

--------------
Alan Karp


On Mon, Sep 12, 2022 at 9:55 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

>
> On 12/09/2022 17:34, Alan Karp wrote:
>
> I just popped out to pick up some bagels.  While standing in line I
> realized why I've been missing your point.  (Something about the smell of
> onion bagels?)
>
> I hope they tasted good :-)
>
>
>
> You are saying that the deputy submits the request with the user's VC.  Is
> that right?
>
> In ABAC the entity is called the PEP (policy enforcement point). But in
> your terminology it is a deputy since the user asks it to do something on
> its behalf.
>
>
> There are two problems with that.  First,  it's a gross violation of the
> Principle of Least Privilege,
>
> No its not, because prior to this step, the user requested to do
> something, and the PEP returned its LP policy, saying if you want to do
> this, then I need the following VCs from you. So LP has already been
> enforced because the PEP is required (in Europe at least due to GDPR) to
> only request those claims that are needed for the task in hand. (DIF has
> produced a draft spec for this request, called Presentation Exchange, to
> which the user returns a VP).
>
>
> because the deputy can use any of the user's permissions.
>
> Again you are missing the point that the PEP is a trusted component of the
> resource site. So it would not request the wrong action on behalf of the
> user, and it could not use the user's VCs itself because it cannot prove
> possession of them.
>
>
> Second, it only avoids confused deputy in the simplest case where there is
> only one argument.  You can still have a confused deputy when there are
> multiple arguments, and some need the permissions of the user and the
> others the permissions of the deputy.
>
> Now you are confusing me, because in the ABAC model the deputy never uses
> its own permissions to enact the task requested by the user (other than the
> ambient authority as we have agreed). If the user wants to perform a series
> of tasks, then the entire process is repeated so that least privileges is
> ensured for each action through the different VCs that the user presents to
> the PEP each time.
>
> Kind regards
>
> David
>
>
> --------------
> Alan Karp
>
>
> On Sun, Sep 11, 2022 at 6:51 AM David Chadwick <
> d.w.chadwick@truetrust.co.uk> wrote:
>
>> Alan
>>
>> your argument is inconsistent. First you say the  PEP (which makes the
>> access request to the PDP) is never a confused deputy, then you say the
>> deputy (which makes the access request to the PDP) has the potential to be
>> a confused deputy. Which is it please?
>>
>> Second the PEP is a trusted component of the resource infrastructure and
>> therefore would never make "any" request to the PDP. It will only ever make
>> the request that the VC Holder is making (barring a bug in the
>> implementation). This is the beauty of the claim based infrastructure, the
>> VC holder decides the designation to make, whilst the resource holder
>> decides which designations are allowed and which are not, thereby greatly
>> increasing the flexibility of the system.
>>
>> Whilst I appreciate the difference between a claims based VC and
>> capability based VC, there is no possibility of a confused deputy in either
>> case (given an un-buggy implementation).
>>
>> Kind regards
>>
>> David
>> On 10/09/2022 23:36, Alan Karp wrote:
>>
>> On Sat, Sep 10, 2022 at 2:30 AM David Chadwick <
>> d.w.chadwick@truetrust.co.uk> wrote:
>>
>>> I think the model works perfectly well for both capability and claims
>>> based VCs. The gatekeeper/PEP blocks the user's access, passes the user's
>>> VCs (of either type) to the appropriate PDP (clearly there will be
>>> different policies for capability based and claims based VCs) and acts upon
>>> the result. In neither case does the PEP pass its own VCs. So there is no
>>> possibility of a confused deputy in either case (unless I have
>>> misunderstood something)
>>>
>> The PEP is never a confused deputy.  (In the simplest case, the PEP only
>> has permission to invoke the PDP.)  The confused deputy is one user (the
>> deputy) performing an action requested by another user.  The deputy can be
>> a confused deputy any time you separate designation from authorization.
>>
>> An authorization VC necessarily designates a single resource and
>> specifies which operations on that resource are being authorized. Hence,
>> designation and authorization are combined in the VC, and there is no
>> confused deputy.  Note that the user delegates to the deputy a new
>> authorization VC for attenuation, selective revocation, and audit purposes.
>>
>> A claims VC says something about the holder, and typically does not
>> designate a specific resource.  When presented for access, the PDP checks
>> some property specified in the VC and makes an access decision for a
>> resource specified in the request.  Here designation and authorization are
>> separated, so there is a possibility of a confused deputy.  You might say
>> you are safer because the deputy can include the user's claims VC in the
>> request, but that would let the deputy make any request with the user's
>> claims VC, whether the user wants it done or not.
>>
>> The essential difference is that the authorization VC specifies something
>> about a specific resource, while a claims VC says something about the
>> holder.
>>
>> --------------
>> Alan Karp
>>
>>
>> On Sat, Sep 10, 2022 at 2:30 AM David Chadwick <
>> d.w.chadwick@truetrust.co.uk> wrote:
>>
>>>
>>> On 09/09/2022 21:16, Alan Karp wrote:
>>>
>>> On Fri, Sep 9, 2022 at 9:57 AM David Chadwick <
>>> david.chadwick@crosswordcybersecurity.com> wrote:
>>>
>>>> Sorry this just isn't the case. In the case of VCs, the user is wanting
>>>> to access a resource with their own VCs, and the resource has a
>>>> gatekeeper/PEP which is the Verifier/RP (the deputy in your terminology).
>>>> So the RP verifies the VC, then validates the VC, and if and only if the
>>>> verification and validation rules are passed is the user allowed to access
>>>> the resource. The RP does not use its own VCs during this process (in fact
>>>> it usually wont have any). I think you are thinking of the process that
>>>> takes place after the user has been granted (or denied) access. In this
>>>> case, say reading records from a database, the RP (deputy) is indeed the
>>>> user accessing the resource (on behalf of the real user). But the RP
>>>> already knows (from the PDP it queried) that the user has the necessary
>>>> permissions.
>>>>
>>> Clearly, I completely misunderstood your point.  If the user invokes the
>>> deputy with an authorization VC, we are talking about a capability
>>> invocation.  There is no confused deputy vulnerability.  I thought you were
>>> saying that the user invokes the deputy with a claims VC.  You might have a
>>> confused deputy depending on how you use those claims to make the access
>>> decision.
>>>
>>> I think the model works perfectly well for both capability and claims
>>> based VCs. The gatekeeper/PEP blocks the user's access, passes the user's
>>> VCs (of either type) to the appropriate PDP (clearly there will be
>>> different policies for capability based and claims based VCs) and acts upon
>>> the result. In neither case does the PEP pass its own VCs. So there is no
>>> possibility of a confused deputy in either case (unless I have
>>> misunderstood something)
>>>
>>> Kind regards
>>>
>>> David
>>>
>>>
>>>
>>> --------------
>>> Alan Karp
>>>
>>>
>>> On Fri, Sep 9, 2022 at 9:57 AM David Chadwick <
>>> david.chadwick@crosswordcybersecurity.com> wrote:
>>>
>>>>
>>>> On 09/09/2022 17:36, Alan Karp wrote:
>>>>
>>>> On Fri, Sep 9, 2022 at 2:49 AM David Chadwick <
>>>> d.w.chadwick@truetrust.co.uk> wrote:
>>>>
>>>>> Hi Alan
>>>>>
>>>>> we did discuss this many years ago in the context of X.509 Attribute
>>>>> Certificates and at the time you did agree that they could be used.
>>>>>
>>>> Yes, they can be used.  The question is if overloading something meant
>>>> as a form of authentication should also be used as a form of
>>>> authorization.  I have no problem doing that if the certificate clearly
>>>> indicates which of them it is for.
>>>>
>>>>> and providing their credentials. The deputy (acting as a PEP) then
>>>>> checks that these credentials are sufficient to do what was requested (by
>>>>> calling a PDP and passing the user's credentials. Note it NEVER passes its
>>>>> own). If the PDP returns OK then the user is granted access, otherwise the
>>>>> user is denied access. So there is no chance of the confused deputy
>>>>> situation arising.
>>>>>
>>>> I think that's the disconnect.  The deputy is not acting as a PEP.  As
>>>> far as the PEP is concerned, the deputy is just another user.
>>>>
>>>>
>>>> Sorry this just isn't the case. In the case of VCs, the user is wanting
>>>> to access a resource with their own VCs, and the resource has a
>>>> gatekeeper/PEP which is the Verifier/RP (the deputy in your terminology).
>>>> So the RP verifies the VC, then validates the VC, and if and only if the
>>>> verification and validation rules are passed is the user allowed to access
>>>> the resource. The RP does not use its own VCs during this process (in fact
>>>> it usually wont have any). I think you are thinking of the process that
>>>> takes place after the user has been granted (or denied) access. In this
>>>> case, say reading records from a database, the RP (deputy) is indeed the
>>>> user accessing the resource (on behalf of the real user). But the RP
>>>> already knows (from the PDP it queried) that the user has the necessary
>>>> permissions.
>>>>
>>>>
>>>> Consider a simple use case in which the user asks the deputy to
>>>> translate a document from French to German and put the result in a
>>>> specified place.  The user never accesses either file directly.  It simply
>>>> tells the deputy which files to use.  It is the deputy that will do the
>>>> reading and writing, so the PEP makes the access decision based on the
>>>> deputy, not the user.
>>>>
>>>> We are talking about different PEPs. In my case, say I go to the google
>>>> translate web service with my browser, and say that it is not a free
>>>> service but a permissioned one. Then I pass my VCs to the google PEP (web
>>>> service) asking it to translate the attached French document. The PEP
>>>> checks my VCs by passing them to its PDP, and either grants or denies me
>>>> permission. If the PDP grants me permission based on my VCs, then the PEP
>>>> will ask for the translation to take place and return the German document
>>>> to me. I think you are talking about this latter step. But this latter step
>>>> will never take place if the user did not have the required permissions in
>>>> the first place.
>>>>
>>>> Kind regards
>>>>
>>>> David
>>>>
>>>> No the access decision has already been made by the PDP and enforced by
>>>>> the deputy. Of course if the PDP's policy is wrong, then the user could be
>>>>> granted access, but that is not a confused deputy it is a bug in
>>>>> implementation.
>>>>>
>>>>>
>>>>> In fact, the verifier does not even know who the user is.
>>>>>
>>>>> In the ABAC model the verifier (PDP) does have the subject attributes,
>>>>> resource attributes, action attributes and environment attributes in order
>>>>> to make the access control decision.
>>>>>
>>>> In the cases in which you have a confused deputy vulnerability, the
>>>> subject is the deputy, not the user.
>>>>
>>>>>
>>>>> The result can be a confused deputy.
>>>>>
>>>>>> Of course with an appropriate schema we can constrain VCs to be
>>>>>> capabilities, but in general this would lose the benefits of the RBAC/ABAC
>>>>>> model. However where the use case requires it e.g. key to open hotel room,
>>>>>> then it is easily achieved with VCs.
>>>>>>
>>>>> Roles, attributes, and even access control lists are fine ways to
>>>>> describe access policies.  In a capability system, those policies are used
>>>>> to decide who gets which capabilities.
>>>>>
>>>>> And a bug in that policy would give a capability to someone who should
>>>>> not have it. So both models can suffer from bugs in implementation.
>>>>>
>>>> Correct.
>>>>
>>>> --------------
>>>> Alan Karp
>>>>
>>>>>