debacleI 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 :-)
MattJdebacle, taking XMPP out of the equation, this is a hard/impossible problem to solve (depending on the requirements)
debacleMattJ, wouldn't TLS client certs do that?
MattJOnly if the device connects directly to you, but you said it can use any server
MattJAnd 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
MattJSee: every attempt at DRM ever
debacleMattJ, the authenticity must be guaranteed only in respect to the server, that is directly connected, btw.
MattJClient certificates are the best way to do this, then, probably
MattJJust don't count on the private certificate(s) not being extracted
debacleMattJ, I'm fine with the limitation that physical access brings.
MattJand the server is a standard server? or what?
debacleMattJ, of course PGP etc. have the same problem. And we don't have any crypto chips on the device.
MattJYes, that's why I started with a "taking XMPP out of the equation" - this applies to any method
debacleIt's an embedded device, which you and I can "root" in seconds.
MattJThen there is no way to keep a secret secret
MattJso someone can copy the private key to their laptop and do TLS pretending to be the device
debacleJust to be sure not to forget any option: Any other idea than PGP and TLS client certs? (With the same limitations accepted, of course.)
MattJIf you're fine with that, I'm fine with that - I still think TLS is the best you can do here
MattJTLS is designed for this (verifying identity), and it's already fairly well supported in XMPP software
debacleGood! 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 :-)
debacleMattJ, your answer was very helpful! Many thanks!
debacleMattJ, 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?
MattJI don't think Prosody does (currently), but other servers probably do
debaclewith this project, we are on ejabberd atm.
debacleI'll look there.
MattJGenerally 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?
MattJThen you should be good
MattJFor the record, the limitation with Prosody is that it generally only does a single auth provider per host
MattJSo to support both you would need two hosts, something like: tlsdevices.example.org and pwdevices.example.org
MattJor you could hack the client cert provider to also support password auth
MattJbut usually that's a weird thing to do
debacleMaybe 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.