Gen2 access restriction tagging of signals

[UlfBj]

Chapter 6, "Authentication and Authorization", describes how JWT tokens can be obtained by clients, to be used to prove that they are authorized to access signals with access restriction. What is currently not described is how the access restriction is assigned to signals. The following is a proposal on how an individual signal, or a group of signals, can have access restriction assigned. As shown in the figure below, the general model is that a client submits a read or write request, addressing one or more signals to a guard (typically part of the Gen2 server). The guard then uses the provided address to inspect whether the addressed signal(s) have any meta data associated that assigns it access protection. If that is the case, then the request must contain a valid token that proves the client has the required authorization. If so, the guard response will contain the requested signal(s), else an error message is returned. Chapter 6 describes that two authorization servers are involved, the backend deployed AGT server that provisions the client with an Access Grant Token (AGT), and the vehicle deployed AT server that provisions the client with an Access Token (AT). The AT is then the token that the client inserts into the request to the guard. Chapter 6 also describes the notion of scope, which defines a subset of the VSS tree, and the authorized operation (read-only or read-write) on this subset. What is missing in chapter 6 is the mechanism for assigning access restriction to signals, which this issue proposes to solve by adding to VSS2.0 a new key-value pair, with the key name "validate", and the value being either "write-only" or "read-write". With this addition to VSS2.0, and an addition to chapter 6 describing it, the Gen2 CORE document will describe a complete solution for implementing access restriction on individual signals, or groups of signals.

[UlfBj]

Below is an attempt to formulate a requirement list for the Gen2 access restrictions.

1. No restriction, read/write is allowed without any token validation.
2. Write-only restriction, write requests require valid token, read requests without token validation.
3. Read-write restriction, both read and write requests require valid token.
4. Restriction can be applied to separate nodes, or to groups of nodes (subtree).
5. Client authorization is provided for a group of nodes (subtree). 
6. The general access to the tree for a client, with or without access restrictions, can be limited to a subtree. This general access can be set per client.

These requirements can be enforced by the following design.

Two new properties are added to the VSS2.0 model:

• "validate": "xxx" // where xxx can be either "write-only" or "read-write"
• "authLevel": X // where X is 0..9

Three fields are added to the Access token:

• "scp": "path" // where path is a valid VSS path
• "acs": "access" // where access is either "read-only" or "read-write"
• "authLev": Y // where Y is 0..9

The "validate" property can be set in branch nodes, or leaf nodes. In branch nodes it leads to that it is inherited in all underlying nodes (may be overridden by a "validate" in any of these nodes). A  node without access restriction set, either through inheritance or explicitly, has no access restriction. The "authLevel" property follows the same inheritance rules as "validate", with the difference that overriding is only possible with a higher value than the inherited, and that a node without authorization level set through inheritance or explicitly, is assigned the value 0. 

With the described information a Gen2 server will then be able to enforce the access restriction requirements 1 through 6 mentioned above. Requirement 6 has the limitation that clients with higher authorization levels can only be allowed to access a superset of what a client with a lower level has access to, i.e. it will always have access to the parts that clients with lower levels have. 

Please comment if you think that the requirements 1-6 are incorrect, or more reqs needs to be added, or if you see any flaws in the design. 

[tguild]

@UlfBj as promised some thoughts on this proposal that I partially shared and as I can't talk and scribe at the same time probably didn't adequately cover in minutes.

Best Practices and manifest

First time you introduced it I mentioned how the soon (awaiting internal discussions and trying to confirm some key players) relaunch the Business Group and how this fits into in-vehicle application Best Practices.

https://www.w3.org/2020/01/07-auto-minutes.html#item02

