Re: Gen2 access restrictions

Hi,

>> After reading this mail I see it is also related to the how deep in the
tree is the node. I think we should avoid mixing deep and security level or
sensitivity

My idea of authlevel does not relate to how deep in the tree the node is.
The onion analogy was maybe not so good, if that is what got you think it
was related to the tree depth.
It is more like your comment "granted level to all documents below their
own security level".
BR
Ulf

On Tue, Jan 21, 2020 at 4:19 PM Isaac Agudo Ruiz <isaac@lcc.uma.es> wrote:

> Hi,
>
> When I first saw authLevel in Ulf e-mail I immediately thought about
> Mandatory Access Control policies (MAC), where documents are graded
> according to its security level, and people are granted level to all
> documents below their own security level. SELinux implements this kind of
> access control policies,
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/mls
> .
>
> After reading this mail I see it is also related to the how deep in the
> tree is the node. I think we should avoid mixing deep and security level or
> sensitivity.
>
> From my perspective, it makes more sense to use Tags for authorization
> instead of numbers. For example, one tag could be OEM, another could USER.
> That way less sensitive node would be granted to several tags (including
> OEM and USER), whereas more sensitive nodes only to OEM tag. We could also
> maintain some kind of ontology on the tags, so that permissions could be
> inherited, e.g. OEM could inherit permission to all nodes granted to the
> rest of the tags.
>
> If we elaborate that model a bit more we are moving to having full support
> to Role Based Access Control (RBAC), which is far more flexible than MAC.
>
> By using authorization tags, and defining an ontology for those
> authorization tags, we are also producing some meaningful information that
> can help deciding when granting access to particular tags.
>
> Best,
>
> *Isaac Agudo*
> *www.nics.uma.es/isaac <http://www.nics.uma.es/isaac> *
> Network, Information and Computer Security Lab.
> University of Málaga
> Spain
>
> El 21 ene 2020, a las 14:47, Ulf Bjorkengren <ulfbjorkengren@geotab.com>
> escribió:
>
> Hi,
>
> >> 1 will only happen in development (and maybe better not even implement
> it), and I am not sure I understand the authlevels, I think access is more
> complex that just separating a tree (of thousands of elements) to n
> authlevels.
> I am not convinced 1 will only happen i development. Remember that the
> transports according to spec must be the secure versions (https, wss).
> During dev it is quite convenient, so I think it should be kept.
>
> Authlevels makes it possible to "layer" the tree into n levels, where
> authlevel=0 provides accessibility to the smallest set of tree nodes, then
> growing for each level to the complete tree at authlevel=9 (analogy could
> be an onion, where authlevel=9 is the complete onion). Authlevel=9 would
> typically only be assigned to OEM controlled clients, while authlevel=0
> would be for third party apps, or the like. The authlevel would also
> control what is returned to the client when requesting a service discovery.
> On top of this there is also the access restriction model.
>
> >> but I think the information WHO actually can access what can not be
> stored in the data model / tree annotations itself.
> Both the access restriction metadata and the authlevel metadata are added
> to the tree by the layering mechanism, it is not part of the generic VSS
> tree. So how it is deployed in the tree is typically OEM specific.
>
> BR
> Ulf
>
> On Mon, Jan 20, 2020 at 3:56 PM Schildt Sebastian (CR/AEX1) <
> Sebastian.Schildt@de.bosch.com> wrote:
>
>> Hi,
>>
>> I may be not up to speed, with all discussion going on here recently, but
>> from what I see from here, I feel
>>
>>
>>
>> 1 will only happen in development (and maybe better not even implement
>> it), and I am not sure I understand the authlevels, I think access is more
>> complex that just separating a tree (of thousands of elements) to n
>> authlevels.
>>
>>
>>
>> I agree an access should differentiate between read and/or write and on
>> the level of individual elements in the tree (so leafs, or subtrees), and
>> an access token needs to describe it (the scp and acs in your model), but I
>> think the information WHO actually can access what can not be stored in the
>> data model / tree annotations itself.
>>
>>
>>
>> Rationale: I may have a VSS Gen2 system providing lots of data, but when
>> I ship it, I do not yet know who will need/be allowed to access what. So it
>> would be hard to stratify the data model using “access levels”. I would
>> rather assume the the token (scsp and acs) will be signed in such a way,
>> that the VSS implementation processing the token, can check whether it
>> trusts that CA (and it may have some idea what kind of data this specific
>> CA might even be allowed to give access to -> like your levels), but I
>> would see this rules as outside VSS scope and more like implementation
>> specific.
>>
>>
>>
>> The annotation of read/write is still useful, because apart from security
>> it is generally useful (meta-)information describing what could (provided
>> you have the right token) be done with a specific data point.
>>
>>
>>
>>
>>
>>
>>
>> Mit freundlichen Grüßen / Best Regards
>>
>>
>>
>> *Sebastian Schildt *
>>
>> *CR/AEX1*
>>
>> Threema / Threema Work: T8YWYXJ9
>>
>>
>>
>> *Von:* Ulf Björkengren <ulf.bjorkengren@gmail.com>
>> *Gesendet:* Donnerstag, 16. Januar 2020 10:55
>> *An:* public-automotive <public-automotive@w3.org>
>> *Betreff:* Gen2 access restrictions
>>
>>
>>
>> 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.
>>
>>
>>
>> BR
>>
>> Ulf
>>
>
>
> --
> 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