Capabilities for Distributed Authorization

1.2.1. Authentication

Password-based authentication mechanisms require that the tuple of user name and password (or password hash) are sent to some central repository where records of such tuples are kept; if the tuple is found, the user name is authenticated.¶

This common scheme mixes different aspects to authentication, however, which are worth disambiguating.¶

Endowment:

The act of logging in establishes an association between a user name and the person interacting with the device. More broadly speaking, (parts of) a three-way endowment are performed: an identifier is endowed with attributes, which describe a person in sufficient detail to identify them.¶

Secret Proving:

Logging in also proves that the person interacting with the device is in possession of some secret, which should only be known to the person which merits having the user name linked to the secret associated with them.¶

The distinction becomes somewhat more relevant when we move towards distributed authentication schemes, which rely on public key cryptography.¶

1.2.2. Authorization

Authorization occurs only after secret proving. Once an identity has been established, it is then mapped to privileges associated with said entity, which determine which object(s) it has access to.¶

There exist a plethora of methods to establish this mapping. Access-control lists (ACL) simply provide tuples of identities, privileges and associated objects. Role-based access control (RBAC) is effectively identical, if the identities specified are not those of individuals, but of groups (as a group member, an individual inhabits the associated role). A comparable approach is Organization-based access control (OrBAC), which not only abstracts the identity to that of a role, but performs a similar abstraction on the object and privilege.¶

More complex systems such as context- or lattice-based access control (CBAC and LBAC respectively) derive a mapping from properties of or labels attached to the individuals and objects. Finally, graph-based access control (GBAC) starts with a graph of an organization, and derives privileges from the properties inherited by being part of a larger organizational structure.¶

What these systems address is the problem of managing the mapping of an identity to access privileges for objects, where each system has advantages and disadvantages for various use cases.¶

Subject:

The subject is the identity (individual or group/role) that intends to perform an action.¶

Action:

The action the subject intends to perform may be as simple as reading or writing a resource, but can be more complex.¶

Object:

Actions are performed on objects , such as a file or network resource.¶

Request Tuple:

A request tuple consists of the subject, action and (optional) object.¶

Privilege:

A privilege encodes whether or not an action is permitted.¶

Authorization Tuple:

An authorization tuple encodes system state, and is thus a tuple of a subject, a privilege and an (optional) object.¶

The act of authorization translates from a request tuple to a Boolean response determining whether a request is permitted. A centralized authorization function provides this answer in real-time. Distributed authorization instead deals in authorization tuples.¶

It may be of interest that and authorization tuple is semantically equivalent to an RDF triple ([RDF]), in that it encodes a specific relationship between a subject and an object. Authorization tuples that consists solely of IRIs [RFC3987] is also syntactically an RDF triple. This implies that authorization tuples can encode arbitrarily complex authorization information by building the knowledge graph resulting from resolving such an RDF triple.¶

1.3.1. Object-Capabilities (OCAP)

Dennis and Van Horn described an approach for securing computations in "multiprogrammed" systems in 1965/66 ([OCAP]). The context in which they operated had little to do with modern distributed systems.¶

However, they recognized the trend of running computing systems complex enough that multiple programmers would contribute to its overall function. This raised a desire for access control to individual sub-functions, which a security kernel within the operating system was to provide.¶

The key differentiator to other systems was that in OCAP, a calling process was to present a "capability", a serialized token to the process being invoked. This capability was intended to encode all relevant information the called process would need to determine whether the caller was permitted to perform such an action.¶

These properties of being serializable and containing all relevant authorization information imply that, conceptually, capabilities are cached results of an authorization query . The called process can then perform access granting without issuing such a query itself, thereby temporally decoupling the two functions.¶

1.3.2. Identity-Capabilities (ICAP)

The OCAP system proved to have a particular weakness, namely that "the right to exercise access carries with it the right to grant access". This is the result the information encoded in an OCAP capability: it contains a reference to the object and action to perform, but does not tie this to any identity.¶

In 1988, Li Gong sought to address this with an Identity-Capability model ([ICAP]). Including an identity in the capability token arrives at the authorization tuple in Section 1.2.2. Furthermore, ICAP introduces the notion of capability use in networked systems. ICAP does this by temporally decoupling the authorization query from access granting.¶