What I have been thinking about (interested in others' thoughts) for as a core component for best practices involves leveraging a policy language to define how an application can behave in a given vehicle as it may vary by manufacturer policy, capabilities and other factors such as party the app is being called by (owner, driver, mechanic) represented by different policies depending on capability of policy language. This is influenced by Armin Gerl's Layered Policy Language (LPL) PhD work he had been sharing with us.

While in VISS we kept it simple and left it to the underlying implementation to police requesting and setting signals, I agree it is better to be explicit. Amoung other benefits would be easier to spot misbehavior and treat applications as suspect/compromised.

Policy language can be used to define various things an application is permitted to do from the vehicle, such as:

• individual signal read and write access
• polling frequency per signal so as not to overtax underlying ECU and potentially cause damage to vehicle (warranty issue)
• amount of CPU and memory the application is permitted as there will be competition for computing resources
• whether the application is permitted to make external connections at all
• what signals (or assessments) can be off-boarded and shared with which specific external sites
• what external data is allowed to be retrieved to the vehicle
• external service certificate and encryption requirements
• what system libraries (or any local system file) can be called
• other interactions within the host system
• ...

An application's policy would be part of its package manifest along with additional configuration for the given vehicle platform, the code itself (no code should not be retrieved imho at run time), content such as images, dependencies, firewall (regular network and Web Application Firewall) rules, etc.

A researcher at MIT and I proposed prototyping this and various deviant behavior detectors/enforcers to the Ford-MIT Alliance but sadly didn't make the cut. I have been trying other grant funding routes for a related tangent telematics security proposal with US DOT, UL, Colorado State University, MIT and Geotab. A piece of that proposal would be contributing to these best practices and I would also focus my effort on the off-board network interactions.

== Granular access and existing standards

When we returned to this topic on the call, I had two additional thoughts not unrelated to the above.

https://www.w3.org/2020/02/04-auto-minutes.html#item01

We may want more clarity than just read and write per signal such as can I off-board a given signal or assessment derived from it and possibly other signals off the car? Perhaps read and/or write is transitional and such interactions are invalid now but may be permitted later eg after car warms up or stops moving. We may want to have those conditions as part of the response (based on Gunnar's layered metadata) so the application can now poll to find when that condition is met before re-requesting.

As promised I started, not done yet, looking around for applicable existing access control standards we might want to evaluate further for our needs. Searching on "access control standards" of course turns up tons of non-technical standards, playing around and adding WAMP for example turns up XACML policy language.

As mentioned, the group earlier kept it simple in VISS and we should discuss how much to complicate it with your proposal being a marked improvement.

[UlfBj]

After reading the proposal by Isaac Agudo to model the Gen2 access control on the RBAC model I have modified my proposal in that direction, as described in the following. Roles follow a hierarchical modelling, and are represented by values from zero to nine [0..9], where a higher value role has access to the nodes of a lower value, plus potentially more. In the token the parameters “scope” and “role” are then specified: “scope”: “path” “role” : x // 0<=x<=9 VSS nodes may be populated with the properties: “read-access”: “write-access”: The above properties can populate any node. In the case of a branch node, then all underlying nodes inherit the access control, if not overridden by a new access declaration in a node. Nodes without any access control specified can be accessed without the request containing any token. This proposal will meet the six requirements I mentioned in an earlier comment, and I believe it is aligned with the RBAC model, and the proposal by Isaac.

[UlfBj]

I think that the comment by @tguild above touches upon important aspect within the ecosystem that the Gen2 API will operate. So I think for Gen2 to become widely used, these topics needs to be worked on. However, I do not think they need to be, or should, be an integral part of the Gen2 spec, but rather be, as Ted mentions, described in a Best practices document, or the like. What needs to be done in the Gen2 context is to ensure that any requirements on Gen2 that this generate are fulfilled. My gut feeling is that it already does, but that is not much of a guarantee.

[tguild]

True, tags as metadata layer in VSS can be compatible if not enable various best practices including utilizing a policy language. As in my comment I mention there may be variables (such as who the authorized user/entity is) and different capabilities (access control to signals), sending that metadata to client application to handle dynamically would be helpful.

[UlfBj]

After the WG meeting yesterday I have updated my RBAC inspired proposal to meet the requirement of supporting mutual exclusivity between clients in regard to access control. The modification is simply to remove the hierarchical relationship between roles. The requirement can by the way be supported also with a hierarchical role relationship, but then it becomes the responsibility of the authorization server to assign the access permissions to realize a mutual exclusivity. Roles may be represented by int values, enum values, or textual names (design choice). There is no explicit relationship between roles. In the token the parameters “scope” and “role” are then specified: “scope”: “path” “role” : x VSS nodes may be populated with the properties: “read-access”: [list-of-roles] “write-access”: [list-of-roles] The above properties can populate any node. In the case of a branch node, then all underlying nodes inherit the access control, if not overridden by a new access declaration in a node. Nodes without any access control specified can be accessed without the request containing any token. I claim that this proposal, together with the access control model described in the Gen2-CORE document (https://rawcdn.githack.com/w3c/automotive/63ebd2f57f847f5a59dd508dbafcad81a2eba280/spec/Gen2_Core.html#-a-name-userauth-a-user-authentication-and-authorization), will meet the six requirements mentioned in an earlier comment, and all functional requirements mentioned in the WG discussion yesterday.

[UlfBj]

After the input from Isaac and Sebastian I would now like to propose the following access control model. VSS is extended with the property “validate”: “x”, where x is either “wrtite-only” or “read-write” The access token contains (besides other fields like name etc) “scope”: “path” “permission”: “z”, where z is either “read-only” or “read-write” “role”: Y, where Y is either an integer, enum value, or string (open design choice) The Access Grant Token server(see below) is responsible for authenticating the client, and assigning a role (negotiation with client). The Access Token server(see below) is responsible to evaluate the client request for “scope” and “permission, in which it after verifying the AGT token , reads the client role, and then uses a policy document to assess whether the request shall be granted or not. If granted the client receives the Access Token that it later uses in the requests to the Gen2 server.

(This is below) See Gen2 Core spec, chapter 6.

The model above is in my view aligned both with the RBAC model that Isaac has proposed that we incorporate, and with the model that Sebastian has presented. It also links together with the policy document discussions that Armin and Ted has brought to the table. So in my view we now have a solution that should be able to satisfy all participants in this discussion:).

[wzr1337]

Chapter 6, "Authentication and Authorization", describes how JWT tokens can be obtained by clients, to be used to prove that they are authorized to access signals with access restriction. What is currently not described is how the access restriction is assigned to signals. The following is a proposal on how an individual signal, or a group of signals, can have access restriction assigned. As shown in the figure below, the general model is that a client submits a read or write request, addressing one or more signals to a guard (typically part of the Gen2 server). The guard then uses the provided address to inspect whether the addressed signal(s) have any meta data associated that assigns it access protection. If that is the case, then the request must contain a valid token that proves the client has the required authorization. If so, the guard response will contain the requested signal(s), else an error message is returned. Chapter 6 describes that two authorization servers are involved, the backend deployed AGT server that provisions the client with an Access Grant Token (AGT), and the vehicle deployed AT server that provisions the client with an Access Token (AT). The AT is then the token that the client inserts into the request to the guard. Chapter 6 also describes the notion of scope, which defines a subset of the VSS tree, and the authorized operation (read-only or read-write) on this subset. What is missing in chapter 6 is the mechanism for assigning access restriction to signals, which this issue proposes to solve by adding to VSS2.0 a new key-value pair, with the key name "validate", and the value being either "write-only" or "read-write". With this addition to VSS2.0, and an addition to chapter 6 describing it, the Gen2 CORE document will describe a complete solution for implementing access restriction on individual signals, or groups of signals.

No security measure should ever default to lowest security (no token in this case) but to the highest (no access in this case).

If no tag is present, the system must response with auth error (http would return 403), until explicitly disabled all security by setting an appropriate token

BR

Patrick

[gunnarx]

I think this discussion has been greatly expanded on the mailing list. https://lists.w3.org/Archives/Public/public-automotive/2020Mar/thread.html

[tguild]

@UlfBj indicates it can be closed, handled in current draft