Approaches for adding authorization?

[blinry]

Hi! I learned about iroh at FOSDEM, and it might solve a real problem for us: Syncing Automerge documents across different local networks in Ethersync!

My question: What approaches do you recommend for adding authorization – making sure that only certain people can exchange data with you? Applications like dumbpipe seem to use only a NodeTicket as an "authorization token" which you need to know to connect. But depending on the enabled discovery mechanisms, isn't it possible that other people could learn about your public key, and then connect to you?

Two ideas:

• Keep a list of trusted public keys. For each new connection, if the peer is not in that list, don't open streams to it/terminate the connection again. What's impractical about this is that two people who want to connect to each other then first have to exchange their public keys in both directions, preventing a simpler usage where you can just give someone a ticket to connect to you.
• Create a passphrase, and add it to the ticket. When receiving a connection, open a stream, and as the very first thing, verify that both parties know the same passphrase using a PAKE algorithm like this one. If the exchange doesn't succeed, abort the connection. I'm not completely confident about the security properties of a solution like that. But it would only require sharing information in one direction.

I think it might be helpful if you wrote a little guide on this topic, because many people who go beyond a certain prototyping stage might ask themselves similar questions.

And some more specific questions:

• In dumbpipe, does keeping the NodeTicket secret actually prevent other people from connecting to the pipe? Would this also be true when DNS or local discovery would be activated? To me, this seems important to mention in the documentation of discovery mechanisms.
• When accepting a connection from an unknown peer, what can they learn about you? Your supported protocols, I assume?
• In iroh-gossip, can people who don't know a Topic somehow learn about it? In other words, is sharing a ticket containing a topic a good way to form private gossip "groups"? Also here, I'd suggest adding this piece of information to the protocol documentation.

Note: The ticket documentation, which mentions "secret document tickets" has two dead links: https://www.iroh.computer/docs/layers/document and https://www.iroh.computer/docs/api/doc-share. And https://www.dumbpipe.dev has a dead link to https://iroh.computer/docs/layers/connections.

Thanks a ton for working on this awesome project! :)

[dignifiedquire]

• In dumbpipe, does keeping the NodeTicket secret actually prevent other people from connecting to the pipe?

In practice yes. The criticial piece of information is the NodeId to connect to a node, think of it like an IP + port number in a world where everyone has a static ip. Now, because there are many more combinations of a NodeId you can't iterate over them easily, like you can do over port numbers, but I would still recommend not reyling on this for actual authentication.

[dignifiedquire]

When accepting a connection from an unknown peer, what can they learn about you? Your supported protocols, I assume?

Roughly

• your public IP addresses
• your supported ALPNs
• connection timings etc

This is the raw iroh level, each protocol on top of course could share different information, depending on what it does

[dignifiedquire]

What approaches do you recommend for adding authorization

I am currently working on a way to add a generic way for simple authentication that can be wrapped around protcols here: #3157

[blinry]

Thanks for the explanations, and very cool that you're working on an authorization wrapper! I have a couple of follow-up questions, as understanding this correctly seems critical for using a library like this:

Confidentiality of NodeIds

The criticial piece of information is the NodeId to connect to a node, think of it like an IP + port number in a world where everyone has a static ip. Now, because there are many more combinations of a NodeId you can't iterate over them easily, like you can do over port numbers.

