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

[Bernard Aboba <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 (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 <[e-mail]> <[e-mail]> on behalf of
> Bernard Aboba <[e-mail]> <[e-mail]>
> *Date: *Tuesday, 2 February 2021 at 16:25
> *To: *"[e-mail]" <[e-mail]> <[e-mail]> <[e-mail]>
> *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>
>
>
> _______________________________________________
> Emu mailing [e-mail]://www.ietf.org/mailman/listinfo/emu
>
>