The main criticism levelled against the paper and capability-based approaches in general in the following years was that some functions were missing, such as a check for revocations. Proposals to address this often added centralized functions again, which led to criticism of the distributed approach in general.¶

1.3.3. Pretty Good Privacy

While we previously discussed PGP in terms of authentication in Section 1.2.1.1, a key property of PGP is the introduction of trust signatures ([RFC4880], Section 5.2.3.13).¶

Trust signatures do not merely authenticate a user, they introduce a kind of authorization as well, as they carry specific notions for what the provided public key may be trusted for. The trust signature thus encodes specific kinds of privileges of an authorization tuple , while the public key encodes a subject . The only component missing in the tuple is the object .¶

While the authorization tuple in PGP is incomplete, the system is based on public key cryptography, and can thus be used to securely verify a binding between the tuple elements.¶

1.3.4. JSON Web Tokens (JWT)

JSON Web Tokens ([RFC7519]) provide a standardized way for serializing access tokens. Current uses are in systems with centralized authorization functions such as OAuth ([RFC6749]).¶

However, the fundamental notion of capabilities, that a serializable token carries authorization information, is provided also here. Furthermore, JWT combines this with cryptographic signatures, providing for - in theory - temporal decoupling as previously discussed.¶

It's well worth pointing out that JWT is suitable as a portable, modern capability format - all it requires is to encode all necessary information within its fields.¶

1.3.5. Power of Attorney

The oldest kind of prior work in this field is the concept of Power of Attorney, as exercised throughout much of human history.¶

In a Power of Attorney system, an authority (a king, etc.) grants a token (an official seal, ...) to a subordinate which makes this subordinate recognizable as carrying some of the king's powers and privileges.¶

Modern day Power of Attorney systems abound, and may be formalized as notarized letters granting such and such rights to other people.¶

Capability-based authorization schemes are no different to this kind of system in principle. In both kinds of systems, the token itself encodes the privileges of the bearer.¶

1.4.1. IoT On-boarding

On-boarding IoT devices into an overall system requires authentication and authorization; this may be mutual.¶

In such scenarios, new devices rarely have connectivity before completing on-boarding. It follows that authentication and authorization must work in a fully offline fashion, which in turn requires that authorization tokens provided to the device contain all information required for the authorization step. As described in Section 1.3.1, this translates to a requirement of temporally decoupling access granting from an authorization query.¶

1.4.2. UAV Control Handover

A similar argument applies to control handover of unmanned aerial vehicles (UAV). The concept of Beyond Visual Line of Sight (BVLOS) missions is to send drones into places that are harder or more costly to reach for humans.¶

Control handover refers to transferring operational control for a drone from one ground control station to (GCS) another. Control handover bears similarities to IoT on-boarding in that the drone is on-boarded to a new control system (and the previous system relinquishes control).¶

In general, aviation authorities such as FAA, EASA, etc. expect control handover to occur under ideal circumstances, in which centralized authorization schemes suffice. There is, however, a class of scenarios where connectivity to a central service cannot be guaranteed.¶

2.1.1. Grantor Identifier

A grantor identifier uniquely identifiers the public key of the key pair; this may be identical to a serialized form of the public key itself, or a cryptographic hash over it (fingerprint), or some alternative scheme.¶

What is sufficient is that there MUST exit a mechanism for uniquely mapping the grantor public key to the grantor identifier and vice versa. This mapping permits verification.¶

2.1.2. Grantor Signature

The grantor undersigns a capability by adding a cryptographic signature to it.¶

2.5.1. Grantee Identifier

A grantee identifier is the identifier used as the subject in an authorization tuple.¶

If the grantee is equivalent to an asymmetric key pair, it MUST also be possible to map the grantee identifier to the grantee public key and vice versa. Such a mapping SHOULD be feasible to perform without connectivity in order to maintain the distributed authentication mechanisms achieved through the use of asymmetric cryptography.¶

2.6.1. Object Identifier