• Without knowing the NodeId, is it always impossible to establish a connection to a node (say I'm in the same local network, and know its IP and the ports it's using)? That would be a useful security property.
• Which discovery mechanism allow others to learn about your NodeId? I'm assuming the LocalSwarmDiscovery would broadcast it in the local network? How about DNS discovery, Pkarr and DHT?
• In dumbpipe/sendme, could the people who run the DNS servers that are used for discovery connect to the nodes offering a connection? (Because they would learn the node's NodeId, and that's all that's needed to connect?) My mental model of these services would be that the "infrastructure in the middle" can't intercept my files, only the people I trust. But maybe that's not the promise you're making?

Different approaches for adding authorization

• When feat(iroh)!: allow for limiting incoming connections on the router #3157 lands, we could use the positive-listing approach. Do you see a way around having to do the following dance?
  1. A tells B its NodeID (via side channel)
  2. B tells A its NodeID (via side channel)
  3. A adds B to its positive list
  4. B connects to A
• What do you think of the following approach: Create a passphrase, and add it to a ticket, and share it with B. When receiving a connection, open a stream, and as the very first thing, verify that both parties know the same passphrase using a PAKE algorithm like this one. If the exchange doesn't succeed, abort the connection. I'm not completely confident about the security properties of a solution like that. But it would only require sharing information in one direction.
• In iroh-gossip, can people who don't know a Topic somehow learn about it? In other words, is sharing a ticket containing a topic a good way to form private gossip "groups"? That would be a solution with the nice property of only having to share information in one direction, instead of a back-and-forth for positive-listing a NodeId.

Really thankful for your time answering those questions! 💚

[matheus23]

Without knowing the NodeId, is it always impossible to establish a connection to a node (say I'm in the same local network, and know its IP and the ports it's using)? That would be a useful security property.

You need to know the NodeId to be able to do the TLS handshake that iroh requires to establish a connection, so yes you can rely on that, except you need to be careful not to "leak" the NodeId in that case, which can easily happen if you enable discovery, as you are already suggesting.

Which discovery mechanism allow others to learn about your NodeId? I'm assuming the LocalSwarmDiscovery would broadcast it in the local network? How about DNS discovery, Pkarr and DHT?

Yes, local swarm discovery broadcasts using mdns, DNS discovery will do lookups unencrypted in your network (as DNS is unencrypted), so passive network attackers will be able to find NodeIds. The PkarrPublisher uses HTTPS, so only you and the pkarr relay you're publishing to learns the NodeId. That pkarr relay then makes the NodeIds available over DNS, but they can't be "listed", but once resolved via DNS, leak to passive network attackers. PkarrResolver is like DnsDiscovery, except it uses an HTTPS endpoint on the pkarr relay, thus passive network attackers can't read resolutions (the downside being you're not benefiting from DNS caches). I can't comment on what exactly would leak with DhtDiscovery, I'm unfamiliar with that subsystem.

In dumbpipe/sendme, could the people who run the DNS servers that are used for discovery connect to the nodes offering a connection? (Because they would learn the node's NodeId, and that's all that's needed to connect?) My mental model of these services would be that the "infrastructure in the middle" can't intercept my files, only the people I trust. But maybe that's not the promise you're making?

I can comment on sendme in particular: For one, by default it doesn't use discovery mechanisms and instead relies on passing information about your home relay and direct addresses via the ticket. If you use it with --ticket-type=id, then you'll use discovery, but even in that case, the recipient needs to know the hash of the file you're transferring (which is in the ticket, but not published via discovery), so people who know the NodeId of someone running sendme can connect, but not actually fetch anything that they don't know the hash of.

When #3157 lands, we could use the positive-listing approach. Do you see a way around having to do the following dance?

This is very use-case dependent. In some cases you might tolerate "unauthorized" access up to a certain rate limit, in other cases you might have a third node that coordinates access lists, thus acting like the "side channel", or you might use a delegation scheme such as UCANs or other certificate-based solutions that authorize users without requiring a direct side channel.

What do you think of the following approach: Create a passphrase, and add it to a ticket, and share it with B. When receiving a connection, open a stream, and as the very first thing, verify that both parties know the same passphrase using a PAKE algorithm like this one. If the exchange doesn't succeed, abort the connection. I'm not completely confident about the security properties of a solution like that. But it would only require sharing information in one direction.

That sounds cool, but I'm not sure you need a PAKE for that. Instead, require that someone connecting will need to provide the pin, and depending on the entropy of the pin, either re-roll the pin after a certain amount of failed attempts (you can do this as you're checking the pin online, not offline), or make the pin a secret with sufficient entropy (e.g. at least 16 bytes), so it can't be brute-forced.

Someone who might help answer the dht discovery question would be @rklaehn, and for gossip, that'd be @divagant-martian and @Frando

[gschaffner]

Without knowing the NodeId, is it always impossible to establish a connection to a node (say I'm in the same local network, and know its IP and the ports it's using)? That would be a useful security property.

You need to know the NodeId to be able to do the TLS handshake that iroh requires to establish a connection, so yes you can rely on that, except you need to be careful not to "leak" the NodeId in that case, which can easily happen if you enable discovery, as you are already suggesting.

Would n0 consider adding a built-in ticket kind to provide this property?

For example: consider dumbpipe. IIUC dumbpipe does not currently have an access control mechanism, so a NodeId that is "leaked" to a relay/DHT/etc. can be a security issue as it allows strangers to connect to the service behind dumbpipe listen-tcp. In other words, AFAICT dumbpipe is currently useful for transit (hole-punching, path migration, public-key addressing), but it still requires users to add their own client authentication mechanism on top (e.g. mTLS w/ client certificates distributed out-of-band, a la SSH/WireGuard). However if a dumbpipe listen-tcp ticket included a secret too, it would be impossible for a stranger to connect just by knowing the "leaked" NodeId. Then dumbpipe would no longer require users to do client auth. themselves.

