On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok <al...@deployingradius.com>
wrote:
> On Feb 1, 2021, at 3:00 PM, Joseph Salowey <j...@salowey.net> wrote:
> > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
> CloseNotify.
>
> With TLS 1.2, the server sends TLS Finished to the client *after* it
> sees the client cert.
>
> With TLS 1.3, the server sends TLS Finished to the client *before* it
> sees the client cert.
>
> So the question is: when the client sees EAP-Success, has it's
> certificate been verified? If there's no more TLS exchange server ->
> client, then malicious parties can forge an EAP-Success, and the client
> doesn't know any better.
>
> This attack isn't possible in TLS 1.2, because the client receives the
> TLS Finished from the server, as a *positive* acknowledgement that the
> server has authenticated the client. In addition, the TLS exporter keys
> are not available until after the server sends TLS Finished.
>
>
[Joe] There are some cases the finished will fail (math and path
problems), but 5216 allows for a different flow which is vulnerable to an
early EAP Success:
In the case where the server authenticates to the peer successfully,
but the peer fails to authenticate to the server, the conversation
will appear as follows:
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
TLS certificate_request,
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Request
EAP-Type=EAP-TLS
(TLS Alert message)
EAP-Response/
EAP-Type=EAP-TLS ->
<- EAP-Failure
(User Disconnected)
> With TLS 1.3, the exporter keys are available *before* the client cert
> has been validated. This "fast path" helps with non-EAP protocols. But
> makes life more difficult for EAP.
>
>
[Joe] We can use Ben's suggestion and make the exported keys depend on the
Peer and server's identities or certificates. But if you are going to want
a protected result indication in EAP-TLS then you cannot end the early.
5216 does not support protected result indicators, it's not clear to me if
implementations do or not.
> Alan DeKok.
>
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
