I want, that a server can be sure, that an IoT device is really the genuine IoT device, and not an imposter, when starting a session. The IoT device allows to select any server. Therefore, username/password cannot be secret. If they are not secret, they cannot guarantee authenticity. What other options are there? I came across:
1. Client side certificate (has a secret part, that is only on the IoT device)
2. PGP (has a secret key, that is only on the IoT device)
PGP seems to very heavy, and there is no need to sign every stanza. Therefore I lean towards client side certs. Any drawbacks? Better ideas? Esp. from the IoT gurus (flow, MattJ), but of course every help is welcome :-)
MattJ
debacle, taking XMPP out of the equation, this is a hard/impossible problem to solve (depending on the requirements)
debacle
MattJ, wouldn't TLS client certs do that?
MattJ
Only if the device connects directly to you, but you said it can use any server
MattJ
And even if the TLS is directly to you, the "secret" part on the device is not secret if you're handing it over to users
MattJ
See: every attempt at DRM ever
debacle
MattJ, the authenticity must be guaranteed only in respect to the server, that is directly connected, btw.
MattJ
Client certificates are the best way to do this, then, probably
MattJ
Just don't count on the private certificate(s) not being extracted
debacle
MattJ, I'm fine with the limitation that physical access brings.
MattJ
and the server is a standard server? or what?
debacle
MattJ, of course PGP etc. have the same problem. And we don't have any crypto chips on the device.
MattJ
Yes, that's why I started with a "taking XMPP out of the equation" - this applies to any method
debacle
It's an embedded device, which you and I can "root" in seconds.
MattJ
Then there is no way to keep a secret secret
MattJ
so someone can copy the private key to their laptop and do TLS pretending to be the device
debacle
Just to be sure not to forget any option: Any other idea than PGP and TLS client certs? (With the same limitations accepted, of course.)
MattJ
If you're fine with that, I'm fine with that - I still think TLS is the best you can do here
MattJ
TLS is designed for this (verifying identity), and it's already fairly well supported in XMPP software
debacle
Good! Maybe a later hardware revision will have a crypto something included, which does TLS etc. without allowing key copying. Not 100 % safe, but better than now. Let's see, who wants to pay for that :-)
debacle
MattJ, your answer was very helpful! Many thanks!
MattJ
np
Alacerhas joined
debacle
MattJ, now I need a way to distinguish IoT devices (need TLS cert) and "normal" clients (= username/password). But I hope/assume, that common servers do support selection of method per JID?
MattJ
I don't think Prosody does (currently), but other servers probably do
debacle
with this project, we are on ejabberd atm.
debacle
I'll look there.
MattJ
Generally with TLS auth, the username/JID is taken from the certificate, which would require a different certificate per unique device... is that what you want?
debacle
yes, exactly
MattJ
Then you should be good
MattJ
For the record, the limitation with Prosody is that it generally only does a single auth provider per host
MattJ
So to support both you would need two hosts, something like: tlsdevices.example.org and pwdevices.example.org
MattJ
or you could hack the client cert provider to also support password auth
MattJ
but usually that's a weird thing to do
debacle
Maybe having two hostnames is not a bad idea anyway. It would allow wild hacks, such as requiring less secure ciphers from IoT devices than from other clients.