Hi
> On 20 Mar 2019, at 11:03, Jim Schaad <i...@augustcellars.com> wrote:
>
> TLS 1.3 introduced early application data; if a server receives a client
> hello with early application data it MUST abort the handshake with an
> EAP-Failure. The server MAY generate a TLS-Alert as well.
This precise text actually may have implications for onboarding, where the
notion is to validate the data retrospectively. In particular this impacts the
previous statement: The EAP server MUST authenticate with a certificate and
SHOULD require the EAP peer to authenticate with a certificate.
draft-ietf-anima-bootstrapping-key-infra defers the authentication during
onboaridng stages, which I would expect draft-lear-eap-teap-brski to do as
well. However, the purpose of the deferral is extremely limited, and the
information exchanged must be authenticated in order for any state generated to
be retained.
Some eyes on this particular aspect would be useful next week.
Eliot
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
