The default configuration of the IdP and the OIDC plugins use the same DataSealer component described in the Client-side Session Storage use case to encrypt and integrity protect a few different kinds of opaque, time-limited data provided to third parties such that it is statelessly recoverable in a secure fashion.
The functional aspects share enough in common to be grouped together as a single use case and include:
Transient SAML Name Identifier values
OAuth authorization codes as defined by the “code” response type
Custom claims embedded in JWT-formatted OAuth tokens of various sorts
Opaque OAuth tokens of various sorts
To differing degrees, these use cases share a common set of requirements:
The data must be recoverable, confidential, and integrity protected (tamper-proof)
The data must contain a verifiable expiration
The data must be usable across different nodes of a cluster without shared state other than a shared key
How does the use-case relate to the software’s intended purpose?
All of the uses amount to a means of sharing data with a third party that may contain information about a subject (possibly simply an identity, but sometimes additional data) that is meant to be used in a subsequent “API call” of sorts such that the API client’s use must be verified as legitimate and time-limited. Sometimes such tokens are “bearer” tokens but may also contain the identity of the token wielder authenticated via other means or contain other sealed information limiting/scoping their use.
For example, SAML transient identifiers would contain the identity of an SP authorized to return them in a query. OAuth access/refresh tokens would contain the OAuth client identity, and might optionally support more advanced usage requirements.
In each case, the data is considered opaque to the third party to whom it is given, must be tamper-proof, and is presumed in some cases to need confidentiality for privacy reasons.
Does the use case involve two or more independent software implementers being able to produce and consume ciphertext for the other or is it self-contained and lacking a requirement for interoperability?
While the data in each case is given to a third party, it never intended to be parsed or understood by that party, rather simply returned in the context of some other documented interaction. The specific format and mechanics used to create and protect the data are undocumented and left as a detail of the implementation.
Are there standards defining/constraining which algorithms are usable for the use case?
No. 1
Is the output ephemeral or durable and for what expected lifetime?
The data is durable for a lifetime that varies by use case but is usually configurable and measured in hours (or less). In principle it could have an extended lifetime, and the specific key used at a particular time to create the data would need to remain accessible throughout that lifetime.
Does the ciphertext provide sufficient information about the algorithm(s) used to allow for it to be consumed arbitrarily later?
Not presently, but since the format is internal to the software, it could in principle evolve to include this if it were needed.
What are the algorithms supported for this use case in current versions of the platform?
Currently, only AES-GCM with variable key size (128, 192, 256) depending on the configured key.
Does a process exist for rotating/changing the key(s) involved in the use case? If this is a standardized process, please reference it, and if not, please describe it. If there is an existing recommended policy regarding rotation frequency, please note that.
A command line tool and Java class are provided to maintain a set of files that track a default key and a variable size history of older keys, but it is a custom implementation. Is is assumed the files can be copied or accessed from a shared fle system by all servers in a cluster. A pluggable interface is used to allow alternative implementations. It is suggested that the key be changed daily or so depending on load, but in principle this is not strictly necessary as a random IV is used during each operation to prevent known ciphertext attacks.
Does a process exist for revoking/expiring the key(s) involved in the use case? If this is a standardized process, please reference it, and if not, please describe it.
Revoking or expiring a key can be accomplished by simply removing it from the source of keys used by the implementation at the cost of losing the ability to support the tokens or other data encrypted by that particular key.
Use of such tokens or data would be deemed invalid as if the client attempted to forge or tamper with it, though the specific warning generated would only reference the fact that an absent key had been used (there is no current provision for noting that a specific key had been formally revoked to produce a different log message).
What degree of cryptographic agility exists in the particular use case?
Because the consumption of the data is purely internal to the implementation, it is possible to update the software unilaterally to alter or extend the set of supported algorithms. Changes to the encryption format would likely be required to account for the possibility of alternate algorithms and/or specifying them in the configuration, but this would be possible without coordination with third parties or major disruption to the software development lifecycle.
However, changes to the format or algorithm set would create implications during rolling upgrades (if a node on one version was unable to create or consume data for or from another version) and this would have to be documented for specific releases. In practice, tokens/etc. would probably be invalidated in such cases, though this could result in disruptions to varying, though limited, degrees.
In principle any authenticated encryption algorithm supported by the JCA could be used without major disruption or difficulty. Using unauthenticated encryption algorithms would require a reimplementation using a layered design to include a MAC, and would introduce additional risk from implementation mistakes. At present, AES-GCM appears to be the only authenticated encryption algorithm required to be implemented by the JCA.
What is the impact of a compromise on the software’s purpose or a deployer’s data or infrastructure in functional (rather than assumed risk) terms?
Very significant/catastrophic in the case of a compromise to the integrity property. Compromise of the confidentiality property would result in a privacy compromise of subjective severity depending on the data involved and local policies or regulations.
A compromise of integrity would result in serious breaches varying by use case, such as:
the ability to forge OpenID logins and data about a subject to a particular relying party
the ability to force access or refresh tokens allowing access to resources relying on the IdP as an OAuth authorization service
the ability to query for data that might not otherwise be intended to be accessible to the caller
A key compromise would be easy to recover from (simply changing the key and removing the compromised one suffices) but a break in the AES-GCM algorithm or a vulnerability in the implementation would require a software update to the IdP (and an alternative algorithm or hybrid approach would need to be used, see also the previous answer).
Are there assumptions about how a deployer implements or uses the feature(s) that impact the answers above?
Some of the discussion is based on the default implementation of the key “strategy” supplied with the software that handles accessing keys. In principle, an alternative implementation built by a third party could impact some of the answers.