On Feb 3, 2021, at 1:51 PM, Michael Richardson <mcr+i...@sandelman.ca> 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 browser->http server occur very early. > > 2) As such, it is possible to run the TLS-Exporter function prior to > actually having authenticated the client. > This is part of the TLS 1.3 changes that essentially permit either > end to (re-)authenticate at any point in the protocol. > > 3) The EAP-Success message is not authenticated in any way.
Yes. > So it seems to be that: > > a) The EAP-Success is meaningless. The client needs to process it, but > it should not affect the state machine at all! It really seems so. The EAP-Success is largely a signal to the Access point / NAS / etc. that EAP has succeeded. This signal needs to be independent of EAP type, so it's just a 4 byte "Success" packet. > b) Success means being able to use the derived keys. > The keys won't be installed by the AAA server into the authenticator > until it has performed appropriate validation of the client. > (e.g, received and validated the client certificate) The key here is that the AAA server *can* define the keys earlier. We may want to update the key derivation, so that the keys are derived from the client / server certificates, too. > c) More important than EAP-Success, is legitimate failure. They need to be > unforgeable by an attacker. Success is easy to determine, and > progress is easy to move forward with. What breaks forward motion are > failure messages. They need to be properly authenticated. RFC 8446 Section E.1 says: As soon as the client and the server have exchanged enough information to establish shared keys, the remainder of the handshake is encrypted, thus providing protection against passive attackers, So the TLS Alert messages would seem to be encrypted. It would be good to get clarification on this. If true, it's one less thing that we have to worry about. If the TLS alert messages are encrypted, then they can't be forged. A malicious actor could forge EAP-Failure, but RFC 3748 Section 7.16 says that peers should ignore unexpected failures: ... a peer silently discards a Failure packet received at a point where the method does not explicitly permit this to be sent. For example, a method providing its own error messages might require the peer to receive an error message prior to accepting a Failure packet. > While EAP-TLS does not really do anything with the resulting TLS channel > afterwards, there are some protocols like EAP-TEAP (and BRSKI-TEAP), that > would like to use the channel afterwards. So anything learnt in EAP-TLS 1.3 > will get repeated. Yes. We do need to ensure that whatever is done here will work for all other TLS-based EAP methods, for both the "full authentication", and the "resumption" exchanges. > My instinct is that the best thing would be to have a TLS-level message which > EAP-TLS 1.3 should define. This is the real success or failure message. TLS > libraries would have to cope. I'm not sure that changing TLS is appropriate here. But I can see how it would be useful. The "hacky" way to add signalling to EAP-TLS is to just send application data inside of the tunnel. The (eventual) follow-on question is then how that affects other TLS-based EAP methods. > The application data, byte, vs zero-length data discussion seems to be > basically dancing around this. TLS 1.3 is too flexible, and we can't either > constrain the TLS 1.3 state machine, nor can we depend upon it anymore the > way that one could with 1.2. Yes. It looks now like the main issue is getting an *authenticated* success from the EAP server to the EAP peer. Neither CloseNotify, not the Commitment message are sufficient for that purpose. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
