EPIC: Node connection requesting access to a private network (Network Entry Bootsrapping)

[amydevs]

Specification

According to #779, there needs to be a way for nodes to bootstrap into a network via obtaining a ClaimNetworkAccess token.

There are 2 RPC calls that should implement this:

1. SignClaimNetworkAccessInitial - An RPC call from a node to a seednode that requests a half-signed ClaimNetworkAccess token to be fully signed by the seednode.
2. SignClaimNetworkAccessFinal - An RPC call from a seednode to a node that contains the fully signed ClaimNetworkAccess token designated to the node.

There is a reason that these 2 calls are separate unary calls rather than a single unary call. That being that in order to implement a CSR-like mechanism for ClaimNetworkAccess token signing, we may want for a human in the loop to manually approve or deny requests for individual nodes to join a network. Hence, we want for the node to receive the token from the seednode whenever the node is online to accept, even after a long response time from the seednode.

When Node A attempts to join a network:

1. Node A sends a SignClaimNetworkAccessInitial call to seed node B.
2. Seed node B may sign or not sign the token based on it's discretion.
3. Seed node B waits until Node A is online and a connection with it is formed.
4. Seed node B sends a SignClaimNetworkAccessFinal call to node A.
5. Node A reads the fully signed token and stores it in it's sigchain.

By implementing this, we have several flows we can end up implementing:

1. This is just the standard accept-all flow. The node is immediately given a Network Access Token upon requesting
2. The await acceptance flow is an example of having a third party service that the seednodes can notify in order to request approvals for network access token requests:
3. We can take advantage of the sigchains on nodes to determine if a node is signed into the user of an external IDP. Since we have 2 separate RPC calls for the requesting and providing of the Network Access Tokens, we can simply embed information in the response of the request call to tell that the client needs to authenticate.
   

Additional context

#779

Tasks

1. ...
2. ...
3. ...

[linear]

ENG-372 Network Node Authentication/Bootstrapping

[tegefaulkes]

I'm going to consolidate this and #780 REF ENG-371 together into this issue. They are two parts of the same problem.

[tegefaulkes]

@amydevs we'll need to go over this to expand it out and tie it into #784 work.

Some notes about the spec so far.

The structure of these claims is being addressed in #779 . so this issue focuses on addressing the logic for issuing the claimNetworkAuthority and the claimNetworkAccess. Issuing both of these should be allowed during the NodeConnection's authenticating stage. Completion of this will depend on the authentication stage update to the nodes domain in #782

So we'll need to update the spec to focus solely on the issuing of these claims and how to authenticate that.

[CMCDragonkai]

This issue seems like it's better suited to be in the PKE repo? If it has information on proprietary details of PKE, it should be in PKE. Plus PK shouldn't be special casing any particular PKE behaviour here.

[tegefaulkes]

This issue focuses on how the nodes interact to request access. PKE only really ties into how we authenticate that request.