Subject: Re: [TLS] [Emu] Underspecification of EAP-TLS 1.3 State Machine

From: John Mattsson <[email-masked]>
Date: Thu, 4 Feb 2021 12:18:37 +0000

Hi Bernard,

I (re-)read the papers you send.

- "Extensible Authentication Protocol Vulnerabilities and Improvements Improvements"

  This paper talks attacks on availability by spoofing messages. It looks into a small amount of ways where spoofed messages causes the TLS connection to fail, especially it focus on alert messages.

  TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically any small error is fatal in TLS. Focusing on alert messages does not seem correct. An attacker can e.g. at any time send a small record with length 2^15, which causes TLS to terminate the connection. I think the only thing that can be achieved without rewriting TLS is that availability attacks does not cause long-term damage, i.e. the nodes can retry the handshake.

- "An Initial Security Analysis of the IEEE 802.1X Standard"

  This paper discusses attacks on 801.11. The weaknesses described seems to come from 802.11 / EAP interactions.

The discussions around IETF 102 was that the uncertainty (NewSessionTicket or not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of the uncertainty. Bernard then pointed out that any message changing the state need to be authenticated to that it is not possible to spoof. I think that both the application layer commit message as well as close_notify fulfill these old requirements.

I think your analysis is correct.

1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 protocol?

The -13 commitment message verifies that both sides are in possession of a derived key. But the server finished already does that. As you state, the -13 commitment message is not an alternative success indication. I think it would be easy to make it an alternative success indication be mandating that the EAP-TLS server must only send it after verifying the client finished. I do not think defining a new exporter is needed.

The -14 close_notify is also not an alternative success indication and can not be made into one either.

If the requirement is that an alternative authenticated success indication is needed. Then I think:

- We need to have an extra roundtrip.
- close_notify does not work and cannot be made to work
- Application data commit message could work as an alternative success indication. TLS would have to be profiled so the alternative success is only send be EAP-TLS server after client finished processed successfully.

2. At what point should keys be pushed down to the lower layer?

What is the exact requirement for eapKeyAvailable = TRUE to be set?

My understanding reading RFC 4137 (correct me if I am wrong) is that it is not enough that the other party is authenticated, but that an alternative success indication has been sent/received. If that is correct the EAP-TLS server would set eapKeyAvailable = TRUE after sendign the alternative success indication and the EAP-TLS client would set eapKeyAvailable = TRUE after receiving the alternative success indication.

3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?

Yes, I agree, receipt of TLS Alert messages should be considered an alternative failure mechanism.

4. What is the purpose of the commitment message?

The -01 to -13 purpose was to indicate in an authenticated way that the EAP-TLS method would not continue and that only success or failure could follow.

If an alternative success indication is required. Which it seems to be according to your mail. I think the alternative success indication would replace the old commitment message.

I think

Cheers,
John

From: Emu <[email-masked]> on behalf of Bernard Aboba <[email-masked]>
Date: Tuesday, 2 February 2021 at 16:25
To: "[email-masked]" <[email-masked]>
Subject: [Emu] Underspecification of EAP-TLS 1.3 State Machine

The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3 interacts with the EAP state machine as specified in RFC 4137.  It appears to me that this under-specification is at the root of the questions about the commitment message.

Historically, under-specification of the EAP-TLS state machine has been a source of potential security vulnerabilities by enabling packet injection attacks [1][2], including attacks involving the injection of EAP-Success and EAP-Failure mechanisms.

RFC 4137 Sections 4.1.1 and 4.1.2 define several variables:

   altAccept (boolean)

      Alternate indication of success, as described in [RFC3748<https://tools.ietf.org/html/rfc3748>].

   altReject (boolean)

      Alternate indication of failure, as described in [RFC3748<https://tools.ietf.org/html/rfc3748>].

   eapKeyData (EAP key)

      Set in peer state machine when keying material becomes available.

      Set during the METHOD state.  Note that this document does not

      define the structure of the type "EAP key".  We expect that it

      will be defined in [Keying<https://tools.ietf.org/html/rfc4137#ref-Keying>].

   eapKeyAvailable (boolean)

      Set to TRUE in the SUCCESS state if keying material is available.

      The actual key is stored in eapKeyData.

The issue in the EAP-TLS 1.3 specification is that the interlock with these variables is not defined.

For example, it appears to me that the commitment message verifies that both sides are in possession of a derived key,

allowing the eapKeyData variables to be set.  However, it does not appear to me that the successful validation of the commitment message is

sufficient to allow keys to be pushed down to the lower layer, allowing data to flow.

Therefore the eapKeyAvailable variable should not yet be set to TRUE.

Also, the commitment message does not constitute an alternative success indication because it is possible for an

alternative failure indication (e.g. a TLS alert) to be sent after the commitment message.

If the commitment message did constitute an alternative success mechanism, then an attacker injecting an

EAP-Success message would be able to cause the peer to believe that authentication

had succeeded even though it had actually failed (e.g. TLS alert sent after the commitment message).

Given these issues, I believe the specification needs to answer several questions:

1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 protocol?

2. At what point should keys be pushed down to the lower layer?

3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?

4. What is the purpose of the commitment message?

Only question 3 looks straight forward to me: receipt of TLS Alert messages should be considered an alternative failure mechanism,

although perhaps some caveats need to be applied to address the injection attacks described in [1].

[1] EAP Vulnerabilities and Improvements, Extensible Authentication Protocol Vulnerabilities and Improvements (sjsu.edu)<https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431&context=etd_projects>

[2] An Analysis of the IEEE 802.1X Standard, An Initial Security Analysis of the IEEE 802.1X Standard | Request PDF (researchgate.net)<https://www.researchgate.net/publication/2562682_An_Initial_Security_Analysis_of_the_IEEE_8021X_Standard>

---

From: John Mattsson <[email-masked]>
Date: Thu, 4 Feb 2021 14:22:23 +0000

I think the major decision for the EMU WG to make going forward is to agree if EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not discuss the EAP state machine at all, but in TLS 1.2 the server finished can be used as an alternative success indication.

close_notify might be possible to turn into an alternative success indication if the TLS implementation can be profiled to not send any close_notify by itself. I don't know if there are any cases where an implementation would send close_notify without the application telling it to.

If the wg agrees that an authenticated alternative success indication is needed (this is to my understanding needed in e.g. 802.11) then the process would be that the EAP-TLS server first process the second flight from the client, if that verifies correctly, the server send application data commit message / close_notify.

Introducing an authenticated alternative success indication would not require any changes to the -14 message flows. In -13 the commitment message would have to be sent in a later flight than server finished.

If a mandatory authenticated alternative success indication is introduced in EAP-TLS 1.3, I do not think any future additions to TLS 1.3 would be needed for EAP-TLS 1.3.

From: John Mattsson <[email-masked]>
Date: Thursday, 4 February 2021 at 13:18
To: Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Hi Bernard,

I think

Cheers,
John

   altAccept (boolean)

   altReject (boolean)

   eapKeyData (EAP key)

---

From: John Mattsson <[email-masked]>
Date: Thu, 4 Feb 2021 23:14:15 +0000

Hi Bernard,

802.11 is a very important use case for EAP-TLS so if an authenticated alternate success indication is needed there, it absolutely needs to be supported by EAP-TLS 1.3

I updated the EAP state machine chapter based on your comments.

---------------------------------------------------------------------------
2.5.  EAP State Machines

   This is a new section when compared to [RFC5216] and only applies to
   TLS 1.3 (or higher).  [RFC4137] offers a proposed state machine for
   EAP

   TLS 1.3 [RFC8446] introduces Post-Handshake messages.  These Post-
   Handshake messages use the handshake content type and can be sent
   after the main handshake.  Examples of Post-Handshake messages are
   NewSessionTicket, which is used for resumption and KeyUpdate, which
   is not useful and not expected in EAP-TLS.  After sending TLS
   Finished, the EAP-TLS server may send any number of Post-Handshake
   messages in separate EAP-Requests.

   To provide an authenticated success result indication and to decrease
   the uncertainty for the EAP-TLS peer, the following procedure MUST be
   followed:

   When an EAP-TLS server has successfully processed the TLS client
   Finished and sent its last handshake message (Finished or a Post-
   Handshake), it commits to not sending any more handshake messages by
   sending a TLS close_notify alert.  The TLS close_notify alert is an
   authenticated success result indication, as defined in [RFC3748].
   After sending the TLS close_notify alert, the EAP-TLS server may only
   send an EAP-Success.  The EAP-TLS server MUST NOT send an TLS
   close_notify alert before it has successfully processed the client
   finished and sent its last handshake message.

   Receipt of any TLS Error alert SHOULD be considered a failure result
   indication, as defined in [RFC3748].  After sending or receiving a
   TLS Error alert, the EAP-TLS server may only send an EAP-Failure.

   The keying material becomes available in the EAP-TLS server after the
   server Finished has been sent.  The keying material becomes available
   in the EAP-TLS peer after the server Finished has been received.
---------------------------------------------------------------------------

I used RFC 3748 terminology as RFC 4237 is an informal draft.

close_notify is now an authenticated success result indication (close_notify could be replaced by TLS application data).

My undertstanding from RFC 4137 is that eapKeyAvailable and aaaEapKeyAvailable seems
to be automatically set at success if eapKeyData and aaaEapKeyData are set.

if (eapKeyData != NONE)
  eapKeyAvailable = TRUE

if (aaaEapKeyData != NONE)
  aaaEapKeyAvailable = TRUE

I therefore only described when the "keying material becomes available" which is the words used by RFC 4137 for eapKeyData and aaaEapKeyData.

Open question if Section 2.5 should say something about TLS 1.2.

Cheers,
John

From: John Mattsson <[email-masked]>
Date: Thursday, 4 February 2021 at 15:22
To: Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Hi Bernard,

I think

Cheers,
John

   altAccept (boolean)

   altReject (boolean)

   eapKeyData (EAP key)

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 4 Feb 2021 15:26:15 -0800

John said:

"The keying material becomes available in the EAP-TLS server after the

   server Finished has been sent.  The keying material becomes available
   in the EAP-TLS peer after the server Finished has been received."

[BA]  There is a distinction between when keys are available on the EAP
server,  and when they are transmitted by the EAP Server to the
authenticator (after an EAP-Success is sent).  Also, there is a distinction
between when the EAP peer derives the keys and when they are to be pushed
down to the lower layer (this should only happen after an alternative
success indication is received). The state machine is more driven by the
transmission/push-down of keys than by their mere derivation.

I'll let the implementers comment on the practicality of a close_notify as
an alternative success indication, as opposed to other potential solutions.

I'll let the implementers comment on the practicality of what you are
proposing.

On Thu, Feb 4, 2021 at 3:14 PM John Mattsson <[email-masked]>
wrote:

> Hi Bernard,
>
>
>
> 802.11 is a very important use case for EAP-TLS so if an authenticated
> alternate success indication is needed there, it absolutely needs to be
> supported by EAP-TLS 1.3
>
>
>
> close_notify is now an authenticated success result indication (close_notify
> could be replaced by TLS application data).
>
>
>
> I therefore only described when the "keying material becomes available"
> which is the words used by RFC 4137 for eapKeyData and aaaEapKeyData.
>
>
>
> *From: *John Mattsson <[email-masked]>
> *Date: *Thursday, 4 February 2021 at 15:22
> *To: *Bernard Aboba <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
>
>
>
>
>
> I think the major decision for the EMU WG to make going forward is to
> agree if EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216
> does not discuss the EAP state machine at all, but in TLS 1.2 the server
> finished can be used as an alternative success indication.
>
>
>
> close_notify might be possible to turn into an alternative success
> indication if the TLS implementation can be profiled to not send any
> close_notify by itself. I don't know if there are any cases where an
> implementation would send close_notify without the application telling it
> to.
>
>
>
> If the wg agrees that an authenticated alternative success indication is
> needed (this is to my understanding needed in e.g. 802.11) then the process
> would be that the EAP-TLS server first process the second flight from the
> client, if that verifies correctly, the server send application data commit
> message / close_notify.
>
>
>
> Introducing an authenticated alternative success indication would not
> require any changes to the -14 message flows. In -13 the commitment message
> would have to be sent in a later flight than server finished.
>
>
>
> If a mandatory authenticated alternative success indication is introduced
> in EAP-TLS 1.3, I do not think any future additions to TLS 1.3 would be
> needed for EAP-TLS 1.3.
>
>
>
>
>
> *From: *John Mattsson <[email-masked]>
> *Date: *Thursday, 4 February 2021 at 13:18
> *To: *Bernard Aboba <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
>
>
>
> Hi Bernard,
>
>
>
>   This paper talks attacks on availability by spoofing messages. It looks
> into a small amount of ways where spoofed messages causes the TLS
> connection to fail, especially it focus on alert messages.
>
>
>
>   TLS and EAP-TLS is trivial for an on-path attacker to shut down.
> Basically any small error is fatal in TLS. Focusing on alert messages does
> not seem correct. An attacker can e.g. at any time send a small record with
> length 2^15, which causes TLS to terminate the connection. I think the only
> thing that can be achieved without rewriting TLS is that availability
> attacks does not cause long-term damage, i.e. the nodes can retry the
> handshake.
>
>
>
> The discussions around IETF 102 was that the uncertainty (NewSessionTicket
> or not) in TLS 1.3 was "inconvinient" and that it would be convient to get
> rid of the uncertainty. Bernard then pointed out that any message changing
> the state need to be authenticated to that it is not possible to spoof. I
> think that both the application layer commit message as well as
> close_notify fulfill these old requirements.
>
>
>
>
>
> The -13 commitment message verifies that both sides are in possession of a
> derived key. But the server finished already does that. As you state, the
> -13 commitment message is not an alternative success indication. I think it
> would be easy to make it an alternative success indication be mandating
> that the EAP-TLS server must only send it after verifying the client
> finished. I do not think defining a new exporter is needed.
>
>
>
> - Application data commit message could work as an alternative success
> indication. TLS would have to be profiled so the alternative success is
> only send be EAP-TLS server after client finished processed successfully.
>
>
>
> My understanding reading RFC 4137 (correct me if I am wrong) is that it is
> not enough that the other party is authenticated, but that an alternative
> success indication has been sent/received. If that is correct the EAP-TLS
> server would set eapKeyAvailable = TRUE after sendign the alternative
> success indication and the EAP-TLS client would set eapKeyAvailable = TRUE
> after receiving the alternative success indication.
>
>
>
> The -01 to -13 purpose was to indicate in an authenticated way that the
> EAP-TLS method would not continue and that only success or failure could
> follow.
>
>
>
> If an alternative success indication is required. Which it seems to be
> according to your mail. I think the alternative success indication would
> replace the old commitment message.
>
>
>
> I think
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Emu <[email-masked]> on behalf of Bernard Aboba <
> [email-masked]>
> *Date: *Tuesday, 2 February 2021 at 16:25
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Emu] Underspecification of EAP-TLS 1.3 State Machine
>
>
>
> The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
> interacts with the EAP state machine as specified in RFC 4137.  It appears
> to me that this under-specification is at the root of the questions about
> the commitment message.
>
>
>
> Historically, under-specification of the EAP-TLS state machine has been a
> source of potential security vulnerabilities by enabling packet injection
> attacks [1][2], including attacks involving the injection of EAP-Success
> and EAP-Failure mechanisms.
>
>
>
>       Alternate indication of success, as described in [RFC3748 <https://tools.ietf.org/html/rfc3748>].
>
>
>
>    altReject (boolean)
>
>
>
>       Alternate indication of failure, as described in [RFC3748 <https://tools.ietf.org/html/rfc3748>].
>
>
>
>    eapKeyData (EAP key)
>
>
>
>       will be defined in [Keying <https://tools.ietf.org/html/rfc4137#ref-Keying>].
>
>
>
> [1] EAP Vulnerabilities and Improvements, Extensible Authentication Protocol Vulnerabilities and Improvements (sjsu.edu) <https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431&context=etd_projects>
>
> [2] An Analysis of the IEEE 802.1X Standard, An Initial Security Analysis of the IEEE 802.1X Standard | Request PDF (researchgate.net) <https://www.researchgate.net/publication/2562682_An_Initial_Security_Analysis_of_the_IEEE_8021X_Standard>
>
>

---

From: Alan DeKok <[email-masked]>
Date: Fri, 5 Feb 2021 08:59:25 -0500

> I think the major decision for the EMU WG to make going forward is to agree if EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not discuss the EAP state machine at all, but i…

  Yes.  Unfortunately 5216 didn't pay enough attention to 4137.  That happens.

> close_notify might be possible to turn into an alternative success indication if the TLS implementation can be profiled to not send any close_notify by itself. I don't know if there are any cases w…

  I  think the TLS libraries rely on the application to initiate close_notify.

> If the wg agrees that an authenticated alternative success indication is needed (this is to my understanding needed in e.g. 802.11) then the process would be that the EAP-TLS server first process t…

  Yes.

> Introducing an authenticated alternative success indication would not require any changes to the -14 message flows. In -13 the commitment message would have to be sent in a later flight than server…

   Yes.  However, I don't think that the close_notify can be sent before verifying the client cert, because IIRC, that closes the TLS connection (server side), and prevents it from sending TLS alerts.

> If a mandatory authenticated alternative success indication is introduced in EAP-TLS 1.3, I do not think any future additions to TLS 1.3 would be needed for EAP-TLS 1.3.

  Yes.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Mon, 8 Feb 2021 05:32:33 +0000

Hi all,

I have now read both the papers. I am not sure the attacks in [2] are anymore possible:

- The first attack described in section 4.1.1 shows that an EAP-Success leads to an unconditional transition to the Authenticated state irrespective of the current state. However, I am not sure this is the case anymore as RFC 4137 (https://tools.ietf.org/html/rfc4137#appendix-A.1) now says :

                             |------------------------+--------------
                             |      rxSuccess &&      |
                             |  (reqId == lastId) &&  |       SUCCESS
                             |   (decision != FAIL)   |
                             |------------------------+--------------

The peer cannot simply transition to SUCCESS state as the decision is initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after the peer decides that the server has sufficiently been authenticated (for EAP methods with mutual authentication).

- The second attack described in section 4.2 relies on the adversary sending a disassociate management frame and then uses the MAC address of the authenticated supplicant to gain network access. This again should not work as a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is followed by 4-way handshake after which there is per packet authenticity and integrity (with Key Confirmation Key). The attacker cannot gain network access without knowing the PMK (derived from the MSK) and performing the 4-way handshake.

The attacks in [1] are not specific to EAP. The attacks relate to Denial of Service (DoS) by injecting spoofed alerts in TLS. John has suggested the following text for the draft (which I think is sufficient):

Protected TLS Error alerts are protected failure result indications and enables the EAP-TLS peer and EAP-TLS server to determine that the failure result was not spoofed by an attacker. Protected failure result indications provide integrity protection and replay but MAY be unauthenticated. Protected failure result does not significantly improve availability as TLS 1.3 treats most malformed data as a fatal error.
--Mohit

[1] Extensible Authentication Protocol Vulnerabilities and Improvements : https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431&context=etd_projects
[2] An Initial Security Analysis of the IEEE 802.1X Standard : http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf

On 2/4/21 2:18 PM, John Mattsson wrote:
Hi Bernard,

I think

Cheers,
John

From: Emu <[email-masked]><mailto:[email-masked]> on behalf of Bernard Aboba <[email-masked]><mailto:[email-masked]>
Date: Tuesday, 2 February 2021 at 16:25
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Emu] Underspecification of EAP-TLS 1.3 State Machine

   altAccept (boolean)

   altReject (boolean)

   eapKeyData (EAP key)

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

---

From: John Mattsson <[email-masked]>
Date: Mon, 8 Feb 2021 06:39:20 +0000

Thanks Mohit,

Based on your comments it seems like protected success indication is not needed in IEEE 802 for security reasons. Would be good with more feedback on this. EAP-TLS 1.3 might get a protected success indication anyway, but the draft should have a few sentences about what the alternate success indication is good for. Would also be good to conclude that other methods do not need an alternate success indication. Seems like e.g. RFC 5448 removed the optional result indications from RFC 4187, probably after an agreement that they were not needed.

Note that RFC 4137 is informal and not mandatory to follow. Similarly a implementation can ignore the alternative success indication unless EAP-TLS 1.3 makes it mandatory. In RFC 5216 it is to my understanding up to the implementation if it wants to use server Finished as a alternate success indication.

Cheers,
John

From: Mohit Sethi M <mohit.m.sethi=[email-masked]>
Date: Monday, 8 February 2021 at 06:33
To: John Mattsson <[email-masked]>, Bernard Aboba <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Hi all,

                             |      rxSuccess &&      |

                             |   (decision != FAIL)   |

I think

Cheers,
John

   altAccept (boolean)

   altReject (boolean)

   eapKeyData (EAP key)

Emu mailing list

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Feb 2021 03:40:11 -0800

John said:

"Based on your comments it seems like protected success indication is not
needed in IEEE 802 for security reasons."

[BA] As described in RFC 4137, protected success indications prevent
attacks involving injection of unprotected EAP-Failure indications, as well
as enabling key synchronization.  So yes, they do serve a purpose.

Would also be good to conclude that other methods do not need an alternate
success indication.

[BA] That would not be good, because it would be an incorrect conclusion.

Note that RFC 4137 is informal and not mandatory to follow.

[BA] Every EAP implementation I am aware of supports RFC 4137.  It was
specifically developed to address security vulnerabilities that were
considered serious enough to block deployment of EAP.  So you can say it is
"informal", "not required", etc. but in practice it is implemented and
necessary.

Similarly a implementation can ignore the alternative success indication
unless EAP-TLS 1.3 makes it mandatory.

[BA] Implementers are going to support alt success and alt failure
indications, as they indicated on the mailing list, because those
indications have been supported by EAP-TLS and other secure EAP methods for
more than a decade. It's not productive to re-introduce security
vulnerabilities into EAP after years of work to remove them.

On Sun, Feb 7, 2021 at 10:39 PM John Mattsson <[email-masked]>
wrote:

> Thanks Mohit,
>
>
>
> Based on your comments it seems like protected success indication is not
> needed in IEEE 802 for security reasons. Would be good with more feedback
> on this. EAP-TLS 1.3 might get a protected success indication anyway, but
> the draft should have a few sentences about what the alternate success
> indication is good for. Would also be good to conclude that other methods
> do not need an alternate success indication. Seems like e.g. RFC 5448
> removed the optional result indications from RFC 4187, probably after an
> agreement that they were not needed.
>
>
>
> Note that RFC 4137 is informal and not mandatory to follow. Similarly a
> implementation can ignore the alternative success indication unless EAP-TLS
> 1.3 makes it mandatory. In RFC 5216 it is to my understanding up to the
> implementation if it wants to use server Finished as a alternate success
> indication.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Mohit Sethi M <mohit.m.sethi=[email-masked]>
> *Date: *Monday, 8 February 2021 at 06:33
> *To: *John Mattsson <[email-masked]>, Bernard Aboba <
> [email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> - The first attack described in section 4.1.1 shows that an EAP-Success
> leads to an unconditional transition to the Authenticated state
> irrespective of the current state. However, I am not sure this is the case
> anymore as RFC 4137 (https://tools.ietf.org/html/rfc4137#appendix-A.1)
> now says :
>
> The peer cannot simply transition to SUCCESS state as the decision is
> initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only
> after the peer decides that the server has sufficiently been authenticated
> (for EAP methods with mutual authentication).
>
> - The second attack described in section 4.2 relies on the adversary
> sending a disassociate management frame and then uses the MAC address of
> the authenticated supplicant to gain network access. This again should not
> work as a) 802.11w-2009 protects disassociate management frame, and b)
> EAP-Success is followed by 4-way handshake after which there is per packet
> authenticity and integrity (with Key Confirmation Key). The attacker cannot
> gain network access without knowing the PMK (derived from the MSK) and
> performing the 4-way handshake.
>
> The attacks in [1] are not specific to EAP. The attacks relate to Denial
> of Service (DoS) by injecting spoofed alerts in TLS. John has suggested the
> following text for the draft (which I think is sufficient):
>
> Protected TLS Error alerts are protected failure result indications and
> enables the EAP-TLS peer and EAP-TLS server to determine that the failure
> result was not spoofed by an attacker. Protected failure result indications
> provide integrity protection and replay but MAY be unauthenticated.
> Protected failure result does not significantly improve availability as TLS
> 1.3 treats most malformed data as a fatal error.
>
> --Mohit
>
> [1] Extensible Authentication Protocol Vulnerabilities and Improvements :
> https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431&context=etd_projects
> [2] An Initial Security Analysis of the IEEE 802.1X Standard :
> http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf
>
> *From: *Emu <[email-masked]> <[email-masked]> on behalf of
> Bernard Aboba <[email-masked]> <[email-masked]>
> *To: *"[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Feb 2021 03:55:51 -0800

Mohit --

The authors of RFC 4137 were among the group (Bill Arbaugh's team and UMD)
that wrote paper [2].  The goal of that RFC was to address the security
vulnerabilities they found, which were considered serious enough to block
the deployment of EAP and IEEE 802.11.  As a result, RFC 4137 is widely
supported by EAP implementations, and bugs (if found) would be considered a
security vulnerability with a fix expected.

On Sun, Feb 7, 2021 at 9:32 PM Mohit Sethi M <[email-masked]>
wrote:

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