docs: State security considerations for ID tokens and security tokens #53
Conversation
|
Refactoring the binding documents in a way that common sections are extracted into a separate document could be a nice idea, I agree. Has this been discussed in some Thursday round? Maybe it's not that urgent right now, but depending on how much we want to elaborate on the documents, this could simplify maintenance. |
|
We should reiterate this text to clarify if those things are normative or not. Please rediscuss in one of the next calls @milux |
|
Let's have a dedicated file/section with security considerations, that sum up the aspects shortly. We can reference from the sections to this new one and use it to link other resources, like the Best Practices (see #104 ) |
Done. Please review this and let me know if it is consistent with what we agreed to in discussion last week. |
| A catalog service may require authorization. If the catalog service requires authorization, requests must include an HTTP `Authorization` header with a token. The contents of | ||
| the token are undefined by may be an OAUTH2, Web DID, or other access token type. | ||
| A catalog service may require authorization. If the catalog service requires authorization, requests must include an HTTP `Authorization` header with a token. | ||
| In that case, security considerations mentioned in section [Security](../model/security.md) apply further. |
There was a problem hiding this comment.
We need to be careful about normative requirements. Apply further is vague.
There was a problem hiding this comment.
Yes, it's vague, not explicitly normative. But since the whole section referenced there declares its content non-normative, this requirement is transitively non-normative, regardless of the wording.
| as [OAuth2 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-06) or [did:web](https://w3c-ccg.github.io/did-method-web/). | ||
| catalog binding specification. | ||
|
|
||
| This specification does not define the contents of security tokens, though security considerations mentioned in section [Security](../model/security.md) apply. |
There was a problem hiding this comment.
Ditto about normative requirements
There was a problem hiding this comment.
Ditto about what I said above.
| - An `Identity Provider` is a trust anchor that generates `ID tokens` used to verify the identity of a `Participant Agent`. Multiple identity providers may operate in | ||
| a dataspace. The identity standard used by a provider is not defined but could be, for example, _OAuth2_ or _Decentralized Identifiers using did:web_. An identity provider may be a third-party | ||
| or a participant itself (for example, in the case of decentralized identifiers). | ||
| It is the responsibility of adopters of this standard to consider security threats like session hijacking. Protection can be accomplished by means like binding of |
There was a problem hiding this comment.
Do we need to say this in a specification? Perhaps the RAM is a better place.
There was a problem hiding this comment.
That should not be there, since it's contained in the security section.
| Session Hijacking describes an attack where stolen or leaked session credentials, i.e. tokens, are used by possibly malicious actors that were not supposed to use them. | ||
|
|
||
| Protection against session hijacking can be accomplished by means like binding of tokens to public keys of their holder, used by transport protocol encryption. In the case of TLS-protected transports like HTTPS, this could be achieved through inclusion of certificate fingerprints, belonging to certificates used by the owner of the token, into the signed token. | ||
| Means like inclusion of the correct receiver(s) into token could also be an option, but may only partially mitigate the issue. |
There was a problem hiding this comment.
I'm not sure this is the correct place for this as there is no linkage to normative requirements. It may be better to put in in the RAM or supporting document
There was a problem hiding this comment.
If this is so, then mentions of (equally non-normative) Authorization aspects should also be moved to the RAM altogether and not be part of the specification.
We already discussed that last week, which led to the new section. The non-normativity is intended.
There was a problem hiding this comment.
+1 to remove the other authorization aspects and just assert that it is defined by other specifications.
There was a problem hiding this comment.
Applies for the ID tokens as well, btw... no further mention except their existence.
|
OK, we agreed that this aspects will go to the RAM and implementation examples like OAuth2, did:web etc. should be removed from the spec. A separate cleanup PR will be created for this. |
|
As agreed in a discussion in our weekly call today this discussion is better suited for the RAM as it's related to solution implementation decisions and thus better suited to be discussed in the Reference Architecture. |
I agree with most of this except for the need for "Management Systems Standards" if that entails defining an API to manage the operations of "connectors" (or broadly, "participant agent systems"). IMO this is too implementation and deployment-specific. We should also be careful to limit what we attempt to standardize until we have sufficient implementation experience. |
|
I totally agree that the protocol should not impose an implementation of any identity or remote attestation scheme. However, I am convinced that we should at least mention these procedures and integrate a modular "placeholder" for authentication and remote attestation. Since TEEs are gaining traction (e.g., EDC in SGX deployments start to happen), it would be useful to have an additional state machine that supports these modes of attestation. What do you think? |
|
The attestation would be a private detail of the implementation of an Enclave based Connector and not a core functionality of the Dataspace Protocol. Therefore it should be specified in the design document for the implementation but not in here. Also, as a side note: I do not think that building the entire connector as an enclave is a good design. What should be an enclave is the data plane. The control plane is a public endpoint. Only a data plane should be a (semi-) private endpoint with protection in an enclave. The attestation state machine would then be part of the design of the enclave based data plane. This would not change the dataspace protocol for the data transfer. Ensuring that an enclave data plane is instantiated and checking its attestation would be part of the provisioning service which needs to check for the attributes of the data plane anyways. an attestation would simply be another policy for a data plane. |
|
Thanks for getting back to me. The contracts will need to support these concepts in the long run, anyway. |
|
As it's possible to encrypt keys or config information in a way that it can only be decrypted by the data plane I see absolutely no need to run the control plane in an enclave. Setting up the exchange of encrypted information between the data sender and the receiving data plane would be part of the data plane design as it would happen after the provisioning of the data plane. |
As mentioned in #52, this PR tries to introduce necessary security advice for safe use of ID tokens and security tokens.
I tried to be as open and generic as possible, whilst providing high-level binding-specific hints for HTTPS.
Realized, though, that there is a lot of duplication across all the binding docs.
@juliapampus Should common sections for the HTTPS binding be refactored into one common document? WDYT?