Hi Michael, Thanks for the input. This is indeed something we should discuss at the upcoming virtual EMU meeting.
Some colleagues (Ingles Sanchez et al.) have also investigated and documented the savings that might result from the use of CBOR in EAP-NOOB: https://hal.archives-ouvertes.fr/hal-02880326/document EAP-NOOB also relies on the JWK specification for encoding public keys. While CBOR equivalent is defined in RFC 8152, it is a rather large document that contains all the functionality of JWK, JWS, JWA (as far as I understand). Following smaller modular specifications was somehow easier at the time. What is more important is that wpa_supplicant currently has a JSON encoder and parser (https://w1.fi/cgit/hostap/tree/src/utils/json.c). I think you would agree that wpa_supplicant is probably the most important tool for those using EAP (at least on 802.11). One could use an external library since there are many CBOR implementations available: https://cbor.io/impls.html. However this has two major downsides: - Adding an external library dependency implies that the overall system becomes more brittle. - Updating and maintaining two components is definitely harder than one. As said, this is worth discussing at the meeting since it would result in a large change to the existing EAP-NOOB implementations. --Mohit On 7/8/20 8:12 PM, Michael Richardson wrote: Speaking as a WG participant. Dave Thaler via Datatracker <nore...@ietf.org><mailto:nore...@ietf.org> wrote: > 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.) I think that the document predates widespread availability of CBOR :-) I think that it would benefit from only using CBOR, as CBOR works into EAP much better than I think JSON does. That would be a radical change, but the document as only just been adopted by the EMU WG. To the extent that EAP is used more on 802.11 rather than 802.15.4 [not that you can't do EAP/1x on 15.4, it just hasn't caught on], IoT devices that have power budget for WiFi can generally do EAP. There is a large variety of arduino class devices running FreeRTOS+micropython, for instance, which already have EAP supplicants. CBOR would be easier for them in the C code parts of them, while if the EAP-NOOB were to involve the python code (for callbacks, etc.) it wouldn't matter much as whether JSON or CBOR, it would likely be presented as python dict() anyway. Where there is a problem is a slightly smaller class of device which use various WiFi *MODULES*. Usually the microcontroller speaks i2c to this module, and the module takes care of all the TCP/IP/Ethernet/WiFi stuff. Those devices do not use EAP today, and they are hard to upgrade. (and from a security point of view, those architectures concern me greatly) -- Michael Richardson <mcr+i...@sandelman.ca><mailto:mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
