Subject: [Emu] EAP-TLS protected result indications

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Feb 2021 11:41:31 -0800

Joe Salowey said:

"[Joe] Based on RFC 5216 the server could fail the finished message or as

section 2.1.3 shows it could send the finish and then it can send an
Alert and result in EAP-Failure.  In this case it would be possible
for an attacker to remove the Alert and send a success.  Whether your
implementation ends up in this scenario or not probably depends upon why
the auth failed and the behavior of your TLS library.

I do not believe that RFC 5216 provides protected result indications.
 It would be a fine thing to add, but it is new to the specification
and I'm not sure that is why the commitment message was added to begin
with."

[BA] EAP-TLS implementations do provide protected result indications.
Due to injection attacks, implementations were modified to support RFC
4137 so as to protect against spoofed EAP-Success and EAP-Failure
messages.  For example, implementations of the EAP-TLS state machine
should not be driven by EAP-Success and EAP-Failure messages, which
are unprotected. This ensures that an Alert sent after Finish will be
correctly recognized as an alternate failure indication, regardless of
whether an attacker injected an EAP-Success message in between.

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 2 Feb 2021 15:53:14 -0800

On Tue, Feb 2, 2021 at 11:41 AM Bernard Aboba <[email-masked]>
wrote:

> section 2.1.3 shows it could send the finish and then it can send an Alert and result in EAP-Failure.  In this case it would be possible for an attacker to remove the Alert and send a success.  Whether your
> I do not believe that RFC 5216 provides protected result indications.   It would be a fine thing to add, but it is new to the specification and I'm not sure that is why the commitment message was added to begin with."
>
> [BA] EAP-TLS implementations do provide protected result indications.  Due to injection attacks, implementations were modified to support RFC 4137 so as to protect against spoofed EAP-Success and EAP-Failure messages.  For example, implementations of the EAP-TLS state machine should not be driven by EAP-Success and EAP-Failure messages, which are unprotected. This ensures that an Alert sent after Finish will be correctly recognized as an alternate failure indication, regardless of whether an attacker injected an EAP-Success message in between.
>
> [Joe] Aha, It's coming back to me now and it does seem that
implementations do this.  Do you know if the implementation requirements
were documented anywhere?

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Feb 2021 17:14:19 -0800

The discussion largely happened in 802.11 since that was where the
vulnerability vulnerability was discovered (by Bill Arbaugh at UMD).
Documentation of the required signals was in RFC 4137, tests on the fixed
implementations were done by UMD and subsequent analysis and security
proofs were done by the Mitchell group at Stanford.

---

From: John Mattsson <[email-masked]>
Date: Wed, 3 Feb 2021 08:24:28 +0000

Hi,

Thanks, that is good information. Note that RFC 4137 is informative examples of how EAP can be implemented and not even mentioned in RFC 5216. Given this discussion it feels like RFC 5216 also needs to follow RFC 4137 or do something similar to be secure. RFC 5216 do not say anything about the EAP state machine.

On a high level I think the group need to decide if the EAP-TLS 1.3 specification should:

a) Have normative state machine text for TLS 1.3 only
b) Have normative state machine text for both TLS 1.2 and 1.3
c) Have informative state machine guidance for TLS 1.3 only
d) Have informative state machine guidance for  both TLS 1.2 and 1.3
e) Leave state machine to the implementaion just like RFC 5216.

The current assumption has been e). Given that this is important for security a), b), c), and d) would have been better. TLS 1.3 likely increases the need to specify this. Adding this would however undoubtely delay the specification.

Cheers,
John

From: Emu <[email-masked]> on behalf of Bernard Aboba <[email-masked]>
Date: Wednesday, 3 February 2021 at 02:14
To: "[email-masked]" <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] EAP-TLS protected result indications

The discussion largely happened in 802.11 since that was where the vulnerability vulnerability was discovered (by Bill Arbaugh at UMD). Documentation of the required signals was in RFC 4137, tests on the fixed implementations were done by UMD and subsequent analysis and security proofs were done by the Mitchell group at Stanford.

On Tue, Feb 2, 2021 at 15:53 Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:

[Joe] Aha, It's coming back to me now and it does seem that implementations do this.  Do you know if the implementation requirements were documented anywhere?

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