Dear Heikki,
Thank you for your comments.
Please see some notes inline.
El 27/7/23 a las 16:07, Heikki Vatiainen escribió:
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.
Even when fragmentation can happen in both ways, in the case the EAP
peer implementation does not do fragmentation, we can rely on two
mechanism in CoAP-EAP to facilitate this process at the lower layer
level. First, establishing the next message exchange through HATEOAS
that does not limit the number of exchanges, and second through the CoAP
Block-wise transfer.
With TLSv1.3 it's possible to omit the CA certificates:
https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc8446*section-4.4.2__;Iw!!D9dNQwwGXtA!RGy9Uwspf6LAcjxwtzYVqxgMobXDWWcptIGwvwQmt1VhSYS_Q3aumyBFPxxNor3QJxlofbU4ZT0UD8WguEw$>
... 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.
Thank you for this point. Even thought large transfers from both sides
are not a problem, it could be interesting to recommend the use of the
latest version of EAP-TLS.
Following this direction, we could add text that recommends for
constrained scenarios, the use of EAP methods that employ few messages
and bytes, with the goal of economisation needed in these cases.
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
