AW: Answers to chat comments

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 ☺ 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<http://www.bosch.com>
Tel. +49 711 811-15765 | Mobile +49 173 7124227 | Sebastian.Schildt@de.bosch.com<mailto: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<mailto: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 ☺




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<http://www.bosch.com>
Tel. +49 711 811-15765 | Mobile +49 173 7124227 | Sebastian.Schildt@de.bosch.com<mailto: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<mailto:ulfbjorkengren@geotab.com>>
Gesendet: Dienstag, 11. Februar 2020 20:00
An: Isaac Agudo Ruiz <isaac@lcc.uma.es<mailto:isaac@lcc.uma.es>>
Cc: Adnan.Bekan@bmwgroup.com<mailto:Adnan.Bekan@bmwgroup.com>; public-automotive <public-automotive@w3.org<mailto: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<mailto: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<http://www.nics.uma.es/isaac>


El 5 feb 2020, a las 13:42, Ulf Bjorkengren <ulfbjorkengren@geotab.com<mailto: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<mailto: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<mailto:adnan.bekan@bmwgroup.com>
Web: http://www.bmwgroup.com<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<mailto:ulfbjorkengren@geotab.com>>
Date: Wednesday, 5. February 2020 at 11:42
To: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: Answers to chat comments
Resent-From: <public-automotive@w3.org<mailto: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<https://www.geotab.com/>





--
Ulf Bjorkengren

Geotab

Senior Connectivity Strategist | Ph. D.

Mobile

+45 53562142

Visit

www.geotab.com<https://www.geotab.com/>





--
Ulf Bjorkengren

Geotab

Senior Connectivity Strategist | Ph. D.

Mobile

+45 53562142

Visit

www.geotab.com<https://www.geotab.com/>