Early Review of draft-ietf-ace-wg-coap-eap-08
review-ietf-ace-wg-coap-eap-08-iotdir-early-lear-2023-07-05-00

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.

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.

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.

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

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.