search

International-Data-Spaces-Association / omejdn-daps

Open Source implementation of the Dynamic Attribute Provisioning Service based on http://github.com/Fraunhofer-AISEC/omejdn-server
Apache License 2.0
7 stars 10 forks source link

Enhancement: Validation of requesting host before issuing DAT #21

Open tmberthold opened 2 years ago

tmberthold commented 2 years ago

The DAPS issues tokens for which it knows for whom it is issuing the token (e.g. referringConnector claim in DAT). However, there seems to be no check whether the request actually came from the referringConnector /host for which the DAT is issued.

A validation would be useful, so that certificate-sharing among connectors/certificate theft can be avoided/addressed. Alternatively, an additional DAT claim could be added into the issued DAT, which indicates whether the request to the DAPS came from the connector/host for which the DAT was actually issued according to referringConnector (true/false).

Note: beware of the ".demo"-referringConnector entries

bellebaum commented 2 years ago

As it stands, the private keys behind the certificates ARE the device's ID. If certificate sharing is an issue, this solution may not solve it as the DATs and Transport certificates can be shared as well.

I think the ultimate mitigation here would be to provide incentives to not share credentials. Difficulty getting them from a Hardware key store could be one such incentive. Even more effective would be a liability for connector actions that always targeted the company the certificate was issued for. Certification within companies may also require that each connector has its own key.

Now for theft:

The best mitigation here would be some sort of quick revocation. I am aware that this is easier said than implemented. Further mitigations may of course be implemented (in Omejdn for instance you could write a plugin to do this), but I would rather not rely on them alone.

On a more technical level: How would you check "where the request came from"? The URL specified in the claim may at most reference further key material (which is sharable), and resolving it using DNS to check IP addresses seems error prone.

SebastianOpriel commented 2 years ago

To reference here an issue regarding revocation lists: https://github.com/Fraunhofer-AISEC/omejdn-server/issues/48

HeinrichPet commented 2 years ago

Regardless of the problem, why is there a hostname specified in the x509 cert and in the DAT, if nobody would check this attribute and therefore nobody can rely on it?

bellebaum commented 2 years ago

@HeinrichPet The DAPS knows that the value is valid because it has been configured as an Attribute for a specific connector (identified by its private key). The check happens before the configuration, not when retrieving a DAT, and is not performed by the DAPS

HeinrichPet commented 2 years ago

The fact is that on many components the hostname is not valid (apart from the fact that every hostname ends with .demo) because there is currently no validation check during run time. There are many reasons for a wrong hostname: Incorrectly specified when requesting the certificate, deployment is different than originally requested, copied certificates for testing, ... So to really trust the value, it must be checked at runtime. We can of course check it inside the connector. But it is strange that the identity was validated by the DAPS and thus the DAT was issued, only to abort the communication in the connector because the identity of the hostname is wrong.

HeinrichPet commented 2 years ago

On the other hand, you can of course also say that you don't want validation to be active in DAPS so that demo scenarios are easier to set up... Therefore it should be configurable in Connector and DAPS.

schanzen commented 2 years ago

The DAPS should not have to check the configured (!) host name at runtime. This is done already by the CA which is issuing the certificates. The public keys of those certificates are used to authenticate the clients. Validating the host names on runtime is not only error prone (because DNS) but can also be very slow. And even IF the DAPS is automatically validating the certificates (which I think is what you are proposing) the connectors should still validate themselves if necessary because the certificate is only presented to the connector, not to the DAPS.

Yes, the configured values are not actual DNS names. But they are valid host names. I am not sure how those are supposed to be "validated" beyond being present in the certificates. If you mean that you validate by resolving the host (through DNS?) and access an endpoint, you are opening a can or worms that each connector may choose to do, but the DAPS would be severely burdened by this IMO.