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 <emu-boun...@ietf.org> 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. <mglt> 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. </mglt> <resp> Edited the abstract to be more specific. </resp> 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, <mglt> 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 ? </mglt> <resp> 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. </resp> o no pre-provisioned device identifier or authentication credentials, <mglt>I do have the same questions as above. </mglt> o limited user interface and configuration capabilities. <mglt>I am finding limited too vague to understand if my device is a candidate for this registration.</mglt> <resp> Edited the text to be more slightly specific. </resp> 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-NOOB October 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. <mglt> I believe that this characteristics should be mentioned earlier as it characterizes the devices. The contextual characteristic to perform the procedure is that the user has physical access to it. The characteristic of your method is, in my opinion, that you perform the registration without any pre-provisioning of the device. Instead only the user needs to have an account to the server. "tens or bytes" tends to characterize the network capacity. I am wondering if we could have a more specific idea of the maximum length of the message. Maybe that will dpeend on the type of devices. device resources: it might be good to provide an estimating of the necessary resources in term of software/RAM necessary to run the protocol. This would probably remove a bunch of devices. </mglt> <resp> Added the specifics about the device to the abstract. I hope your point is now sufficiently addressed without tiring the reader. </resp> Naturally, this solution may not be appropriate for very small sensors or actuators that have no user interface at all or for devices that are inaccessible to the user. We also assume that the OOB channel is at least partly automated (e.g. camera scanning a bar code) and, thus, there is no need to absolutely minimize the length of the data transferred through the OOB channel. This differs, for example, from Bluetooth simple pairing [BluetoothPairing], where it is critical to minimize the length of the manually transferred or compared codes. Since the OOB messages are dynamically generated, we do not support static printed registration codes. This also prevents attacks where a static secret code would be leaked. 2. Terminology [...] peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the supplicant. <mglt>It might be good to explicitly mention the device is now designated as peer.</mglt> <resp> yes </resp> 3. EAP-NOOB protocol [...] 3.1. Protocol overview One EAP-NOOB protocol execution spans multiple EAP conversations, called Exchanges. This is necessary to leave time for the OOB message to be delivered, as will be explained below. <mglt>"leave time": This was unclear to me until I read the following paragraph. My first reading was that multiple messages would take sufficient time, so the OOB message can be delivered (in paralell ?). Then I thought that the implication of the three parties requires multiple exchanges. I think that multiple exchange enable multiple parties as well as the necessary flexibility that is required by a human interaction with non deterministic delays which requires probing capabilities. I also have the impression that we could introduce a better terminology to distinguish session - that includes the initial Exchange, step a set of exchanges within a session a exchange with one round trip. Note this is just a suggestion, and I am not sure what is commonly used. </mglt> <resp>Rewrote the confusing paragraph. Not sure I understand the suggestion about session terminology; need to give it still some though. It is the kind of terminology issue which we wrestled a lot when writing the draft. Changes in terminology would need to be done consistently throughout. </resp> The overall protocol starts with the Initial Exchange <mglt>There is probably a reference to EAP that is needed in the first line of the paragraph as well as an indication that the Initial Ex is part of the EAP message.</mglt> <resp>Added a reference to EAP and that the Initial Exchange consist of four EAP request-response pairs.</resp> [...] OOB Output/Initial Exchange/ Waiting Exchange .-----. | v .------------------. Initial .------------------. | | Exchange | | .->| 0. Unregistered |---------------->|1. Waiting for OOB| | | | | | | '------------------' '------------------' | | | ^ User Reset Completion | | | | Exchange | OOB OOB |<-------. .-------------------------' Input Reject/ | | | | Initial | | | | Exchange | | v v | | .------------------. Completion .------------------. | | | Exchange | | | | 4. Registered |<----------------| 2. OOB Received | | | | | | | '------------------' '------------------' | | ^ | Mobility/ | | Timeout/ Reconnect | Failure Exchange | | | | v | | .-----------------. | | | '--| 3. Reconnecting | | | '-----------------' <mglt> maybe that would be good to specify (explicitly) the numbers in the figure represents state values. I think the first time I went through the graph I interpreted as chronological indications. It took me also some time to figure out that 0..2 means 0-2 or 0, 1, 2. I think (1) would be clearer than 1. if the number represents a state value.. I am only providing this as an input, but I am also fin if I am the only one that got partly confused. </mglt> <resp>Good point, changes the style of numbering.</resp> Figure 1: EAP-NOOB server-peer association state machine [...] The server MUST NOT repeat a successful OOB Step with the same peer except if the association with the peer is explicitly reset by the user or lost due to failure of the persistent storage in the server. More specifically, once the association has entered the Registered state, the server MUST NOT delete the association or go back to states 0..2 without explicit user approval. Similarly, the peer MUST NOT repeat the OOB Step unless the user explicitly deletes from the peer the association with the server or resets the peer to the Unregistered state. The server and peer MAY implement user reset of the association by deleting the state data from that endpoint. If an endpoint continues to store data about the association after the user reset, its behavior SHOULD be equivalent to having deleted the association data. <mglt> I understand as a need to set mechanisms to prevent the peer and the server to become de-synchronized as well as the peer to be associated twice. It is unclear to me why a double association needs to be prevented given that the peer is mot limited to one association. Naively, I would expect the peer to select one of these association. That it ends int the expected association is a different thing. I am questioning the "The server MUST NOT repeat a successful OOB Step". I have the impression, the server decides whether OOB is neeeded or not. I have the impression that depends on the trust model. If the purpose is to get the device authenticated by the server that associate the device to a user. We can have the server requesting an OOB operation for devices that have not been used for a while. This could be correct if you believe that an attacker does not have access to the device for example. Homenetwork may fall in that category. When the devices enters into a OOB phase it either removes older associations or add this one. This would at least ensure that the server and devices are always able to recover from one another. The main issue I see is that any server can overwrite the device's association, but I am not sure this is required in every scenarii.. I believe that the two approach may be described. If this is not expected, this means that we expect that when the authentication failure happens, the device should not set a new association. Potential reasons for a failure may be the device not being registered, the procedure to fail because of a bug.... I am wondering how the user may be able to see that the device has not been registered AND the server is not the expected server. In this case we do not want to reset the device, while in other cases, a retry or a reset will be sufficient. If the server identity doesn't appear my feeling is that, the most common operation will be reset and register again. While going through the document I see that error message can make the distinction. I believe that would be worth mentioning it. </mglt> <resp>The issue here is that temporary failure of communication must not cause the peer to ask the user to repeat the OOB step (either to replace the association or to create a second one). The cost of sending a person physically to fix connection problems in IoT devices is high, and any other way of fixing the association should the tried first, such as recovering association data on the server side. Consider distributed smart displays: businesses cannot afford to send engineers around the city if it can be avoided, and home users will soon get tired of reconfiguring the devices that go back to bootstrapping mode. Eventually, the user may determine that the server-side association is permanently lost and decide to reset the device, but that is an external action (pressing reset button) and not a transition that the device ever takes on its own initiative. (The failures that cause the device to go back to bootstrapping could also be caused by a malicious attacker. However, this is more a reliability issue than a security issue. I’m not sure where to discuss the “reliability considerations” as there is no special section for it and it does not seem right to clutter the specification text itself.) </resp> [...] 3.2. Protocol messages and sequences [...] 3.2.1. Common handshake in all EAP exchanges </mglt>The title should be EAP-NOOB I think.</mglt> <resp>yes</resp> All EAP-NOOB exchanges start with common handshake messages. The handshake starts with the identity request and response that are common to all EAP methods.. Their purpose is to enable the AAA architecture to route the EAP conversation to the EAP server and to enable the EAP server to select the EAP method. The handshake then continues with one EAP-NOOB request-response pair in which the server discovers the peer identifier used in EAP-NOOB and the peer state. In more detail, each EAP-NOOB exchanges begin with the authenticator <mglt>Though I am not native english speaker, "each exchanges begin" sounds strange to me. wouldn't "the" more appropriated?</mglt> <resp>Right. Changed to “each begins”.</resp> [...] If one of the peer or server is in the OOB Received (2) state and the other is either in the Waiting for OOB (1) or OOB Received (2) state, the OOB Step has taken place and the server chooses the Completion Exchange. If both the server and peer are in the Waiting for OOB (1) state, the server chooses the Waiting Exchange. If the peer is in the Reconnecting (3) state and the server is in the Registered (4) or Reconnecting (3) state, the server chooses the Reconnect Exchange. All other state combinations are error situations where user action is required, and the server indicates such errors to the peer with the error code 2002 (see Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB when the peer is in Registered (4) state. </mglt>I am wondering if some normative language should not be used to describe the server's behavior (MUST).</mglt> <resp>yes</resp> EAP Peer EAP Server | | |<----------- EAP-Request/Identity -| | | | | | |------------ EAP-Response/Identity -------------->| | (NAI=n...@eap-noob.net<mailto:n...@eap-noob.net>) | | | | | |<----------- EAP-Request/EAP-NOOB ----------------| | (Type=9) | | | | | |------------ EAP-Response/EAP-NOOB -------------->| | (Type=9,[PeerId],PeerState=1) | | | | continuing with exchange-specific messages... | Figure 2: Common handshake in all EAP-NOOB exchanges 3.2.2. Initial Exchange <mglt>As a comment, I am wondering if Initial Step would not be more appropriated instead of Exchange, each step being accomplished by a number of exchanges. </mglt> <resp>We tried to find the appropriate word and settled on “exchange”, similar to “key exchange”, which does not mean only request-response patterns. Maybe it is misleading, but before changing the terminology, I’d like to be sure that the replacement is clearer and can be done in a consistent way thoughou the draft. Step/stage/phase/protocol all have their problems because they are reserved words somewhere. </resp> [...] 3.2.3. OOB Step [...] The OOB receiver MUST compare the received value of the fingerprint Hoob with a value that it computes locally. If the values are equal, the receiver moves to the OOB Received (2) state. Otherwise, the receiver MUST reject the OOB message. For usability reasons, the OOB receiver SHOULD indicate the acceptance or rejection of the OOB message to the user. The receiver SHOULD reject invalid OOB messages without changing its state, until an application-specific number of invalid messages (OobRetries) has been reached, after which the receiver SHOULD consider it an error and go back to the Unregistered (0) state. <mglt>I probably have missed them, but it is unclear to me what a Noob or Hoob are it would be good to provide a high level definition as well as a reference to the section 3.3.2. Message data fields.</mglt> <resp>added</resp> [...] The sender will typically generate a new Noob, and therefore a new OOB message, at constant time intervals (NoobInterval).. The RECOMMENDED interval is NoobInterval = NoobTimeout / 2, so that the two latest values are always accepted. <mglt> If I understand it correctly, the number of Nood will be 2 in that case, and the received will be the first two. </mglt> <resp>Clarified the text. The receiver of the OOB will at any given time accept either of the two latest Noob values. </resp> [...] 3.2.4. Completion Exchange After the Initial Exchange, if both the server and the peer support the peer-to-server direction for the OOB channel, the peer SHOULD initiate the EAP-NOOB method again after an applications-specific waiting time in order to probe for completion of the OOB Step. Also, if both sides support the server-to-peer direction of the OOB exchange and the peer receives the OOB message, it SHOULD initiate the EAP-NOOB method immediately. Depending on the combination of the peer and server states, the server continues with with the Completion Exchange or Waiting Exchange (see Section 3.2.1 on how the server makes this decision). <mglt>I understand that Completion requires the session of a new session that is the agreement of a new ecdhe secret and does not leverage from the established session for the Initial exchange. I understand better why the authentication procedure is particular. I am wondering if we do not include a Hoob associated to the previous Initial Exchange as well as the OOB exchanges to make sure there is a strong binding between these exchanges. This could be achieved at least partly by specifying the Noob to include Hoob. Going through the document I have seen Z, which might address my concerns. </mglt> <resp>Yes, Z is a cumulative function of the association history.</resp> [...] 3.2.5. Waiting Exchange [...] 3.3. Protocol data fields This section defines the various identifiers and data fields used in the EAP-NOOB protocol. 3.3.1. Peer identifier, realm and NAI [...] Another way to generate the identifiers is to choose a random 22-character alphanumeric string. It is RECOMMENDED to not use identifiers longer than this because they result in longer OOB messages. <mglt> 22 leads to 154 or 176 bits. I am wondering if limiting the number the expected number of device could be recommended in order to limit the size of the message. </mglt> <resp>This is a good observation and requires some analysis. The way the identifiers are allocated and used has changed after fixing the length, and it might be possible to use shorter ones. I need to return to this question. </resp> [...] The default realm for the peer is "eap-noob.net<http://eap-noob.net>". However, the user <mglt> the domain name has been registered. I believe that is a useful information to mention. I am wondering how this domain will remain reserved once standardized and if something under .arpa may not be preferred as being managed by the IANA. </mglt> <resp>I understand that allocating an .arpa domain is more appropriate for the purpose. Added notes about this to the relevant sections.</resp> [...] Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,Cryptos uitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). NoobId = H("NoobId",Noob). MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo,C ryptosuitep,Dirp,[Realm],PeerInfo,0,PKs,Ns,PKp,Np,Noob). MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N p2,"") MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo] ,Cryptosuitep,"",[Realm],[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],N p2,"") Missing input values are represented by empty strings "" in the array. The values indicated with "" above are always empty strings. Realm is included in the computation of MACs and MACp if it was sent or received in the preceding Initial Exchange. Each of the values in brackets for the computation of Macs2 and Macp2 MUST be included if it was sent or received in the same Reconnect Exchange; otherwise the value is replaced by an empty string "". <mglt>maybe an explanation for [] is also needed. </mglt> <resp>yes, added</resp> [...] 3.5. Key derivation [...] +------------+------------------------------------------------------+ | KeyingMode | Description | +------------+------------------------------------------------------+ | 0 | Completion Exchange (always with ECDHE) | | | | | 1 | Reconnect Exchange, rekeying without ECDHE | | | | | 2 | Reconnect Exchange, rekeying with ECHDE, no change | | | in cryptosuite | | | | | 3 | Reconnect Exchange, rekeying with ECDHE, new | | | cryptosuite negotiated | +------------+------------------------------------------------------+ Table 3: Keying modes The key derivation has three different modes (KeyingMode), which are specified in Table 3.. Table 4 defines the inputs to KDF in each KeyingMode. <mglt>I am counting 4 modes. I am also wondering why the Initial Exchange is not mentioned ? </mglt> <resp>Yes, 4. No keying takes place in the Initial Exxhange. It takes place in the Completion Exchange that follows the Initial Exchange and OOB Step, and in the stand-alone Reconnect Exchange, where it can take three different forms (1-3).</resp> [....]
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu