The fragmentation issue that Heikki mentions is specific to EAP over RADIUS, where RADIUS is using UDP transport. It isn’t a property of EAP itself, and so I don’t follow why this makes EAP impractical for IoT.
Josh From: Emu <emu-boun...@ietf.org> On Behalf Of Behcet Sarikaya Sent: Thursday, July 27, 2023 9:39 PM To: Heikki Vatiainen <h...@radiatorsoftware.com> Cc: iot-director...@ietf.org; draft-ietf-ace-wg-coap-eap....@ietf.org; e...@ietf.org; ace@ietf.org Subject: Re: [Emu] [Ace] [suspect] Re: Iotdir early review of draft-ietf-ace-wg-coap-eap-08 +1 to Heikki. I think the use of AAA, in particular EAP for IoT is simply not practical, thanks to Heikki for making this specific. It could be theoretically beautiful though :) Behcet On Thu, Jul 27, 2023 at 7:08 AM Heikki Vatiainen <h...@radiatorsoftware.com <mailto:h...@radiatorsoftware.com> > wrote: On Wed, 19 Jul 2023 at 11:45, Dan Garcia Carrillo <garcia...@uniovi.es <mailto:garcia...@uniovi.es> > wrote: On 5/7/23 15:36, Alan DeKok wrote: > 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? We tried not to go there in the document, just to acknowledge that CoAP fits the requirements for an EAP lower layer. In any case, EAP messages larger than 1024 could be sent using CoAP Block-wise transfer, that will seamlessly take care of sending payloads larger than CoAP Minimum MTU. A couple of additional notes about EAP authentication exchange and its data use. First, if look at EAP-TTLS and PEAP but not EAP-TLS, it may seem that the authentication exchange is very asymmetric in how it uses data. The EAP server sends a long certificate chain and the client sends very little with many of client responses being just simple ACKs that tell the server to continue. EAP-TLS, especially with TLSv1.2 and earlier, uses plenty of data for both directions. EAP servers know how to fragment the data but clients sometimes may attempt to send messages that get fragmented by the lower layer and may get lost in transit (firewalls etc. being a problem). The problem with clients is typically that there may not be a setting or a method that tells the client to use a certain EAP message size. In other words, EAP-TLS, for example, supports fragmentation, but the clients especially may now know how small the fragment needs to be when they send out their client certificate and its associated CA certificate chain. Some EAP methods, such as PEAP and EAP-TTLS allow running EAP-TLS as the inner authentication method, which means you have TLS within TLS and client fragmentation becomes even more complex. Servers typically know how to handle this too. This is not the most common thing to do, but with TLSv1.2 is the method to hide client certificate information when using EAP-TLS. To summarise: with EAP-TLS there is typically large amount of data transferred in both directions. With TLSv1.3 it's possible to omit the CA certificates: https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2 ... a certificate that specifies a trust anchor MAY be omitted from the chain ... This can be a large size saver, but please see the whole paragraph too. The CA certificates (trust anchors) would need to be know be the other TLS endpoint if this is done. This is yet another good reason to use TLSv1.3 even though TLSv1.2 and earlier still remain in wide use with TLS based EAP methods. -- Heikki Vatiainen h...@radiatorsoftware.com <mailto:h...@radiatorsoftware.com> _______________________________________________ Ace mailing list Ace@ietf.org <mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
