Stateless OSCORE

Introduction [ See also abstract. ]

Terminology For the purpose of this document, a server is stateless if a new client can establish an OSCORE context with the server, and the server’s storage requirements are only porportional to the the logarithm of the number of existing clients. (Practically, the storage requirements are not increased at all per new client, but the required counter of established clients may increase to the point of requiring a longer identifier and thus counter).

Motivating background The Network Time Security mechanism () describes cookies that enable a client to request time from a server in a secure way while the server remains stateless. Applied to OSCORE, the same mechanism may protect any CoAP based time retrievals as well as other CoAP based information discovery where a server acting on a replayed request is not harmful, for example DNS over CoAP . Storing OSCORE contexts is not very costly in terms of memory: When deriving from the master key without a master salt, then a minimal a security context (containing a recipient ID, a 4-byte recipient ID, but no sender sequence number (could be global), no sender ID (it can be fixed 0-byte as suitable for servers without role reversal), and no replay window (see )) uses 20 bytes. Storing 4 billion contexts (using up all identifiers) “just” takes 80 Gigabytes, which is managable for a server in the mid-2020s and may well fit in its RAM. However, when used with clients that are unilaterally authenticated, that limit can be exceeded by attackers, creating a denial-of-service problem. Stateless OSCORE can also be used remove the need for synchronization in a distributed server: When a CoAP server is distributed over a network (e.g. using an anycast address), it removes the need to synchronize information about every single established client context.

Operating a stateless OSCORE server

Prerequisites An OSCORE server may operate in a stateless way under a set of requirements.

The server does not perform role reversal with its clients.
All resources accessible through that security context are safe in the sense of , meaning they do not take any other action on the resource than retrieval, i.e., they are only GET and FETCH requests. A server MAY also use support methods that are not defined to be safe, as long as the allowed operations take no actions other than retrieval or the application is otherwise robust against replays sent in any order.

That the server may establish OSCORE contexts that are not stateless; the constraints above do not apply to those contexts. The server may tell those contexts apart from a prefix to the KID, the KID context, or by using different lengths of KIDs / KID contexts for the stateful contexts.

Implementation requirements As a stateless OSCORE server can not store a OSCORE context per peer, it needs to re-derive the security context from data provided by the client as part of the request. It also needs to encode the scope of the client’s authorization in there; that information needs to be verified. That information can be encoded in the KID or in the KID context. As the key material is re-derived, the replay window is in an uninitialized state. Consequently, the server can not decide whether a request is a replay. Therefore, it MUST NOT use the sender’s nonce for the response, and MUST instead use an own sequence number. As the sender sequence number for that context is not stored, it needs to use some global counter for sender sequence numbers. Some justification for why potentially replayed requests can safely be responded to can be found in .

Distributed implementation Operating in stateless OSCORE mode enables running a server distributed over multiple physical systems without the need to distribute key material per client. Instead, servers MUST take measures to synchronize their sender sequence numbers such that under no circumstances, a sender sequence number can be used in two different responses. One way of doing this is to use the lowest N bits of the sequence number field to indicate which of the up to 2^N servers sent the response, and count in the higher fields. As this mechanisms negatively affects the total number of messages that can be sent with a key (which, as per the previous section, is a global limit rather than a per-client limit), alternatives are being investigated: Potential options are sending a sender ID in the response or using the not-capable form of KUDOS . Users of such a server can transparently switch between different physical servers. Caveats are that switching is not possible during an EDHOC exchange (unless the EDHOC servers support recovering EDHOC state in the distributed server), and that clients that perform replay window checks on responses will fail when switching from a busy server to a less busy server.

Suggested implementation A stateless server may use the following pattern to re-derive its keys: The server partitions its recipient IDs into two fields, an Internal Key ID (IKI) and an Internal Key Counter (IKC). Their total length limits the number of clients an OSCORE context is active with at any time; the separation allows the server to roll over its internal keys and notify clients whose state may get lost. The IKC can be incremented but can not overflow; instead, a new internal key with a new IKI needs to be created. When the IKI number space is exhausted, a new internal key may replace an old key (with the IKI wrapping in modulo arithmetic), and clients using the replaced key lose access to the server through this mechanism. A typical size of the IKI is 1 byte, while the IKC is sized 4 bytes. This allows serving 2^40 or roughly 1 trillion clients, and can be expanded to a total of 7 bytes (10^16 clients) within the default algorithm’s KID. If there are differentiated scopes for a client’s authorization on a server, that information can be appended to the KID if it is short (for example, with the default algorithm, 1 byte IKI and 4 byte IKC leave 2 byte for the authorization), or in the KID Context. Alternatively, different IKIs can be used for different authorizations if the set of possible authorization values is very small. For every IKI, the server maintains an internal key that is exclusively used as input material for OSCORE master keys. The master secret of the OSCORE context corresponding to a key ID is derived by applying an extraction function such as HKDF to the key and the IKC. The other parameters of the OSCORE context are pre-agreed. When a new client is provisioned, the KID (consisting of IKI and IKC) and the master secret are sent to the client through a secure channel. From then on, the client can use that KID to send safe requests to the server, and the server can reconstruct the security context from the IKI and IKC. The IKI and IKC are not protected: The server can be made to derive the OSCORE context for any IKI/IKC combination by an attacker. They are only verified when the derived key material successfully decrypts the request. The authentication is likewise verified by being part of the key derivation in the id or id_context field of the info array. All information is thus verified at the time the request’s plaintext becomes available. When a client sends a request from a IKI that may be reused with a new key in the foreseeable future (possibly taking into account some estimate of the request intervals of clients), the server provisions the client with a new key through . There is no requirement in this specification to use this particular implementation. For example, a server may also use information sent in the KID Context, and may store the encrypted key material in the KID context instead of re-deriving it. However, there is no known advantage to that.

Distributing key material The previously standardized methods of establishing an OSCORE context, EDHOC and the ACE-OSCORE profile create key material by mutual agreement -- but for stateless servers, transfer from the server is necessary. Stateless contexts can be set up from non-stateless contexts: When a client sends a request to a server, the server can tell the client to switch to a stateless context using the OSCORE-Context-Setup option. That option can be sent along with a successful response when there is room in the message, or with an unsuccessful 4.01 Unauthorized response (in which case the content of the OSCORE-Context-Setup indicate a context that is authorized). The OSCORE-Context-Setup option is Elective, Safe-to-Forward and NoCacheKey. It is repeatable, and only sent in response messages. The option number is CPA220. Future specifications may describe their semantics of repeated options or their presence in a request; recipients unaware of those semantics ignore them in requests, and ignore all but the first in the response. The content of the option is [ yet to be specified, but will be some cnf/osc representation of the master secret and the server’s recipient ID ]. The KID context, the client’s recipient ID and the master salt are absent (KID context) or the empty byte string unless specified in the option. The defaults for OSCORE version, HKDF and algorithm are those of the encapsulating OSCORE context (if there is one -- this could also be established through CoAP over (D)TLS), otherwise OSCORE’s defaults apply. A client receiving this option SHOULD NOT continue using the security session through which that option was received any more for requests that are safe. Instead, it SHOULD establish an OSCORE context with the provided details for further requests. The client MAY rely on the server not to send requests (and therefore does not need to process requests to the server-dictated / empty recipient ID), and MAY forego the creation of keeping a replay window if it does not intend to send requests with multiple responses. A client MUST treat the KID context and its Sender ID as opaque values.