Add a way for devices to attest to their generation of "join form" submissions

[ethanjli]

In #12, no mechanism is specified for checking the validity of "join form" submissions - instead, the network administrator must check out-of-band that the information is valid, and that the device operator agrees with the contents of the "join form". It will be much easier and smoother to add devices to the network if some of this can be driven by the operator of the device which is being added to the network.

[ethanjli]

Here are possible approaches for confirming with the device operator (via the device) that they produced the "join form" submission. This allows us to protect against other people trying to impersonate the device operator (specifically making "join form submissions" without coordinating with the device operator), so we can be sure that the "join form" submission actually belongs to the device it says it belongs to. However, it doesn't allow us to confirm who the device operator is or whether they are someone we want on the network. The identity and trustworthiness of the device operator would have to be determined out-of-band anyways.

Run a server on the joining device

If the joining device runs a server, then the network host's server can directly talk to it over a secured, private route from the assigned IPv6 address and and ask it to confirm that the "join form" submission's information is correct.

Challenges:

• The joining device must be configured to open the port for that server, which moves us away from zero-configuration.
• For full security, we'd probably need certificates for the server on the joining device, so that the network host's server can be sure that the IP address it's talking to actually belongs to the device with the right node ID. But maybe we don't need this?

Temporary network and API endpoint on the network host

For every join "join form" submission (which is uniquely identified by a triple of the network ID and the node ID), the network host provisions a unique temporary network for the joining device to join, with the joining device's node ID already whitelisted; then the network announces the network ID as well as the IPv6 address to connect to, which serves an API endpoint available only on that private network. The network host can then monitor the network, and once the joining device has joined, the device accesses the API endpoint to review the "join form" submission and verify that the joining device's operator produced the "join form" submission.

Challenges:

• The network host may need to provision a new API endpoint server on a new port to bind to each new temporary network, which may be an inefficient use of limited system resources; this new API endpoint server could run from another device, not necessarily the machine running the network host. It will have to have an expiration on these resources.

Temporary network on the joining device

The network host's server knows the Node ID of the joining device. If the joining device provisions its own unique temporary network and provides the network ID in the "join form" submission, and whitelists the network host's node ID (which can be extracted from the network ID), then the network host's server can try to join; if it's accepted, then the network host can be sure that the "join form" submission came from someone who operates the joining device (or who can eavesdrop on the list of joined networks on the joining device). So the temporary network's network ID and configuration acts as a proof that the "join form"'s submitter has control over or privileged visibility into the joining device. Afterwards, the joining device's temporary network should be destroyed. There should be a way to ensure that the "join form" submission can't be tampered with - i.e. an attacker leaving the joining device's temporary network unchanged while changing other fields.

This would be vulnerable to an attack where the joining device provisions a new temporary network for the network host to join, and then the attacker gains knowledge of that network ID and makes a "join form" submission using it. This could happen through a few attacks:

• The attacker is able to access the joining device's ZeroTier One REST API and eavesdrop on its networks and network configuration. If the attacker can run software on the joining device this is very easy, because the authtoken.secret is copied to an unprivileged location for Latreutes to run. In this case the attacker could also impersonate the operator of the device or just run Latreutes directly anyways, so we'll still need some out-of-band verification of the authenticity of the submitted information regardless.
• The attacker doesn't have access to the joining device but is able to catch the joining device's "join form" submission and substitute it with a modified submission. If we have secret communication between the joining device and the network host (e.g. through HTTPS) then we should be secure against this.

Temporary network on the network host

As a response to every "join form" submission, the network host provisions a unique temporary network for the joining device to join within n minutes and replies to the "join form" submission with the network ID. If the joining device joins that network within that duration, then the network host takes that as proof that whoever made the "join form" submission also controls the joining device. This is probably the simplest approach, and it's the most similar to device pairing protocols (e.g. a user tries to log in to a mobile messaging app from the desktop, then the desktop asks the user to open a QR code from their phone).

If needed, each temporary network ID can also be given a human-readable heroku-style hostname for someone to join manually, though I don't think this would ever actually be needed.

Attacks:

• If an attacker can make a "join form" submission and then socially engineer an operator of the joining device to join a particular network, then the network's host will trust the malicious "join form" submission. This seems quite unlikely because Latreutes will automate the process of joining the temporary network, so the operator would have to go out of their way to join this other network. Having a human-readable hostname for the temporary network ID could make it easier for an operator to be manipulated, e.g. if they're tricked into typing the wrong domain name for a network to join - so we probably wouldn't want to have human-readable hostnames for these temporary networks.
• If an attacker can make a "join form" submission and then already has access to the ZeroTier One service on the joining device, they can make the device attest to the "join form" submission. In effect they're also an operator of the device, and we have no way to differentiate such an attacker from any other operator; we'd just have to rely on out-of-band communication for the network host to verify the trustworthiness of the person who filled in the "join form" submission, which we need anyways.