eclipse-hono
Possibility to provide auth-ID pattern as tenant configuration
With introduction of auto-registration feature there's possibility to configure device-id pattern, which is used during device registration process, see: #2664.
I think it would be also helpful to provide similar configuration for auth-id which is created during device registration process and used for device authentication. Currently auth-id for certificate based device authentication completely corresponds to subject-DN of device certificate.
I'll try to explain it with the help of one example:
The client certificates of devices in the field can be renewed and updated. The renewed certificates can contain some changes in subject-DN, e.g. the department name is changed. In such case subject-DN of the client certificate will not be similar to the subject-DN from the old certificate. And when such device will try to connect with a new certificate the authentication will fail as auth-id (subject-DN) registered in Device Registry will not match with auth-id (subject-DN) from the new client certificate.
In such case it would be helpful to provide possibility to configure which parts from Subject-DN should be used for auth-id, which are not affected and changed by certificate renewal and stay stable and unique during the whole lifecycle of the device.
See below examples of possible auth-id patterns:
auth-id-pattern: "{{subject-CN}}" -> only use the subject CN from the device certificate
auth-id-pattern: "{{subject-DN}}" -> use the subject DN from the device certificate
WDYT?
At least in the example, it's more about selecting certain attributes from the subject to be used in the authentication. I wonder if it would be better to specify a list of attributes rather than a pattern. That would be easier to use because not all possible attributes and their order would have to be considered. @alinaserg @sophokles73 WDYT?
@b-abel, for me your proposal sounds reasonable. I don't see anything that speaks against of this approach.
@b-abel I am not sure if I get your point. We are using this approach already for defining the device-id of an auto-provisioned device. FMPOV we should simply use the same mechanism here as well. This should also help with keeping things understandable for users.
I'm thinking about how the authentication mechanism needs to be modified. I think we should keep it as simple as possible.
I understood the following to be only examples of accepted patterns:
auth-id-pattern: "{{subject-CN}}"-> only use the subject CN from the device certificate
auth-id-pattern: "{{subject-DN}}"-> use the subject DN from the device certificate
But if we offer only these two options, this can be mapped well in the authentication process.
I do not see why we wouldn't/shouldn't allow a pattern like
devices-of-{{subject-OU}}
in order to allow for some augmentation with contextual but otherwise static information.
IMHO we should also allow for something like
{{subject-OU}}-{{subject-CN}}
don't you think?
So, I summarize what we want here:
- Define a list of placeholders and document them in the Management API. We start with the following:
- {{subject-CN}}
- {{subject-DN}}
- {{subject-OU}}
- The auth-id pattern is resolved with the values from the device cert during the (auto-)provisioning process.
- During the authentication of a device, the pattern (the Management API calls it template, I think we should keep that) is taken from the tenant stored in the database, the placeholders are replaced with the values from the certificate of the device that tries to authenticate and then checked if the result matches the auth-id from the stored credentials.
Constraints that need to be documented:
- when a new certificate is issued for a device, the values for the used placeholders must be the same that are used during the provisioning.
- the pattern defined for a tenant registration must not be changed, otherwise, the authentication of existing devices will fail.
Currently device-id template configuration supports placeholders namely {{subject-cn}} and {{subject-dn}}. I think it's good to support also another subjectDN's attribute Organizational Unit Name ({{subject-ou}}). We can make the auth-id template in sync with that of the device-id template to support {{subject-cn}}, {{subject-dn}} and {{subject-ou}}.
When supporting OU it also seems very reasonable to support O as well, as OU is usually used to indicate a sub-unit of a larger organization, e.g. O=ACME Inc. and OU=Marketing Dept.
Constraints that need to be documented:
- when a new certificate is issued for a device, the values for the used placeholders must not be the same that are used during the provisioning.
- the pattern defined for a tenant registration must not be changed, otherwise, the authentication of existing devices will fail.
I agree with the latter one. If the template is being changed for an existing trust anchor, then we have no chance of successfully authenticating the devices anymore.
With the former I disagree. FMPOV the opposite is true, i.e. when a new certificate is being issued to the same device, then the values for the place holders actually need to be identical to the values that were used when the device was (auto-)registered. Otherwise the auth-id determined for the device when it authenticates would not match the registered auth-id anymore, would it?
@kaniyan Looks like we had already established the fact that the auth-id template must not be changed after registration.
when a new certificate is being issued to the same device, then the values for the place holders actually need to be identical to the values that were used when the device was (auto-)registered.
Sorry, my bad. That is what I actually wanted to say. I just messed up the sentence to say the exact opposite. I'll fix it.
With the former I disagree. FMPOV the opposite is true, i.e. when a new certificate is being issued to the same device, then the values for the place holders actually need to be identical to the values that were used when the device was (auto-)registered. Otherwise the auth-id determined for the device when it authenticates would not match the registered auth-id anymore, would it?
I disagree too for the first point. The values of the placeholders should remain the same.
@kaniyan Looks like we had already established the fact that the auth-id template must not be changed after registration.
Tried to make it resilent to template modifications. After analysis and considering the changes involved, it seems that we go ahead with the constraint. In future, if it has any practical disadvantages, we can still go back to the analysis that we discussed in #2968.