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! 💚

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

I wanted to add to this thread that we've settled on the following approach:

If a peer wants to give others a way to connect to it, it creates a random 256-bit passphrase. This passphrase, along with the node ID, is then shared via a trusted channel. When a peer connects, it sends that passphrase as the very first thing, and the first peer verifies that it is correct. Otherwise, it aborts the connection.

Compared to what I suggested above, this does not need a PAKE, as the passphrase is per-peer.

If anyone sees issues with this approach, kindly let us know! :)

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

[baterja]

What's the current state? I'm looking for a safe p2p protocol that will allow me to create a private, mesh-like network of mutual trust (authN & authZ) for sharing files/backups/free space.
Nice to have: no metada leaks before trust is established.

[andrewchen5678]

I am currently using a unique alpn name only known to the client and server as a secret, need to confirm if it is a sound approach or the alpn name can somehow leaked.

Update: gave up that approach

[flub]

The ALPN is (effectively) sent unencrypted by the client and server.

[matheus23]

So to spell it out: No, do not rely on that as a secret! (Someone listening to your UDP packets on the same Wifi or your ISP or whoever can read the ALPN)