+1 /Steffen On 02 Apr 2014, at 15:51, Kevin Smith <[email protected]> wrote:
> On Wed, Apr 2, 2014 at 2:35 PM, Peter Waher <[email protected]> wrote: >> Hello Peter & community >> >> As I mentioned before, I have an idea on how to make IBR secure. It would >> work as follows: >> >> * A manufacturer, or responsible party, would create an account on the xmpp >> server, or have an account created for him by an operator. There he/she >> could be allowed to create a certain number of accounts automatically. >> * The manufacturer would get a shared secret (say an "API Key") identifying >> the account. >> * Each device or application wanting to perform IBR would have this key >> configured. >> * When the device or app connects to the server, using IBR, it returns a >> registration form, as specified in IBR. But one (or two) of the fields would >> contain a challenge. >> * The device or application fills in the response field according to the >> shared secret and the challenge. Perhaps using OAUTH. >> * When registering, the new account would be discounted from the pool of >> accounts permitted by the key. >> * If a shared secret gets to be known, the manufacturer or responsible party >> can just choose to generate a new shared secret (or key). >> >> In this way operatos of the xmpp server can have control of who are trusted >> to create accounts automatically. And they in turn have control of how many >> accounts can be created, and monitor how many have been created. And it >> allows them to create devices without preprogrammed JID:s. >> >> What do you think about such an approach? > > If you're at the stage of putting shared secrets into the devices, why > not generate certs for the devices, and do auto-provisioning of > accounts based on the certs provided by clients? This doesn't require > new protocol and allows fine-grained control. > > /K
smime.p7s
Description: S/MIME cryptographic signature
