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