[#2825] Make use of auth-id template to get credentials

[kaniyan]

While working on extending Credentials Management implementations to generate auth-id (if auth-id template is available) from subject DN and store it, I came across a severe drawback in that approach. What if the auth-id template has been changed after device/credentials registration or removed? In that case, with the current approach, we won't get any credentials as no auth-id will match. To overcome this, I believe that we should always store the subject DN as the auth-id as we did before. During get credentials operation, we can apply the auth-id template to the subject DN and then filter based on the template. This approach is resilient to such auth-id template modifications.

@sophokles73 WDYT?

[sophokles73]

@kaniyan I agree that we need to consider how to deal with changing templates. However, I am not sure if the change you propose will work for the original use case that we had in mind, i.e. resilience against an updated client certificate that contains a changed subject DN. My understanding is that when a device tries to authenticate using a client certificate we

1. determine the device's tenant by means of a lookup of the trust anchor using the certificate's issuer DN
2. check if the trust anchor defines an auth-id template
3. apply the auth-id template to the certificate's subject DN, if applicable
4. look up the credentials using the computed auth-id

So, if the client certificate's subject DN changes over time, we would no longer be able to find the credentials if we kept the original subject DN as the auth-id on record, would we?

[kaniyan]

So, if the client certificate's subject DN changes over time, we would no longer be able to find the credentials if we kept the original subject DN as the auth-id on record, would we?

The auth-id is generated by applying the auth-id template to the subject DN. Hence the generated auth-id (placeholders part) is always subset of the original subject DN. Hence it doesn't matter if we store the subject DN or the generated auth-id. We need to slightly change the logic of how we find the credentials as in the draft (CredentialsServiceImpl).

1. first get the credentials for the device (instead of looking up by auth-id).
2. for the x509-cert credentials, apply the template and generate the auth-id, if applicable
3. filter credentials by comparing the generated auth-id with that of the one from the find credentials request.

[sophokles73]

first get the credentials for the device (instead of looking up by auth-id).

How do we do that if we do not have the device ID?
One of the reasons why we look up the credentials is that we need to resolve the device ID based on the auth-id and type of credentials ...
Or am I missing something here?

[kaniyan]

first get the credentials for the device (instead of looking up by auth-id).

How do we do that if we do not have the device ID? One of the reasons why we look up the credentials is that we need to resolve the device ID based on the auth-id and type of credentials ... Or am I missing something here?

Yes you are right that we don't have device-id to filter all the credentials belonging to a particular device. My bad that I assumed it is there. The other way would be to compare the template placeholders value with that of the subject DN stored in the auth-id to filter credentials. It is relatively easier to implement in MongoDb registry. Whereas in case of JDBC the queries are already defined statically in a file and not that easy to frame dynamic queries with the current setup. Also we cannot ensure that all JDBC databases support such features or easier to implement. Such pattern searching can impact the performance of the query thereby the authentication time of devices might increase (if not cached). I don't see any other way to overcome template modifications. It seems to me that we go back to our first approach with the constraint that it is not resilient to template modifications.

[sophokles73]

The other way would be to compare the template placeholders value with that of the subject DN stored in the auth-id to filter credentials.

Can you elaborate how this is supposed to work? Maybe you can use an example client cert and an example auth-id template to illustrate your idea?

[kaniyan]

Can you elaborate how this is supposed to work? Maybe you can use an example client cert and an example auth-id template to illustrate your idea?

Let us assume that the template is {{subject-cn}}-{{subject-ou}}-{{subject-o}} and the auth-id is stored as OU=Hono,O=Eclipse,CN=Device1,UID=111. During authentication, lets say that a device authenticates using a client certificate with subject DN OU=Hono,O=Eclipse,CN=Device1,UID=222. We can still match the credentials by verfiying if the auth-id has OU as Hono, CN as Device1 and UID as 111 O as Eclipse.

MongoDB example:
db.getCollection('credentials').find({"credentials.auth-id": {$regex: "(?=.*CN\=Device1.*)(?=.*OU\=Hono.*)(?=.*O\=Eclipse.*)"}})

Postgres example:
FROM device_credentials WHERE auth_id ~* '(?=.*CN\=Device1.*)(?=.*OU\=Hono.*)(?=.*O\=Eclipse.*)'

[kaniyan]

It seems to me that we go back to our first approach with the constraint that it is not resilient to template modifications.

Even the first approach cannot be implemented as it is, which is computing the auth-id by applying template and store them. If the update credentials request has certificate, we can retrieve the issuer DN to find the corresponding template. If the request has only subject DN then we cannot retrieve the template as the issuer DN is not available. We need to extend the credential management spec additionally to provide issuer DN too. Else the user should provide the final auth-id to be used for authentication and the device registry won't generate auth-id based on the defined template.

[sophokles73]

In your example, what do we store as the auth-id property's value in the credentials? The client certificate's unaltered subject DN or the result of applying the auth-id template to the client certificate's subject DN?

[kaniyan]

In your example, what do we store as the auth-id property's value in the credentials? The client certificate's unaltered subject DN or the result of applying the auth-id template to the client certificate's subject DN?

We store the client certificate's unaltered subject DN as the auth-id property's value.

[kaniyan]

In your example, what do we store as the auth-id property's value in the credentials? The client certificate's unaltered subject DN or the result of applying the auth-id template to the client certificate's subject DN?

We store the client certificate's unaltered subject DN as the auth-id property's value.

@sophokles73 WDYT?

[sophokles73]

If the update credentials request has certificate, we can retrieve the issuer DN to find the corresponding template. If the request has only subject DN then we cannot retrieve the template as the issuer DN is not available. We need to extend the credential management spec additionally to provide issuer DN too. Else the user should provide the final auth-id to be used for authentication and the device registry won't generate auth-id based on the defined template.

I am in favor of the former option, i.e. adding an optional issuer-dn. With the latter option, I am 100% sure that users will not be able to produce the correct auth-id based on the template.

[kaniyan]

Closed in favor of #2985.