This isn't specific to dumbpipes; it's more generally about iroh connections. I think that something like "construct an Endpoint whose protocols are not accessible to those without the full ticket, including the secret" could be useful/common-enough to justify including it in iroh.

Is this understanding correct? If so, it is possible that some dumbpipe/Endpoint users mistakenly think that their services are only accessible by those that their ticket has been shared with.

[matheus23]

Would n0 consider adding a built-in ticket kind to provide this property?

Yeah I see how having such a ticket type can be useful. That said, anyone can build their own ticket types! There's no need for them to be compatible between e.g. dumbpipe and sendme (or any other applications that people build).
We've specifically moved away from making tickets a core iroh concept. See them more as a design pattern :)

However if a dumbpipe listen-tcp ticket included a secret too, it would be impossible for a stranger to connect just by knowing the "leaked" NodeId. Then dumbpipe would no longer require users to do client auth. themselves.

Is this understanding correct? If so, it is possible that some dumbpipe/Endpoint users mistakenly think that their services are only accessible by those that their ticket has been shared with.

I took a quick peek at the dumbpipe code. It doesn't actually use any discovery mechanisms, so it doesn't leak its NodeId.
There's still a way for the NodeId to leak, but only to an active attacker: The attacker would need to prevent the one incoming connection that is accepted, and replace it with their own connection attempt. This risk is very minimal. That said, personally I think we should just update dumbpipe to contain a small secret in the ticket - agreed (I'll check back with the team about that). This would make its use safe, assuming tickets are transferred safely.

[gschaffner]

I took a quick peek at the dumbpipe code. It doesn't actually use any discovery mechanisms, so it doesn't leak its NodeId.

Does an Endpoint that doesn't use any discovery mechanisms still leak its NodeId to its home relay? The FAQ states:

[Relays] theoretically know that Node ID X talks to Node ID Y

I don't want the compromise of an endpoint's home relay to give an attacker any access to applications. Ideally the worst that a compromised relay could do would be collecting connection metadata and denial of service.

That said, personally I think we should just update dumbpipe to contain a small secret in the ticket - agreed (I'll check back with the team about that). This would make its use safe, assuming tickets are transferred safely.

This sounds great. I'm really looking forward to this—having a reference implementation for this in dumbpipe would be very useful and I'd be pretty happy to borrow it in other code (if the implementation is reasonably portable).

Would n0 consider adding a built-in ticket kind to provide this property?

Yeah I see how having such a ticket type can be useful. That said, anyone can build their own ticket types! There's no need for them to be compatible between e.g. dumbpipe and sendme (or any other applications that people build). We've specifically moved away from making tickets a core iroh concept. See them more as a design pattern :)

Yeah I saw that anyone can build their own ticket types. AFAICT if someone wants to have a ticket type that provides verification that the peer is credentialed, they'd need to implement that verification at the application layer. Even if implementing b"mypakeprotocol/1" would mostly just require selecting a PAKE algorithm & implementation and defining a couple message types to carry it (or basing it on the implementation in dumbpipe, if that implementation is relatively portable), taking that route would create more room for us to write subtle security-critical mistakes than some alternatives, e.g. using TLS 1.3 Client Authentication. Like blinry we're also

not completely confident about the security properties of a solution like that. But it would only require sharing information in one direction.

Thinking out loud: if verifying that the dialing peer has credentials to connect is a common-enough need, then it might make sense to package it upstream rather than reimplement it in each of these places. (For example it seems to be needed in dumbpipe, by blinry for Ethersync, and in a library I work on.) IIUC partial built-in support for verifying that the dialing peer has credentials to connect has already been added upstream (AccessLimit). IIUC AccessLimit is suitable in scenarios where you can do an out-of-band transmission from a client (i.e. connecting) peer to a server (i.e. listening) peer, but it doesn't help when the out-of-band transmission that you can do is in the other direction. For example, dumbpipe/sendme/magic-wormhole/etc. have an out-of-band transmission from the listening peer to the connecting peer, but they would need an out-of-band transmission from the connecting peer to the listening peer in order for the listening peer to use AccessLimit (or any other NodeId-based server-side ACL.) Is that correct?

