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.
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
