[Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

Hi, Bernard brought up compability with RFC 4137 and the need for protected alternate indication of success in the context of EAP-TLS 1.3 https://mailarchive.ietf.org/arch/msg/emu/F-LcEX3UbAEX20Amk0xBBqfPQNQ/ I think we need to discuss this in a general EAP setting as this in not EAP-TLS

Re: [Emu] EAP-TLS and TLS alerts

On Feb 6, 2021, at 1:01 AM, John Mattsson wrote: > > I personally fine with writing MUST send an Error alert if the WG wants that. This is what all implementations have done for ~15 years. The TLS Alert satisfies the "altReject" requirements of RFC 4137. Which means it's a very good iea.

Re: [Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

Hi John, all: First of all my apoligies if some thoughts in my e-mail have been already discussed. Please see inline. > El 6 feb 2021, a las 10:43, John Mattsson > escribió: > > Hi, > > Bernard brought up compability with RFC 4137 and the need for protected > alternate indication of

[Emu] Consensus call for result indicators in EAP-TLS 1.3

There is growing support for mandating result indicators for EAP-TLS 1.3. The result indicators help protect the EAP protocol exchange in the many different types of environments EAP-TLS is used and make the integration with the EAP state machine clearer. This has the impact of adding a round

Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

Joseph Salowey wrote: > There is growing support for mandating result indicators for EAP-TLS > 1.3. The result indicators help protect the EAP protocol exchange in > the many different types of environments EAP-TLS is used and make the > integration with the EAP state machine