Re: [Emu] draft-aura-eap-noob-07 review
Hi Daniel, Thank you for the review! I really appreciate you taking the time to read the draft with such care. I have fixed most of the issues, but some require more thought and I run out of time for today’s deadline. Responses are inline. Tuomas From: Emu On Behalf Of Daniel Migault Sent: Thursday, 16 January, 2020 18:14 To: emu@ietf.org Subject: [Emu] draft-aura-eap-noob-07 review Importance: High Hi, I have reviewed the eap-noob document and believe it is ready for adoption. I have made a series of comments that are mostly editorial and some clarifying questions. I am happy to review the document further. Yours, Daniel [...] Abstract Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server. A nit. There are double spaces, so maybe :%s/ / /gc may be needed. I believe that *minimal* should be expanded here as it might be an important characteristic of the object. Typically the ability to communicate an URL to the end user, is a characteristic that is not generic to all devices at least maybe not the bulb or temperature network. I would be good that from the abstract the reader knows if this methods apply or not. Edited the abstract to be more specific. 1. Introduction This document describes a method for registration, authentication and key derivation for network-connected ubiquitous computing devices, such as consumer and enterprise appliances that are part of the Internet of Things (IoT). These devices may be off-the-shelf hardware that is sold and distributed without any prior registration or credential-provisioning process. Thus, the device registration in a server database, ownership of the device, and the authentication credentials for both network access and application-level security must all be established at the time of the device deployment. Furthermore, many such devices have only limited user interfaces that could be used for their configuration. Often, the interfaces are limited to either only input (e.g. camera) or output (e.g. display screen). The device configuration is made more challenging by the fact that the devices may exist in large numbers and may have to be deployed or re-configured nimbly based on user needs. More specifically, the devices may have the following characteristics: o no pre-established relation with a specific server or user, I understand this characteristic as requiring that devices must be completely new. I have the impression that the characteristic concerns more the state of the device then the device itself. Does the text means that such characteristics are not necessary or that these characteristic if existing will make the registration impossible. Typically, I imagine the following scenarios. I have a registered screen from in a server in my company. I am taking that screen to the University that organises a workshop. Can the screen work with two different accounts/registration on different servers ? Do I have to necessarily factory reset the screen ? Do I have to redo the registration procedure when I bring the screen back to my company ? Am I going to possibly register the screen I bought on second-hand-gatan ? Added hard reset as alternative to off-the-shelf. Multiple registrations is something we have consciously avoided discussing because the protocol itself is agnostic to the number of simultaneous instance one device can implement. I’ll think about an appropriate way of discussing this. o no pre-provisioned device identifier or authentication credentials, I do have the same questions as above. o limited user interface and configuration capabilities. I am finding limited too vague to understand if my device is a candidate for this registration. Edited the text to be more slightly specific. Many proprietary OOB configuration methods exits for specific IoT devices. The goal of this specification is to provide an open standard and a generic protocol for bootstrapping the security of network-connected appliances, such as displays, printers, speakers, Aura & Sethi Expires May 1, 2020 [Page 3] Internet-Draft EAP-NOOBOctober 2019 and cameras. The security bootstrapping in this specification makes use of a user-assisted out-of-band (OOB) channel. The device authentication relies on user having physical access to the device, and the of the key exchange security is b
[Emu] draft-aura-eap-noob-07 review
Hi, I have reviewed the eap-noob document and believe it is ready for adoption. I have made a series of comments that are mostly editorial and some clarifying questions. I am happy to review the document further. Yours, Daniel [...] Abstract Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server. A nit. There are double spaces, so maybe :%s/ / /gc may be needed. I believe that *minimal* should be expanded here as it might be an important characteristic of the object. Typically the ability to communicate an URL to the end user, is a characteristic that is not generic to all devices at least maybe not the bulb or temperature network. I would be good that from the abstract the reader knows if this methods apply or not. 1. Introduction This document describes a method for registration, authentication and key derivation for network-connected ubiquitous computing devices, such as consumer and enterprise appliances that are part of the Internet of Things (IoT). These devices may be off-the-shelf hardware that is sold and distributed without any prior registration or credential-provisioning process. Thus, the device registration in a server database, ownership of the device, and the authentication credentials for both network access and application-level security must all be established at the time of the device deployment. Furthermore, many such devices have only limited user interfaces that could be used for their configuration. Often, the interfaces are limited to either only input (e.g. camera) or output (e.g. display screen). The device configuration is made more challenging by the fact that the devices may exist in large numbers and may have to be deployed or re-configured nimbly based on user needs. More specifically, the devices may have the following characteristics: o no pre-established relation with a specific server or user, I understand this characteristic as requiring that devices must be completely new. I have the impression that the characteristic concerns more the state of the device then the device itself. Does the text means that such characteristics are not necessary or that these characteristic if existing will make the registration impossible. Typically, I imagine the following scenarios. I have a registered screen from in a server in my company. I am taking that screen to the University that organises a workshop. Can the screen work with two different accounts/registration on different servers ? Do I have to necessarily factory reset the screen ? Do I have to redo the registration procedure when I bring the screen back to my company ? Am I going to possibly register the screen I bought on second-hand-gatan ? o no pre-provisioned device identifier or authentication credentials, I do have the same questions as above. o limited user interface and configuration capabilities. I am finding limited too vague to understand if my device is a candidate for this registration. Many proprietary OOB configuration methods exits for specific IoT devices. The goal of this specification is to provide an open standard and a generic protocol for bootstrapping the security of network-connected appliances, such as displays, printers, speakers, Aura & Sethi Expires May 1, 2020 [Page 3] Internet-Draft EAP-NOOBOctober 2019 and cameras. The security bootstrapping in this specification makes use of a user-assisted out-of-band (OOB) channel. The device authentication relies on user having physical access to the device, and the of the key exchange security is based on the assumption that attackers are not able to observe or modify the messages conveyed through the OOB channel. We follow the common approach taken in pairing protocols: performing a Diffie-Hellman key exchange over the insecure network and authenticating the established key with the help of the OOB channel in order to prevent impersonation and man-in-the- middle (MitM) attacks. The solution presented here is intended for devices that have either an input or output interface, such as a camera, microphone, display screen, speakers or blinking LED light, which is able to send or receive dynamically generated messages of tens of bytes in length. I believe that this characteristics should be mentioned earlier as it characterizes the devices. The
