here is a list of properties that I think are desirable in a p2p secure channel. It is assumed that peers already know the pubkeys of a server. It may not be possible to support all of these properties in one protocol.
- content is forward secure
- server verifies client identity
- client verifies server identity
- server knows client has verified
- client knows server has verified
- resists replay attack
- resists man-in-the-middle attack
- prevents cold calling/war-dialing (only accept calls from clients that know who server is)
- eavesdropper cannot learn client key
- eavesdropper cannot learn server key
- eavesdropper cannot confirm client key
- eavesdropper cannot confirm server key
- replay attack cannot learn who is authorized
- unauthorized client cannot learn server key.
- unauthorized client cannot confirm server key
- man in the middle cannot learn or confirm client or server keys
how to achieve the above properties
Use diffie-helman style key exchange, an ensure a different key is used every connection.
challenge the remote peer to provide a signature of a nonce.
acknowledge their signed challenge by signing it.
force peer to respond (sign) something you know is unique (nonce) (see 2,3)
verify identities & client must abort connection if response was from unexpected server. Use diffie-helman to exchange keys (or box every message)
client must prove it knows the server's pubkey. This treats the pubkey as a write capability.
one method would be to box the hello to the server's pubkey. Another option, would be to hmac with the server's pubkey.
do not send long term keys as plaintext. It shouldn't be necessary to send the server key at all, given that the client has know business connecting to a server they don't know (see 8, prevent war dialing)
If an eavesdropper happens to know the client or server's key, are they able to know it is those peers talking? This property protects the client's privacy in particular. The server is likely to be a staticly addressed server, so their key is likely to eventually become public knowledge. Although, in a p2p protocol it's likely that the server may also move.
The client on the other hand, is likely to be a mobile device that changes ip addresses. Being able to identify / observe their key would allow you to know track their location.
This property is stronger than 9,10 even if the eavesdropper knows the keys, they are unable to confirm the identity of the peer.
It would be easy for a eavesdropper to record client hellos, and then send them to random servers to see whether that client is authorized on that server. If the server rejects that connection before the client has proven their identity then this leaks information from the server's access list. The server should wait until the client has proved their identity before rejecting a connection.
To realize this property it would be necessary for the client to auth to the server first. This property seems reasonable - "hi this is Alice, is Bob there?" if Bob isn't talking to Alice, or if it's a wrong number the server responds "sorry wrong number" and hangs up. This will require an extra round trip, because a challenge must be issued to the client.
This property would prevent an active attacker from learning who a given server is.
This property is stronger than 14, because 14 means the server shouldn't reveal their key to an unauthorized client, but this property means the server should not give the client evidence incase the client already knows happens to know that key. This means a malicious client cannot get a list of keys (by some other mechanism) and check that those servers really are those keys.
to realize this property it is necessary for the client to authorize to the server first, and for the server to be able to reject the client without revealing any more information.
The client needs asymmetrically encrypt their authorization to the server, such that the server will act the same way whether the client is unauthorized, or just dialed a wrong number (unauthorized server)