Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

John said: "Based on your comments it seems like protected success indication is not needed in IEEE 802 for security reasons." [BA] As described in RFC 4137, protected success indications prevent attacks involving injection of unprotected EAP-Failure indications, as well as enabling key synchro

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Mohit -- The authors of RFC 4137 were among the group (Bill Arbaugh's team and UMD) that wrote paper [2]. The goal of that RFC was to address the security vulnerabilities they found, which were considered serious enough to block the deployment of EAP and IEEE 802.11. As a result, RFC 4137 is wid

Re: [Emu] Key Derivation for EAP-TLS 1.3

On Feb 7, 2021, at 10:46 PM, Martin Thomson wrote: > What I was concerned about was the information that is exchanged in EAP > *before* the TLS handshake begins that might affect the choice of certificate > to offer. As this is not authenticated at all, there are trivial attacks if > a client

Re: [Emu] Key Derivation for EAP-TLS 1.3

On Feb 7, 2021, at 9:27 PM, Joseph Salowey wrote: > > I'd like to get feedback from the working group on the EAP-TLS 1.3 key > derivation. Does this improve the security of the system? Are there any > implementation barriers? > > The key derivation for TLS 1.3 uses the key exporters defined

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Bernard: RFC 4137 says: altAccept (boolean) Alternate indication of success, as described in [RFC3748]. altReject (boolean) Alternate indication of failure, as described in [RFC3748]. Is it referring

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

John, This may be a side note in the TLS discussion, but just looked at the below list: > Looking at the other active documents in the EMU WG: > > draft-ietf-emu-rfc5448bis > draft-ietf-emu-aka-pfs > […] > None of them has a protected alternate indication of success […] And it seems to me that

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

>This consensus call has two parts: > >1. Please respond to the list if you support adding explicit result >indications of success and failure from the EAP Server to the EAP Peer in >EAP-TLS 1.3. If you object please respond to the list indicating why. I support this based on that implementors su

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

Thanks, Good to know that RFC 5448 (EAP-AKA’) and aka-pfs have protected result indicators. I missed that RFC 5448 gets this from RFC 4187. John -Original Message- From: "jari.ar...@piuha.net" Date: Monday, 8 February 2021 at 18:07 To: John Mattsson Cc: EMU WG Subject: Re: [Emu] Gen