[Standards] deprecating in-band registration

Steffen Larsen zooldk at gmail.com
Wed Apr 2 13:59:22 UTC 2014


On 02 Apr 2014, at 15:51, Kevin Smith <kevin at kismith.co.uk> wrote:

> 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.
> /K

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140402/7c242387/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4130 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140402/7c242387/attachment.bin>

More information about the Standards mailing list