Cacheable OSCORE
draft-amsuess-core-cachable-oscore-08
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Christian Amsüss , Marco Tiloca | ||
| Last updated | 2024-01-10 | ||
| 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-cachable-oscore-08
A server that does not support Deterministic Requests would not be
able to create the necessary Recipient Context, and thus will fail
decrypting the request.
1. If not already available, the server retrieves the information
about the Deterministic Client from the Group Manager, and
derives the Sender Key of the Deterministic Client.
2. The server actually recognizes the request to be a Deterministic
Request, due to the presence of the Request-Hash option and to
the 'kid' parameter of the OSCORE option set to the Sender ID of
the Deterministic Client.
If the 'kid' parameter of the OSCORE option specifies a different
Sender ID than the one of the Deterministic Client, the server
MUST NOT take the following steps, and instead processes the
request as per Section 9.4 of [I-D.ietf-core-oscore-groupcomm].
3. The server retrieves the hash H from the Request-Hash option.
4. The server derives a Recipient Context for processing the
Deterministic Request. In particular:
* The Recipient ID is the Sender ID of the Deterministic Client.
* The Recipient Key is derived as the key K in step 3 of
Section 3.4.2, with the hash H retrieved at the previous step.
5. The server verifies the request using the pairwise mode of Group
OSCORE, as defined in Section 9.4 of
[I-D.ietf-core-oscore-groupcomm], using the Recipient Context
from step 4, with the difference that the server does not perform
replay checks against a Replay Window (see below).
In case of successful verification, the server MUST also perform the
following actions, before possibly delivering the request to the
application.
* Starting from the recovered plain CoAP request, the server MUST
recompute the same hash that the client computed at step 2 of
Section 3.4.2.
If the recomputed hash value differs from the value retrieved from
the Request-Hash option at step 3, the server MUST treat the
request as invalid and MAY reply with an unprotected 4.00 (Bad
Request) error response. The server MAY set an Outer Max-Age
option with value zero. The diagnostic payload MAY contain the
string "Decryption failed".
Amsüss & Tiloca Expires 13 July 2024 [Page 14]
Internet-Draft Cacheable OSCORE January 2024
This prevents an attacker that guessed a valid authentication tag
for a given Request-Hash value to poison caches with incorrect
responses.
* The server MUST verify that the unprotected request is safe to be
processed in the REST sense, i.e., that it has no side effects.
If verification fails, the server MUST discard the message and
SHOULD reply with a protected 4.01 (Unauthorized) error response.
Note that some CoAP implementations may not be able to prevent
that an application produces side effects from a safe request.
This may incur checking whether the particular resource handler is
explicitly marked as eligible for processing Deterministic
Requests. An implementation may also have a configured list of
requests that are known to be side effect free, or even a pre-
built list of valid hashes for all sensible requests for them, and
reject any other request.
These checks replace the otherwise present requirement that the
server needs to check the Replay Window of the Recipient Context
(see step 5 above), which is inapplicable with the Recipient
Context derived at step 4 from the value of the Request-Hash
option. The reasoning is analogous to the one in
[I-D.amsuess-lwig-oscore] to treat the potential replay as
answerable, if the handled request is side effect free.
3.4.4. Response to a Deterministic Request
When preparing a response to a Deterministic Request, the server
treats the Request-Hash option as a Class I option. The value of the
Request-Hash option MUST be equal to the value of the Request-Hash
option that was specified in the corresponding Deterministic Request.
Since the client is aware of the Request-Hash value to expect in the
response, the server usually elides the Request-Hash option from the
actually transmitted response.
Treating the Request-Hash option as a Class I option creates the
request-response binding, thus ensuring that no mismatched responses
can be successfully unprotected and verified by the client (see
Section 2).
The client MUST reject a response to a Deterministic Request, if the
Request-Hash value of the response is not equal to the value that was
specified in the Request-Hash option of that Deterministic Request.
When preparing the response, the server performs the following
actions.
Amsüss & Tiloca Expires 13 July 2024 [Page 15]
Internet-Draft Cacheable OSCORE January 2024
1. The server sets a non-zero Max-Age option, thus making the
Deterministic Request usable for the proxy cache.
2. The server preliminarily sets the Request-Hash option with the
full Request-Hash value, i.e., the same value of the Request-Hash
option that was specified in the Deterministic Request.
3. If the Deterministic Request included an inner Observe option but
not an outer Observe option, the server MUST include an inner
Observe option in the response.
4. The server MUST protect the response using the group mode of
Group OSCORE, as defined in Section 8.3 of
[I-D.ietf-core-oscore-groupcomm]. This is required to ensure
that the client can verify the source authentication of the
response, since the "pairwise" key used for producing the
Deterministic Request is actually shared among all the group
members.
Note that the Request-Hash option is treated as Class I here.
5. The server MUST use its own Sender Sequence Number as Partial IV
to protect the response, and include it as Partial IV in the
OSCORE option of the response. This is required since the server
does not perform replay protection on the Deterministic Request
(see Section 3.4.4).
6. The server uses 2.05 (Content) as outer code even though the
response is not necessarily an Observe notification [RFC7641], in
order to make the response cacheable.
7. The server SHOULD remove the Request-Hash option from the
response before sending the response to the client, as per the
general option mechanism defined in Section 3.3.
8. If the Deterministic Request included an inner Observe option but
not an outer Observe option, the server MUST NOT include an outer
Observe option in the response.
Upon receiving the response, the client performs the following
actions.
1. In case the response includes a 'kid' in the OSCORE option, the
client MUST verify it to be exactly the 'kid' of the server to
which the Deterministic Request was sent, unless responses from
multiple servers are expected (see Section 3.4.5).
Amsüss & Tiloca Expires 13 July 2024 [Page 16]
Internet-Draft Cacheable OSCORE January 2024
2. In case the response does not include the Request-Hash option,
the client adds the Request-Hash option to the response, setting
its value to the same value of the Request-Hash option that was
specified in the Deterministic Request.
Otherwise, the client MUST reject the response if the value of
the Request-Hash option is different from the value of the
Request-Hash option that was specified in the Deterministic
Request.
3. The client verifies the response using the group mode of Group
OSCORE, as defined in Section 8.4 of
[I-D.ietf-core-oscore-groupcomm]. In particular, the client
verifies the countersignature in the response, based on the 'kid'
of the server it sent the request to. When verifying the
response, the Request-Hash option is treated as a Class I option.
4. If the Deterministic Request included an inner Observe option but
not an outer Observe option (see Section 3.1), the client MUST
silently ignore the inner Observe option in the response, which
MUST NOT result in stopping the processing of the response.
[ Note: This deviates from Section 4.1.3.5.2 of RFC 8613, but it is
limited to a very specific situation, where the client and server
both know exactly what happens. This does not affect the use of
OSCORE in other situations. ]
3.4.5. Deterministic Requests to Multiple Servers
A Deterministic Request _can_ be sent to a CoAP group, e.g., over UDP
and IP multicast [I-D.ietf-core-groupcomm-bis], thus targeting
multiple servers at once.
To simplify key derivation, such a Deterministic Request is still
created in the same way as a one-to-one request and still protected
with the pairwise mode of Group OSCORE, as defined in Section 3.4.2.
Note that this deviates from Section 8 of
[I-D.ietf-core-oscore-groupcomm], since the Deterministic Request in
this case is indeed intended to multiple recipients, but yet it is
protected with the pairwise mode. However, this is limited to a very
specific situation, where the client and servers both know exactly
what happens. This does not affect the use of Group OSCORE in other
situations.
Amsüss & Tiloca Expires 13 July 2024 [Page 17]
Internet-Draft Cacheable OSCORE January 2024
[ Note: If it was protected with the group mode, the request hash
would need to be fed into a group key derivation just for this corner
case. Furthermore, there would need to be a signature in spite of no
authentication credential (and public key included therein)
associated with the Deterministic Client. ]
When a server receives a request from the Deterministic Client as
addressed to a CoAP group, the server proceeds as defined in
Section 3.4.3, with the difference that it MUST include its own
Sender ID in the response, as 'kid' parameter of the OSCORE option.
Although it is normally optional for the server to include its Sender
ID when replying to a request protected in pairwise mode, it is
required in this case for allowing the client to retrieve the
Recipient Context associated with the server originating the
response.
If a server is member of a CoAP group, and it fails to successfully
decrypt and verify an incoming Deterministic Request, then it is
RECOMMENDED for that server to not send back any error message, in
case the server asserts that the Deterministic Request was sent to
the CoAP group (e.g., to the associated IP multicast address) or in
case the server is not able to assert that altogether.
4. Obtaining Information about the Deterministic Client
This section extends the Joining Process defined in
[I-D.ietf-ace-key-groupcomm-oscore], and based on the ACE framework
for Authentication and Authorization [RFC9200]. Upon joining the
OSCORE group, this enables a new group member to obtain from the
Group Manager the required information about the Deterministic Client
(see Section 3.4.1).
With reference to the 'key' parameter included in the Join Response
defined in Section 6.3 of [I-D.ietf-ace-key-groupcomm-oscore], the
Group_OSCORE_Input_Material object specified as its value contains
also the two additional parameters 'det_senderId' and 'det_hash_alg'.
These are defined in Section 6.2 of this document. In particular:
* The 'det_senderId' parameter, if present, has as value the OSCORE
Sender ID assigned to the Deterministic Client by the Group
Manager. This parameter MUST be present if the OSCORE group uses
Deterministic Requests as defined in this document. Otherwise,
this parameter MUST NOT be present.
* The 'det_hash_alg' parameter, if present, has as value the hash
algorithm to use for computing the hash of a plain CoAP request,
when producing the associated Deterministic Request. This
Amsüss & Tiloca Expires 13 July 2024 [Page 18]
Internet-Draft Cacheable OSCORE January 2024
parameter takes values from the "Value" column of the "COSE
Algorithms" Registry [COSE.Algorithms]. This parameter MUST be
present if the OSCORE group uses Deterministic Requests as defined
in this document. Otherwise, this parameter MUST NOT be present.
The same extension above applies also to the 'key' parameter included
in a Key Distribution Response (see Sections 9.1.1 and 9.1.2 of
[I-D.ietf-ace-key-groupcomm-oscore]).
With reference to the 'key' parameter included in a Signature
Verification Data Response defined in Section 9.6 of
[I-D.ietf-ace-key-groupcomm-oscore], the Group_OSCORE_Input_Material
object specified as its value contains also the 'det_senderId'
parameter defined above.
5. Security Considerations
The same security considerations from [RFC7252][I-D.ietf-core-groupco
mm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this
document.
The following elaborates on how, compared to Group OSCORE,
Deterministic Requests dispense with some of the OSCORE security
properties, by just so much as to make caching possible.
* A Deterministic Request is intrinsically designed to be replayed,
as intended to be identically sent multiple times by multiple
clients to the same server(s).
Consistently, as per the processing defined in Section 3.4.3, a
server receiving a Deterministic Request does not perform replay
checks against an OSCORE Replay Window.
This builds on the following considerations.
- For a given request, the level of tolerance to replay risk is
specific to the resource it operates upon (and therefore only
known to the origin server). In general, if processing a
request does not have state-changing side effects, the
consequences of replay are not significant.
Just like for what concerns the lack of source authentication
(see below), the server must verify that the received
Deterministic Request (more precisely, its handler) is side
effect free. The distinct semantics of the CoAP request codes
can help the server make that assessment.
Amsüss & Tiloca Expires 13 July 2024 [Page 19]
Internet-Draft Cacheable OSCORE January 2024
- Consistently with the point above, a server can choose whether
it will process a Deterministic Request on a per-resource
basis. It is RECOMMENDED that origin servers allow resources
to explicitly configure whether Deterministic Requests are
appropriate to receive, as still limited to requests that are
safe to be processed in the REST sense, i.e., they do not have
state-changing side effects.
* Receiving a response to a Deterministic Request does not mean that
the response was generated after the Deterministic Request was
sent.
However, a valid response to a Deterministic Request still
contains two freshness statements.
- It is more recent than any other response from the same group
member that has a smaller sequence number.
- It is more recent than the original creation of the
deterministic keying material in the Group OSCORE Security
Context.
* Source authentication of Deterministic Requests is lost.
Instead, the server must verify that the Deterministic Request
(more precisely, its handler) is side effect free. The distinct
semantics of the CoAP request codes can help the server make that
assessment.
Just like for what concerns the acceptance of replayed
Deterministic Requests (see above), the server can choose whether
it will process a Deterministic Request on a per-resource basis.
* The privacy of Deterministic Requests is limited.
An intermediary can determine that two Deterministic Requests from
different clients are identical, and associate the different
responses generated for them. A server producing responses of
varying size to a Deterministic Request can use the Padding option
to hide when the response is changing.
[ More on the verification of the Deterministic Request ]
6. IANA Considerations
Note to RFC Editor: Please replace "[RFC-XXXX]" with the RFC number
of this document and delete this paragraph.
Amsüss & Tiloca Expires 13 July 2024 [Page 20]
Internet-Draft Cacheable OSCORE January 2024
This document has the following actions for IANA.
6.1. CoAP Option Numbers Registry
IANA is asked to enter the following option numbers to the "CoAP
Option Numbers" registry within the "Constrained RESTful Environments
(CoRE) Parameters" registry group.
+--------+--------------+------------+
| Number | Name | Reference |
+--------+--------------+------------+
| TBD1 | Request-Hash | [RFC-XXXX] |
+--------+--------------+------------+
| TBD2 | Padding | [RFC-XXXX] |
+--------+--------------+------------+
Figure 2: CoAP Option Numbers
[
For the Request-Hash option, the number suggested to IANA is 548.
For the Padding option, the option number is picked to be the highest
number in the Experts Review range; the high option number allows it
to follow practically all other options, and thus to be set when the
final unpadded message length including all options is known.
Therefore, the number suggested to IANA is 64988.
Applications that make use of the "Experimental use" range and want
to preserve that property are invited to pick the largest suitable
experimental number (65532)
Note that unless other high options are used, this means that padding
a message adds an overhead of at least 3 bytes, i.e., 1 byte for
option delta/length and two more bytes of extended option delta.
This is considered acceptable overhead, given that the application
has already chosen to prefer the privacy gains of padding over wire
transfer length.
]
6.2. OSCORE Security Context Parameters Registry
IANA is asked to register the following entries in the "OSCORE
Security Context Parameters" registry within the "Authentication and
Authorization for Constrained Environments (ACE)" registry group.
* Name: det_senderId
Amsüss & Tiloca Expires 13 July 2024 [Page 21]
Internet-Draft Cacheable OSCORE January 2024
* CBOR Label: TBD3
* CBOR Type: bstr
* Registry: -
* Description: OSCORE Sender ID assigned to the Deterministic Client
of an OSCORE group
* Reference: [RFC-XXXX] (Section 4)
* Name: det_hash_alg
* CBOR Label: TBD4
* CBOR Type: int / tstr
* Registry: -
* Description: Hash algorithm to use in an OSCORE group when
producing a Deterministic Request
* Reference: [RFC-XXXX] (Section 4)
7. References
7.1. Normative References
[COSE.Algorithms]
IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>.
[I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
10, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
groupcomm-bis-10>.
Amsüss & Tiloca Expires 13 July 2024 [Page 22]
Internet-Draft Cacheable OSCORE January 2024
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
and J. Park, "Group Object Security for Constrained
RESTful Environments (Group OSCORE)", Work in Progress,
Internet-Draft, draft-ietf-core-oscore-groupcomm-20, 2
September 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-oscore-groupcomm-20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/rfc/rfc8132>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
7.2. Informative References
[I-D.amsuess-lwig-oscore]
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>.
Amsüss & Tiloca Expires 13 July 2024 [Page 23]
Internet-Draft Cacheable OSCORE January 2024
[I-D.bormann-core-responses]
Bormann, C. and C. Amsüss, "CoAP: Non-traditional response
forms", Work in Progress, Internet-Draft, draft-bormann-
core-responses-01, 3 February 2022,
<https://datatracker.ietf.org/doc/html/draft-bormann-core-
responses-01>.
[I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", Work in Progress, Internet-
Draft, draft-ietf-ace-key-groupcomm-oscore-16, 6 March
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
ace-key-groupcomm-oscore-16>.
[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-05, 17
November 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-dns-over-coap-05>.
[I-D.ietf-core-observe-multicast-notifications]
Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini,
"Observe Notifications as CoAP Multicast Responses", Work
in Progress, Internet-Draft, draft-ietf-core-observe-
multicast-notifications-07, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
observe-multicast-notifications-07>.
[ICN-paper]
Gündoğan, C., Amsüss, C., Schmidt, T. C., and M. Wählisch,
"Group Communication with OSCORE: RESTful Multiparty
Access to a Data-Centric Web of Things", October 2021,
<https://ieeexplore.ieee.org/document/9525000>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/rfc/rfc7641>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/rfc/rfc8323>.
Amsüss & Tiloca Expires 13 July 2024 [Page 24]
Internet-Draft Cacheable OSCORE January 2024
[RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander,
"Constrained Application Protocol (CoAP): Echo, Request-
Tag, and Token Processing", RFC 9175,
DOI 10.17487/RFC9175, February 2022,
<https://www.rfc-editor.org/rfc/rfc9175>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/rfc/rfc9200>.
[SW-EPIV] Lucas, G., "Star Wars", Lucasfilm Ltd. , 1977.
Appendix A. Change log
Since -07:
* Use of "Consensus Request" instead of "Deterministic Request" in
one sentence.
* Added DNS over CoAP as possible use case.
* The computation of the Request Hash takes as input the aad_array
(i.e., not the external_aad).
* Corrected parameter name 'sender_cred'.
* Simplified parameter provisioning to the external signature
verifier.
Since -06:
* Clarifications, terminology alignment, and editorial improvements.
Since -05:
* Updated references.
Since -04:
* Revised and extended list of use cases.
* Added further note on Deterministic Requests to a group of servers
as still protected with the pairwise mode.
* Suppression of error responses for servers in a CoAP group.
Amsüss & Tiloca Expires 13 July 2024 [Page 25]
Internet-Draft Cacheable OSCORE January 2024
* Extended security considerations with discussion on replayed
requests.
Since -03:
* Processing steps in case only inner Observe is included.
* Clarified preserving/eliding the Request-Hash option in responses.
* Clarified limited use of the Echo option.
* Clarifications on using the Padding option.
Since -02:
* Separate parts needed to respond to unauthenticated requests from
the remaining deterministic response part. (Currently this is
mainly an addition; the document will undergo further refactoring
if that split proves helpful).
* Inner Observe is set unconditionally in Deterministic Requests.
* Clarifications around padding and security considerations.
Since -01:
* Not meddling with request_kid any more.
Instead, Request-Hash in responses is treated as Class I, but
typically elided.
In requests, this removes the need to compute the external_aad
twice.
* Derivation of the hash now uses the external_aad, rather than the
full AAD. This is good enough because AAD is a function only of
the external_aad, and the external_aad is easier to get your hands
on if COSE manages all the rest.
* The Sender ID of the Deterministic Client is immutable throughout
the group lifetime. Hence, no need for any related expiration/
creation time and mechanisms to perform its update in the group.
* Extension to the ACE Group Manager of ace-key-groupcomm-oscore to
provide required info about the Deterministic Client to new group
members when joining the group.
* Alignment with changes in core-oscore-groupcomm-12.
Amsüss & Tiloca Expires 13 July 2024 [Page 26]
Internet-Draft Cacheable OSCORE January 2024
* Editorial improvements.
Since -00:
* More precise specification of the hashing (guided by first
implementations)
* Focus shifted to Deterministic Requests (where it should have been
in the first place; all the build-up of Token Requests was moved
to a motivating appendix)
* Aligned with draft-tiloca-core-observe-responses-multicast-05 (not
submitted at the time of submission)
* List the security properties lost compared to OSCORE
Appendix B. Padding
As discussed in Section 5, information can be leaked by the length of
a response or, in different contexts, of a request.
In order to hide such information and mitigate the impact on privacy,
the new CoAP option with name Padding is defined, in order to allow
increasing a message's length without changing its meaning.
The option can be used with any CoAP transport, but is especially
useful with OSCORE as that does not provide any padding of its own.
Before choosing to pad a message by using the Padding option,
application designers should consider whether they can arrange for
common message variants to have the same length by picking a suitable
content representation; the canonical example here is expressing
"yes" and "no" with "y" and "n", respectively.
B.1. Definition of the Padding Option
As summarized in Figure 3, the Padding option is elective, safe to
forward and not part of the cache key; these follow from the usage
instructions. The option may be repeated, as that may be the only
way to achieve a certain total length for the padded message.
+------+---+---+---+---+---------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+---------+--------+--------+---------+
| TBD2 | | | x | x | Padding | opaque | any | (none) |
+------+---+---+---+---+---------+--------+--------+---------+
Figure 3: Padding Option
Amsüss & Tiloca Expires 13 July 2024 [Page 27]
Internet-Draft Cacheable OSCORE January 2024
When used with OSCORE, the Padding option is of Class E, which makes
it indistinguishable from other Class E options or the payload to
third parties.
B.2. Using and processing the Padding option
When a server produces different responses of different length for a
given class of requests but wishes to produce responses of consistent
length (typically to hide the variation from anyone but the intended
recipient), the server can pick a length that all possible responses
can be padded to, and set the Padding option with a suitable all-zero
option value in all responses to that class of requests.
Likewise, a client can decide on a class of requests that it pads to
reach a consistent length. This has considerably less efficacy and
applicability when applied to Deterministic Requests. That is: an
external observer can group together different requests even if they
are of the same length; and padding would hinder convergence on a
single Consensus Request, thus requiring all users of the same Group
OSCORE Security Context to agree on the same total length in advance.
Any party receiving a Padding option MUST ignore it. In particular,
a server MUST NOT make its choice of padding a response dependent on
any padding present in the corresponding request. A means driven by
the client for coordinating response padding is out of scope for this
document.
Proxies that see a Padding option MAY discard it.
Appendix C. Simple Cacheability using Ticket Requests
Building on the concept of Phantom Requests and Informative Responses
defined in [I-D.ietf-core-observe-multicast-notifications], basic
caching is already possible without building a Deterministic Request.
The approach discussed in this appendix is not provided for
application. In fact, it is efficient only when dealing with very
large representations and no OSCORE inner Block-Wise mode (which is
inefficient for other reasons), or when dealing with observe
notifications (which are already well covered in
[I-D.ietf-core-observe-multicast-notifications]).
Rather, it is more provided as a "mental exercise" for the authors
and interested readers to bridge the gap between this document and
[I-D.ietf-core-observe-multicast-notifications].
Amsüss & Tiloca Expires 13 July 2024 [Page 28]
Internet-Draft Cacheable OSCORE January 2024
That is, instead of replying to a client with a regular response, a
server can send an Informative Response, defined as a protected 5.03
(Service Unavailable) error message. The payload of the Informative
Response contains the Phantom Request, which is a Ticket Request in
the broader terminology used by this document.
Unlike a Deterministic Request, a Phantom Request is protected with
the Group Mode of Group OSCORE. Instead of verifying a hash, the
client can see from the countersignature that this was indeed the
request the server is answering. The client also verifies that the
request URI is identical between the original request and the Ticket
Request.
The remaining exchange largely plays out like in
[I-D.ietf-core-observe-multicast-notifications]'s "Example with a
Proxy and Group OSCORE": The client sends the Phantom Request to the
proxy (but, lacking a tp_info, without a Listen-To-Multicast-
Responses option), which forwards it to the server for lack of the
option.
The server then produces a regular response and includes a non-zero
Max-Age option as an outer CoAP option. Note that there is no point
in including an inner Max-Age option, as the client could not pin it
in time.
When a second, different client later asks for the same resource at
the same server, its new request uses a different 'kid' and 'Partial
IV' than the first client's. Thus, the new request produces a cache
miss at the proxy and is forwarded to the server, which responds with
the same Ticket Request provided to the first client. After that,
when the second client sends the Ticket Request, a cache hit at the
proxy will be produced, and the Ticket Request can be served from the
proxy's cache.
When multiple proxies are in use, or the response has expired from
the proxy's cache, the server receives the Ticket Request multiple
times. It is a matter of perspective whether the server treats that
as an acceptable replay (given that this whole mechanism only makes
sense on requests free of side effects), or whether it is
conceptualized as having an internal proxy where the request produces
a cache hit.
Amsüss & Tiloca Expires 13 July 2024 [Page 29]
Internet-Draft Cacheable OSCORE January 2024
Appendix D. Application for More Efficient End-to-End Protected
Multicast Notifications
[I-D.ietf-core-observe-multicast-notifications] defines how a CoAP
server can serve all clients observing a same resource at once, by
sending notifications over multicast. The approach supports the
possible presence of intermediaries such as proxies, also if Group
OSCORE is used to protect notifications end-to-end.
However, comparing the "Example with a Proxy" in Appendix E of
[I-D.ietf-core-observe-multicast-notifications] and the "Example with
a Proxy and Group OSCORE" in Appendix F of
[I-D.ietf-core-observe-multicast-notifications] shows that, when
using Group OSCORE, more requests need to hit the server. This is
because every client originally protects its Observation request
individually, and thus needs a custom response served to obtain the
Phantom Request as a Ticket Request.
If the clients send their requests as the same Deterministic Request,
then the server can use these requests as Ticket Requests as well.
Thus, there is no need for the server to provide a same Phantom
Request to each client.
Instead, the server can send a single, unprotected Informative
Response - very much like in the example without Group OSCORE - hence
setting the proxy up and optionally providing also the latest
notification along the way.
The proxy can thus be configured by the server following the first
request from the clients, after which it has an active observation
and a fresh cache entry in time for the second client to arrive.
Appendix E. Open questions
* Is "deterministic encryption" something worthwhile to consider in
COSE?
COSE would probably specify something more elaborate for the KDF
(the current KDF round is the pairwise mode's; COSE would probably
run through KDF with a KDF context structure).
COSE would give a header parameter name to the Request-Hash (which
for the purpose of OSCORE Deterministic Requests would put back
into Request-Hash by extending the option compression function
across the two options).
Conceptually, they should align well, and the implementation
changes are likely limited to how the KDF is run.
Amsüss & Tiloca Expires 13 July 2024 [Page 30]
Internet-Draft Cacheable OSCORE January 2024
* An unprotection failure from a mismatched hash will not be part of
the ideally constant-time code paths that otherwise lead to AEAD
unprotect failures. Is that a problem?
After all, it does tell the attacker that they did succeed in
producing a valid MAC (it's just not doing it any good, because
this key is only used for Deterministic Requests and thus also
needs to pass the Request-Hash check).
Appendix F. Unsorted further ideas
* All or none of the Deterministic Requests should have an inner
observe option. Preferably none -- that makes messages shorter,
and clients need to ignore that option either way when checking
whether a Consensus Request matches their intended request.
* We could allows clients to elide all other options than Request-
Hash, and elide the payload, if it has reason to believe that it
can produce a cache hit with the abbreviated request alone.
This may prove troublesome in terms of cache invalidation (the
server would have to use short-lived responses to indicate that it
does need the full request, or we'd need special handling for
error responses, or criteria by which proxies don't even forward
these if they don't have a response at hand).
That may be more trouble than it's worth without a strong use case
(say, of complex but converging FETCH requests).
Hashes could also be used in truncated form for that.
Acknowledgments
The authors sincerely thank Michael Richardson, Jim Schaad, and Göran
Selander for their comments and feedback.
The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
(Grant agreement 952652).
Authors' Addresses
Christian Amsüss
Austria
Email: christian@amsuess.com
Amsüss & Tiloca Expires 13 July 2024 [Page 31]
Internet-Draft Cacheable OSCORE January 2024
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: marco.tiloca@ri.se
Amsüss & Tiloca Expires 13 July 2024 [Page 32]