Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey <[e-mail]>]

On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok <[e-mail]>
wrote:

> On Feb 1, 2021, at 3:00 PM, Joseph Salowey <[e-mail]> 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.
>
>