Subject: Re: [Emu] [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

---

From: Aura Tuomas <[email-masked]>
Date: Thu, 30 Jul 2020 19:04:51 +0000

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 <[email-masked]> 
Sent: Saturday, 13 June, 2020 03:40
To: [email-masked]
Cc: [email-masked]; [email-masked]
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.

> 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.)

---

From: Aura Tuomas <[email-masked]>
Date: Fri, 31 Jul 2020 07:25:52 +0000

I understand the issues that have been discussed: (1) feature completeness of the specification, (2) availability of implementations, and (3) compactness of the binary encoding. We initially, in 2016, considered ASN.1, CBOR and JSON as equal candidates and rejected CBOR because the specification and implementation were not mature at the time. While CBOR now has both the features (issue 1) and implementations (issue 2), I hesitate to make such a big change so late in the standardization process. The compactness of the binary representation (issue 3) make little difference because EAP-NOOB is a bootstrapping protocol; the efficiency gains of CBOR would be more significant in payload data or signaling that continues throughout the device lifetime. 

There is, however, another issue that always bothered me much more. It is the ability to verify the HMAC correctly.

That is, my biggest concern with both JSON and CBOR is (4) the lack of canonical binary serialization. IN EAP-NOOB, we need to receive a serialized data message, extract some fields and subtrees, compose an HMAC input out of these parts of the data, and reliably compute always the same HMAC on it. The easy but flawed implementation would be to decode the received message, extract the selected parts, and then re-encode them, but the lack of canonical encoding means that the resulting byte string could be different in different encoder/decoder implementations. 

For the above reason, we have to extract the unmodified binary encoding of received messages. Some JSON libraries provide access to the unmodified binary encoding of document parts, but many either have no such function, return the Unicode serialization but no binary one, or do not guarantee that the returned byte string is unmodified. When we initially looked at CBOR, I expected it to solve this problem but found that, just like for JSON, there was no such function and we had to read the code of the decoder/encoder implementations to figure out a solution. 

A theoretical advantage of CBOR over JSON in this respect is that CBOR is serialized directly to a byte string while JSON is serialized to a Unicode string, which is then encoded as a byte string. This means that it may be easier for a CBOR library to provide access to the unmodified binary representation of fields and subtrees of received messages. But if the specification does not require them to provide that access, there is no real difference to JSON.

Tuomas

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Carsten Bormann
Sent: Saturday, 11 July, 2020 16:40
To: Mohit Sethi M <mohit.m.sethi=[email-masked]>
Cc: [email-masked]; [email-masked]; Dave Thaler <[email-masked]>; [email-masked]
Subject: Re: [Emu] [Iot-directorate] Iotdir early review of draft-ietf-emu-eap-noob-01
Importance: High

Hi Mohit,

Not sure I follow.

Certainly!

Grüße, Carsten

[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 31 Jul 2020 09:51:21 +0200

> That is, my biggest concern with both JSON and CBOR is (4) the lack of canonical binary serialization. IN EAP-NOOB, we need to receive a serialized data message, extract some fields and subtrees, c…

rfc7049bis (in IETF last call, ends 2020-08-14) provides rules for deterministic encoding (called canonical in RFC 7049).
I am not a big fan of protocols that require its use, but if that is your design, CBOR has the support.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 31 Jul 2020 15:21:33 +0200

The point that came up in the discussion is how deterministic encoding would work with the extension points.

I said that it is easy to isolate extension points via encapsulation of an encoded CBOR data item in a byte string — that causes a generic decoder to hand up that byte string (which can then be decoded separately, and which can go into a signature input unchanged).

Tuomas noted that the extension points are not very clearly delineated in the document.  My personal recommendation would be to make those very explicit (*).

I maybe didn’t understand part of the discussion; it seemed that you currently require something of your JSON libraries that is much less widely implemented than canonical/deterministic encoding in CBOR libraries.

I do understand that this change requires work in implementations.  I cannot comment on whether getting this right or getting this done quickly is more important.

Grüße, Carsten

(*) My personal recommendation would also be to define the data structures and their extension points using some formal technique.  Independent of whether they are JSON or CBOR, CDDL (RFC 8610) fits the bill.

> On 2020-07-31, at 09:51, Carsten Bormann <[email-masked]> wrote:
>