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

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

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

; > > Cheers, > > John > > > > *From: *Mohit Sethi M > *Date: *Monday, 8 February 2021 at 06:33 > *To: *John Mattsson , Bernard Aboba < > bernard.ab...@gmail.com>, "emu@ietf.org" , "t...@ietf.org" < > t...@ietf.org> > *Subject:

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

: Mohit Sethi M Date: Monday, 8 February 2021 at 06:33 To: John Mattsson , Bernard Aboba , "emu@ietf.org" , "t...@ietf.org" Subject: 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] a

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

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

On Feb 4, 2021, at 9:22 AM, John Mattsson wrote: > I think the major decision for the EMU WG to make going forward is to agree > if EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not > discuss the EAP state machine at all, but in TLS 1.2 the server finished can > be

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

; if (aaaEapKeyData != NONE) > > aaaEapKeyAvailable = TRUE > > > > I therefore only described when the "keying material becomes available" > which is the words used by RFC 4137 for eapKeyData and aaaEapKeyData. > > > > Open question if Section 2.5 shoul

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

oba , "emu@ietf.org" , "t...@ietf.org" Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine I think the major decision for the EMU WG to make going forward is to agree if EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not discuss the EAP st

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

, I do not think any future additions to TLS 1.3 would be needed for EAP-TLS 1.3. From: John Mattsson Date: Thursday, 4 February 2021 at 13:18 To: Bernard Aboba , "emu@ietf.org" , "t...@ietf.org" Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine Hi B

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

Hi Bernard, I (re-)read the papers you send. - "Extensible Authentication Protocol Vulnerabilities and Improvements Improvements" This paper talks attacks on availability by spoofing messages. It looks into a small amount of ways where spoofed messages causes the TLS connection to fail,

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

On Feb 3, 2021, at 1:51 PM, Michael Richardson wrote: > My understanding is that: > 1) the TLS Finish message can now occur prior to the client certificate > even being transmitted, let alone validated. > This is a feature in TLS 1.3 that lets application data in the > typical

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

I haven't been able to follow all of thread on the impedance mismatch between EAP and TLS, which the EAP-TLS specification is intended to resolve. (I did talk on the phone with Alan yesterday, and he recapped some issues for me. My other qualification is that I implemented EAP-SIM 20 years ago,

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

On Feb 3, 2021, at 8:32 AM, John Mattsson wrote: > I seriously don't know where you got all of the above from. I only summarized > the earlier discussion. I did not state any opinions. I'm asking you as author to understand, explain, and defend the draft that you wrote. The issue is

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

Alan DeKok wrote: >Does that mean all open issues have been addressed and resolved? > >The current suggestion from Eric is to *not* use application data, but to use >>CloseNotify instead. Does this mean the earlier discussion was wrong, or is >the >current suggestion wrong? Are we allowed to

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

On Feb 3, 2021, at 5:26 AM, John Mattsson wrote: > At the same meeting it was also ruled out to use the Reserved bits in EAP-TLS > header and to make EAP-Success carry payload. Latency and security was > discussed a lot with Bernard keeping the security high and Jouni expressing > on the

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

Cheers, John -Original Message- From: John Mattsson Date: Wednesday, 3 February 2021 at 00:48 To: "emu@ietf.org" Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine Alan wrote: > wrote: >> 4. was something I thought was clear. The -13 version state

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

On Tue, Feb 2, 2021 at 2:10 PM Alan DeKok wrote: > On Feb 2, 2021, at 4:42 PM, John Mattsson 40ericsson@dmarc.ietf.org> wrote: > > 4. was something I thought was clear. The -13 version states that “The > EAP-TLS server commits to not send any more handshake messages”. This was > according

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

Alan wrote: > wrote: >> 4. was something I thought was clear. The -13 version states that “The >> EAP->TLS server commits to not send any more handshake messages”. This was >> >according to my memory exactly what was requested from the implementors. > > The text is in

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

On Feb 2, 2021, at 4:42 PM, John Mattsson wrote: > 4. was something I thought was clear. The -13 version states that “The > EAP-TLS server commits to not send any more handshake messages”. This was > according to my memory exactly what was requested from the implementors. The text is in

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

Hi, Bernard Aboba wrote: > The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3 > interacts with the EAP state machine as specified in RFC 4137 > The issue in the EAP-TLS 1.3 specification is that the interlock with these > variables is not defined It is definitely true