On Feb 4, 2021, at 9:22 AM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
