+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> wrote: > On Wed, 19 Jul 2023 at 11:45, Dan Garcia Carrillo <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 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
