Subject: Re: [Emu] EAP-TLS and TLS alerts

From: John Mattsson <[email-masked]>
Date: Sat, 6 Feb 2021 06:01:12 +0000

Hi,

I personally fine with writing MUST send an Error alert if the WG wants that. This would maybe help with using close_notify as an alternate success indication.

The most pressing question regarding alerts is if EAP-TLS can force the TLS implementation to not use close_notify in any situation except for success.

RFC 8446 allow an TLS implementation to send close_notify after receiving client finished. The server might send it because of an error in the client Finished or because it wants to close the connection for any reason.

    EAP-TLS Peer                                      EAP-TLS Server

                                                         EAP-Request/
                                 <--------                  Identity
    EAP-Response/
    Identity (Privacy-Friendly)  -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                 <--------                (TLS Start)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS ClientHello)             -------->
                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                                    (TLS ServerHello,
                                             TLS EncryptedExtensions,
                                              TLS CertificateRequest,
                                                     TLS Certificate,
                                               TLS CertificateVerify,
                                 <--------              TLS Finished)
    EAP-Response/
    EAP-Type=EAP-TLS
   (TLS Certificate,
    TLS CertificateVerify,
    TLS Finished)                -------->
									
									Server decides to close connection.

                                                         EAP-Request/
                                                    EAP-Type=EAP-TLS
                                 <--------         (TLS close_notify)
    EAP-Response/
    EAP-Type=EAP-TLS             -------->
                                 <--------               EAP-Failure

I don't if this would be common or expected behavior from the server, but if EAP-TLS cannot enforce that this to not happen, then we cannot use close_notify as an alternate success indication, because an alternate success indication cannot be followed by EAP-Failure.

John

---

From: Alan DeKok <[email-masked]>
Date: Sat, 6 Feb 2021 07:49:21 -0500

On Feb 6, 2021, at 1:01 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> I personally fine with writing MUST send an Error alert if the WG wants that.

  This is what all implementations have done for ~15 years.  The TLS Alert satisfies the "altReject" requirements of RFC 4137.  Which means it's a very good iea.

> This would maybe help with using close_notify as an alternate success indication.

  I'm not sure how.  Both are needed, but they're independent.

> The most pressing question regarding alerts is if EAP-TLS can force the TLS implementation to not use close_notify in any situation except for success.

  TLS libraries will not close TLS connections unless applications ask for that.  Anything else is madness, TBH.

> RFC 8446 allow an TLS implementation to send close_notify after receiving client finished. The server might send it because of an error in the client Finished or because it wants to close the conne…

  OK...
>                                 <--------         (TLS close_notify)

  All that is normal and expected.

>    EAP-Type=EAP-TLS             -------->

  That seems wrong.

> I don't if this would be common or expected behavior from the server, but if EAP-TLS cannot enforce that this to not happen, then we cannot use close_notify as an alternate success indication, beca…

  Perhaps just update the document to say that such use-cases are forbidden?

  We can never prevent implementations from doing stupid things.  But it is very useful for a specification to note the corner cases / error conditions, describe them, and explain why they're wrong and should not be used.

  Alan DeKok.