[Standards] deprecating in-band registration
kevin at kismith.co.uk
Wed Apr 2 13:51:19 UTC 2014
On Wed, Apr 2, 2014 at 2:35 PM, Peter Waher <Peter.Waher at clayster.com> 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.
More information about the Standards