Re: [Emu] Iotdir early review of draft-ietf-emu-eap-noob-01
Dave, thank you for the thorough review. It helped to weed out any vague expressions that could later become stumbling blocks. We incorporated may changes based on your comments already in draft-ietf-emu-eap-noob-02 (both the comments below and the ones in the linked pdf). I'll post answers to the comments here for the record. Applicability - 1) Added an explanation of the benefits of dynamic OOB message versus static registration codes. The main reason is that the receipt of the OOB message authorizes the server to take ownership of the device. Static registration codes cannot be expected to stay secret over time, thus, do cannot provide this functionality. 2) EAP does have retransmission timer, and thus I think we can assume one for EAP-NOOB. (Nevertheless, I really like this kind of observations and can add a note about relative time clocks if necessary.) 3) Need to come back to the JSON vs CBOR discussion. 4) Added the word RECOMMENDED to maximum length of the ServerUrl. The 60-character maximum was chosen to fit into some QR code size that I felt was reasonable. There is not reason for a strict limit, though. Remembering many PeerIds (from the linked file): To clarify, remembering many PeerIds (which the server assigns in the Initial Exchange) is different from remembering many Noobs (which are sent by the OOB sender). In any case, in both cases, the constrained peer may remember only the latest one. Interoperability 5,6) Changes to MUST as suggested. This was a good lesson on interoperability in details. 7) Sending updated Realm, ServerInfo and PeerInfo in the Reconnect Exchange is truly optional. There is not pressure to implement that part. The normative parts of this specification do not make use of the values and therefore I would not want to say anything about alternative update methods. 8) It is true that ServerInfo and PeerInfo could be specified in more detail. The way this draft is written that it makes minimal suggestions for the initial deployments. We need more experience before standardizing the contents, which could be done in a later specification. Attacks and mitigations --- 9) Replaced the printer example with LEDs and lightbulbs, which are also output-only devices. The printer example is pretty interesting and could even be one of the practical applications for EAP-NOOB, but elaborating on its intricacies would clutter the text. 10) Will add discussion of UI clogging attacks against the server to the next version. Identity protection (from the linked file): I have to think what to say about identity protection. We did have a plan for changing random peer identifiers, but the reliability issues related to the possible failure of synchronization are quite complex, and explaining them and the solution would have taken over the specification. Internationalization 11-13) This is a good lesson about the need to be precise about character sets. Changed the text to say bytes or ASCII characters when that is what we mean. Miscellaneous - 14) Clarified. 15) Added a reference to 802.11 for "SSID". 16) Upper and lower case are allowed. Good point. 17) Yes, attestation is a good idea if the peer device has the hardware. Added a reference to ietf-rats-eat. Again, this review was really valuable. Regards, Tuomas -Original Message- From: Dave Thaler via Datatracker Sent: Saturday, 13 June, 2020 03:40 To: iot-director...@ietf.org Cc: draft-ietf-emu-eap-noob@ietf.org; emu@ietf.org Subject: Iotdir early review of draft-ietf-emu-eap-noob-01 Importance: High Reviewer: Dave Thaler Review result: Ready with Issues A marked up copy with my comments inline, including editorial nits not covered in this email is at https://www.microsoft.com/en-us/research/uploads/prod/2018/06/draft-ietf-emu-eap-noob-01.pdf (a Word version is also available if requested, but the PDF should suffice). See change tracking in red throughout the PDF for editorial nits. Summary of issues: Applicability - 1) The document states that it does not support static printed registration codes. It would benefit from stating the *rationale* for not supporting things like QR code stickers. E.g., does the WG believe that such things are less secure? The document does say this "also" prevents attacks where a static secret code would be leaked, but the use of "also" implies that's not the main rationale. 2) Section 3.2.5 says: > A peer that has not received an OOB message MUST wait at least the > server-specified minimum waiting time in seconds This means that this protocol cannot be easily implemented in IoT devices that have no relative time clock. Does EAP itself already have this limitation regardless of EAP method? If not, it would be good to call this out, since this limits applicability to constrained devices.
[Emu] Iotdir early review of draft-ietf-emu-eap-noob-01
Reviewer: Dave Thaler Review result: Ready with Issues A marked up copy with my comments inline, including editorial nits not covered in this email is at https://www.microsoft.com/en-us/research/uploads/prod/2018/06/draft-ietf-emu-eap-noob-01.pdf (a Word version is also available if requested, but the PDF should suffice). See change tracking in red throughout the PDF for editorial nits. Summary of issues: Applicability - 1) The document states that it does not support static printed registration codes. It would benefit from stating the *rationale* for not supporting things like QR code stickers. E.g., does the WG believe that such things are less secure? The document does say this "also" prevents attacks where a static secret code would be leaked, but the use of "also" implies that's not the main rationale. 2) Section 3.2.5 says: > A peer that has not received an OOB message MUST wait at > least the server-specified minimum waiting time in seconds This means that this protocol cannot be easily implemented in IoT devices that have no relative time clock. Does EAP itself already have this limitation regardless of EAP method? If not, it would be good to call this out, since this limits applicability to constrained devices. Maybe add an "Applicability" section like EAP (RFC 3748) section 1.3 has. 3) Section 3.3.2 says: > The in-band messages are formatted as JSON objects [RFC8259] So this limits applicability to constrained IoT devices, since JSON can be verbose compared to, say, CBOR, and if the IoT device already uses CBOR for its normal protocol use this requires adding a separate parser for JSON which may cause code size issues. Is there a rationale for why CBOR could not be an option? E.g., if this protocol is not applicable for constrained devices, then say so. (I don’t know whether EAP itself already inherently has problems that limit its applicability for constrained devices.) 4) Appendix E says: > The ServerInfo in this case includes a JSON member called ServerUrl > of the following format with maximum length of 60 characters: Just an observation: This limits applicability to servers that can get short hostnames (and paths), which might make it less applicable users in some cultures/languages. Interoperability 5) Section 3.1 says: > 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. As phrased, there are 3 compliant behaviors: Behavior 1) Follow the MAY and delete the data Behavior 2) Don’t follow the MAY, do follow the If, and follow the SHOULD and act as if data was deleted Behavior 3) Don’t follow the MAY, do follow the If, and don’t follow the SHOULD and hence act in any other way. In my experience, such undefined behavior can cause interoperability issues. Is there any reason to permit behavior 3? Why can’t you make the SHOULD be a MUST (since the If already makes it conditional on implementations that don’t follow the MAY). 6) Section 3.2.5 says: > If the server has not sent any SleepTime > value, the peer SHOULD wait for an application-specified minimum time > (SleepTimeDefault). Since the minimum time is app-specified as this sentence says, what does it mean to not follow this SHOULD? I.e., why is it not a MUST? 7) Section 3.4.2 says: > The endpoints MAY send updated Realm, ServerInfo and PeerInfo objects > in the Reconnect Exchange. So if this MAY is not followed, does that mean any updates are not sent at all, or that they are sent via some other mechanism? 8) Appendix C says: > They contain > JSON objects whose structure may be specified separately for each > application and each type of OOB channel. It doesn’t look like you’re specifying an IANA registry to contain field names. Given that, how do you get interoperability? If every app and type of OOB channel specifies a different structure, how do you do capability negotiation to agree on which structure definition is being used? (Since two specifications might use the same field names for very different purposes, in theory.) I didn’t see any identifier that can be used as the “type” of the ServerInfo or PeerInfo data. Attacks and mitigations --- 9) Section 3.1 says: > For example, consider a printer > (peer) that outputs the OOB message on paper, which is then scanned > for the server. Elaborate on this use case… Is the assumption that the printer would automatically consume paper in response to any unauthenticated message (hence being a resource consumption attack)? Or that it would only do so after getting approval from a human to output the OOB message? 10) Section 6.3 discusses misbinding attacks, but another attack is where a rogue device keeps generating random IDs (MAC,
