Stateless OSCORE
draft-amsuess-core-stateless-oscore-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Christian Amsüss | ||
| Last updated | 2024-10-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-amsuess-core-stateless-oscore-01
core C. Amsüss
Internet-Draft 16 October 2024
Intended status: Experimental
Expires: 19 April 2025
Stateless OSCORE
draft-amsuess-core-stateless-oscore-01
Abstract
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.
About This Document
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.
Status of This Memo
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."
Amsüss Expires 19 April 2025 [Page 1]
Internet-Draft Stateless OSCORE October 2024
This Internet-Draft will expire on 19 April 2025.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Motivating background . . . . . . . . . . . . . . . . . . 3
1.3. Operating a stateless OSCORE server . . . . . . . . . . . 3
1.3.1. Prerequisites . . . . . . . . . . . . . . . . . . . . 3
1.3.2. Implementation requirements . . . . . . . . . . . . . 4
1.3.3. Suggested implementation . . . . . . . . . . . . . . 5
1.4. Distributing key material . . . . . . . . . . . . . . . . 6
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Normative References . . . . . . . . . . . . . . . . . . 8
4.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[ See also abstract. ]
1.1. 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).
Amsüss Expires 19 April 2025 [Page 2]
Internet-Draft Stateless OSCORE October 2024
1.2. Motivating background
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.
1.3. Operating a stateless OSCORE server
1.3.1. 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 [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.
Amsüss Expires 19 April 2025 [Page 3]
Internet-Draft Stateless OSCORE October 2024
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.
1.3.2. 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 Section 3.1 of
[I-D.amsuess-lwig-oscore-00].
1.3.2.1. 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
[I-D.ietf-core-oscore-key-update].
Amsüss Expires 19 April 2025 [Page 4]
Internet-Draft Stateless OSCORE October 2024
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.
1.3.3. 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 [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.
Amsüss Expires 19 April 2025 [Page 5]
Internet-Draft Stateless OSCORE October 2024
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.
1.4. Distributing key material
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.
Amsüss Expires 19 April 2025 [Page 6]
Internet-Draft Stateless OSCORE October 2024
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.
2. IANA Considerations
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
3. Security Considerations
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.
Amsüss Expires 19 April 2025 [Page 7]
Internet-Draft Stateless OSCORE October 2024
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.
4. References
4.1. Normative References
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/rfc/rfc8613>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/rfc/rfc8915>.
4.2. Informative References
[I-D.amsuess-lwig-oscore-00]
Amsüss, C., "OSCORE Implementation Guidance", Work in
Progress, Internet-Draft, draft-amsuess-lwig-oscore-00, 29
April 2020, <https://datatracker.ietf.org/doc/html/draft-
amsuess-lwig-oscore-00>.
[I-D.ietf-core-dns-over-coap]
Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C.,
and M. Wählisch, "DNS over CoAP (DoC)", Work in Progress,
Internet-Draft, draft-ietf-core-dns-over-coap-08, 26
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-dns-over-coap-08>.
[I-D.ietf-core-oscore-key-update]
Höglund, R. and M. Tiloca, "Key Update for OSCORE
(KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
core-oscore-key-update-08, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
oscore-key-update-08>.
Amsüss Expires 19 April 2025 [Page 8]
Internet-Draft Stateless OSCORE October 2024
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"The Object Security for Constrained RESTful Environments
(OSCORE) Profile of the Authentication and Authorization
for Constrained Environments (ACE) Framework", RFC 9203,
DOI 10.17487/RFC9203, August 2022,
<https://www.rfc-editor.org/rfc/rfc9203>.
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/rfc/rfc9528>.
Appendix A. Change log
Since draft-amsuess-core-stateless-oscore-00:
* Added use case of distributed systems.
* Pointed out limitations to differentiated client authorizations.
Acknowledgments
Thanks to Tamme Dittrich for setting me on the track to this with his
presentation of time synchronization on the RIOT Summit 2024.
Author's Address
Christian Amsüss
Austria
Email: christian@amsuess.com
Amsüss Expires 19 April 2025 [Page 9]