Spike on JWT Hardening

[marcgs]

Feature agera-edc/MinimumViableDataspaceFork#116 Upstream https://github.com/eclipse-dataspaceconnector/DataSpaceConnector/issues/1176

Description

JWTs are used in EDC as means to authenticate IDS requests. The current implementation allows for a malicious entity that gets ahold of a JWT to impersonate the original sender, and thus send requests to any other participant. In this spike we want to evaluate different methods to prevent this situation.

• Use the audience claim to identify the JWT target. A JWT token sent to another participant than the one it was initially intended for will be rejected. This prevents from a malicious participant to reuse JWTs sent to him as a producer, to impersonate the signer of that JWT as a consumer himself.
• Evaluate further options to verify that the sender domain matches the one the JWT was originally sent from. This prevents a malicious attacker that gets ahold of a leaked JWT to reuse that JWT as his domain does not match the domain of the original sender. This is a less critical case as the first one, as it involves a previous JWT leak.

Acceptance Criteria

• [x] Evaluate methods mentioned above
• [x] Proposal to EDC team
• [x] Define further steps and write follow-up stories if required

[algattik]

I'm not sure it's worth spending time on sender domain checks until we have a concept for enterprise deployment. Surely EDC will be behind an enterprise gateway.

[marcgs]

I'm not sure it's worth spending time on sender domain checks until we have a concept for enterprise deployment. Surely EDC will be behind an enterprise gateway.

Yes, this is probably the reason as well why no standardized claims exist for this purpose in JWT. We will do a short analysis and document outcomes without investing much time on that one.

[marcgs]

Initial analysis for first solution: currently there seems not to be an appropriate identifier available at both sides (consumer & provider) that is appropriate for using in the audience claim. Probably the best option would be to use the DID of the provider as the audience claim, but this information is not available at the consumer at the moment. We would require to pass this information to the DataManagementApi in a similar manner as we do with "connectorAddress". Using the connector address as identifier seems wrong as it is not meant to be an identifier (it can change). Waiting for Jims and Stefan van der Wiele's inputs as suggested by Paul.

[marcgs]

See follow-up story: https://github.com/agera-edc/MinimumViableDataspace/issues/61

[marcgs]

PR opened in agera-edc branch: https://github.com/agera-edc/DataSpaceConnector/pull/229