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 <mohit.m.se...@ericsson.com> 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 <emu-boun...@ietf.org> <emu-boun...@ietf.org> on behalf of > Bernard Aboba <bernard.ab...@gmail.com> <bernard.ab...@gmail.com> > *Date: *Tuesday, 2 February 2021 at 16:25 > *To: *"emu@ietf.org" <emu@ietf.org> <emu@ietf.org> <emu@ietf.org> > *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 listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
