CAProck Distributed Authorization Scheme

CAProck The basic functionality of CAProck is to provide a cryptographic signature over a number of claims with the intent that it can be verified at a later date, when actions based on those claims are to be performed. This temporal decouping between the time of signature and time of verification represents both the greatest strength and weakness of capability based schemes, as it raises the question for what time period these claims are to be considered valid. Rare is the case where a privilege should be granted to a subject for perpetuity, but choose the time period too small, and a claim may not be usable. Furthermore, this temporal decoupling introduces the issue of what should happen when a privilege is granted and the associated capability transmitted, but subsequently trust in the subject is lost. This loss of trust should ideally be known to the party that is supposed to execute an action on behalf of the subject. The typical approach is to verify via some real-time blocklist query. However, the design goals for CAProck prohibit such an approach. Note, however, that systems using CAProck may still employ this method. The requirement is included to drive the design to broader applicability also in situations where real-time queries are infeasible. To these ends, CAProck defines additional metadata beyond that described in , namely: A validity timespan (scope) An expiry policy Grant as well as revocation markers Furthermore, this document defines a conflict resolution scheme for resolving multiple capabilities.

Identifiers Generally speaking, a capability based distributed authorization scheme is agnostic to the specific contents of identifiers used for the capability issuer, subject and object. However, such a scheme requires that issuer and subject identifiers can be uniquely mapped to public keys. The issuer public key is required to verify the capability signature. At the same time, accepting and executing an action requires that the capability subject is authenticated, which typically involves use of its public key as well. The space saving concerns suggest that full public keys should only be used in authentication, while shorter identifiers derived from these keys are sufficient for use in capabilities. To that end, CAProck defines two kinds of identifiers for issuers and subjects:

SHA-3 Identifiers:: Identifiers may be SHA-3 hashes () over DER encoded () public keys.
Raw Identifiers:: If the key scheme supports it, identifiers may also be raw public keys. This identifier MUST NOT be chosen if it is longer than the longest identifier generated under the SHA-3 scheme for the same key, but SHOULD be used if the result is shorter than the SHA-3 scheme produces.

Algorithm Identifier Preferred Scheme Reference PureEdDSA for curve25519 ed25519 raw , PureEdDSA for curve448 ed448 raw , DSA dsa SHA-3 RSA rsa SHA-3 ECDSA ecdsa SHA-3

Object Identifiers Unlike with issuer and subject identifiers, object identifiers do not require mapping to public keys, though it may be in the application's interest to also define object identifiers in this fashion. CAProck places only a single constraint on object identifiers: that they have the same length as issuer and subject identifiers. More specifically, object identifers MUST be between 28 and 64 octets in length, and SHOULD be one of the sizes yielded by either of the issuer and subject identifier schemes. In practice, this constraint suggests to use a default SHA-3 digest size for identifiers of any kind, unless the use of EdDSA allows shorter issuer or subject identifiers.

Group Identifiers As CAProck does not define much about identifiers, it is also agnostic as to whether any identifier refers to an individual or group. Such definitions are part of the application concern. Note, however, that as subject and issuer identifiers must be mappable to a public key, the use of groups with a CAProck based scheme essentially becomes a public key management problem.

Predicates Predicate formats are outside of the scope of this document. This is to permit maximum flexibility for the application concern. However, arbitrary length predicates are in conflict with the space saving requirements, while short predicates may limit the application in how to apply them. CAProck takes a compromise approach here: predicates MUST NOT be larger than 2^16 = 65,536 octets. This limit is far too generous for 0-RTT handshakes, so predicates SHOULD be limited to significantly shorter lengths, such that an entire capability fits comfortably into an IP packet with authentication information.

Claims CAProck's capabilities require that one or more claims are provided to create them, i.e. tuples of subject identifier and predicate, and an optional object identifier. Note that a claim that includes an object identifier has a signficantly different semantic from one that does not. Authorization tuples with an object identifier assert that the predicate describes the relationship between the given subject and object. Authorization tuples without an object assert that the predicate describes an aspect of the subject itself.

