Raw Public Key for client authorization

[boaks]

@sophokles73

Some months ago I received that sequence diagram for a "raw public key" client authentication.

In the meantime I got aware, that to use the credentials service, it's required to get the credentials client related to a tenant. So the call 2.2 "Credentials Service Get", which returns in 2.3 the "credentials with device and tenant id", would already require the "tenant id" ahead.

So, what was the intention to determine that tenant id?

[sophokles73]

I have no clue (yet). We are facing a similar issue with devices using an X.509 certificate for authenticating. However, for those, we are able to determine the tenant by means of using the certificate's issuer DN to look up the tenant. However, with an RPK there is no issuer DN :-(
So, options are limited, I guess. The device could indicate the tenant it belongs to by means of SNI in the DTLS handshake ...

[boaks]

So I think, postpone that RPK support will currently be the best choice :-).

FMPOV, there is a difference between "auth_id" scoped for tenants, and "public key id", which are intended to be "natural global unique" (or the crypto-security would be broken anyway). With such "natural global unique id's", hono would require to have also a "global unique credentials service". But that would be a more future story.

[sophokles73]

hono would require to have also a "global unique credentials service"

Which would probably make sense for certain types of credentials (as you correctly pointed out). I would rather not close this issue yet but keep it as a reminder of the lack of support we have for this.

[boaks]

May be, a LWM2M like solution could be used:

1. accept handshake with RPK
2. use PUT /telemetry/${tenantId}/${deviceId} or /event/${tenantId}/${deviceId}
3. validate that the provided ${tenantId}/${deviceId} is configured to use the received public key.

[sophokles73]

That would be quite similar to what we are doing for X.509 (except, of course, for checking signatures).
I like the idea :-) When a device uses RPK and tries to use a POST to just telemetry or event we would then return a 403. right?

[boaks]

That would be quite similar to what we are doing for X.509 (except, of course, for checking signatures).

That's only true for TLS x.509, for the DTLS x.509 implementation the client certificate is validated during the handshake. The DNs are used to identify the tenant and device and though the scandium threads are independent form vert.x, they don't block the vert.x processing.

POST to just telemetry or event we would then return a 403. right?

FMPOV, POST will always fail, because "/telemetry/${tenantId}/${deviceId}" is only defined for PUT.
Or do I misinterpret something?

Though "/telemetry/${tenantId}/${deviceId}" is not defined for POST at all, this would either cause 4.00, 4.04, or 4.05. I'm not sure if 4.03 would be the right for POST.

For PUT, I would also guess, that only a mismatching public key would return 4.03. But currently, I don't think, defining the return code makes too much sense. Especially, when the case cause multiple violations, it may be hard to define the returned error code ahead of the real implementations.

[sophokles73]

FMPOV, POST will always fail, because "/telemetry/${tenantId}/${deviceId}" is only defined for PUT.
Or do I misinterpret something?

The HTTP adapter allows POSTing to just /telemetry, i.e. without putting the tenant and device ID into the URI. This, however, is only allowed for authenticated devices because we can then determine the tenant and device ID as part of the authentication.

[boaks]

OK, your right, 4.03