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

Hi, Martin Thompson 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 uses that information to gu

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

Thanks Mohit, Based on your comments it seems like protected success indication is not needed in IEEE 802 for security reasons. Would be good with more feedback on this. EAP-TLS 1.3 might get a protected success indication anyway, but the draft should have a few sentences about what the alterna

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

Hi all, I have now read both the papers. I am not sure the attacks in [2] are anymore possible: - The first attack described in section 4.1.1 shows that an EAP-Success leads to an unconditional transition to the Authenticated state irrespective of the current state. However, I am not sure this

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

On Mon, Feb 8, 2021, at 13:27, Joseph Salowey wrote: > Both Martin and Ben proposed adding the peer identity into the context > parameter for the TLS exporter key derivation. So I wasn't suggesting the client certificate, as that is covered by the client key confirmation and (I think) the resul

[Emu] Key Derivation for EAP-TLS 1.3

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 for TLS 1.3. A few reviews have pointed out that the exporter mast

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

Hi all, I am catching up on all the discussion of protected indication of success. I think it is important to note that protected indication of success can be exchanged in both directions (i.e. peer to server and server to peer). For example, RFC 3748 says: For example, within EAP-TLS [RFC2

Re: [Emu] Session tickets in TLS 1.3

On Feb 7, 2021, at 6:11 AM, John Mattsson wrote: > > Alan DeKok wrote: > >> The document should explain this in detail, and suggest which message flows >> are preferred, and which >ones MUST be supported. It should explain what >> happens when resumption is negotiated, and 20 >> tickets are

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

On Feb 6, 2021, at 8:22 PM, Joseph Salowey wrote: > 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 it. > 2. Plea

Re: [Emu] EAP-TLS and TLS alerts

Alan DeKok 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. Jorge said offline th

Re: [Emu] Session tickets in TLS 1.3

Alan DeKok wrote: >The document should explain this in detail, and suggest which message flows >are preferred, and which >ones MUST be supported. It should explain what >happens when resumption is negotiated, and 20 >tickets are received by the peer. What does that mean? What does the peer do

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

Hi, I think it is important to point out that the discussion has been about _protected_ result indications. RFC 3748 discussed protected and non-protected result indications. Also worth noting that it is not possible with protected failure indication when the server does not accept the ClientHe