Subject: [Emu] Consensus call for result indicators in EAP-TLS 1.3

From: Joseph Salowey <[email-masked]>
Date: Sat, 6 Feb 2021 17:22:08 -0800

There is growing support for mandating result indicators for EAP-TLS 1.3.
The result indicators help protect the EAP protocol exchange in the many
different types of environments EAP-TLS is used and make the integration
with the EAP state machine clearer.  This has the impact of adding a round
trip to EAP-TLS 1.3 making a total of 4.5 round trips.  It may be possible
to optimize this exchange, but that would need further study and would be
beyond the scope of this effort.

This consensus call has two parts:

1. Please respond to the list if you support adding explicit result
indications of success and failure from the EAP Server to the EAP Peer in
EAP-TLS 1.3.  If you object please respond to the list indicating why.

2. Please respond to the list if you support using TLS close_notify alert
for a success indication and TLS error alert for a failure indication.  If
you object please respond to the list indicating why.

This call will run for 1 week.  Please respond by February 15, 2021.

Thanks,

Joe

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Feb 2021 21:20:57 -0500

Joseph Salowey <[email-masked]> wrote:
    > There is growing support for mandating result indicators for EAP-TLS
    > 1.3.  The result indicators help protect the EAP protocol exchange in
    > the many different types of environments EAP-TLS is used and make the
    > integration with the EAP state machine clearer.  This has the impact of
    > adding a round trip to EAP-TLS 1.3 making a total of 4.5 round trips.
    > It may be possible to optimize this exchange, but that would need
    > further study and would be beyond the scope of this effort.

    > indications of success and failure from the EAP Server to the EAP Peer
    > in EAP-TLS 1.3.  If you object please respond to the list indicating
    > why.

I support this.

    > 2. Please respond to the list if you support using TLS close_notify
    > alert for a success indication and TLS error alert for a failure
    > indication.  If you object please respond to the list indicating why.

As I understand it, it is the use of Close_Notify that pushes us to 4.5 round
trips.

Given a client-certificate (or chain) of >1500 bytes more than one packet would be
required send that, and I believe that we can't send Close_Notify until the
certificate has been communicated (and verified).

So my question is: is this really 3.5 round trips -> 4.5 round trips, or is
it really more like that we are going from perhaps 5.5 round trips to 6.5
round trips (for example).
I posit this, because I think that the increase in round trip count is
largely irrelevant on non-challenged (RFC7228 term) networks.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: John Mattsson <[email-masked]>
Date: Sun, 7 Feb 2021 10:14:38 +0000

Hi,

I think it is important to point out that the discussion has been about _protected_ result indications. RFC 3748 discussed protected and non-protected result indications. Also worth noting that it is not possible with protected failure indication when the server does not accept the ClientHello.

Michael Richardson wrote:
>is this really 3.5 round trips -> 4.5 round trips, or is it really more like that we are >going from perhaps 5.5 round trips to 6.5 round trips (for example).

For a full handshake it is probably more like 10.5 -> 11.5 roundtrips or more. Certificate chains are large and EAP-TLS typically sends 2 of them.

For resumption is might 3.5 round trips -> 4.5.

In cases a no-more-handshake indication is needed anyway to ease implementation, or in cases where the server wants client finished before sending newsessionticket, there is probably no increase at all.

John

-----Original Message-----
From: Emu <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Sunday, 7 February 2021 at 03:21
To: EMU WG <[email-masked]>
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

I support this.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 7 Feb 2021 06:32:18 -0500

On Feb 6, 2021, at 8:22 PM, Joseph Salowey <[email-masked]> wrote:
> 1. Please respond to the list if you support adding explicit result indications of success and failure from the EAP Server to the EAP Peer in EAP-TLS 1.3.  If you object please respond to the list indicating why.

  I support it.

> 2. Please respond to the list if you support using TLS close_notify alert for a success indication and TLS error alert for a failure indication.  If you object please respond to the list indicating why.  

  I support the TLS error alert for a failure indication.

  I would prefer sending one byte of application data instead of close_notify.  For the simple reason that it better unifies the code paths for all TLS-based EAP methods.   That being said, we definitely need *a* protected success indication.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Tue, 9 Feb 2021 08:53:33 +0000

