On Jul 5, 2023, at 4:09 AM, Eliot Lear via Datatracker <nore...@ietf.org> 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. It's also worth discussing AAA issues in more detail. e.g. what to do when the AAA server doesn't reply. Does the Controller silently drop the EAP session? Does it send a notification to the IoT device that this has happened? Section 6.2: >> On the other hand, when taking into account the EAP method overload, this >> reduction is less but still significant if the EAP method generates large >> EAP messages. If the EAP method is very taxing, the impact of the reduction >> in the size of the EAP lower layer is less significant. I'm not clear what this discussion means. Given that the EAP packets can be forced to be no more than 1024 octets, the only difference between EAP methods is the number of packets exchanged, and the total amount of data exchanged. Current EAP supplicants and authenticators limit the total number of exchanges to 50 or 100, depending on various factors. Is there a similar limit for CoAP? i.e. will CoAP go fail if there is 64K of data being exchanged in EAP? >> This leads to the conclusion that possible next steps in this field could be >> designing new EAP methods that can be better adapted to the requirements of >> IoT devices and networks. I'm wary of such a suggestion. EAP is widely used outside of CoAP. Adding new EAP methods also means that those EAP methods can be used in other circumstances, which don't have the transport security / reliability provided by CoAP. Other EAP methods which may be suitable for CoAP include EAP-PWD, which is also small and has few exchanged. Even EAP-TLS may not be that bad, as EAP-TLS provides for PSK authentication. Even when certificates are used, the total packet exchanges are ~18 rounds, and maybe 20K or so. Session resumption is reduces that to maybe 4 rounds, and a few K of data. Would that be too much for this use-case? Alan DeKok. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