Wildcards Furthermore, in CAProck each claim component may be a wildcard. As predicate formats are outside of this document's scope, predicates may also contain a wildcard, but the semantics of that must be defined with the predicate scheme to use. Wildcards make more general statements than a claim typically does, and due to this genericity, implementations MUST take great care with their use. Broadly speaking: A wildcard subject states that the predicate applies to an object for any subject. Such a statement may imply that authenticating a subject is no longer of interest, i.e. grant public privileges. A wildcard predicate states that all relationships between the given subject and object are affected. This may e.g. be used to revoke all privileges from a subject. A wildcard object is not the same as omitting an object altogether; instead, it states that the subject and predicate combination applies to all objects. Note, though, that the issuer does not have authority over all possible objects, so this is naturally limited to only those objects the issuer has authority over. Combinations of wildcard fields in a single claim may have sense within the application's privilege scheme, but can also be increasingly confusing, and thus prone to creating security flaws. For that reason, public privilege schemes MUST document the semantics for every combination of wildcard elements they support, and SHOULD limit such combinations to a minimum required amount. Other combinations of wildcards SHOULD be rejected as invalid.

Metadata The most basic data encoded into a CAProck token is mostly described in and consists of the following fields: An issuer identifier (also see ). One or more claims (), each consisting of: A subject identifier (). A predicate (). An optional object identifier (). A validity range (). An expiry policy (). A signature by the issuer over a serialized version of the previous fields (). Please note that the specific encoding or serialization format for the data affected by the signature is not defined in this document; this is because alternative encodings are possible. For this reason, documents specifying such encodings MUST be clear on how this payload data is serialized, and how the signature is added to the token.

Validity Range/Temporal Scope The validty range or temporal scope for a token is defined by a tuple of timestamps, much as in certificates. In these certificates, the validity range is defined by rather awkwardly named "not before" and "not after" fields, CAProck prefers the "from" and "to" fields. The "from" timestamp MUST be provided, while the "to" timestamp is optional. Tokens without the "to" timestamp are valid in perpetuity, after the "from" time has been reached. The range from "from" to "to" is inclusive, i.e. the token is valid not before the "from" date, but both at and after the "from" timestamp. The same logic applies to the "to" timestamp. The wire encoding specifies how to represent these fields in the token. However, implementations MUST accept the subset of ISO-8601 time stamp formats as defined in as input to either field, in order to set consistent expectations with the user base.

Expiry Policy Distributed authorization in general and CAProck in particular are designed for scenarios in which connectivity is not always given. This can mean that having a access to a synchronized clock is impossible at the time of validation, which would imply that evaluating the valdity range timestamps above is impossible. To mitigate this, tokens MAY contain an optional expiry policy field. This field can take the symbolic values of issuer and local. If omitted, the value MUST be assumed to be issuer. The semantics of each value are as follows:

Issuer:: If the expiry policy is set to issuer, then the valdity scope of the issuer MUST be respected. An unsynchronize clock may lead to failures, but that is the issuer's wish.
Local:: The verifier is permitted to apply local policies for failures. That is, a CAProck system must now query the application whether to accept or reject a token.

Leaving the possibility to defer to the applications permits resolving clock conflicts by means outside the ability of CAProck to influence. One such method might be to simply ask the application user. As this behaviour is a potential security risk, implementations MAY reject tokens with local expiry policy outright.

Signature Asymmetric signatures are made over hashes of content; the hash algorithm to use depends on the key type used for signing. The EdDSA algorithm defines what signature hash function to use in . The DSA algorithm requires the selection of a hashing algorithm. Implementations MUST use one of the SHA-2 or SHA-3 family of hash functions (see ). The ECDSA algorithm likewise requires the selection of a hashing algorithm. We also use SHA-2 or SHA-3 here. For ECDSA, specifies that the hash length shall be no less than the ECDSA key bit length. The RSA algorithm also requires specification of a signature hash. Implementations MUST select one of the SHA-3 family of hash functions (see ). CAProck does not specify which digest sizes to use for SHA-2/SHA-3. However, wire encodings may restrict the choices here further.

Grants and Revocations Capabilities in CAProck either grant privileges or revoke them; these are called grants or grant tokens and revocations or revocation tokens, respectively. As each token contains one or more claims, the implication is that each token either grants all of the claimed privilege or revokes all. Other metadata (see ) applies equally to the entire set of claims. But individual tokens may contain differing metadata. If the metadata differs, this can create a set a tokens that make conflicting claims. Consider the following scenario: Grant G1 contains claims C1 and C2 for a period of [S1,E1] defined by a start S1 and end E1 timestamp. Revocation R1 revokes claim C1 for a new, shorter time period [S2,E2] where S2 > S1 and E2 < E1. In this simple scenario, whether C1 is granted or revoked already depends on whether one looks at time period [S1,S2), [S1,E2] or (E2,E1] - or some period before S1 or after E1. If the two tokens are examined in the order listed, that is all there is to it. However, what should happen if the tokens arrive in reverse order? For this, we need to define a conflict resolution algorithm (). Things only gain in complexity when more claims are processed, and revocations are themselves further "revoked" by issuing another grant for a different time period.