>is this really 3.5 round trips -> 4.5 round trips, or is it really more like that we are >going from perhaps 5.5 round trips to 6.5 round trips (for example).

Another question is if EAP-Success should even be counted. A protected success indication would make EAP-Success a dummy message. It has to be sent according to EAP, but would not really be used....

John 

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Sunday, 7 February 2021 at 11:14
To: EMU WG <[email-masked]>
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

Hi,

John

-----Original Message-----
From: Emu <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Sunday, 7 February 2021 at 03:21
To: EMU WG <[email-masked]>
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

I support this.

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 18 Feb 2021 21:26:01 -0800

We have had a lot of productive discussion on this topic.  I feel
comfortable calling consensus that we should add protected result
indicators to EAP-TLS 1.3.

There also seems to be consensus to use TLS Failure alert for failure
result indications.

How to represent success indicators is not as clear.  Fortunately, we have
two options that seem to have some support.

1. Zero-byte application record.  Multiple implementations already use this
mechanism and it is clear that the EAP-TLS peer and server "application"
can receive and send this indicator.  There were additional concerns about
the ordering of this application data record in the flight, but it seems
that this should not be a problem as long as the TLS library is fed the
entire EAP-TLS message containing the flight to process.

2. Close-Notify Alert.  This would use an existing TLS message to signal
success.  We have had some implementation reports that the EAP-TLS server
"application" can trigger the close_notify on at least one library.  I have
not heard any news from implementers if close_notify is accessible to the
EAP-TLS peer/supplicant "application".  I think it is not clear if the
signal would be accessible to implementers for both the EAP-TLS peer and
server.

I'd like to hear from implementers about their experience with this
mechanism:

1. Have you implemented the zero byte application record signa? If not, why
not?l
a. Is it sent after receiving the client finished?
b. Do you anticipate problems if the application record comes before or
after a NewSessionTicket message?
c. did you run into any issues with this mechanism?

2. Have you implemented the close notify method? If not, why not?
a. Is it sent after receiving the client finished?
b. Were you able to cause the message to be sent for the server or
determine that the message was received for the peer/supplicant?
c. Did you run into any issues with this mechanism?

Joe

---

From: John Mattsson <[email-masked]>
Date: Fri, 19 Feb 2021 06:08:57 +0000

Small nit: Zero-byte application record was removed in -06 as many TLS implementations did not support sending a Zero-byte application record. Zero-byte was then changes to send 0x00 but accept any application data. Other EAP-TLS based method might require longer specific stings like “EAP-Success”.

I think you questions are fine if the word “Zero-byte” is removed everywhere.

Cheers,
John

From: Emu <[email-masked]> on behalf of Joseph Salowey <[email-masked]>
Date: Friday, 19 February 2021 at 06:26
To: EMU WG <[email-masked]>
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

We have had a lot of productive discussion on this topic.  I feel comfortable calling consensus that we should add protected result indicators to EAP-TLS 1.3.

There also seems to be consensus to use TLS Failure alert for failure result indications.

How to represent success indicators is not as clear.  Fortunately, we have two options that seem to have some support.

1. Zero-byte application record.  Multiple implementations already use this mechanism and it is clear that the EAP-TLS peer and server "application" can receive and send this indicator.  There were additional concerns about the ordering of this application data record in the flight, but it seems that this should not be a problem as long as the TLS library is fed the entire EAP-TLS message containing the flight to process.

2. Close-Notify Alert.  This would use an existing TLS message to signal success.  We have had some implementation reports that the EAP-TLS server "application" can trigger the close_notify on at least one library.  I have not heard any news from implementers if close_notify is accessible to the EAP-TLS peer/supplicant "application".  I think it is not clear if the signal would be accessible to implementers for both the EAP-TLS peer and server.

I'd like to hear from implementers about their experience with this mechanism:

1. Have you implemented the zero byte application record signa? If not, why not?l
a. Is it sent after receiving the client finished?
b. Do you anticipate problems if the application record comes before or after a NewSessionTicket message?
c. did you run into any issues with this mechanism?

2. Have you implemented the close notify method? If not, why not?
a. Is it sent after receiving the client finished?
b. Were you able to cause the message to be sent for the server or determine that the message was received for the peer/supplicant?
c. Did you run into any issues with this mechanism?

Joe

