Re: [Emu] Iotdir early review of draft-ietf-ace-wg-coap-eap-08

[Dan Garcia Carrillo <[e-mail]>]

Hi Eliot,

Thank you very much for your time to review the document.


On 5/7/23 10:09, Eliot Lear via Datatracker wrote:
> Reviewer: Eliot Lear
> Review result: On the Right Track
>
> This draft provides a means for EAP authentication via CoAP.  This is
> an evolution on top of EAPoL/EAP so as to not require 802.1X on
> certain classes of devices.  The general goal of reusing existing EAP
> methods – and code – is admirable.

Thank you very much, this was one of the objectives of the work.

>
> I would like to bring several issues to the attention of the working group:
>
> 1.  There is, I think, a fundamental change between 802.1X and CoAP
> that needs to be better stated: when used without a bypass (MAB),
> 802.1X prevents *any* IP connectivity to a network.  While Section 7.1
> discusses authorization, it does not really note this aspect, and in
> my opinion it should.


This is an interesting point. Yes, indeed CoAP and 802.1X are different, 
and to be able to work with CoAP we would have to allow one-hop  
link-local connectivity (with the possibility of using a proxy), without 
L2 protection until the authentication is completed.

We will add these consideration to the document.

>
> 2.  While the draft describes out to derive an EMSK, and while the
> appendices begin to talk about application, it would be good to show
> at least one entire flow in which that EMSK is used by L2, and in
> particular may I suggest any of the 802.15.4 specifications such as
> THREAD.  A key point is that many of these technologies have their own
> encryption practices, and understanding how they fit together will
> make this work far more applicable.  I suggest this because it is not
> clear to me how to bridge the gap.

To secure L2 after the authentication is completed, we can follow 
different models, depending on the objective.

- We could use CoAP-EAP to derive the needed PSK to run 6TiSCH 
Constrained Join Protocol (CoJP) [RFC9031].

- If we want to have a network shared key shared among all devices at 
L2, we can follow the process Zigbee IP does. They use PANA as EAP lower 
layer for authentication and delivering a network-wide key to the 
authenticated devices. The MSK is used only for securing the PANA 
security association. Analogously, with CoAP-EAP, once performed the 
authentication of the EAP peer, it can receive through the CoAP-EAP 
security association (OSCORE) the needed L2 security configuration in 
the CoAP-EAP_Info CBOR Object securely.

- If we want to deliver pairwise keys at L2, once the EAP authentication 
is finished (without L2 security yet), we can derive pair-wise keys 
either with the MSK or the EMSK.

We understand that your comments on the EMSK is for the purpose of using 
a different root key, right? So MSK can be used to protect CoAP-EAP and 
EMSK for other purposes (e.g., L2 security). This would imply, though, 
that we would have to distribute to the EAP authenticator the MSK and a 
key that is derived from the EMSK at the same time.

We could also simplify things and use the MSK as root key, using 
different tags when deriving keys for different purposes.

What do you think?



>
> 3.  The terminology is a problem.  On the one hand, some people like
> to use the terms "IoT Device" and "Controller".  In the EAP world,
> this term is meaningless.  We use "peer", "authenticator", and
> "authentication server".  I would suggest that those implementing this
> work will be from the EAP world, and that this document will be far
> more accessible to them if those terms are used.  Also, the use of
> "IoT Device", while demonstrating application, limits applicability of
> the work.  In the immortal words of Larry Wall, "So don't do that."


Thank you for this point, surely we do not want to limit the applicability.

We will fall back to using only EAP terminology to avoid issues.


>
> 4.  The discussion about packet sizes is interesting, but too
> abstract.  Some form of an example involving the use of certificates
> seems in order, since the most taxing examples may involve methods
> such as EAP-FAST, TEAP, and EAP-TLS.  These have been made to work
> perfectly reasonably across 802.11 networks, and a reasonable question
> is whether any adaption layer for smaller MTUs should occur here,
> doubly so since the draft state:
>
>     Lower layers need to provide an EAP MTU size of 1020
>     octets or greater.
>
> I realize this is a can of worms.  Certainly fellow EMU colleagues
> will have had more experience at opening and managing it than I have.
>
I think this is solved by EAP itself. According to RFC3748:

"EAP methods can assume a minimum EAP MTU of 1020 octets in the absence 
of other information. EAP methods SHOULD include support for 
fragmentation and reassembly if their payloads can be larger than this 
minimum EAP MTU."


Thank you.


>
>
>