Re: [Emu] Iotdir early review of draft-ietf-ace-wg-coap-eap-08
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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Iotdir early review of draft-ietf-ace-wg-coap-eap-08
On Jul 5, 2023, at 4:09 AM, Eliot Lear via Datatracker wrote: > 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. I agree. My $0.02 is that there are very few stand-alone EAP authentication libraries suitable for integration into CoAP. I suspect that most use-cases will proxy the EAP packets to an AAA server. Some more nit-picks on text: Section 2: >> The IoT device will act as a CoAP server for this service, and the EAP >> authenticator as a CoAP client. The rationale behind this decision, as >> expanded later, is that EAP requests go always from the EAP server to the >> EAP peer. Accordingly, the EAP responses go from the EAP peer to the EAP >> server. I don't know that this issue of "who gets the request or response" matters. In RADIUS, the Access-Request packet contains the EAP response. That's fine. i.e. the EAP layer shouldn't change the role of the parties in a CoAP conversation. If the IoT device is normally the CoAP client, then just keep it as the CoAP client for EAP. it's fine. >> It is worth noting that the CoAP client (EAP authenticator) MAY interact >> with a backend AAA infrastructure when EAP pass-through mode is used, which >> will place the EAP server in the AAA server that contains the information >> required to authenticate the EAP peer. When the EAP packets are proxied to an AAA server, the keying material comes back in the attributes MS-MPPE-(Send/Recv)-Key. RFC 5216 Section 2.3 defines those attributes as containing the MSK. This document should explain that connection, reference 5216, and explain how to derive the MSK from the MS-MPPE keys. Reading the document shows an unclear discussion of what is meant by "keying material". Perhaps the text could be updated to explain this: >> EAP methods transported in CoAP MUST generate cryptographic material >> [RFC5247] in an MSK for this specification. The MSK is used as the basis >> for further cryptographic derivations. And later: >> For this specification, the EAP method MUST be able to derive keying >> material (MSK). Section 3: >> In CoAP-EAP, the IoT device (EAP peer/CoAP server) will only have one >> authentication session with a specific Controller (EAP authenticator/ CoAP >> client) and it will not process any other EAP authentication in parallel >> (with the same Controller) It may be worth noting that the controller may have parallel EAP sessions with multiple IoT devices. Just to make it very clear that the limitation on the IoT device is not a limitation on the Controller. Section 3.2: >> The message also includes a URI in the payload of the message to indicate to >> what resource (e.g. '/a/x' It would be good to give guidance here on choosing the URI. The examples of "a/x" and then "a/y" are generic, but could give insufficient guidance to implementors. Perhaps it is worth suggesting that the implementors choose a URI with a common format, which can aid with implementation and administrator debugging. The resource could be "path/eap/counter". e.g. * "path" is some local path on the device to make the path unique. This could be omitted if desired. * "eap" îs the name which indicates that the URI is for the EAP peer. This has no meaning for the protocol, but helps with debugging. * "counter' which is an incrementing unique number for every packet. So the examples can use "path/eap/1", and then "path/eap/2", etc. Without such a suggestion, there is a temptation for implementors to come up with their own schemes, which are likely to be worse that this one. e.g. just using the same URI every time, or deriving the URI from some kind of hash, etc. Section 3.3: >> When the CoAP-EAP state is close to expiring, the IoT device MAY want to >> start a new authentication process Nit: I don't think MAY needs to be uppercase here. Section 6.1: >> Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 octets or >> greater. CoAP assumes an upper bound of 1024 for its payload which covers >> the requirements of EAP To address Eliots comments this should be fine. But it should be highlighted more strongly. I would also suggest adding a note that when EAP is proxied over an AAA framework, the Access-Request packets MUST contain a Framed-MTU attribute with value 1024. This attribute signals the AAA server that it should limit is responses to 1024 octets. If the Framed-MTU attribute isn't included, then the AAA server could assume that the EAP packets are going over Ethernet, and assume an MTU ion 1536 octets. Which will cause this specification to silently break.
[Emu] Iotdir early review of draft-ietf-ace-wg-coap-eap-08
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. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
