Hi all, I am catching up on all the discussion of protected indication of success. I think it is important to note that protected indication of success can be exchanged in both directions (i.e. peer to server and server to peer). For example, RFC 3748 says:
For example, within EAP-TLS [RFC2716<https://tools.ietf.org/html/rfc2716>], in the client authentication handshake, the server authenticates the peer, but does not receive a protected indication of whether the peer has authenticated it. In contrast, the peer authenticates the server and is aware of whether the server has authenticated it. In the session resumption handshake, the peer authenticates the server, but does not receive a protected indication of whether the server has authenticated it. In this mode, the server authenticates the peer and is aware of whether the peer has authenticated it. The discussion thus far has mostly focused on protected indication of success from the server to peer. I think in EAP-TLS 1.3 it is useful to have a protected indication of success from the server to the peer. Whether this is close_notify or one byte of application data can be discussed. The reason for having such a protected indication of success from the server to peer is because it also indicates that no more post handshake messages will be sent. But I disagree that such protected indication of success is needed for all EAP methods. Note RFC 3748 says: Result indications improve resilience to loss of Success and Failure packets when EAP is run over lower layers which do not support retransmission or synchronization of the authentication state. In media such as IEEE 802.11, which provides for retransmission, as well as synchronization of authentication state via the 4-way handshake defined in [IEEE-802.11i<https://tools.ietf.org/html/rfc3748#ref-IEEE-802.11i>], additional resilience is typically of marginal benefit. Depending on the method and circumstances, result indications can be spoofable by an attacker. A method is said to provide protected result indications if it supports result indications, as well as the "integrity protection" and "replay protection" claims. A method supporting protected result indications MUST indicate which result indications are protected, and which are not. Protected result indications are not required to protect against rogue authenticators. Within a mutually authenticating method, requiring that the server authenticate to the peer before the peer will accept a Success packet prevents an attacker from acting as a rogue authenticator. Also note that spoofing an EAP-Success will still not force the peer to transition to the SUCCESS state. As shown in appendix A.1 of RFC 4137: rxSuccess && | | (reqId == lastId) && | SUCCESS | (decision != FAIL) The peer cannot simply transition to SUCCESS state as the decision will still be set 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). Additionally, the protected indication of success can help with synchronization of authentication result as noted in RFC 3748: While result indications may enable synchronization of the authentication result between the peer and server, this does not guarantee that the peer and authenticator will be synchronized EAP-NOOB even models an attacker which can selectively drop the last message to cause a synchronization failure and has a mechanism to recover, see: https://tools.ietf.org/html/draft-ietf-emu-eap-noob-03#section-6.7 Finally, as noted in RFC 3748: Success indications may be explicit or implicit. So in some cases, receipt of a message from the server is sufficient to indicate that the peer was authenticated. To summarize, we should have a protected success indication for EAP-TLS but there is no reason to panic and modify all other specifications. --Mohit On 2/6/21 11:43 AM, John Mattsson wrote: Hi, Bernard brought up compability with RFC 4137 and the need for protected alternate indication of success in the context of EAP-TLS 1.3 https://mailarchive.ietf.org/arch/msg/emu/F-LcEX3UbAEX20Amk0xBBqfPQNQ/ I think we need to discuss this in a general EAP setting as this in not EAP-TLS specific at all but also related to all other EAP methods including draft-ietf-emu-rfc5448bis, draft-ietf-emu-aka-pfs, draft-ietf-emu-eap-noob, and draft-ingles-eap-edhoc. The need for anprotected alternate indication of success in IEEE 802.1X is as described in [1] "lack of per-packet authenticity and integrity in IEEE 802.11 frames (data and management) has been a key contributor in many of the protocol's security problems." "due to a series of flaws in the composition of protocols that make up RSN". Regarding solutions [1] states "there are currently no plans by the IEEE to add integrity protection to management frames" "Fortunatly, however, our attacks can easily be prevented through the addition of message authenticity to EAP" To summarize IEEE 802.1X has some design flaws that will not be fixed. Any EAP method must have a protected alternate indication of success to be secure in IEEE 802.1X. The attack seems pretty bad. Without a protected alternate indication of success an attacker can easily hijack the whole connection. I do not have a deep understanding of modern IEEE 802.1X, so I cannot say if anything has changed since 2002. Looking at the other active documents in the EMU WG: draft-ietf-emu-rfc5448bis draft-ietf-emu-aka-pfs draft-ietf-emu-eap-noob and draft-ingles-eap-edhoc None of them has a protected alternate indication of success and they would to my understanding be completely unsecure to use in IEEE 802.1X as it looked like in 2002. Not having a protected alternate indication of success and pushing out keys before success is secure in general, otherwise TLS 1.3 itself would be insecure. I think all of these protocols would be secure when used in 3GPP 5G, but I think basically all EAP protocols want to function with IEEE 802.1X. I think EMU need to verify that protected alternate indication of success is still needed in IEEE 802.1X. If it is I think draft-ietf-emu-rfc5448bis, draft-ietf-emu-aka-pfs, draft-ietf-emu-eap-noob, and draft-ingles-eap-edhoc need to be updated, or state that they cannot be used in IEEE 802.1X. draft-ingles-eap-edhoc would be very easy to fix by just adding EDHOC message_4 which is desgined for use cases like this. EDHOC exported already derived keys from the client's second flight as recently discussed might be good to add to TLS 1.3. [1] http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf Cheers, John _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