The object identifier uniquely identifiers an object. This document places no syntactic restrictions upon the object identifier, other than that there exists a canonical encoding for it. For the purposes of cryptographic signing and verification, the object identifier MUST be treated as equivalent to its canonical encoding.¶

2.9.1. Extensions

Note that each of the fields in an authorization tuple may be treated as a list of zero or more such elements. While a longer discussion of this is out of scope for this document, two notes should be made:¶

1. Implementations must provide clarity what it means to provide a list. Does the capability apply to each element in the list individually, or to some combination? This is highly specific to the semantics of each capability, so cannot be covered here.¶
2. A tuple consisting of a subject and privilege only (zero objects) effectively turns into a statement about the subject, and no longer relates to authorization concerns. However, other aspects of a distributed trust system still apply. This is the approach taken by Pretty Good Privacy.¶

4.1.1. In Scope

Connectivity:

Distributed authorization observes end-to-end principle, by temporally decoupling distinct functions in the authorization process, so that connectivity can be almost arbitrarily unreliable.¶

Reliability:

Capabilities provide reliability by removing the need for real-time reliability.¶

Content agnosticism:

The elements of authorization tuples are only defined in the abstract; as noted in {#sec:authorization}, they can encode arbitrarily complex relationships. Of course, the semantics SHOULD be somewhat focused on authorization.¶

Integrity:

The use of cryptographic signatures in capabilities also provides integrity checking, but no explicit mechanism for distinguishing between integrity failures and authenticity is provided.¶

Authenticity:

Proving authenticity is a core concept of cryptographic capabilities.¶

Pseudonymity:

This document deliberately distinguishes between endowment and secret proving in {#sec:authentication}, precisely because authorization does not need to make use of such information.¶

Censorship resistance:

Temporally decoupling authorization queries from access granting provides one element in a censorship resistant system, as it permits for capabilities to travel out-of-band by means that circumvent potential censorship, such as e.g. via a sneakernet, etc.¶

Outcome Transparency:

This document's main focus is on illustrating the outcomes of distributed authorization schemes.¶

Adaptability:

As this document provides a generalized view on distributed authorization schemes and capabilities, it is highly adaptable in specific implementations.¶

Decentralization:

Decentralization - rather, distribution - is the goal of this document.¶

Open Standards:

Care has been taken to define this specification in reference to other open standards (see the references section).¶

Security:

As this document describes an authorization scheme, security is of great concern. However, guidelines in [BCP72] do not fully apply to an abstract description. See {#sec:security-considerations} for more detail.¶

4.1.2. Out of Scope

Confidentiality:

Confidentiality is out of scope of the general concept of capabilities; capability content is almost by definition public data. However, nothing prevents an implementation from providing confidentiality for the capability elements outside of the signature.¶

Heterogeneity Support:

There is no specific heterogeneity support in distributed authorization schemes.¶

Remedy:

Remedy (new in [I-D.draft-irtf-hrpc-guidelines-16] often stands in stark contrast to anonymity and pseudonymity, both of which are out of scope. Implementations must take care to balance these concerns.¶

Internationalization:

This document focuses on abstract concepts; internationalization is not in scope.¶

Localization

See internationalization; this is not in scope.¶

Privacy:

For privacy protections, implementations must themselves ensure that any information encoded in a capability cannot be abused to resolve otherwise private information.¶

Anonymity:

Anonymity is out of scope for this document. While pseudonymous use is feasible if sufficient care is taken, authorization always ties to an identity, however transient.¶

Accessibility:

Accessibility concerns are out of scope.¶

4.3.1. Confidentiality

Confidentiality concerns are out of scope of this document.¶

4.3.2. Data Integrity

Data integrity is provided as a side effect of requiring a cryptographic signature over capability payloads.¶

4.3.3. Peer Entity Authentication

Peer entity authentication is not, strictly speaking, a concern of this document. However, it should be noted that an agent in the process MUST obviously authenticate a grantee before proceeding to verify capabilities.¶

As noted previously, distributed authorization does not require endowment in this process, however.¶

4.3.4. Non-Repudiation

Non-repudiation is strictly speaking out of scope of this document because key exchange is out of scope. However, key exchange is a necessary precondition for verifying capabilities. Non-repudiation is one of the guarantees that verification provides.¶

4.3.5. Unauthorized Usage

Preventing unauthorized usage is the core concern of this document.¶

4.3.6. Inappropriate Usage

Any scheme that prevents unauthorized use may also be extended to prevent inappropriate use. However, such additions are out of scope.¶

4.3.7. Denial of Service

Denial of service mitigation is out of scope, because this document does not describe a protocol.¶

However, as avoiding a single point of failure (Section 1.2.2.1) is one of the problems that distributed authorization schemes address, it can easily be argued that preventing denial of service is a major concern of this document, and consequently fully addressed here.¶

4.3.8. Replay Attacks

Capabilities can be "replayed" as much as an attacker wants. As they encode a state, such state does not change when it is received multiple times.¶

However, implementations MUST take care not to invite replay attacks when designing their specific validity metadata (Section 2.8). Furthermore, implementations MUST include such metadata in the signature.¶

4.3.9. Message Insertion

Message insertion is of no concern to this document.¶

4.3.10. Message Deletion

Message deletion is of little concern to this document, except insofar as if the transmission of capabilities is disrupted, access granting cannot proceed. Implementations MUST take care to provide safeguards against this as their threat model requires.¶

4.3.11. Message Modification

Message modification is prevented by the cryptographic signatures in capabilities.¶

4.3.12. Man-In-The-Middle

As this document does not provide a protocol specification, this consideration does not apply.¶

4.3.13. Key Usage

This document relies on secure key exchange.¶

4.3.14. Revocation

As ICAP was criticized for introducing a centralized solution for revocatins, (see Section 1.3.2), a modern distributed authorization system must adequately consider these.¶

Fortunately, anything that can encode the granting of a privilege can also encode the removal of said grant, by - essentially - encoding a negative privilege. Doing so provides distributed revocations by the same overall mechanism that distributed authorization is provided. A sequence of grants and revocations for a particular request tuple will map to a sequence of Boolean values, and can so be understood as a bit stream.¶

This introduces a new requirement, namely that verifiers can reconstruct the bit stream in order to understand the latest, most up-to-date state. Unfortunately, this can be hard due to the time-delayed nature of the communications channel.¶

Fortunately, research into conflict-free replicated data types has yielded several methods for ordering also partially received streams, which can be applied here by providing appropriate validity metadata. This yields eventually consistent states in a distributed authorization system, which in many cases may be sufficient.¶

It is not the purpose of this document to prescribe any particular method for ordering grants and revocations into a consistent stream, nor whether revocations are used at all. However, implemtations MUST take care to consider this aspect.¶

4.4.1. Surveillance

The surveillance concerns outlined in [RFC6973] specifically relate to network protocols; this document does not describe such a protocol.¶

As noted previously, pseudonymous use is well supported by this kind of scheme, while fully anonymous use is not. If appropriate confidentiality is provided by implementations, distributed authorization schemes can be considered fairly resistant to surveillance.¶

That being said, systems SHOULD still use transport encryption in order to further mitigate against surveillance.¶

4.4.2. Stored Data Compromise

Stored data concerns are largely identical to surveillance concerns in the context of distributed authorization.¶

4.4.3. Intrusion

Authorization schemes in general aim to protect against intrusion.¶

4.4.4. Misattribution

Misattribution in [RFC6973] refers to misattribution to individuals, which relates to endowment. This document considers endowment out of scope.¶

4.4.5. Correlation

Distributed authorization tokens cannot protect against correlation, unless confidentiality concerns are addressed. This is, however, an implementation concern.¶

4.4.6. Identification

Similar arguments can be made for identification concerns. Distributed authorization is fundamentally concerned with identifying elements in a system, but if confidentiality is provided, identification is not possible.¶

4.4.7. Secondary Use

Secondary use concerns are not in scope of this document.¶

4.4.8. Disclosure

Disclosure concerns are effectively identical to confidentiality concerns in that capabilities may leak identifiers, which may be pseudonymous.¶

4.4.9. Exclusion

Exclusion is a network protocol consideration, and does not apply here.¶