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 <nore...@ietf.org> 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. 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, etc.) in order to cause havoc with the server, whether that’s a memory attack, or an attempt to cause so much UI noise to users that it DoS’s the user's ability to add valid devices. I didn't see such attacks discussed. Internationalization -------------------- 11) Section 3.4.1, Table 2, says about PeerId: > UTF-8 string (typically 22 bytes) Top of page 17 says “Another way to generate the identifiers is to choose a random 22-character alphanumeric string” and “alphanumeric” is defined at https://www.merriam-webster.com/dictionary/alphanumeric as being letters and numbers. Unicode of course does not restrict “letters” or “numbers” to ascii. Note that a UTF-8 character can be anywhere from 1 to 4 bytes long. A 22 character string could thus be up to 88 bytes long. The word “typically” means you think ASCII (1 byte UTF-8) is typical. If you meant ASCII back on page 17 (and I suspect you did), then say so there. Otherwise, change this to “characters”. 12) Section 3.4.3 says: > including situations where the server does not recognize the PeerId The server “recognizing” the PeerId implies that it compares it to existing state, but PeerId is a utf-8 string. Is comparison to be done byte-wise? (I.e., it must match exactly, with no differences in NFC vs NFD, or half-width vs full-width, or case, or punycode-encoded realm vs not, etc.) If I understand correctly, the peerId is assigned by the server, and sent back to the same server, and does not need to be entered by a human or be in any specific form the peer would use natively, and so a byte-wise comparison should suffice and you can say that explicitly. 13) Table 11 says, about SSIDList and Base64SSIDList: > JSON array of UTF-8 encoded SSID strings. and similarly for SSID in table 12. And appendix D says: > If present, the peer MAY use this list as a hint to determine the > networks where the EAP-NOOB association can be used for access > authorization This is pretty vague. Is the SSID supposed to be normalized in any way (normalization form, half-width vs full-width, etc.)? Is the peer responsible for normalizing the SSIDList Unicode strings if it needs to match the networks? Or is the server responsible for sending them in a normalized form that the AP expects? Miscellaneous ------------- 14) Section 4.3 reserves space for Experimental Use. https://tools.ietf.org/html/rfc8126#section-4.2 says: “When code points are set aside for Experimental Use, it's important to make clear any expected restrictions on experimental scope. For example, say whether it's acceptable to run experiments using those code points over the open Internet or whether such experiments should be confined to more closed environments. See [RFC6994] for an example of such considerations.” 15) Table 11 says, about SSIDList: > List of wireless network identifier (SSID) > strings used for roaming support, ... Is table 11 specific to 802.11? Or is this suggesting that SSIDList is a field not specific to 802.11 SSIDs? Same question on table 12. 16) Table 12 says MACAddress and BSSId are EUI-48 strings. Are both upper case A-F and lower case a-f allowed? 17) Section 6.4 says: > Without > verification by the user or authentication with vendor certificates on > the application level, the PeerInfo is not authenticated information > and should not be relied on. The PeerInfo can be anything, right? So draft-ietf-rats-eat could be used as the PeerInfo structure to provide attestability of the information for example. I'd suggest at least mentioning that attestation could be used with the PeerInfo to provide such authentication. (Optionally add an informative reference to draft-ietf-rats-eat as a "for example", but ok if you choose not to reference it.) _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
