OSCORE Implementation Guidance

2.1.1. Plain ACE-OSCORE

A client tries to access a resource over unprotected CoAP, but the server requires credentials (and thus a secure connection).¶

On the initial unprotected request, the server responds 4.01 Unauthorized, and sends the client off to the AS with information from the payload.¶

The client, which needs to have a pre-established association with the AS (or establishes one using yet unspecified mechanisms on the fly), obtains a token from it, posts it over the original unprotected CoAP transport to the server, and from then on has an OSCORE context with the server, over which it can request the resource successfully.¶

This is illustrated well in [I-D.ietf-ace-oscore-profile] Figure 1.¶

This combination has the advantage of not requiring any asymmetric cryptography, but has the original request data unprotected, and the AS can decrypt communication between C and RS if it intercepts their first exchanged messages.¶

2.1.2. ACE with opportunistic LAKE

A client that tries to access a resource but does not want to reveal the request details to passive eavesdroppers can run an EDHOC with the origin server. Nothing else being preconfigured, it runs it on a raw public key, and accepts any credentials from the server. (If a set of root certificates of a public key infrastructure (PKI) is set, it could require a certificate chain to the root certificates).¶

Inside that opportunistically encrypted channel, the client sends a first request to the resource. If the server, as in the ACE-OSCORE example, requires authorization, it can still reject the request and send the client off to the AS with the same response.¶

The client obtains a token from the AS as before, but does not need to generate a new OSCORE context from it (and thus does not use the OSCORE profile for ACE). Instead, it can post the token to the server in the existing EDHOC-created OSCORE context, and thus upgrades the authorization set of that context.¶

This combination has the advantage of not sending any actual request unprotected, but does not ensure to the client that the server has any association with the AS.¶

Alternatively, it can use ACE-OSCORE when obtaining the token and when posting it to the RS over the EDHOC-created OSCORE context to obtain a new OSCORE context.¶

This combination has similar properties to the plain ACE-OSCORE, at the cost of an asymmetric cryptography step, but protecting the original request from passive eavesdroppers.¶

3.1.1. Background

[RFC8613] Section 7.4 says that the server "SHALL stop processing the message" if that fails, [ and I'm in quite a pickle here because I'd like to tell implementers that they can partially ignore that ].¶

In OSCORE, replay protection serves two distinct purposes:¶

• To ensure that only one response is sent with no Partial IV present to any given request Partial IV on a context - i.e., to curb nonce reuse.¶
• To ensure that any action authorized by OSCORE protection on the request is only executed once.¶

For the first purpose, that mandate is absolute: processing any request a second time and responding with an absent Partial IV is a severe security violation. It does not apply, however, if the server chooses to encode an own Partial IV in the response in step 3 of RFC8613 Section 8.3.¶

The relevance of the second purpose depends on the request and the implememtation of the resource backing it. If the request is safe (in the sense of [RFC7231] Section 4.2.1, i.e. it is a GET or FETCH), or at least idempotent (i.e. PUT, DELETE or iPATCH), processing a replay of it has no side effect on the server, and the only thing an attacking replaying party could learn from another response is the current content's length.¶

[ TBD: Talk about how this interacts with freshness. ]¶

3.1.2. Optimization

Combined, these open some space for legitimate processing of replays. Opening up to such processing is beneficial to the server, as it allows a common optimization to happen even on OSCORE messages: [RFC7252] Section 4.5 allows relaxation on message deduplication for idempotent requests, to the point where some implementations of CoAP do not perform message deduplication at all and demand of their applications to only implement idempotent behavior.¶

On platforms that perform selective optimizations, these optimizations can free up memory otherwised used for deduplication and retransmission, provided the operation's idempotency is communicated to the OSCORE and CoAP implementation (which would, in general, not be allowed to enact that optimization for the POST requests OSCORE requests appear as).¶

On platforms that do not perform deduplication at all, this enables the implementation of OSCORE in the first place. (Otherwise, any lost response message results in an otherwise unactionable 4.01 Unauthorized error).¶

Intermediaries (proxies) have no justification for treating the POST requests they see most OSCORE request as as idempotent; however [ and this can not really be called "moving on the fringe of the specification" because it's clearly exceeding it ], clients of a very constrained proxy (which might not even be able to forward non-idempotent requests at all) might still appreciate a presumed-idempotent forwarding of OSCORE messages over a 5.05 Proxying Not Supported.¶

3.1.3. Implementation

Ensuring that only one response without a Partial IV is ever sent to a given request is of utmost importance when implementing this optimization.¶

One way of doing this is to annotate the received nonce or partial IV with a marker that indicates the usability as an elided response Partial IV. That marker is originally unset when the Partial IV is extracted from the request, and only ever gets set the very time that sequence number gets removed from the replay window. The marker is removed from the data structure when it is used in the encryption of a message. Care must be taken when a nonce / Partial IV is copied to only let the marker stay with one copy, and to unset it on the other one.¶

Note that this aligns well with the typical other cases when responses use an own Partial IV:¶

• In observations, the first response can be sent without a Partial IV. Later notifications are built with AAD linked to the original request's Partial IV, but that was copied over from the original request's Partial IV and thus does not carry a marker any more.¶
• In responses that serve to recover the replay window as in [RFC8613] Appendix B.1.2, the replay window is invalid when the first response is generated, thus there is no marker to respond without Partial IV.¶

3.1.4. Consequences for replay window recovery using Echo

[ This is maybe more corr-clar or even my own wishful thinking than actual implementation guidance. ]¶

For the first response to the replay window recovery of [RFC8613] Appendix B.1.2, applying the above considerations means that the server may not need to recover its replay window right away.¶

If the initial request that triggers the recovery process is idempotent (for example, the typical initial GET to /.well-known/core), the server can accept the request as possible duplicate, and send a successful response righ away.¶

The response should still contain an Echo value (and the client should send the same Echo with the next request) for the benefit of future non-idempotent operations and to eventually allow the server to send shorter responses (without a Partial IV).¶

Only when a resource with freshness requirements is accessed, the client needs to have included the Echo value in at latest that very response. A 4.01 response (which incurs the additional round-trip) thus only needs to happen if the first request that triggers recovery is not idempotent.¶