Internet-Draft Onion CoAP July 2023
Amsüss, et al. Expires 5 January 2024 [Page]
Workgroup:
t2trg
Internet-Draft:
draft-amsuess-t2trg-onion-coap-01
Published:
Intended Status:
Experimental
Expires:
Authors:
C. Amsüss
M. Tiloca
RISE AB
R. Höglund
RISE AB

Using onion routing with CoAP

Abstract

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.

Discussion Venues

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 (t2trg@irtf.org), 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.

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.

1. Introduction

[ See also abstract. ]

1.1. Components overview

This document introduces separate mechanisms that in combination enable setups similar to how Tor is used for anonymous web access. Some of the mechanisms need no new protocol components, but merely describe which existing steps are used to obtain the desired results.

  • A client can use EDHOC to establish a unilaterally authenticated OSCORE context with proxies (see Section 3.1).
  • A server can use EDHOC to establish a unilaterally authenticated OSCORE context to establish a reverse proxy address (see Section 3.2).
  • A discovery mechanism for proxies (see Section 3.3).
  • A naming and discovery mechanism for hidden services (see Section 3.4).

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.

P1 P2 Client 1 -> P3 P4 P5 Server 1 (published as server addr.) P6 P7 Client 2 P1 P2 P3 P4 P5 Server P6 P7 (published as server addr.)
Figure 1: Example topology of an onion style CoAP network showing two routes in separate graphs. Note that the hop P4-->P2 is present in both chains, and can be pooled into one TLS connection

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. Mechanisms

3.1. Client proxy chain

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:

  • Can EDHOC be run without transmitting two public keys (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.

3.1.1. Guidance for setting up proxy chains

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.

3.2. Server 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.

3.3. Proxy discovery

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.

Both proxies’ discovery process may need to be augmented 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 forwrd 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 name is 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. It is still up to the hidden server’s policy to decide whether to allow access that is merely protected by the chain of hidden proxies, but not end-to-end. Note that the server will be unable to tell whether the client used just one layer of EDHOC and OSCORE to reach the introduction point, or has built its own client chain -- the former is merely a client proxy chain of zero length.

Along with discovering the addresses of proxies, a well-maintained Tor-like network would provide authentication information for them. This would allow participants to trust that the proxy chain they are building is not all controlled by a single entity, but have been around independently for some time.

TBD: Such a service is not specified yet.

3.4. Naming and name resolution

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 [I-D.ietf-core-transport-indication]). 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).

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. TBD: The benefits of this layer are yet unclear, as is whether this needs to be a layer of OSCORE, or whether the mechanisms of [I-D.selander-lake-authz] could be used to roll that into the end-to-end establishment. (Likely, an extra layer is needed, for even if that mechanism is used for some kind of encrypted origin indication, the later OSOCRE phase will need some origin indication at the introduction point to distinguish multiple hidden services behind the introduction point in such a way that an observer of the introduction’s ingress point can not tell which services are being used).

3.5. Establishing TLS connections between proxies

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

  • it profits from TCP's flow control,
  • it hides more request metadata (even though none of the metadata visible at this point should be linkable to the server or the client, with the exception of message length), and
  • it allows requests to be mixed across MTU and thus to hide their length and number (provided there is sufficient traffic on the link to ensure that multiple messages are processed within one Nagle interval).

