Authentication vs. Authorisation of keynodes

[robert-cronin]

We need to separate the authentication and authorisation of the keynodes. Authentication is verifying that and agent is known and trustworthy or in other words that agent A knows agent B and trusts that person B controls keynode B. Authorisation is treated as the separate issue of what to allow the already authorised agent B to do.

One can also think of half opened vs fully opened connections. Here a half opened connection would occur when agent A has 'trusted' agent B but agent B has yet to manually vet agent A. Furthermore, agent B might not even know that agent A has trusted it so it only discovers this when it manually vets (i.e. approves the pub key of) agent A.

We probably don't want authentication to occur through pure peer discovery. What if agent B is malicious, but agent A thinks it's their friend from work? We could solve this issue by giving the agent A user some social proof (e.g. this pubkey that wants to connect with you also owns the twitter/github/facebook handle john-doe). But I think the best thing to do for now is assume that both agents have exchanged pub keys. In this way it's purely a mutual authentication and no sharing can happen unless both agents know the other's pub key already. The handshake is then the way we confirm that the target keynode actually controls the corresponding pubkey (i.e. confirm that they can use the private key to decrypt something)

This doesn't stop agent A from 'pre-sharing' one of it's vaults with agent B. In fact it's probably more efficient from a user-perspective to do it this way. Agent A knows about agent B and shares to B first, then when B verifies A, it doesn't then have to wait for A to approve a vault since its already authorised to pull from that vault.

[CMCDragonkai]

So during our discussion it seems capability model wouldn't really be used. Instead we are using a sort of tinder like algorithm. Both keynodes must trust each other for notifications to be sent to each other. This is important to avoid spam.

But at the same time, please review these resources anyway:

• https://blog.acolyer.org/2016/02/16/capability-myths-demolished/
• https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
• https://en.wikipedia.org/wiki/Proof_of_work

So you understand what's available.

[CMCDragonkai]

Basic sharing should just be done directly through key exchange.

Beyond that, authorization of secrets within the vault really only makes sense with OAuth2.

But the clients of that system would not be PK agents, they would be arbitrary external clients supporting HTTPS/GRPC transports to query a PK agent.

Between PK agents, I'd like to keep it simple and stay with vaults sharing through key exchange.

Only one extra thing might be read/write exchange, we may allow another agent to read a vault, or read/write a vault. That should keep it simple for MVP purposes.

[CMCDragonkai]

Some points of discussion...

Push Authority

1. Keynodes all have unique keypairs
2. For push authority, there is a Source keynode and Target keynode.
3. Target keynode must know the public key of the Source keynode, and must have in its access control list, a entry tuple of push permission, source keynode public key, and unique vault id
4. The unique vault id is identifying a vault that already exists on the source keynode, and may or may not exist on the target keynode. This vault id is directly related to the commit history. This is to ensure that the source keynode can only push a specific vault that it has to the same vault on the target keynode.
5. What is the definition of "same" vault. It is the vault that shares the same linear chain of commit history. How does this translate to a unique commit id, I am not sure.
6. All vaults are started with at least 1 commit. We don't have any empty vaults corresponding to git init, so there is no vault where anything can be pushed there.
7. It also means that push only makes sense from the source keynode that originates the vault with respect to both source and target keynodes. It does not make sense for the target keynode to allow the source keynode to push a vault that it does not have.
8. If the target keynode has a vault that the source keynode doesn't have, the source keynode will need to first get that vault first, before the source keynode can allow it to push that vault. However the ACL entry can be created ahead of time, it just means until the source keynode gets that vault, it cannot push anything.
9. The above only works if the source keynode always the same vault that has an equal or later commit revision history. If the source keynode has an earlier commit revision history, it cannot push. This is more about history management, which requires some more analysis with respect to secret sharing usecases.

[robert-cronin]

I think we also need a vault-id that is static and generated upon vault creation. This is required for push/pull request messages so the source and target can agree on which vault they are talking about regardless of the vault-name which is not guaranteed to be globally unique.

[CMCDragonkai]

Just leaving some links here in case we do something where we can push a commit chain and have that match to some vault.

• https://en.wikipedia.org/wiki/Hash_chain
• https://en.wikipedia.org/wiki/Merkle_tree

[CMCDragonkai]

