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. 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. 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. 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? 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. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
