Pre-Shared Keys #4461
|
I am wondering how to best implement "private networks" and found #983. The issue is closed, but without an implementation, as far as I can see. There are some related comments in #981 but I do not really understand these as an outsider. I found https://github.com/rustonbsd/iroh-auth which also indicates that PSKs are not supported in Is this something you will consider adding to |
Replies: 2 comments 1 reply
|
Afaik, Noise and TLS 1,3 symmetric PSKs would usually be for forward secure ratchet continuity, like a connection restart, usually PSKs improve security of the initial messages where the handshake would've weaker security otherwise. I'd assume PSKs would always be changing based upon the relationship between the nodes, but never really seen them used outside of the ratchets in e2ee messangers, and maybe they are allowed to just be some secret long-term constant in handshakes. Any good handshake like Noise or TLS 1.3 should've long-term authentication keys from one or both sides, in addition to the ephemeral keys the hashshake makes itself. You'll want control over those long-term authentication keys, not the PSK. |
|
That issue is about a really old version of iroh that doesn't exist anymore. |
That issue is about a really old version of iroh that doesn't exist anymore.
Our recommendation is to build authorization on top of authenticated iroh connections, similar to iroh-auth, and similar to how it works when you use e.g. HTTPS Auth headers.
In your private network use case that would mean you have some sort way of checking private network membership on every node.
When someone connects to your endpoint on your node, you handshake, and then in the endpoint hook you check for the private network membership. If it fails, you close the connection.