One issue is that if the target keynode has to know the vault id to create the ACL entry to allow the source keynode to push. How does the target keynode know what vaults are available on the source keynode?

The target keynode can scan the source keynode. But atm, they can only see keynodes that the source keynode has made available to be pulled.

There may be situations where the source keynode doesn't want to allow vaults to be pulled. Thus it is not showing these vaults to be scannable.

Therefore the target keynode won't know what vaults to be allow being pushed to itself.

It seems like the source keynode will have to initiate a request. Almost a sort of "push request". Indicating to the target keynode that this is a vault they would like to push to the target. Then the target keynode can create the entry to allow this or not.

Unless you couple pushing to pulling. So source keynode indicates that these vaults are allowed to be pulled by the target. Then the target scans the source and allows the source to push a specific vault.

But this then prevents the possibility of pushing without allowing the target to pull.

In normal git situations, this is not a problem, since the source knows what it wants to push. And the push permission is global. On Github, once you add a pub key in, the source can push anything to anywhere the pub key has access to. Here it's a bit different. Since the permission to push has to be created with a specific vault id, so that the target keynode can control what is allowed to be pushed (and it doesn't even have the vault at the beginning).

It seems that when the target keynode becomes aware of the source keynode. They can elect to start communicating. Then it is possible for the source keynode to create a push request.

Alternatively, the source keynode is what is configuring the target keynode. So a out-of-band channel is being used to communicate the vault id. Like if source owner talks to target owner, and says I want to push this secret to you. The secret is called "X-vault-id". Swap the people with a configuring system like Matrix OS. And it's like creating a hierarchy of keynodes.

I think one of the issues is that the communication between keynodes are staged. There is the process of discovering pubkeys and IP mappings, this can be done through ping (active discovery, broadcast/multicast) and listen (passive discovery). But then there's the second stage of allowing communication, this is the symmetric add-as-friend sort of thing. Both keynodes must allow comms for comms to occur. This then allows messages like scan (look for pullable vaults and pushable vaults and pullable & pushable vaults) to occur (this is a cached information). Both sides is able to make edits to their ACL.

I think one thing we need to find out. Is that if you can push to a git repository, does that necessarily mean you must be able to pull from a git repository? I'm just thinking that way git pushes, is that there is a communication about the state of the pushed repository? If that is true, then we might as well say that if source can push to target, that necessarily means target can pull from source. If we do this, this solves the problem easily and that means, as long as target can edit the ACL to enable pullable vaults, then these are scannable, and then the target keynode can add these entries with push permission.

I still think from a users perspective. There are situations where I want to be able to push a secret vault, but not allow the target to pull the secret vault. This allows me to dictate when secrets are shared. It also allows me to share only once, and then later change the secret in the secret vault.

Here's a possibility. When editing the ACL, one might enable from the source side, the ability to push to a target keynode. This enables these vaults to be scanned (but instead of being pullable, these are the vaults it is advertising to push). The source keynode still has to make the decision to add its entry. This ensures that there is potential for spam. One can only allow inquiries, but never force the target keynode to make actions.

This is interesting because then the ACL entries is more than just the list of things other keynodes can do to the current keynode. But also the list of things we want to be able to do to the other keynode. And advertising that. But the advertising must rely on the target keynode performing a scan operation.

Scanning can be one way. So going from simply discovery active/passive stage to communication stage is actually 1 way. If the ACL has no entries related to the scanning keynode, the scanned keynode will not answer the request. It will blackhole it. The cost of sending the request has to be higher than the cost of checking whether to answer the request. This builtin cost will disadvantage spam. Simply adding an entry means that it can answer scan requests. Note that answering scan requests can be put into a queue that is event-driven as well. We need to also prevent priority inversion here between higher priority requests and lower priority requests. So handling these events means putting into a priority queue. https://stackoverflow.com/questions/26114749/assign-priority-to-nodejs-tasks-in-a-event-loop

Note that allowing a push is actually multi stage thing:

1. The pub key must match
2. The vault id must match
3. The push permission must be true
4. The commit history must be compatible

[CMCDragonkai]

I'm also realizing we are creating a system that uses asymmetric cryptography but also ACLs, but it's "communicating" ACLs. It doesn't seem to fit the capability paradigm at all here.

[robert-cronin]

Closing on account of migration to gitlab