Robert Cragie writes: > It is important to distinguish: > > 1) Authentication and authorization for network access > 2) Authentication and authorization for application
Yep. > The two often get mixed up and they shouldn't be. On the other hand when you have IoT devices who create dedicated radio network between them, which is only used by them, then those things can also be same thing. I.e. if you have temperature sensor talking to the temperature control device, and those two devices are only one on the network, then the fact that you are part of the network (i.e. network access authentication and authorization) also provides application authentication and authorization. If you have general purpose network (6lowpan or wifi) then this is not true. > > 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> Yep. For here I have mostly been talking about the network access configuration, but in some devices those configurations might be combined. I do not think there is need to complicate things here with the functional device configuration stuff. That is application level settings, and we are specifying stuff that is way below that level. > > 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>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> Yes. In this example the first network is out-of-band mechanism, and should be outside the scope of drafts we specify here. It is one of the methods to provide the initial netowkr access configuration to devices. The security of that network might be provided by physical means, i.e devices put in to the faraday cage, or the powerlevel of network turned down to minimal level so that devices must be next to each other. So I disagree with you. I do not think we should concentrate on this first network. I think it should stay outside the scope. We should concentrate what happens after that, i.e. after the initial network access information is already provided. During this initial network access information provisioning phase, the device might for example get its unique public/private key pair, or certificate, or unique shared key used for the future authentication steps. It might not get the K1 or K2 for the network, i.e. those might still be generated / exchanged during the bootstrap phase while using the authentication information given in that earlier step. > > 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>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 want to have new devices joining the network, you do need some level of "guest" connectivity. How much these guests can do is completely different thing. At minimal they should be able to talk to the JCE so they cam authenticate and authorize themselves, and join the network. The network might also provide more "guest" access. This is very common in wifi networks. For example before you are able to go to the initial login page for the network, you need to be able to do certain things. For example you need to be able to send/receive dhcp messages, you might need to have limited dns access. If the login page is protected by the https, then you might need OCSP access etc. This is something the network adminstrator needs to set up. Anyways, I think we should concentrate on the network access configuration case. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
