feat: NoPorts policy plane aka delegated authorization (DRAFT, WIP)

[gkc]

- What I did

• Initial implementation of a NoPorts policy plane aka delegated authorization.
• Daemons may talk to another atSign (the policy manager) to ask whether a given client atSign may connect to it.
• closes https://github.com/atsign-foundation/noports/issues/855

- How I did it

• New npa library in noports_core package
• New demo binaries in sshnoports package
• New command-line option for sshnpd : -p or --policy-manager

- How to verify it

• Automated tests should pass
• Manual tests
  • cd /path/to/repo/packages/dart/sshnoports
  • Run ./buildBinaries
  • Run the demo NoPorts policy CLI program, a NoPorts daemon and a NoPorts client like this:

    bin/demo/npa_cli -a "@policy_atsign" --daemon-atsigns "@daemon_atsign[,...]"
    bin/sshnpd -p @policy_atsign -a @daemon_atsign -d devicename -u -s -v
    bin/sshnp -f @client_atsign -d devicename -s ~/.ssh/IDFILE.pub -i ~/.ssh/IDFILE -t @daemon_atsign -h @rv_am
    

[cconstab]

Noticed that some times the policy is approved without the asking of the policy server.
If you approve then immediately run another sshnp it connects and does not ask. Was not sure if that is expected behavoir?

[gkc]

Noticed that some times the policy is approved without the asking of the policy server. If you approve then immediately run another sshnp it connects and does not ask. Was not sure if that is expected behavoir?

@cconstab Yes, intentional. The results of a given policy check are cached for 30 seconds; this is to mitigate dos-style attacks on policy servers

[cconstab]

Another small niggle.. If everything is quiesced then on the first try the sshnp times out before the auth has been answered.

The second attempt works 100% of the time.. See below the first timed out before the request was approved, the second connection worked with the approval that was established (within the 30 seconds)

╭─cconstab@servalan in /bin 
╰$ sshnp -f @cconstab -t @ssh_1 -h @rv_am -d servalan_a -u gkc
2024-04-08 15:11:52.234766 : Sending daemon feature check request
2024-04-08 15:11:52.234812 : Resolving remote username for user session
2024-04-08 15:11:52.234827 : Resolving remote username for tunnel session
2024-04-08 15:11:52.234988 : Fetching host and port from srvd
2024-04-08 15:11:54.345994 : Received host and port from srvd
2024-04-08 15:11:54.346015 : Waiting for daemon feature check response
2024-04-08 15:12:02.235015 : Received daemon feature check response

Error: Ping to servalan_a@ssh_1 timed out after 10 seconds
╭─cconstab@servalan in /bin 
╰$ sshnp -f @cconstab -t @ssh_1 -h @rv_am -d servalan_a -u gkc
2024-04-08 15:12:08.667671 : Sending daemon feature check request
2024-04-08 15:12:08.667715 : Resolving remote username for user session
2024-04-08 15:12:08.667727 : Resolving remote username for tunnel session
2024-04-08 15:12:08.667853 : Fetching host and port from srvd
2024-04-08 15:12:10.305997 : Received host and port from srvd
2024-04-08 15:12:10.306020 : Waiting for daemon feature check response
2024-04-08 15:12:10.584779 : Received daemon feature check response
2024-04-08 15:12:10.585989 : Required daemon features are supported
2024-04-08 15:12:10.609837 : Sending session request to the device daemon
2024-04-08 15:12:10.819001 : Waiting for response from the device daemon
2024-04-08 15:12:11.573998 : Received response from the device daemon
2024-04-08 15:12:11.574095 : Creating connection to socket rendezvous
2024-04-08 15:12:11.684701 : Starting tunnel session
2024-04-08 15:12:12.393373 : Starting user session
Warning: Permanently added '[localhost]:33011' (ED25519) to the list of known hosts.
Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 6.5.0-26-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

Expanded Security Maintenance for Applications is not enabled.

12 updates can be applied immediately.
To see these additional updates run: apt list --upgradable

9 additional security updates can be applied with ESM Apps.
Learn more about enabling ESM Apps service at https://ubuntu.com/esm

*** System restart required ***
Last login: Mon Apr  8 15:12:12 2024 from 127.0.0.1
gkc@servalan:~$ 

[gkc]

@cconstab OK ... will extend the ping timeout to 20 seconds

[gkc]

@cconstab OK ... will extend the ping timeout to 20 seconds

Done.

[gkc]

@cconstab making a note here of what we discussed

• write another demo policy service, this time file-based
• allow clients to specify overall timeouts of up to 40 seconds (for slooooow networks); and clients to request srvd grace periods of up to 60 seconds (currently it's set to 30 in the rvd with no option to set a different max); clients would request an srvd grace period of $clientTimeout + 20
• federated log aggregation will make it easier for users to diagnose issues i.e. rather than getting "Timed out" and just having to make do with that, they could request to view logs from the daemon/device that they were trying to access - log viewing access would also be controlled by policy service
• small optimizations at the daemon side for timeliness e.g. if daemon received an Approval from the policy service for @alice the last time it checked, then it should respond to pings from alice straight away, and then send the policy request to approve or deny new session request; thus once alice makes the actual session request the daemon is likely to have received response from the policy service. Overall this minimizes the policy-checking-related delays which could be perceived by clients
• Something we didn't discuss today but discussed a few days ago - allow policy atSigns to create policy records which are shared with their daemon atSign(s) - then a daemon could either (1) always make rpc to policy server or (2) always do a lookup of a policy record which has been shared by its policy atSign or (3) do a lookup first, then make an rpc, or (4) do an rpc and do a lookup if the rpc times out