[ 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.

3.6. Other tricks

TBD. Current ideas:

  • For increased privacy, it may make sense to spool requests and responses in proxies for "as long as practical". Those setting up the proxy may indicate that in the security context. While it increases the proxy's memory requirements a lot to keep several seconds of traffic around, it is not expected that these proxies will be operating at network capacity limits.
  • Add chatter between proxies. With the stark contrast between constrained device bandwidths and Internet bandwidths, this can be tolerable.
  • Access point assistance: While all of this is aimed at constrained devices as defined in [RFC7228], devices of Class 1 may not be capable of using the full proxy discovery service or setting up security contexts with all the hops in the chain. Instead, they may only provide end-to-end encryption, and use a service provided by a local node (e.g. the border router in a 6LoWPAN network [RFC8138]) to set up the hops. Such a setup can also be used to defer policy decisions to the network, which may decide to advertise its own address as an introduction point, or use a suitable length of reverse proxies.
  • The introduction point would be the only suitable location to place a caching proxy when [I-D.amsuess-core-cachable-oscore] is used. As the server is be aware that cacheable OSCORE is used, it can select a reverse proxy that was advertised with caching capabilities (with that metadatum still TBD).

3.7. Overhead and optimizations

TBD. Main points:

  • Establishing a default Uri-Host likely gives most savings.
  • For intermediate hops, using a shorter AEAD tag might be an option.

4. Security Considerations

  • 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.

  • What are the effects of sequence numbers on correlation? Is it good or bad to use the same sequence number for all hops in a chain?

6. References

6.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

6.2. Informative References

[I-D.amsuess-core-cachable-oscore]
Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Progress, Internet-Draft, draft-amsuess-core-cachable-oscore-06, , <https://datatracker.ietf.org/doc/html/draft-amsuess-core-cachable-oscore-06>.
[I-D.amsuess-core-resource-directory-extensions]
Amsüss, C., "CoRE Resource Directory Extensions", Work in Progress, Internet-Draft, draft-amsuess-core-resource-directory-extensions-08, , <https://datatracker.ietf.org/doc/html/draft-amsuess-core-resource-directory-extensions-08>.
Amsüss, C., "rdlink: Robust distributed links to constrained devices", Work in Progress, Internet-Draft, draft-amsuess-t2trg-rdlink-01, , <https://datatracker.ietf.org/doc/html/draft-amsuess-t2trg-rdlink-01>.
[I-D.ietf-core-oscore-edhoc]
Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and G. Selander, "Using EDHOC with CoAP and OSCORE", Work in Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-edhoc-07>.
[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-18, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-groupcomm-18>.
[I-D.ietf-core-transport-indication]
Amsüss, C., "CoAP Protocol Indication", Work in Progress, Internet-Draft, draft-ietf-core-transport-indication-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-transport-indication-02>.
[I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-19>.
[I-D.selander-lake-authz]
Selander, G., Mattsson, J. P., Vučinić, M., Richardson, M., and A. Schellenbaum, "Lightweight Authorization for EDHOC", Work in Progress, Internet-Draft, draft-selander-lake-authz-02, , <https://datatracker.ietf.org/doc/html/draft-selander-lake-authz-02>.
[I-D.tiloca-core-oscore-capable-proxies]
Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work in Progress, Internet-Draft, draft-tiloca-core-oscore-capable-proxies-06, , <https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-capable-proxies-06>.
[I-D.tiloca-core-oscore-capable-proxies-06]
Tiloca, M. and R. Höglund, "OSCORE-capable Proxies", Work in Progress, Internet-Draft, draft-tiloca-core-oscore-capable-proxies-06, , <https://datatracker.ietf.org/doc/html/draft-tiloca-core-oscore-capable-proxies-06>.
[I-D.tschofenig-tls-cwt]
Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-tschofenig-tls-cwt-02, , <https://datatracker.ietf.org/doc/html/draft-tschofenig-tls-cwt-02>.
[RFC7228]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, , <https://www.rfc-editor.org/rfc/rfc7228>.
[RFC8138]
Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, , <https://www.rfc-editor.org/rfc/rfc8138>.
[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, , <https://www.rfc-editor.org/rfc/rfc8323>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/rfc/rfc8392>.

Appendix A. Change log

Since -00:

  • Shaped into separate sections on the bits and pieces involved.
  • Added illustrations.
  • Moved all points from the previous notes in with the new text.

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.

Authors' Addresses

Christian Amsüss
Austria
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Kista
Sweden
Rikard Höglund
RISE AB
Isafjordsgatan 22
SE-16440 Kista
Sweden