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

[Alan DeKok <[e-mail]>]

On Feb 4, 2021, at 9:22 AM, John Mattsson <john.mattsson=[e-mail]> 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 used as an alternative success indication.

  Yes.  Unfortunately 5216 didn't pay enough attention to 4137.  That happens.

> close_notify might be possible to turn into an alternative success indication if the TLS implementation can be profiled to not send any close_notify by itself. I don't know if there are any cases where an implementation would send close_notify without the application telling it to.

  I  think the TLS libraries rely on the application to initiate close_notify.

> If the wg agrees that an authenticated alternative success indication is needed (this is to my understanding needed in e.g. 802.11) then the process would be that the EAP-TLS server first process the second flight from the client, if that verifies correctly, the server send application data commit message / close_notify.

  Yes.

> Introducing an authenticated alternative success indication would not require any changes to the -14 message flows. In -13 the commitment message would have to be sent in a later flight than server finished.

   Yes.  However, I don't think that the close_notify can be sent before verifying the client cert, because IIRC, that closes the TLS connection (server side), and prevents it from sending TLS alerts.

> If a mandatory authenticated alternative success indication is introduced in EAP-TLS 1.3, I do not think any future additions to TLS 1.3 would be needed for EAP-TLS 1.3.

  Yes.

  Alan DeKok.