Hello Kevin Thanks for your input.
>> 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. Actually, I've left the nature of the shared secret open at this point to be able to have a discussion. I've myself been a proponent for many years of using certificates in assuring communication, but with very poor results to be honest. It has been very difficult for me to convince product manufacturers why they should use certificates, even when it has been possible. The problem with certificates is basically: They are costly (either you have to buy them, or set up a certificate server) and limited in time. A manufactured product like a sensor or meter must have a life span of 10 years. Where do you get a valid certificate valid for 10 years, without self-signing one and manually installing it in the certificate registry (something you shouldn't do)? Using certificates to install system components, especially server components is easier to motivate, or to identify public domains even easier. This trend for a simpler method for authentication than using certificates is visible also in API design and mobile app development (paralleling the work to simplify web service requests, where developers prefer REST before SOAP). OAUTH [1] has become a very popular choice, and is one which I personally am leaning on would make a good candidate. It much easier for a non-initiated to become started, and it's easy for a production environment, and it is sufficiently secure and reliable. There's an IETF draft for a SASL extension to OAUTH [2] and large web API operators like Google support it [3]. It is also completely free and easy to automate in a production environment (or on a Web API page). An XMPP Server can easily produce new valid OAUTH keys by itself. [1] http://oauth.net/ [2] http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-14 [3] https://developers.google.com/accounts/docs/OAuth2 Actually, Google models their API accounts in a similar way to the one proposed above. There, an account holder is given a certain number of API calls per time unit, which it can then distribute among its users. The above method would do something similar: An account holder would be given a certain number of accounts that can be created, and can distribute this right to its users (Thing). Best regards, Peter Waher
