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

[Carsten Bormann]

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  wrote:
> 
> On 2020-07-31, at 09:25, Aura Tuomas  wrote:
>> 
>> 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.
> 
> 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
> 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Carsten Bormann]

On 2020-07-31, at 09:25, Aura Tuomas  wrote:
> 
> 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.

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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Aura Tuomas]

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  On Behalf Of Carsten Bormann
Sent: Saturday, 11 July, 2020 16:40
To: Mohit Sethi M 
Cc: draft-ietf-emu-eap-noob@ietf.org; emu@ietf.org; Dave Thaler 
; iot-director...@ietf.org
Subject: Re: [Emu] [Iot-directorate] Iotdir early review of 
draft-ietf-emu-eap-noob-01
Importance: High

Hi Mohit,


> On 2020-07-11, at 15:27, Mohit Sethi M 
>  wrote:
> 
> 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

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, JWA (as far as I understand). 
> Following smaller modular specifications was somehow easier at the time. 

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

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

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 
&g

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

[Benjamin Kaduk]

On Sat, Jul 11, 2020 at 03:40:25PM +0200, Carsten Bormann wrote:
> Hi Mohit,
> 
> 
> > On 2020-07-11, at 15:27, Mohit Sethi M 
> >  wrote:
> > 
> > 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. 
> 
> 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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Mohit Sethi M]

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:
> Hi Mohit,
>
>
>> On 2020-07-11, at 15:27, Mohit Sethi M 
>>  wrote:
>>
>> 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
> 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, JWA (as far as I 
>> understand). Following smaller modular specifications was somehow easier at 
>> the time.
> RFC 8152 does have a section structure, so you don’t need to read all of it 
> to just get the equivalent of JWK.
>
>> 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=1=3870678c-1f3b-4f09-8cde-269a88395e80=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=1=3870678c-1f3b-4f09-8cde-269a88395e80=https%3A%2F%2Fcbor.io%2Fimpls.html.
>>  However this has two major downsides:
>>
>> - 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
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Carsten Bormann]

Hi Mohit,


> On 2020-07-11, at 15:27, Mohit Sethi M 
>  wrote:
> 
> 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

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, JWA (as far as I understand). 
> Following smaller modular specifications was somehow easier at the time. 

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

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

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

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Mohit Sethi M]

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  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 , 
Sandelman Software Works
 -= IPv6 IoT consulting =-







___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Michael Richardson]

Speaking as a WG participant.

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





signature.asc
Description: PGP signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu