| Internet-Draft | Stateless OSCORE | October 2024 |
| Amsüss | Expires 19 April 2025 | [Page] |
OSCORE (Object Security for Constrained Restful Environemnts, [RFC8613]) provides secure communication between peers that share symmetric key material. This document describes how a server can operate with an arbitrarily large number of peers, and how key material for this kind of operation can be provisioned to the client.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-amsuess-core-stateless-oscore/.¶
Discussion of this document takes place on the CoRE Working Group mailing list (mailto:core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Subscribe at https://www.ietf.org/mailman/listinfo/core/.¶
Source for this draft and an issue tracker can be found at https://codeberg.org/chrysn/stateless-oscore.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[ See also abstract. ]¶
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).¶
The Network Time Security mechanism ([RFC8915]) 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 [I-D.ietf-core-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 Section 1.3.2)) 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.¶
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 [RFC7252], 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.¶
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 Section 3.1 of [I-D.amsuess-lwig-oscore-00].¶
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 [I-D.ietf-core-oscore-key-update].¶
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.¶
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 [RFC5869] 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 Section 1.4.¶
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.¶
The previously standardized methods of establishing an OSCORE context, EDHOC [RFC9528] and the ACE-OSCORE profile [RFC9203] 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.¶
IANA is requested to register into the CoAP Option Numbers Registry in the CoRE Parameters group:¶
Number: CPA220.¶
The RFC Editor is requested to replace “CPA220” with the assigned number at registration time, and remove this paragraph. The number 220 is suggested: It has the right properties, is free, and is the largest free number in the 1-byte extended space. This leaves smaller numbers of the same space free for more new numbers where delta encoding with other typical options would allow the new number to use a shorter serialization.¶
Name: OSCORE-Context-Setup¶
Reference: Section 1.4 of this document¶
Section 8.2 of [RFC8915] on Cookie Encryption Key Compromise applies to the Internal Key.¶
Failure to follow the requirement of using an own sequence number would result in nonce reuse and thus possibly compromise of that security context’s key material.¶
In OSCORE, it is crucial to the system’s security that every sender sequence number is used only by one server. This deserves special mention here because it is not trivial to uphold in a distributed system.¶
Since draft-amsuess-core-stateless-oscore-00:¶
Thanks to Tamme Dittrich for setting me on the track to this with his presentation of time synchronization on the RIOT Summit 2024.¶