Conflict Resolution While privileges encoded in predicates are arbitrarily complex, whether a token represents a grant or revocation is essentially a binary value. It is therefore possible to view a set of grants and revocatons for a given claim as a bit stream, in which only the latest bit has any significance. The question then is how to bring order into this token set. To this end, CAProck introduces a simple counter. This is represented by an unsigned 64 bit integer value. The only requirement on the counter is that tokens issued earlier have smaller values than tokens issued at a later date. The counter value is scoped to the issuer that issues the token; therefore, no synchronization of counters between issuers is required. In order to query the validity of a claim, then, a time point must be provided, and the following algorithm MUST be used: Start with the state that the claim is invalid. Assume a token store containing only tokens with valid cryptographic signatures. From the token store, pick all tokens pertaining to the claim being queried. Note that this may include claims containing wildcards. Order the picked tokens by the counter value from lowest value to highest value, essentially ordering by age of the token. Process each token in order, and compare it's validity range to the given time point: Discard tokens for which the time point does not lie in the validity range. If the token expiry policy is local, consult the local policy whether to discard it. See section for details. If the time point lies in the validity range, set the current state to valid for grants, and invalid for revocations. When all tokens are processed, the current state is the final state of processing. If that state is invalid, reject the claim. For valid end states, process the claim by application specified rules for the predicate. The information contained here may still make the claim invalid, but this is beyond the scope of CAProck. Note that CAProck explicitly does not introduce timestamps for ordering tokens. This is due to several considerations. First, using a counter permits an implementation to update the value more sparsely. Between issuing two tokens, a lot of time may pass, which would increment a timestamp by a significant number. By contrast, a counter may use the value space more efficiently by being incremented only by one each time. Second, the extra information a timestamp imparts is not necessary for deconflicting tokens. However, it is possible to infer information from it that may best be hidden, namely when the token was issued. This permits for analysis on the time periods an issuer was active, and may imply further communications between the issuer and subject. Finally, using timestamps introduces a hard dependency on a valid understanding of the current time for validation. In early boot processes or handshakes for reading a clock, such a dependency cannot necessarily be fulfilled.

State Compression The above algorithm makes it possible to compress state. First, any expired tokens can be discarded, as they are no longer consulted at all. They have the same semantics as a revocation for the claim. Furthermore, subsequent tokens that completely overrule a prior token make it unnecessary to keep storing the prior token. Implementations are not required to perform any state compression, and MAY find additional means to compress state. However, such compressions MUST NOT affect the results as would be achieved by the above algorithm.

Confidentiality All of the data fields described here are required for a party validating a capability or a set thereof; therefore, CAProck cannot provide confidentiality for this data itself. However, individual permissions may well be in need of protection. If any subject is issued a privilege, this should not be visibly to any party other than the issuer, the verifier, and most likely the subject itself. Implementations SHOULD therefore transport capability tokens in such a way that confidentiality is preserved. This leaves room for potentially replacing the cryptographic signature with an authenticated encryption method. Such a scheme, however, should be considered an extension to CAProck and defined in a separate document.

Delegation Delegation of authority comes in two distinct flavors in a distributed authorization system. CAProck addreses the set of scenarios in which a subject wishes to perform an action (on an object), and presents its authorization to do so. The other set of scenarios involves delegating the authority to grant priveleges. This is not explicitly addressed in CAProck, though the following may provide some guidance. First, a predicate that states a subject may itself create subgrants is likely more complex than predicates permitting other actions. At minimum, such a predicate should provide limits on which subgrants may be issued; such limits may include a list of permitted predicates, different time slots for the subgranted privilege, and a limit on whether grants or revocations or both may be issued. Effectively, such a predicate might contain the same information as a CAProck token, or even more. Second, a subgrant may also be issued to grant further subgrants. If this is the case, there is likely need for bounding such subsubgrants to a certain depth, otherwise it is likely that subjects receive grants that the original issuer never intended to issue grants to.