On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
There is growing support for mandating result indicators for EAP-TLS 1.3.  The result indicators help protect the EAP protocol exchange in the many different types of environments EAP-TLS is used and make the integration with the EAP state machine clearer.  This has the impact of adding a round trip to EAP-TLS 1.3 making a total of 4.5 round trips.  It may be possible to optimize this exchange, but that would need further study and would be beyond the scope of this effort.

Thanks,

Joe

---

From: John Mattsson <[email-masked]>
Date: Fri, 19 Feb 2021 06:48:52 +0000

But if I missed something and implementors are fine with “Zero-byte”, I do not object. Zero-bytes is allowed by the TLS 1.3 specification and theoreticallty better as it is not send normally.

From: Emu <[email-masked]> on behalf of John Mattsson <john.mattsson=[email-masked]>
Date: Friday, 19 February 2021 at 07:09
To: Joseph Salowey <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

Cheers,
John

Joe

Thanks,

Joe

---

From: John Mattsson <[email-masked]>
Date: Fri, 19 Feb 2021 07:30:46 +0000

My mistake, I read zero-bytes instead of zero-byte. The text is fine. Sorry for the spam.

---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>

On 19 February 2021 at 07:49:15 CET, John Mattsson <john.mattsson=[email-masked]> wrote:

Cheers,

John

Joe

Thanks,

Joe

<ATT00001.txt>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 19 Feb 2021 06:32:55 -0500

> 1. Have you implemented the zero byte application record signa? If not, why not?l

  Yes.

> a. Is it sent after receiving the client finished?

  Originally no, but now yes.

> b. Do you anticipate problems if the application record comes before or after a NewSessionTicket message?

  No.

> c. did you run into any issues with this mechanism?

  No.

> 2. Have you implemented the close notify method? If not, why not?

  Yes.  Right now, it's a secret configurable flag to switch between these options.

> a. Is it sent after receiving the client finished?

  Yes.

> b. Were you able to cause the message to be sent for the server or determine that the message was received for the peer/supplicant? 

  Yes.

> c. Did you run into any issues with this mechanism?

  No.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 19 Feb 2021 08:14:24 -0800

> > I'd like to hear from implementers about their experience with this

Was this both Peer and server implementation?

---

From: Alan DeKok <[email-masked]>
Date: Fri, 19 Feb 2021 11:22:07 -0500

On Feb 19, 2021, at 11:14 AM, Joseph Salowey <[email-masked]> wrote:
> 
> On Fri, Feb 19, 2021 at 3:32 AM Alan DeKok <[email-masked]> wrote:

  I've implemented the server side.  Microsoft implemented the peer side.  IIRC, the behaviours are largely similar.

  Both peer and server side have been implemented for hostap / wpa_supplicant.

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Feb 2021 17:30:01 +0100

> On 9 Feb 2021, at 09:53, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> Another question is if EAP-Success should even be counted. A protected success indication would make EAP-Success a dummy message. It has to be sent according to EAP, but would not really be used….

Except to the authenticator, right?

Eliot

---

From: Jorge Vergara <[email-masked]>
Date: Fri, 19 Feb 2021 17:56:52 +0000

Here are my answers as a client implementor. You'll see our implementation has had more time to bake with the application data, but I don't think either is technically problematic. I do favor the application data because I believe it is better suited for the semantic purpose as a protected result indicator for EAP-TLS. When close_notify was floated in the group and put in draft-14, the group was very specifically discussing the semantic of "no more messages will be sent" - for which close_notify carries that intent very clearly. The group has now realized that a protected result indicator is needed instead, and this is very different from "no more messages will be sent." It's my opinion that close_notify is less suited for this new purpose.

Yes.

>a. Is it sent after receiving the client finished?
Observably in server implementations we are testing against, yes.

No.

No.
>2. Have you implemented the close notify method? If not, why not?
Yes, but testing isn't finished.

>a. Is it sent after receiving the client finished?
We're ironing out a few implementation issues.

>b. Were you able to cause the message to be sent for the server or determine that the message was received for the peer/supplicant?
We're ironing out a few implementation issues.

>c. Did you run into any issues with this mechanism?
Yes, as above - but theoretically I don't see a technical issue once the kinks are ironed out. We believe the signal should be accessible to our client implementation.

Jorge Vergara