Using onion routing with CoAP

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."¶

This Internet-Draft will expire on 5 January 2024.¶

Copyright Notice

Copyright (c) 2023 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

[ See also abstract. ]¶

2. Conventions and Definitions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Mechanism outline

• The client can hide its position in the network from the origin server, while still possibly protecting communications end-to-end with OSCORE.¶
• Use the method defined in Section 3 of [I-D.tiloca-core-oscore-capable-proxies-06] to achieve OSCORE-protected onion forwarding, through a chain of proxies (at least three are expected). Every message generated by or intended to the origin client must traverse the whole chain of proxies until the intended other endpoint (typically, the origin server). The chain of proxies has to be known in advance by the client, i.e., the exact proxies and their order in the chain.¶

• The typical case addressed in this document considers an origin client that, at most, shares one OSCORE Security Context with the origin server and one OSCORE Security Context with the first proxy in the chain.¶

  If onion forwarding is used, the origin client shares an OSCORE Security Context with the origin server, and a dedicated OSCORE Security Context with each of the proxies in the chain.¶

• The origin client protects a request by applying first the OSCORE layer intended to the origin server, then the OSCORE layer intended to the last proxy in the chain, then the OSCORE layer intended to the second from last proxy in the chain and so on, until it applies the OSCORE layer intended to the first proxy in the chain.¶

  Before protecting a request with the OSCORE layer to be consumed by a certain proxy in the chain, the origin client also adds proxy-related options intended to that proxy, as indications to forward the request to (the next hop towards) the origin server.¶

  Other than the actions above from the client, there should be no difference from the basic approach defined in Section 3 of [I-D.tiloca-core-oscore-capable-proxies-06]. Each proxy in the chain would process and remove one OSCORE layer from the received request and then forward it to (the next hop towards) the origin server.¶

• The exact way used by the client to establish OSCORE Security Contexts with the proxies and the origin server is out of scope.¶

  If the EDHOC key establishment protocol is used (see [I-D.ietf-lake-edhoc]), it is most convenient for the client to run it with the first proxy in the chain, then with the second proxy in the chain through the first one and so on, and finally with the origin server by traversing the whole chain of proxies.¶

  Then, it is especially convenient to use the optimized workflow defined in [I-D.ietf-core-oscore-edhoc] and based on the EDHOC + OSCORE request. This would basically allow the client to complete the EDHOC execution with an endpoint and start the EDHOC execution with the next endpoint in the chain, by means of a single message sent on the wire.¶

• Hop-by-hop security has to also be achieved between each pair of proxies in the chain. To this end, two adjacent proxies would better use TLS over TCP than OSCORE between one another (this should be acceptable for non-constrained proxies). This takes advantage of the TCP packet aggregation policies, and thus:¶

  • As request forwarding occurs in MTU-size bundles, the length of the origin request can be hidden as well.¶
  • Requests and responses traversing the proxy chain cannot be correlated, e.g., by externally monitoring the timing of message forwarding (which would jeopardize the client's wish to hide itself from anything but the first proxy in the chain).¶

• Cacheability of responses can still happen, as per Section 4 of [I-D.tiloca-core-oscore-capable-proxies-06] and using the approach defined in [I-D.amsuess-core-cachable-oscore].¶

  The last proxy in the chain would be the only proxy actually seeing the Deterministic Request originated by the client and then caching the corresponding responses from the origin server. It is good that other proxies are not able to do the same, thus preventing what might lead to request-response correlation, again opening for localization of the origin client.¶

• Possible optimizations along the proxy chains¶

  • In particular settings involving additional configuration on the client, some proxy in the chain might be a reverse-proxy. Then, such a proxy can be configured to map on one hand the OSCORE Security Context shared with the origin client (and used to remove a corresponding OSCORE layer from a received request to forward) and, on the other hand, the addressing information of the next hop in the chain where to forward the received request to. This would spare the origin client to add a set of proxy-related options for every single proxy in the chain.¶

  • It is mentioned above to additionally use TLS over TCP hop-by-hop between every two adjacent proxies in the chain. That said:¶

    • The OSCORE protection of the request has certainly to rely on authenticated encryption algorithms (as usual), when applying the OSCORE layer intended to the origin server (the first one applied by the origin client) and the OSCORE layer intended to the first proxy in the chain (the last one applied by the origin client).¶
    • For any other OSCORE layer applied by the origin client (i.e., intended for any proxy in the chain but the first one), the OSCORE protection can better rely on an encryption-only algorithm not providing an authentication tag (as admitted in the group mode of Group OSCORE [I-D.ietf-core-oscore-groupcomm] and assuming the registration of such algorithms in COSE).¶
    • This would be secure to do, since every pair of adjacent proxies in the chain relies on its TLS connection for the respective hop-by-hop communication anyway. The benefit is that it avoids transmitting several unneeded authentication tags from OSCORE.¶

4. Security Considerations

TBD.¶

5. IANA Considerations

TBD.¶

Appendix A. Change log

Since [I-D.tiloca-core-oscore-capable-proxies-06]:¶

• The main body of the text was moved here and will be absent from the -07 version of that document.¶
• An abstract was added.¶

Acknowledgments

TBD.¶

Authors' Addresses