From the perspective of someone that's very interested and curious about iroh, and also from the perspective of looking into building on iroh and answering "We are using mTLS; what would we replace that with on iroh?": from our PoV, we currently control the TLS handshake and TLS is facilitating three main things: (a) verifying that the dialed peer has credentials (via TLS server authentication), (b) verifying that the dialing peer has credentials (via TLS Client Authentication), and then encryption+integrity of application data. Iroh conveniently solves (a) via public-key addressing¹. It would be convenient if iroh also solved (b). We could run a second layer of TLS on top of iroh's raw public key-based TLS specifically to add TLS Client Authentication, but it seems a bit silly.

Somewhat related, but a bit more niche: with TLS 1.3, clients can ensure that they don't expose their identity (certificate/raw public key) except to their peer (and only after they have verified the peer's identity against a CA/ACL). IIUC with iroh a client's identity is often exposed to hole-punching/addressing infrastructure, if "identity" here means NodeId. A client could use ephemeral NodeIds, but then AFAICT its peers can't use AccessLimit with it unless an out-of-band client-to-server transmission can be done for every fresh ephemeral NodeId. However in a system where listeners authenticate connecters via a secret included in an out-of-band listener-to-connecter transmission, one would get back the property that client identities are hidden to everyone except the intended peer. Is this correct?

That said, personally I think we should just update dumbpipe to contain a small secret in the ticket - agreed (I'll check back with the team about that). This would make its use safe, assuming tickets are transferred safely.

Hmm, I was thinking about the example of sendme as well: should sendme have a secret in the ticket too? My understanding of iroh-blobs is lacking, but AFAICT to download from a sendme send a client needs the NodeId and HashSeq hash (or child hashes). For unique data, the hash(es?) should be uniformly distributed, so if the hash is long enough it should be hard to guess. However, can a peer who knows an interesting HashSeq hash, or an interesting blob hash, (a) determine whether a given NodeId is offering to upload that blob and (b) download that blob from that node? If so, sendme users coming from magic-wormhole or croc (such as me!) are probably not expecting that. IIUC with magic-wormhole and croc the out-of-band server-to-client transmission contains a random secret that is independent of the file contents being transferred, whereas with sendme it seems like there might currently be no random secret: HashSeq is not random (it's deterministic) and could be known to theoretical attackers, and NodeId is (IIUC) shared with relays/DHT/etc.

Something interesting: magic-wormhole and croc are both using PAKEs for the same purpose that dumbpipe is considering using them for. wormhole-rs is an magic-wormhole implementation that has both a TCP forwarding mode (dumbpipe-like) and a file transfer mode (sendme-like, but without content-addressing/bao fanciness).

Thanks very much for your time!

Footnotes

1. Potentially at the cost of human-readable DNS names, but we do not need/use those in this case, nor do e.g. dumbpipe & sendme, because all three of these situations are already designed around having an out-of-band server-to-client transmission sometime prior to the client connecting. ↩

[matheus23]

Sorry this is a lot to respond to. Good ideas overall that I'm positive on. Let me address one point in particular though:

We could run a second layer of TLS on top of iroh's raw public key-based TLS specifically to add TLS Client Authentication, but it seems a bit silly.

We do use TLS client authentication, specifically to verify that a connecting client indeed has the NodeId it claims it has. This is what allows our AccessLimit implementation to work by only verifying that the connecting Connection::remote_node_id is indeed one of the NodeIds on the ACL.

[blinry]

Wanted to send a gentle ping on the above questions, as I'm genuinely curious and interested in Iroh, and considering building on it! :)

If having a short call would be easier to discuss these questions, I'm also open to that!

[tekacs]

On the topic of secrets, could I ask the maybe-dumb question of whether it would be possible for the PkarrPublisher/DnsDiscovery/mDNSDiscovery mechanism to not hold the raw NodeID itself, but e.g. HMAC(secret, NodeID) or even simply a Hash(NodeID), such that it can still be used by a client that knows the NodeID to find that node, but not used by the discovery service to connect to the node?

Simply not leaking the NodeID in cases where the remote side already knows the NodeID and can derive a variant that it's able to use to perform discovery seems like it would go a long way towards making many cases 'impossible to reach by default'. It would be lovely to be able to mostly rely on simply keeping NodeID secret and knowing that the discovery mechanisms can be easily used in a way which won't leak it, which seems like it would relatively simply prevent access by third parties?

[matheus23]

Maybe. We've considered similar ideas for e.g. mdns discovery (to avoid leaking a stable identifier that can be tracked roughly geographically).
My 2 cents about this is that perhaps we shouldn't try to go down the route of secrets-based authorization. Instead, keep the public keys public, use iroh's built-in client authentication and authorize the public key via some third other mechanism. It would be nice if we (as maintainers of iroh) had a clear answer for "which third mechanism" that would be, but so far I feel like it's just a little too usecase-dependent.