Hi Tero, It is important to distinguish:
1) Authentication and authorization for network access 2) Authentication and authorization for application The two often get mixed up and they shouldn't be. More comments inline. Robert On 05/05/2015 12:39, Tero Kivinen wrote:
Tom Phinney writes:That would be all well and good for an industry standard, such as WirelessHART (which itself mandates a different secure way to do that initial provisioning). But it's unlikely to be acceptable for something that purports to be a communication standard, since mandating a specific type of auxiliary provisioning channel is unlikely to be acceptable to the wider community.Most commonly devices currently either automatically trust the first network they connect to, and can receive initial configuration from that network.
<RCC> Initial configuration for what? 1) Operating correctly as a member of the network? 2) Operating as a functional device?It is likely to get both but again they are quite distinct and the configuration data in each case may come from entirely difference sources. In the case of (1) it is likely to come from an authoritative device in the network sense (e.g. access point). In the case of (2), it could be from a cloud server.</RCC>
<RCC>You have to look at this as two separate networks where the first network is an out-of-band mechanism to pre-provision information for the second network. In this case, it is the first network we concentrate on wrt. in-band mechanisms for authentication and authorization</RCC>For example lots of wifi devices will create their own wifi-network for configuration. I.e. you connect to this "config" network take http connection to some ip-number in there, and then you get web page where you can config the device. During that process you install admin key and provide other network setup information. All this is stored on the stable storage and after that the device boots up normally using the stored network setup.
<RCC>That isn't going to work unless any network in the vicinity somehow provides "guest" connectivity to a device which can configure it for the right network somehow. Not impossible but quite a complex commissioning model. Otherwise your phone must also be able to guest on the network the device has just joined. Then it has to find that network etc. etc. Then there is a second stage of jumping on to the right network.</RCC>If you need to do that again (reprovision) you press some button or something during the bootup and it will reset all configuration. Another setup is that devices just boot up and join the first network they can see, and then you can for example use some application in your phone, which will search those devices from the network and allow you to do the initial configuration for them.
<RCC>This is likely application auth/authz as this doesn't really make sense for local network configuration unless we are talking about a AAA model.</RCC>Or the devices might come with a code that you use to log in the vendors cloud service, and install the configuration there, and then when the device boots up it always connects to that cloud service to download the configuration.
The problem with wifi setups is that before you can do the last two ways of configuration you need to get credentials for the network, i.e. you need the wifi network key before you can connect to the net, which is why the first setup might be there in addition to the last two...
<RCC>Which comes back to distinguishing the two cases clearly.</RCC>
For IoT in home environments I would think the best option would be to have raw public key on the device, and during the initial bootup the device joins whoever is there, and tries to download configuration from some server from there. During this process it authenticates himself with that raw public key, and the server can then either accept it directly or it can match it against the list of raw public key fingerprints configured to it (i.e. they might have been printed to the side of device in QR code, or they might be distributed using email or some other electronic method).
<RCC>Are we talking auth/authz for network access or application here?</RCC>
<RCC>Probably only in a AAA model. A RPK (or self-signed cert.) cannot be implicitly trusted so it would have to be checked against a whitelist on a trusted server</RCC>During this initial provisioning the device cannot authenticate the network, but network can authenticate the device.
Once the initial provisioning is done, the device stores the network authentication information to the stable storage (for example the fingerprint of the JCE) and after that for later bootstratps it can authenticate the network too.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
