Subject: Re: [Emu] Protected Result Indicators in EAP-TLS 1.3

From: John Mattsson <[email-masked]>
Date: Wed, 10 Feb 2021 10:48:10 +0000

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.

---

From: John Mattsson <[email-masked]>
Date: Fri, 12 Feb 2021 07:53:48 +0000

Hi,

These three alternatives seem to work for EAP-TLS. (2) seems the simplest from a EAP-TLS standpoint.

But how do these work with other EAP methods now that we are taking about a protected success. I assume this will be needed in TTLS, PEAP, FAST, TEAP?

The -13 commitment message could be sent as the first application data, the protected success would to my understanding be the last application data.

This was discussed in the last months but with unclear definitions of what the commitment message was.

Is it only (1a) or (1b) that work?

My understanding is that:

"After sending application data in an EAP-Request the EAP-TLS server MUST send only EAP-Success."

would not work for TTLS, PEAP, FAST, TEAP. To make it work the application data would have to be something specific like "EAP-SUCCESS".

John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Wednesday, 10 February 2021 at 11:48
To: EMU WG <[email-masked]>, "[email-masked]" <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [Emu] Protected Result Indicators in EAP-TLS 1.3

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

  Yes.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2021 09:01:14 -0500

> But how do these work with other EAP methods now that we are taking about a protected success. I assume this will be needed in TTLS, PEAP, FAST, TEAP?

  The other methods use the TLS tunnel to send application data.  That application data is authentication credentials.

  Once the inner tunnel authentication method has finished, the user is authenticated.   That inner authentication method serves (mostly) as a protected success indicator.

  If the inner method fails, then that method serves (mostly) as a protected failure indicator.

> would not work for TTLS, PEAP, FAST, TEAP. To make it work the application data would have to be something specific like "EAP-SUCCESS".

  That MUST for EAP-TLS shouldn't apply to other TLS-based EAP methods.  Because the application data is an inner authentication method, with it's own meaning.

  The resumption behavior for these methods will be identical to EAP-TLS, since there is no application data being exchanged.  So we don't need to worry about that.

  However...

  I say "mostly" above because not all inner methods include success / failure signalling.  For example with TTLS and PAP inside the tunnel, the server receives the clear-text password from the peer in one EAP message (encapsulated in TLS).  If the password is OK, the reply from the server is EAP-Success.  If the password is wrong, the reply from the server is EAP-Failure.

  In contrast, when MS-CHAP is used, or other EAP methods are used inside of the TLS tunnel, there is inner-tunnel signalling for success / failure.

  We cannot use application data as a protected success indicator, as it's already being used for inner-tunnel authentication credentials.  We don't want to modify the inner-tunnel authentication methods, as that involved rev'ing things like PEAP, which is not an IETF standard.

  If we want the same protection for other methods as for TLS (and I suspect we do), then we need something else.

  After looking through the options, it appears one solution may be:

* require all TLS-based EAP methods to send close_notify after successful inner-tunnel authentication.  This will add another round trip, but I don't think there are many other options.

* require all TLS-based EAP methods to send a TLS alert after failed inner-tunnel authentication.  The TLS alert could be "access_denied":

      A valid certificate or PSK was received, but when
      access control was applied, the sender decided not to proceed with
      negotiation.

  I don't think there is a better choice.

  There are a few big caveats here.  There appears to be no OpenSSL API which allows the application to send a TLS alert.  After rooting through OpenSSL a bit, it seems that it has no code which can *ever* send an "access_denied" alert.  Also, it's not clear that the TLS state machine allows for this alert after exchanging application data.

  So in short, it's relatively easy to add protected success indicators for other TLS-based EAP methods.  Adding protected failure indicators may be more difficult.

    Alan DeKok.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 14 Feb 2021 18:46:47 -0800

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

On first look it seems like all of those will be able to achieve the
required properties.  In some sense it is "probably" going to be "easier"
for an application using TLS to use TLS application data (as opposed to
alerts) to affect its behavior, though I believe that TLS implementations
generally do provide the needed information about received alerts and
flexibility in what alert to send that's needed for the (1) variants.

Another potential factor that I'm not (currently) equipped to evaluate is
the reusability of the machinery defined by EAP-TLS for use by other EAP
mechanisms.  E.g., if we say that for EAP-TLS any application data is a
protected success, would that be in conflict with any scenarios for the EAP
mechanisms that do have to send some data on the TLS application data
stream?

I'd be happy to hear some more voices from the TLS WG chiming in to
corroborate (or contradict) my conclusions in the first paragraph.

Thanks,

Ben

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 15 Feb 2021 12:22:12 -0800

On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk <[email-masked]> wrote:

> > 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.
>
[Joe] In the past handling of close_notify was one of the rougher parts of
TLS implementations.  I'm not sure how much it has improved.

> mechanisms that do have to send some data on the TLS application data
[Joe]  TEAP already has a result indicator within the tunnel, so it would
not need to use the same machinery.  I believe that many of the other
tunnel methods have something similar, so I would expect tunneled methods
to use their own mechanism as a result indication.

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 15 Feb 2021 15:37:14 -0500

> flexibility in what alert to send that's needed for the (1) variants.

  close_notify seems to work fine for EAP-TLS with multiple peer / server implementations, and at least 2 TLS library implementations.

> mechanisms that do have to send some data on the TLS application data

  Implementation so far shows no.  The patches to make PEAP / TTLS work with TLS 1.3 are relatively minor.  Mostly updating the key exporters.

  We have protected success / failure indicators for EAP-TLS 1.3.  I think that's a positive step.

  The question for the other EAP methods is "do we need protected success / failure indicators".   As Joe noted, TEAP already provides them in the inner tunnel, as does PEAP (with inner MS-CHAP), or TTLS (with inner MS-CHAP.  TTLS with inner PAP / CHAP doesn't provide them.

  If we're willing to live without those indicators for other TLS-based EAP methods, then draft-dekok-emu-tls-eap-types is essentially done.  It needs some minor updates, but there are no major protocol questions left open.

  Alan DeKok.