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
