Re: Answers to chat comments

This discussion encouraged me to update my access control proposal as found
here
https://github.com/w3c/automotive/issues/322

BR
Ulf

On Thu, Feb 13, 2020 at 9:34 AM Ulf Bjorkengren <ulfbjorkengren@geotab.com>
wrote:

> Hi Sebastian,
>
> I like your analogy:).
>
> And in my story there is no difference in that the guests will have to
> come with a signed list of which rooms they want to visit.
>
> Going back to my original proposal, the only difference is that the
> bouncer only requires the guests to show the list for certain rooms (like
> the kings more private rooms).
>
> By just adding one line in the root of the tree, “validate”: “read-write”,
> the stories actually become identical, the bouncer will require a list
> signed by the king by all visitors, for all rooms.
>
> But at the same time it gives flexibility in that for certain rooms the
> bouncer do not require a list, and for some the bouncer only require the
> list if the guest plan to stay over the night (write), not for day visits
> (read).
>
> The concept of roles can still be utilized, in the model described in
> chapter 6 of the Gen2 Core spec the guest would have to tell (and prove)
> the AGT-server not only its name, but also the role it wants. In the
> contact thereafter with the AT-server the guest name and role is on the
> (first) list signed by the king, and this server then uses this trusted
> information together with a policy document the king has provided it to
> assess whether the request for rooms to visit shall be granted to a guest
> with that role. If accepted this results in the signed list the guest
> brings to the bouncer.
>
> So I would say that we are aligned in the general concept, the difference
> is whether the bouncer shall require a signed list for all rooms per
> default, or whether the king shall be able to instruct the bouncer to leave
> some rooms unchecked (or only check stayover guests).
>
> BR
>
> Ulf
>
>
> On Wed, Feb 12, 2020 at 4:13 PM Schildt Sebastian (CR/AEX1) <
> Sebastian.Schildt@de.bosch.com> wrote:
>
>> Hi Ulf,
>>
>>
>>
>> I think turning this around does not necessarily means to be less open.
>> Yes, in our use cases we always require/use “mandatory” access control,
>> however in practice this would not preclude to for example configure parts
>> of the tree “free for all” (i.e. you can use them if you can reach the vis
>> server port). That would be like OBD, where the access control model is: If
>> you have (in case of OBD physical) access, you can get a certain
>> standardized set of information. In that case the only access/Security kind
>> of information in the tree nodes would be “public-writable” or
>> “public-readable”
>>
>>
>>
>> In another use case you might have a certain amount of access right, if
>> you run in a specific domain/runtime environment. For examples sake maybe I
>> am on an autonomous driving ECU,  I might assume all
>> programs/runnable/whatever in that domain have full access.
>>
>>
>>
>> For some shared ECUs I might really have fine-grained access controls on
>> a per-app basis.
>>
>>
>>
>> The main difference here is: We do not provide the bouncer (VIS server)
>> with a complete list of names and which rooms every  guy might access
>> beforehand, but instead every guest brings his own list of rooms  signed
>> and sealed by the king himself. Whether I got my papers from the king
>> directly, or whether I just have a default set, because I am member of the
>> royal guard does not concern the bouncer. Ok, I stop:  Let’s not
>> overstretch the metaphor here J Another advantage is, you can also
>> revoke those rights, limit them in time etc…
>>
>>
>>
>>
>>
>> Mit freundlichen Grüßen / Best regards
>>
>>
>> *Dr. Sebastian Schildt *
>> Communication and Network Technology (DS1) (CR/AEX1)
>> Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com
>> Tel. +49 711 811-15765 | Mobile +49 173 7124227 |
>> Sebastian.Schildt@de.bosch.com
>>
>> Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
>> HRB 14000;
>> Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
>> Dr. Volkmar Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian
>> Fischer, Dr. Stefan Hartung,
>> Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe
>> Raschke, Peter Tyroller
>>
>>
>> *Von:* Ulf Bjorkengren <ulfbjorkengren@geotab.com>
>> *Gesendet:* Mittwoch, 12. Februar 2020 15:38
>> *An:* Schildt Sebastian (CR/AEX1) <Sebastian.Schildt@de.bosch.com>
>> *Cc:* Isaac Agudo Ruiz <isaac@lcc.uma.es>; Adnan.Bekan@bmwgroup.com;
>> public-automotive <public-automotive@w3.org>
>> *Betreff:* Re: Answers to chat comments
>>
>>
>>
>> Hi Sebastian,
>>
>>
>>
>> it is an interesting and valid use case you bring up. With role data in
>> the VSS tree, if you want to add a new role it becomes necessary to have a
>> means to modify the tree in the vehicle.
>>
>> One possible solution, I do not necessarily recommend it, would be to
>> incorporate this into the "dynamic registry" mechanism that is a
>> discussed Gen2 feature.
>>
>> I do not see any other realistic solutions.
>>
>> This could be taken as an argument to go back to my initial proposal,
>> where role data was not in the tree:). Roles could still be part of the
>> complete model, but reside in the backend, as you suggest.
>>
>>
>>
>> Regarding your proposal, I believe it relies on that the tree has a
>> default read/write access control on all nodes?
>>
>> If so, personally I am not so fond of a "closed" paradigm like that. I
>> advocate a more "open" paradigm that require active choices to apply access
>> control.
>>
>>
>>
>> BR
>>
>> Ulf
>>
>>
>>
>> On Wed, Feb 12, 2020 at 1:48 PM Schildt Sebastian (CR/AEX1) <
>> Sebastian.Schildt@de.bosch.com> wrote:
>>
>> Hi,
>>
>>
>>
>> Just read through it, but one thing is not quite clear to me. Of course
>> in a system there are roles (and they can be as fine-grained or coarse as
>> desired) and those roles imply certain access rights to the VSS data model.
>> In your GIT discussion I saw:
>>
>>
>>
>> VSS nodes may be populated with the properties:
>>
>> “read-access”: [list-of-roles]
>> “write-access”: [list-of-roles]
>>
>> I understand the semantic to be: “To read this node, you need to be one
>> of those roles”. But isn’t the VSS tree representation a fundamentally a
>> wrong place to store this?
>>
>>
>>
>> I assume inside a vehicle I have the VSS data model and corresponding
>> server. Maybe I already know about some basic roles (i.e. OEM can do
>> everything. Third party Android Infotainment App thingy can only read some
>> non-critical stuff…)
>>
>>
>>
>> However, if some time after SOP I want to deploy a new
>> component/function/app with some specific requirements to access data (i.e.
>> a new role), I have lost, if the data model already lists roles (because I
>> would also need to update the data model/server in the car). Shouldn’t
>> rather the software component itself contain a manifest token, that
>> describes specifically
>>
>>
>>
>> Read-acces: powertrain.trasnmission.*
>>
>> Write-Acces: cabin.doors.*
>>
>>
>>
>> That way you gain flexibility. I still thing that you need “roles”,
>> however I would assume that generic roles (“OEM”, “third-party”,
>> trusted-thirdparty”) live in the backend. So for example a Keycloak server
>> might be used to model roles and stuff and then generate specific tokens to
>> be deployed with specific software components. That way would also allow to
>> change what rights are part of a role after deployment of the base software
>> stack.
>>
>>
>>
>> Tldr; VSS data model should not reference “roles”
>>
>>
>>
>>
>>
>> If I misunderstood, please enlighten me J
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Mit freundlichen Grüßen / Best regards
>>
>>
>> *Dr. Sebastian Schildt *
>> Communication and Network Technology (DS1) (CR/AEX1)
>> Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com
>> Tel. +49 711 811-15765 | Mobile +49 173 7124227 |
>> Sebastian.Schildt@de.bosch.com
>>
>> Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
>> HRB 14000;
>> Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
>> Dr. Volkmar Denner,
>> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian
>> Fischer, Dr. Stefan Hartung,
>> Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe
>> Raschke, Peter Tyroller
>>
>> *Von:* Ulf Bjorkengren <ulfbjorkengren@geotab.com>
>> *Gesendet:* Dienstag, 11. Februar 2020 20:00
>> *An:* Isaac Agudo Ruiz <isaac@lcc.uma.es>
>> *Cc:* Adnan.Bekan@bmwgroup.com; public-automotive <
>> public-automotive@w3.org>
>> *Betreff:* Re: Answers to chat comments
>>
>>
>>
>> Hi Isaac,
>>
>>
>>
>> I got inspired by your proposal to use RBAC, and have modified my
>> proposal accordingly.
>>
>> https://github.com/w3c/automotive/issues/322
>>
>> I would be very interested to hear your comments on it. Any by anyone
>> else also.
>>
>>
>>
>> BR
>>
>> Ulf
>>
>>
>>
>> On Wed, Feb 5, 2020 at 5:57 PM Isaac Agudo Ruiz <isaac@lcc.uma.es> wrote:
>>
>> Hi,
>>
>>
>>
>> I don’t want to introduce more noise to this issue but it is important
>> that we understand the implications of defining access control policies
>> that are both flexible and effective. I was tempted to comment in the repo
>> but I think I better explain my point of view by email.
>>
>>
>>
>> Assuming most nodes would be open, i.e. without any access restriction,
>> it makes sense to opt for a blacklist-like restriction, where only those
>> nodes that need some protection are tagged accordingly. However, I still
>> think we should go for a RBAC-like model, as mentioned in a previous e-mail.
>>
>>
>>
>> My proposal would be to add the following two properties to the data
>> model:
>>
>>
>>
>> “write” : [list of roles granted write access]
>>
>> “read” : [list of roles granted read access]
>>
>>
>>
>> This is the definition of an access policy, that applies to a particular
>> node and all nodes below in the hierarchy, until a conflict is found, in
>> which case, the properties of the node prevail and will become the default
>> for nodes below it.
>>
>>
>>
>> In the token we need to add the path and the roles granted to the user:
>>
>>
>>
>> "scp": "path"
>>
>> “roles": [list of roles issued in the token]
>>
>>
>>
>> In order to gran explicit access to all nodes easily, we can define a
>> base role and grant write and read to this role in the root node, so that
>> all nodes behind it would be accesible, both read and write modes, by the
>> base role without any explicit annotation.
>>
>>
>>
>> As an example, we could define only nine roles and name them from 0 to 9,
>> in order to implement a similar functionality to Ulf proposal. Then, in the
>> root we can place something like this:
>>
>>
>>
>> “write": [“0”]
>>
>> “read”: [“0”]
>>
>>
>>
>> That way, all nodes will be granted read and write access by default for
>> role “0”. However in order to implement the requirement that higher roles
>> will still gain access to nodes granted to role “0” we need to encode also
>> a hierarchy in the roles, i.e. “0”<“1”<…<“9”, that in this case is very
>> simple. If we plant to use general roles we would need to find a place
>> where to define this role hierarchy. Another, less elegant, solution would
>> be to grant multiple roles in the same token ...
>>
>>
>>
>> RBAC might seem more complex but it is also more flexible and allows for
>> the definition of some meaningful role names, e.g. “CAR_OWNER”,
>> “CAR_MANUFACTURER”, “ALL”, etc.
>>
>>
>>
>> If you find some value in my proposal I don’t mind elaborating it a bit
>> more and describe it in the repo. Also, if you think this could be
>> something to discuss in the f2f meeting please let me know. I would try to
>> be there.
>>
>>
>>
>> As a side proposal, but also in the line of access restriction, I would
>> like to get your feedback regarding the inclusion of end to end security
>> guarantees in the model.
>>
>>
>>
>> Do you think it makes sense to request the values of some nodes
>> encrypted, so that independently of the transport channel, they won’t be
>> accessed until they reach their intended destination?
>>
>>
>>
>> That’s particularly relevant if the final user is requesting data using
>> some kind of proxy. A solution would be to include in the token the public
>> key of the requestor, and have the server encrypt the results using this
>> key.
>>
>>
>>
>> Again, I’ll be happy to describe that as an issue if you find it
>> interesting.
>>
>>
>>
>> Best,
>>
>>
>>
>> Isaac Agudo
>>
>>
>>
>> Associate Professor
>>
>> Network, Information and Computer Security Lab
>>
>> University of Malaga
>>
>> www.nics.uma.es/isaac
>>
>>
>>
>>
>>
>> El 5 feb 2020, a las 13:42, Ulf Bjorkengren <ulfbjorkengren@geotab.com>
>> escribió:
>>
>>
>>
>> >> How would you keep 3 different scenarios in parallel, T1, T2, T3 with
>> C1 C2 and C3?
>>
>> Only one of the scenarios A, B, or C is possible at a given time.
>>
>>
>>
>> >> In proposal we have option to specify only 1 Tag, for actuator, sensor
>> or branch. I did not understand how to handle several Tags per actuator for
>> varipus clients.
>>
>> A tag is inherited by underlying nodes, unless a different tag exists in
>> a node.
>>
>> In the scenario I described, a tag was added to the vehicle.cabin.door
>> branch node, thus all leaf nodes below it inherited the tag property.
>>
>> It is only possible to assign one tag per node.
>>
>>
>>
>> >> Proposal would work if we would have only 1 client.
>>
>> Please explain why it would not work as described in the scenarios.
>>
>>
>>
>> >> As well how to handle complexity  users x tags x paths?
>>
>> With flexibility comes some level of complexity, that is unavoidable.
>>
>> If flexibility is not a desired feature, then the VIWI model could be
>> applied, and all nodes are statically assigned read-write access
>> restriction, i. e. every client request must contain a valid token. Then
>> this tag design can be scrapped.
>>
>>
>>
>> BR
>>
>> Ulf
>>
>>
>>
>> On Wed, Feb 5, 2020 at 12:02 PM <Adnan.Bekan@bmwgroup.com> wrote:
>>
>> >> how flow would look like for 4 diff clients, with tag read, write
>> only, read/write and "no tag", and they would access to exactly same branch
>> vehicle.cabin.door. Story with tokens I understand and all good, but with
>> tags I did not see any additional benefit.
>>
>> Excluding the write-only case, the following I believe shows the benefits
>> it can provide.
>>
>> The vehicle.cabin.door branch node has three different tagging options:
>>
>> T1: No tag
>>
>> T2: Validate: write-only
>>
>> T3: Validate: read-write
>>
>> The three clients have respectively: client 1:no token,client 2:
>> read-only token, client 3: read-write token (tokens have a scope containing
>> this subtree, and are non-expired).
>>
>> A: For the T1 scenario all clients are able to both read and write the
>> leaf nodes of the subtree.
>>
>> B: For the T2 scenario clients 1 and 2 can read leaf nodes, client 3 can
>> both read and write leaf nodes.
>>
>> C: For the T3 scenario client 1 can neither read nor write any leaf
>> nodes, client 2 can read leaf nodes, and client 3 can both read and write
>> leaf nodes.
>>
>> -----------
>>
>> How would you keep 3 different scenarios in parallel, T1, T2, T3 with C1
>> C2 and C3? In proposal we have option to specify only 1 Tag, for actuator,
>> sensor or branch. I did not understand how to handle several Tags per
>> actuator for varipus clients. Proposal would work if we would have only 1
>> client. As well how to handle complexity  users x tags x paths?
>>
>>
>>
>> Thank you
>>
>>
>>
>> --
>>
>> *BMW Group*
>>
>> Adnan Bekan
>>
>> Research, New Technologies, Innovations
>>
>> E/E Architecture, Technologies (LT-3)
>>
>> IoT and Software Technologies
>>
>>
>>
>> Parkring 19, 85748 Garching
>>
>>
>>
>> Telefon: +49-89-382-56368
>>
>> Mobile: +49-151-601-56368
>>
>> Mail: adnan.bekan@bmwgroup.com
>>
>> Web: http://www.bmwgroup.com
>>
>> --------------------------------------------------------------------
>> Bayerische Motoren Werke Aktiengesellschaft
>> Vorstand/Board of Management: Oliver Zipse (Vorsitzender/Chairman),
>>
>> Klaus Fröhlich, Ilka Horstmeier, Milan Nedeljković,
>>
>> Pieter Nota, Nicolas Peter, Andreas Wendt.
>>
>> Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Norbert
>> Reithofer
>>
>> Sitz und Registergericht/Domicile and Court of Registry: München HRB 42243
>> --------------------------------------------------------------------
>>
>>
>>
>> *From: *Ulf Bjorkengren <ulfbjorkengren@geotab.com>
>> *Date: *Wednesday, 5. February 2020 at 11:42
>> *To: *public-automotive <public-automotive@w3.org>
>> *Subject: *Answers to chat comments
>> *Resent-From: *<public-automotive@w3.org>
>> *Resent-Date: *Wednesday, 5. February 2020 at 11:38
>>
>>
>>
>> >> how flow would look like for 4 diff clients, with tag read, write
>> only, read/write and "no tag", and they would access to exactly same branch
>> vehicle.cabin.door. Story with tokens I understand and all good, but with
>> tags I did not see any additional benefit.
>>
>> Excluding the write-only case, the following I believe shows the benefits
>> it can provide.
>>
>> The vehicle.cabin.door branch node has three different tagging options:
>>
>> T1: No tag
>>
>> T2: Validate: write-only
>>
>> T3: Validate: read-write
>>
>> The three clients have respectively: client 1:no token,client 2:
>> read-only token, client 3: read-write token (tokens have a scope containing
>> this subtree, and are non-expired).
>>
>> A: For the T1 scenario all clients are able to both read and write the
>> leaf nodes of the subtree.
>>
>> B: For the T2 scenario clients 1 and 2 can read leaf nodes, client 3 can
>> both read and write leaf nodes.
>>
>> C: For the T3 scenario client 1 can neither read nor write any leaf
>> nodes, client 2 can read leaf nodes, and client 3 can both read and write
>> leaf nodes.
>>
>>
>>
>>
>> --
>>
>> *Ulf Bjorkengren*
>>
>> *Geotab*
>>
>> Senior Connectivity Strategist | Ph. D.
>>
>> Mobile
>>
>> +45 53562142
>>
>> Visit
>>
>> www.geotab.com
>>
>>
>>
>>
>>
>>
>> --
>>
>> *Ulf Bjorkengren*
>>
>> *Geotab*
>>
>> Senior Connectivity Strategist | Ph. D.
>>
>> Mobile
>>
>> +45 53562142
>>
>> Visit
>>
>> www.geotab.com
>>
>>
>>
>>
>>
>>
>> --
>>
>> *Ulf Bjorkengren*
>>
>> *Geotab*
>>
>> Senior Connectivity Strategist | Ph. D.
>>
>> Mobile
>>
>> +45 53562142
>>
>> Visit
>>
>> www.geotab.com
>>
>>
>>
>
>
> --
> Ulf Bjorkengren
> *Geotab*
> Senior Connectivity Strategist | Ph. D.
> Mobile +45 53562142
> Visit www.geotab.com
>
>
>
>

-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com