[Blueprint] Full authentication in Concent API

[cameel]

Currently Golem clients are not authenticated. We identify them based on the public key they declare but there are no safeguards against one client impersonating another. We need to start verifying that the key matches the message.

In send/

• Stop using the Concent-Client-Public-Key and Concent-Other-Party-Public-Key HTTP headers. Instead always take public keys from TaskToCompute. Either from the one included in the message (if this is the first message related to the subtask) or one stored in the database.
  • Always validate that TaskToCompute in a message is identical with the one we have in the database (if we already have it there).
  • Always validate that if a message contains multiple nested instances of TaskToCompute, these instances are identical.
  • Validate that TaskToCompute is itself signed with the keys it contains.

In receive/ and receive-out-of-band/

• Require the client to submit a special authentication message in the body of the request. This message should contain:
  • His public key
  • A timestamp (can be just the normal timestamp of the message)
  • Please submit a pull request to add such a message to golem-messages
• The message must be signed with the key it contains. This the proof that the client indeed has the private part of that key.
• The timestamp must not be too far from the current time. Make sure the time verification is not skipped.
• Use the key instead of the one passed in the Concent-Client-Public-Key HTTP header.

In gatekeeper:

• Stop using the Concent-Client-Public-Key HTTP header.
• Require a HTTP header called Concent-Auth. This header should contain the new authentication message (same as in receive/).
• Ensure that client's public key in the authentication message matches the one embedded in FileTransferToken.

Note that the mechanism for receive is safe only with the assumption that no one can intercept the authentication message in the short time window where the timestamp is acceptable. This may be a problem later when we switch to a P2P protocol. For now we're going to use SSL (HTTPS) so we can assume that messages cannot be easily intercepted.

[cameel]

Update: We can't keep using the current header in gatekeeper. We have to use the authentication message there too.

[rwrzesien]

@cameel

1. Validate that TaskToCompute is itself signed with the keys it contains.

Which key, provider or requestor ? Or it just depends on use case context ?

2. Stop using the Concent-Client-Public-Key and Concent-Other-Party-Public-Key HTTP headers.

But only for authentication, right ? We still need this in request to load golem message.

[cameel]

1. TaskToCompute is always created and signed by the requestor. Please look at integration tests for core. They always sign it with the right key. TaskToCompute is serialized separately from the message containing it because it's a message passed between the requestor and the provider.
2. We don't need these headers now at all. We have the keys inside TaskToCompute instance associated with the Subtask so the headers are redundant.

[cameel]

OK, after talking on Slack I see the problem.

It should be technically possible to decode a message without validating its signature. The only question is whether golem-messages lets us do that in an easy easy way, without copying its intenal implementation. If not, we'll need to request changes.

[rwrzesien]

After analyzing the amount of work which needs to be done to complete this looks like this:

UTILS:

• function for loading message without public key
• function for validating if passed list of TaskToCompute contains identical instances
• function for validating if passed golem message is itself signed with the keys it contains
• function for validating ClientAuthorization message

CORE VIEWS + API_VIEW:

• remove validation of request.META['HTTP_CONCENT_CLIENT_PUBLIC_KEY'] from api_view
• remove loading of golem_message from api_view and handling of related exceptions
• add validation of public keys in task_to_compute in views
• add loading of golem_message and handling of related exceptions in views, separatelly for first message in each use case and messages which come after that
• change handling/storing/quering related with public keys in all use cases

CORE TESTS:

• remove usage of 'HTTP_CONCENT_CLIENT_PUBLIC_KEY' and 'HTTP_CONCENT_OTHER_PARTY_PUBLIC_KEY' from all tests
• make sure public keys are in every TaskToCompute in tests (they should be)
• add ClientAuthorization to every call to receive and receive_out_of_band in tests
• in all auth tests, add TaskToCompute (and usage of it in nested messages that are send in request) with wrong keys
• in all auth tests, add ClientAuthorization with wrong keys to every call to receive and receive_out_of_band in tests

API_VIEW TESTS:

• Rewrite all tests which test usage of 'HTTP_CONCENT_CLIENT_PUBLIC_KEY', as this will now happen in views
• Rewrite all tests which test handling exceptions in loading golem message in api_view, as this will now happen in views

GATEKEEPER:

• remove validation and usage of request.META['HTTP_CONCENT_CLIENT_PUBLIC_KEY'] in views
• add validation of ClientAuthorization message in views (probably the function used in core can be reused)
• add usage of ClientAuthorization message in views

GATEKEEPER TESTS:

• add ClientAuthorization to every request in tests

LOGGING:

• currently we have a lot of generic logging in api_view, which use request.META['HTTP_CONCENT_CLIENT_PUBLIC_KEY'] to log client public key, now it has to be moved into lot of places and get public key in different ways, depending on a context

I will create a separate issues for a group of those points.