Re: [Iot-directorate] [Emu] Iotdir early review of draft-ietf-emu-eap-noob-01

[Mohit Sethi M <[e-mail]>]

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 <[e-mail]><mailto:[e-mail]> 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 <[e-mail]><mailto:[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-







_______________________________________________
Emu mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/emu