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, and I did some EAP over IKEv1 work at one point)
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.
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!
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)
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.
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.
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.
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.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
