| Internet-Draft | Onion CoAP | May 2024 |
| Amsüss, et al. | Expires 18 November 2024 | [Page] |
The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and client similar to how Tor (The Onion Router) enables it for TCP based protocols.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document takes place on the Thing-to-Thing Research Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=t2trg.¶
Source for this draft and an issue tracker can be found at https://gitlab.com/chrysn/onion-coap.¶
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 18 November 2024.¶
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. ]¶
The network described in this document is designed to allow participation of Class 1 devices as defined in [RFC7228] as servers and clients. It should reuse building blocks these devices will already implement if they use EDHOC for authenticated key establishment and OSCORE for encryption. Operations that are costly for constrained devices, such as creating and verifying signatures, should not be part of regular operation.¶
This document introduces separate mechanisms that in combination enable setups similar to how Tor is used for anonymous web access and anonymous hosting of web sites. Some of the mechanisms need no new protocol components, but merely describe which existing steps are used to obtain the desired results.¶
Note that these mechanisms should be largely independent: A server that does not intend to hide its position can still advertise a cryptographic name at its real network coordinates, and thus be available both to clients that do hide their location (even if their proxies do not work as “exit nodes” in Tor terminology) and to clients on a local network.¶
Figure 1 illustrates an example topology, and Figure 2 illustrates a cross-section of the OSCORE layers along one path.¶
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.¶
A client can pick one or more proxies to hide its position in the network.¶
Without OSCORE proxies, only one proxy hop can be chosen, because the CoAP requests contains at most two addresses: The address in the IP header, and the address in the Uri-Host option. With the mechanisms introduced in [I-D.tiloca-core-oscore-capable-proxies], CoAP request can contain a Uri-Host option in each layer of OSCORE, effectively building a source routing chain.¶
To build the chain, the client first chooses its first proxy hop, and runs EDHOC to establish an OSCORE context. In this process, the proxy authenticates with its long-term credentials, whereas the client uses an ephemeral key (a plain CWT Cliams Set, [RFC8392]). The process can take as little as one round-trip per proxy; when message 3 of EDHOC is sent along with the OSCORE message (see [I-D.ietf-core-oscore-edhoc]) that contains the next hop’s message 1,¶
Once one proxy context is established, EDHOC can be run through that proxy with the next proxy, until a chain of sufficient length has been established. Care has to be taken to never use one of the later proxies with any chain other than the chain through which the connection was established, for otherwise the client can be deanonymized mor easily.¶
When forwarding messages, every forward proxy strips off a layer of OSCORE from the request, and adds one to the response.¶
Possible optimizations:¶
G_X and G_I) for the client?
(I.e., Can G_X be re-used as G_I without harm to EDHOC (likely not), and how would that be communicated?)¶
For hops that are only ever used with a single next-hop, as is typical with all but the first proxy (see guidance below): Can default values for Proxy-Scheme and Uri-Host be communicated during EDHOC, values that would later be elided? Otherwise, every request would contain explicit addresses of the full chain. If taken to the extreme, this might be setting up a SCHC context that also compresses parts of the OSCORE option, where the client tells each proxy what the KID used with the next proxy is, and uses the same sender sequence number for the hops. (This has own security considerations; might be necessary to apply offsets, at which point it gets overly complex).¶
Effectively, setting a default value for Proxy-Scheme and Uri-Host makes that (originally forward) proxy a reverse proxy.¶
TBD: This section should contain guidance distilled from Tor operations. In particular, it might recommend that a client pick one proxy hop as a long-term first hop, while building the remaining chain individually for each new origin server.¶
Following common tor practice, it is expected that typical chain lengths are around 3 hops. Note that the amount of processing on the peer side is independent of the length of the chain chosen by a host. If a client deems a one-hop setup sufficient and only has resources for maintaining one extra OSCORE context, it can still use a server that is hidden behind a 3 long proxy chain.¶
A server can pick one or more proxies to hide its position in the network.¶
Unlike forward proxies, which are configured per request, this requires a dedicated mechanism.¶
TBD: This document does not yet specify such a mechanism, but may draw upon the reverse proxy request of Section 2 of [I-D.amsuess-core-resource-directory-extensions].¶
When forwarding messages, every reverse proxy adds a layer of OSCORE to the request, and removes one from the response.¶
Possible optimizations:¶
CRED_x used in EDHOC.¶
The mechanisms discussed in [I-D.amsuess-t2trg-rdlink] can be used by hidden services to come up with names for their services. (That document will need to be updated to use mechanisms from Appendix F of [I-D.ietf-core-transport-indication]).¶
Along with the service’s public key (that is announced as part of the name), the published record may also include the public key of the introduction point, as that will allow the client to establish an extra layer with the introduction point. As the published record is not trusted, the client can use the EAD option described in Appendix D of [I-D.ietf-core-transport-indication] to verify the proxy’s public key as part of the end-to-end session. If client and server support this, they can rule out that an attacker might advertise itself as the introduction address and could thus monitor large portions of the traffic toward a hidden service (even though that attacker would still not learn the location of the server, the location of hidden clients, or the content of the communication). As an alternative (TBD: when would which be chosen), the client’s last chosen proxy, when seeing the cryptographic address of the hidden service, may not just establish an EDHOC session with the introduction proxy, but also with the hidden service, therein performing the same verification. The server should therefore allow for at least one level of nesting within incoming EDHOC sessions.¶
A mechanism for discovering forward proxies is already described in [I-D.ietf-core-transport-indication]; discovery of reverse proxies suitable for servers will depend on the precise mechanism used.¶
Services with cryptographic identifiers outlined in {#naming} can register these names in a distributed Resource Directory following the same [I-D.amsuess-t2trg-rdlink] style setup. Unlike described there, they would not enter their network address into the distributed directory, but the address of their most remote reverse proxy (the introduction point).¶
This directory propagates changes relatively fast, limited by the performance of the underlying Distributed Hash Table (DHT).¶
Clients looking for services may not need to use the discovery service directly: Instead, they can send requests to a proxy of their chosing, and rely on the proxy to utilize the directory to look up a next hop. (They do need to perform discovery of the introductory node if they want to hide the ciphertext of their conversation from their last proxy and establish a secure connection to the introduction proxy chosen by the server, verifying it using the EAD option described in Appendix D of [I-D.ietf-core-transport-indication] instead of relying on their own last proxy).¶
In order to hide their location, clients as well as servers need to discovery lists of eligible proxies, along with metadata that indicates whether the proxy is willing to proxy to arbitrary locations on the Internet, or merely to hidden peers.¶
That distinction in forwrad proxies would be similar to how Tor distinguishes relay and exit nodes. In reverse proxies, there is an analogous distinction that is not so much based on policy but rather on the structure of the authority component used by that reverse proxy: If the proxy can offer names that are resolvable on regular CoAP stacks (i.e., DNS can resolve it to a global IP address), then regular CoAP clients can use the introduction address as an entry point. The hidden service trusts the user to establish an end-to-end connection: If the client is unauthenticated (i.e., using a plain CCS as its credential), the hidden server can not tell whether the incoming EDHOC session is end-to-end or merely set up by a proxy, let alone whether the client is using a chain of proxies or not. Many proxies may not offer such names, and services may not want to rely on such names anyway -- in that case, clients are required to use (most probably by proxy) the DHT in which services are announced.¶
Maintenance of this list is out of scope of this document, but the produced list will have some properties required for the constrained devices: * For each proxy that is available to form a hiding circuit, the list includes: * the proxy’s cryptographic identity (eg. in a CCS): to authenticate the proxy, * affiliation information (operator and location): this enables hiding nodes to find paths of probably non-colluding proxies * optionally a public IP address: this enables nodes to use the proxy as a first hop * The list is updated regularly, with an update rate measured in hours or a few days. * The list needs to be signed by independent entities. (This is the only place in the whole setup where signatures are required: it appears unrealistic that the maintainers of the network will be online to perform non-signing challenges for the document all the time. Devices that can not even perform that verification might have a trusted source, possibly their firmware update source, that performs the verification for them). * The list’s size will excede the memory capacity of individual devices, so it needs to be split up, possibly in a way similar to a Merkle tree. (At a bare minimum, a Tor sized network of 10k nodes with 32 bytes of key material for each node would already exceed the RAM available to Class 2 devices [RFC7228]). It may be beneficial for long-term stability if the list is structured such that there is always a fragment with long-term stable addresses that nodes can store.¶
TBD: Describe operations of this service in a separate document.¶
The three tasks of proxying, participation in the distributed Resource Directory and participation in the dissemination of the proxy list are conceptually separate. None the less, it is expected that proxies eligible for the list will perform all those roles.¶
Nodes partipating in this network will always keep at least some verified fragments of the list across restarts, and should be provisioned with a current state of the list at setup time. As the proxies also provide the list, devices can obtain the latest version through the first EDHOC connection they establish with a proxy they know from the most recent version the have. For the unlikely event that all stored proxies have become unavailable, nodes may accept recent signed versions of the list through other means.¶
Proxy-to-proxy requests, which are the majority of transmitted request, are transmitted between unconstrained devices across the Internet. As such, protecting those connections with an extra layer of TLS (as specified in [RFC8323]) is desirable, because¶
[ TBD: Explore whether coercing traffic through specific pairs of nodes instead of random node pairings would make sense. If it is dangerous, maybe servers might pair up on their own to ensure that it is hard to monitor their ingress and egress traffic for correlation. ]¶
A challenge in establishing TLS connections on that link is that proxies are advertised with EDHOC credentials in the network’s discovery area. The tools of [I-D.tschofenig-tls-cwt] may help bridging that gap. If that work does not progress, proxies might establish an EDHOC session inside an intially unauthenticated / self-signed TLS session, tying the sessions together by the use of a data item exported from the TLS key material exporter.¶
TBD. Current ideas:¶
TBD. Main points:¶
When using proxy chains, only contact a proxy through the one chain it is set up with, and only accept messages into a context if they were transported in the hop they are expected to be received from.¶
It is of utmost importance to not have observably different behavior between messages with an unknown context and messages whose context is known but not expected at this point. For example, if an attacker controls a server’s introduction point and intends to deanonymize clients, it may attempt to send responses directly to the suspected address of the client.¶
In implementations, this can be mitigated by first looking up the list of contexts depending on the outer layer, and then looking up inside that list whether the security context is known and the message expected.¶
TBD.¶
Since -01:¶
Since -00:¶
TBD.¶