Add trust-based authorization (certificate/token)

[tjrmarques]

Describe the feature

Problem Statement

Currently, Zenoh uses static per-node ACLs as its authorization mechanism, based on either user/passwd or certificate common-name, depending on the authentication method.

Although this is a simple solution and works on non-dynamic small-scale installations, it does not seem to scale well for larger and dynamic environments.

An example use case would be a Zenoh-based secure interface for robot/drone swarms (e.g. Intel's drone light shows), where every vehicle or ground station needs to be authorized to send/receive telemetry and command and control to/from the swarm. As for the previous use case, the problem is that all drones would need to update their user/certificate database (and maybe permissions) for every new drone or ground station added to (or removed from) the swarm.

Making the existing authorization methods work in these scenarios seems to require either:

• updating each node every time a new (relevant) user-password/certificate is added/deleted/changed, which can be really expensive for large deployments and sometimes impossible,
• sharing user/passwd between different nodes with equivalent permissions, which is a clear security breach and prevent auditing,
• sharing certificate CN between different nodes with equivalent permissions or managing certificate CNs to a common root with wildcards (one unique per permission set), which is also a security breach preventing auditing,

An additional problem to consider is that these distributed systems may not be connected to the internet at all, requiring them to be updated in person, or they may have spotty internet connection which may delay remote actions/functionalities or even prevent critical missions from being achieved.

Solution

The proposed solution is to implement an authorization method based on trust: each node would present a certificate/token with a set of attributes (roles or permissions) that is signed by a (chain of) authorization authority(ies) which, if trusted by the other node (via a trusted certificate/key store or a request to an authorization server), would grant access to the relevant actions/resources.

This "permission-asking" flow is the general idea behind OAuth2, OpenID Connect and Attribute Certificates (where authorization authorities work on the same trust chain principle has SSL certificate authorities), among others.

The specific mechanism by which nodes acquire such authentication tokens/certificates could be outside Zenoh's scope, but some revocation mechanism may need to be in scope, though it may consist of a simple revocation list that's populated by the application outside Zenoh's scope.

I'm not a security expert, so I defer to the Zenoh core team to select the most suitable technology to use or to design a more general solution that can support multiple of such trusted "permission-asking" technologies. I do prefer solutions that don't require full-time online access to an authorization server, in order to be able to support the no-internet or spotty connection use cases.

I'm willing to contribute to this feature with support from the Zenoh core team, as I've only just skimmed over Zenoh's authentication and authorization (access control) features implementation.

[anhaabaete]

Hello,

I sugest a simple solution that I has worked and thinking.

Use verbatim chunk, and create a hash channel based in a token. After associate a channel with it, you would have a exclusive e security cannel.

[roby2014]

Hello,

I sugest a simple solution that I has worked and thinking.

Use verbatim chunk, and create a hash channel based in a token. After associate a channel with it, you would have a exclusive e security cannel.

Mind explaining more in-depth or providing a simple PoC/pseudocode?