On 6/8/20 2:25 PM, Hannes Tschofenig wrote: > Hi all
> I read through draft-aura-eap-noob-08 during the call for adoption. > The draft acknowledges that the concept of "onboarding" is a new term for an > old concept, namely network access authentication. I like the draft from that > point of view. > The content looks fine good and the design is well described. There is a > formal analysis available and sample code available. Thank you for taking the time to review, and also for the positive feedback.. > I believe it would be good to note that the solution does not support any > form of cloning prevention because the device is assumed to be "blank" from > the point of view of keying material. This is a good point. We'll add text in the security considerations. All blank devices are treated the same in EAP-NOOB. Thus, technically you can make as many clones of a blank device as you want. To prevent cloning, the protocol could be extended to bind the peer identity a TEE. > I was wondering about one aspect, and maybe I missed it somewhere: what are > you actually authenticating? > The identifier for the client is assigned by the EAP server. The server is > also unknown at the start of the protocol. The peer device is authenticated based on the fact that the user has physical access to it. The user typically authenticates the server based on a web certificate, but that depends on the OOB channel. EAP-NOOB is akin to device-pairing protocols (such as Bluetooth); the difference is that, instead of associating two devices with each other, EAP-NOOB associates a device with a server (and a user account in the server). > I also got the impression that the authors are not entirely sure about > repeating the OOB step. Earlier in the document it sounds like the authors do > not really like the idea to repeat it and then later in the document they > acknowledge that it will be necessary to deal with it anyway. Am I reading > in-between the lines here? I think this point could be written more clearly in the draft. It is mentioned multiple times because one of our most important goals for the design was to avoid repeating the OOB step after a successful association whenever it possibly can be avoided. In the protocol, this means creating an association that will be used for reauthentication, and that a temporary network or server failure should not cause the peer device to go back to its initial state. The protocol also supports rekeying and, unlike typical OOB pairing protocols, algorithm update (ECDH curve update) without a new OOB step. The exception is that, if the device or server lose the association state, there is no way to recover without resetting also the other endpoint. > There is also a not-so-bright side of this draft: the deployment. The > solution places many constraints on potential solutions, the authors have > little influence on the deployment environment, the use of EAP is not that > common in IoT communication technologies, there are many other competing > solutions, etc. This is a reasonable point to make about EAP-NOOB and for EAP more generally. There is always tension between generic protocols like EAP and proprietary or technology-specific solutions. The advantages of EAP include the ability to change the authentication method without changing anything else in your protocol and system, independence of the lower-layer technology, lower cost of application development given the existing specifications and implementations, and ready support for roaming. For example 3GPP moved from technology-specific protocols to EAP, and they must see some advantage in it. It escapes me why 802.11 has not given up on the non-EAP authentication methods that add lots of complexity to their specification. > Ciao > Hannes Thank you again for your comments. Tuomas
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
