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

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Jul 2020 13:12:21 -0400

Speaking as a WG participant.

Dave Thaler via Datatracker <[email-masked]> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mohit Sethi M <[email-masked]>
Date: Sat, 11 Jul 2020 13:27:06 +0000

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:

--
Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 11 Jul 2020 15:40:25 +0200

Hi Mohit,

> On 2020-07-11, at 15:27, Mohit Sethi M <mohit.m.sethi=[email-masked]> wrote:
> 
> Hi Michael,
> 

That paper simply translates a JSON-like structure into CBOR, without using any of the additional benefits of using CBOR (e.g., numeric map labels).
So I would expect the benefits of moving to CBOR to be larger than described in this paper.

> 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,…

RFC 8152 does have a section structure, so you don’t need to read all of it to just get the equivalent of JWK.

> - Adding an external library dependency implies that the overall system becomes more brittle. 

To the contrary.  An implementation of JSON just for one application is likely to have received less testing and overall development attention than an industrial-strength library.  If you for some reason don’t agree with that, you can always create another CBOR implementation in an afternoon :-)

> - Updating and maintaining two components is definitely harder than one. 

Not sure I follow.

> As said, this is worth discussing at the meeting since it would result in a large change to the existing EAP-NOOB implementations. 

Certainly!
I just wanted to make sure you don’t make your decision for the wrong reasons.

Grüße, Carsten

---

From: Mohit Sethi M <[email-masked]>
Date: Sat, 11 Jul 2020 15:03:59 +0000

Thanks Carsten. This is very valuable input for the working group before 
it makes a critical decision.

--Mohit

On 7/11/20 4:40 PM, Carsten Bormann wrote:
>> What is more important is that wpa_supplicant currently has a JSON encoder and parser (https://protect2.fireeye.com/v1/url?k=be5e912f-e0fe3fe2-be5ed1b4-866132fe445e-d1e084c426bf1ae9&q=1&e=3870678c-1f3b-4f09-8cde-269a88395e80&u=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Ftree%2Fsrc%2Futils%2Fjson.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://protect2.fireeye.com/v1/url?k=e6a1854a-b8012b87-e6a1c5d1-866132fe445e-29d16d211c0fc3e9&q=1&e=3870678c-1f3b-4f09-8cde-269a88395e80&u=https%3A%2F%2Fcbor.io%2Fimpls.html. However this has two major downsides:
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 11 Jul 2020 18:49:48 -0700

> RFC 8152 does have a section structure, so you don’t need to read all of it to just get the equivalent of JWK.

draft-ietf-cose-rfc8152bis-struct and draft-ietf-cose-rfc8152bis-algs have
section structure, too :)

-Ben