Subject: Re: [Emu] Emu Digest, Vol 145, Issue 37

From: "Vadim Cargatser (vcargats)" <[email-masked]>
Date: Wed, 10 Feb 2021 21:15:30 +0000

Not sure if that idea has already been discussed, but is that reasonable to append an encrypted success/failure message as an opaque field to EAP-Success/Failure.

Granted rfc 3748 explicitly define the length of EAP-Success/Failure, but these *extended* EAP-Success/Failure will be sent if and only if EAP-TLS 1.3 is negotiated before.

Ragards,
Vadim

On 2/10/21, 10:02 PM, "Emu on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    Send Emu mailing list submissions to
    	[email-masked]

    To subscribe or unsubscribe via the World Wide Web, visit
    	https://www.ietf.org/mailman/listinfo/emu
    or, via email, send a message with subject or body 'help' to
    	[email-masked]

    You can reach the person managing the list at
    	[email-masked]

    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of Emu digest..."

    Today's Topics:

       1. Re: Protected Result Indicators in EAP-TLS 1.3 (John Mattsson)

    ----------------------------------------------------------------------

    Message: 1
    Date: Wed, 10 Feb 2021 10:48:10 +0000
    From: John Mattsson <[email-masked]>
    To: EMU WG <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin
    	Kaduk <[email-masked]>
    Subject: Re: [Emu] Protected Result Indicators in EAP-TLS 1.3
    Message-ID: <[email-masked]>
    Content-Type: text/plain; charset="utf-8"

    With Alan's comments, I think we are down to 3 alternatives:

    (1a). Use close_notify alert as protected success.
          Use error alerts as protected failure.

         - Forbid close_notify except as success indication
         - Mandate Error alert before EAP-Failure
         - Forbid all use of user_cancelled

    (1b). Use close_notify alert as protected success.
          Use all other alerts as protected failure.

          - Forbid close_notify except as success indication
          - Mandate Error alert or user_cancelled before EAP-Failure

    (2). Use application data as protected success.
         Use all alerts as protected failure.

        - After sending application data in an EAP-Request the EAP-TLS server MUST send only EAP-Success.
        - Mandate alert (closure, error) before EAP-Failure

    I think it is important to discuss what the ongoing EMU consensus call will mean in practice. Previous discussions was mostly about not sending more handshake messages. Protected result indicators are quite different.

    It would we very good with early feedback from Ben and the TLS WG if they see problems with any of the alternatives.

    Cheers,
    John

    ?-----Original Message-----
    From: Alan DeKok <[email-masked]>
    Date: Tuesday, 9 February 2021 at 15:22
    To: John Mattsson <[email-masked]>
    Cc: EMU WG <[email-masked]>
    Subject: Re: [Emu] Protected Result Indicators in EAP-TLS

    On Feb 9, 2021, at 5:00 AM, John Mattsson <john.mattsson=[email-masked]> wrote:
    > 
    > Below is my summary of the situation:
    > 
    > - It seems like there will be consensus to have protected result indicators in EAP-TLS 1.3.
    > - No one has objected to mandate Error alert on fatal error condition.
    > - Optional protected result indicators are different from mandatory result indicators,
    >  recent suggestion is that protected failure result indicators shall be mandatory.
    > - Success indicators and failure indicators need to be discuss together.

      Yes.

    > Below is my summary of the alternatives:

      I think whatever the altAccept notice is used, the altReject needs to be a TLS alert.  This alert is secured and authenticated.

    > 1. Use close_notify alert as protected success. Use other alerts as protected failure.
    > 
    >  To make it work I think EAP-TLS 1.3 needs to profile TLS 1.3 as:
    > 
    >  - Forbid close_notify except as success indication
    >  - Mandate Error alert before EAP-Failure
    >  - Forbid all use of user_cancelled

      If we use close_notify, yes.

    > 2. Use application data for protected result indicators. Mandate alert (closure or error) before EAP-Failure.
    > 	
    > 	TLS people has stated that this might be reordered and that it is a layer violation.

      Unlike many other uses of TLS, EAP is *not* handing control of the transport protocol over to the TLS layer.  i.e. TLS libraries often implement TCP (or even HTTP) wrappers.  None implement EAP.

      This limitation means that there are no ordering issues with use of application data.  In packet N, the EAP-TLS server asks the TLS layer for data, and encodes it into EAP, and then sends it out.  Some packet M>N, the EAP-TLS server has verified the client certificate.  At that point, it can write application data to TLS.

      The other benefit of using application data is that it is needed for other TLS-based EAP methods.  i.e. there is little reason to have complex code paths when a more unified approach will do.  This protocol choice helps to simplify implementations.

    > 	I think the worries can be overcome by writing things as requirements on
    > 	the EAP-TLS layer, e.g.
    > 
    > 	"After sending application data in a EAP-Request the EAP-TLS server MUST not send
    >      any more EAP-Request"

      The EAP-TLS server MUST send only EAP-Success.

    > 3. Success and failure indication on the EAP-TLS layer
    > 
    >   This was never discussed beyond that using an uprotected flag bit was not acceptable.
    > 
    > 	Things at the EAP-TLS layer can quite easily be made protected.
    > 
    > 	- Use one of the reserved bit in the EAP-TLS pakcet to indicate success.
    > 	- Append TLS-Exporter("EXPORTER_EAP_TLS_SUCCESS_" + Type-Code, "", 16) to the packet
    > 
    > 	- Use another of the reserved bit in the EAP-TLS pakcet to indicate failure.
    > 	- Append TLS-Exporter("EXPORTER_EAP_TLS_FAILURE_" + Type-Code, "", 16) to the packet
    > 
    > 	A solution at the EAP-TLS layers would not be dependant on profiling TLS 1.3

      Appending data to the EAP-TLS packets is problematic.  We already have a secured tunnel inside of the TLS layer.  Using that is *significantly* easier than mangling packets.

    > 4. Success on EAP-TLS layer, Mandate alert (closure or error) before EAP-Failure.
    > 
    > 5. Failure on EAP-TLS layer. Application data for success, 

      I'm not sure what those mean.

    > I think 1. seems like the most complicated solution. It is also kind of ugly as it use an alert as indication for success. That said, I can live with any solution that are acceptable for implementors and TLS people.

      (1) and (2) have essentially simpler complexity.  (3) is by far and aware more complex to implement.

      For us, the code changes to support TLS 1.3 are maybe a few hundred lines of C.  The difference between (1) and (2) is maybe 50 lines.  Having multiple TLS exporters is maybe 100 lines.  (3) is much larger, and much more error prone.

      Alan DeKok.

    ------------------------------

    Subject: Digest Footer

    _______________________________________________
    Emu mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/emu

    ------------------------------

    End of Emu Digest, Vol 145, Issue 37
    ************************************

---

From: John Mattsson <[email-masked]>
Date: Thu, 11 Feb 2021 07:47:30 +0000

Hi Vadim,

Extending EAP-Failure/EAP-Success has been discussed in the past. People have expressed that it would be good to protect EAP-Failure/EAP-Success and to be able to send data with them. Changing EAP-Failure/EAP-Success is however not seen as possible and was not discussed in any recent discussion.

EAP allows other protected/unprotected result indicatiors in the method or in lower layers. The recent discussion was to use the TLS layer for result indicatiors or to extend the EAP-TLS request packet format. As Alan think extending the EAP-TLS packets is more complex, the only remaining alternatives on the table is to rely on the TLS layer.

Cheers,
John