Implement downgrading privilege for user principals authenticated over gRPC / HTTP

[tiziano88]

Once the challenge-response mechanism is implemented (as per #1357), the Oak Runtime should then use the result of the authentication step to determine the downgrading privilege of the client connecting to it.

The most elegant way of doing this would be to create a sort of "virtual" node per invocation that has exactly the downgrading privilege corresponding to the provided authenticated client.

For instance:

• client connects over gRPC
• client obtains challenge from Oak Runtime over gRPC
• client signs challenge with its private key
• client sends data to the Application over gRPC
  • data is labelled with an arbitrary label, which is independent of the authentication
  • additionally, the client provides the signed challenge as an extra metadata field, to prove its own identity (and does this for any subsequent invocation over the same connection)
• Runtime receives the request, validates the signed challenge (if any is provided)
• if one is provided and it matches the public key, then it creates a new pseudo-Node dedicated to that invocation, with the privilege to declassify the principal corresponding to the public key of the provided signed challenge (more details are needed here, I'm handwaving for now)

[rbehjati]

In the case of the HttpServerNode this requires replacing the Pipe with the virtual node as follows:

1. After receiving a request from the user, the HttpServerNode creates a channel for communication with the virtual node.

2. The HttpServerNode creates the virtual node, setting its privilege to the user's identity.

3. The HttpServerNode sends a NodeMessage, containing the user's request as the data, the invocation_channel (between the HttpServerNode and the actual server node) as one handle, and an outer_response_writer as another handle.

4. The virtual node creates request_reader and response_writer channels with correct tags as in Set the user's identity as the confidentiality tag in invocation channels for HTTP and gRPC server nodes #1428 (this is currently done inside Pipe):
   

   oak/oak_runtime/src/node/http/mod.rs

   Lines 349 to 354 in a6e6294

   	struct Pipe {
   	request_writer: oak_abi::Handle,
   	request_reader: oak_abi::Handle,
   	response_writer: oak_abi::Handle,
   	response_reader: oak_abi::Handle,
   	}

5. The virtual node send the request over the request_reader channel.

6. The virtual node then bundles the the read-half of the request_reader, and the write half of the response_writer in an invocation and sends that over the invocation_channel to the actual server node.

7. The virtual node waits for receiving the response on the read-half of the response_writer, declassifies it and sends a NodeMessage with the HTTP response, back to the HttpServerNode on the outer_response_writer channel to the HTTP server p-N.

@tiziano88 Does this make sense? This basically doubles the number of channels that we create per request.

[rbehjati]

Actually maybe I can merge steps 2 and 3 above, so the HttpServerNode includes the HttpRequest, the invocation_channel, and the outer_response_writer in the config that it uses for creating the virtual node.

[tiziano88]

Thanks for the writeup @rbehjati , it makes sense to me, we can start with that, and then we may explore ways of trying to unify some of the channels or structs in the future, once we have something up and running.

[tiziano88]

cc @daviddrysdale in case he has any suggestions or comments upfront

[rbehjati]

Thanks. BTW, my second suggestion is not that interesting as it would require adding HttpRequest to the application config protobuf, which does not sound like a nice design. So, I am going with my original suggestion.

[tiziano88]

@rbehjati I believe this is already on your plate, let me know if I am mistaken.

[rbehjati]

Yes. But I think we need to discuss it further :) I'll get back to it when I am done with the first increment of the challenge-response authentication for HTTP and gRPC.

[rbehjati]

This can be closed for now, since the stated functionality is supported via the top privilege in the gRPC and HTTP nodes.