Hi John, all: First of all my apoligies if some thoughts in my e-mail have been already discussed. Please see inline.
> El 6 feb 2021, a las 10:43, John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> escribió: > > 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/ If we take RFC 4137 as reference, altAccept and altReject are variables that are part of the interface defined from lower layer to EAP peer state machine (4.1.1. Variables (Lower Layer to Peer)). Therefore, I believe these variables are not related to the EAP method itself, unless I am missing something. These variables are more related with section 3.4 <https://tools.ietf.org/html/rfc3748#section-3.4>. Lower Layer Indications in RFC 3748. I mention this because these variables have been mentioned in relation to EAP-TLS. In any case, I think it would be important to clarify this because, as I said, I may be missing something. Regarding eapKeyAvailable and eapKeyData, Figure 3 in RFC 4137 (https://tools.ietf.org/pdf/rfc4137.pdf <https://tools.ietf.org/pdf/rfc4137.pdf>) shows that the variable eapKeyAvailable is set to TRUE in the SUCCESS state, if key is available in eapKeyData. The SUCCESS state is reached in two cases: when an EAP Success is received or altAccept is set to TRUE. This variable altAccept is set by Lower Layer to EAP peer state machine. The same happens for altReject. However eapKeyData may have the key (see METHOD state) but the eapKeyAvailable variable will be FALSE until the EAP Success or altAccept is TRUE. It is completely certain that EAP Success is not protected and the message that enables the altAccept may be unprotected (e.g. first message of 4-way handshake in IEEE 802.11). Having said this, I think section 7.16 <https://tools.ietf.org/html/rfc3748#section-7.16>. Protected Result Indications in RFC 3748 is also relevant for the discussion. In this sense, regarding draft-ingles-eap-edhoc please see below: > > 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 message_4 would help, however if you merely include this in the current flow in Figure 1 in draft-ingles-eap-edhoc you will need an extra message_5 because EDHOC message_4 would be contained in a EAP Request so you need an EAP Response. To avoid this, my proposal is to change the roles (initiator, responder) so that the EDHOC exchanges would be as follows: Responder Initiator +--------+ +-------+ | EAP | | EAP | | Peer | | AuthN | +--------+ +-------+ | EAP-Request/Identity | | <---------------------------------------------------+ | | | | EAP-Response/Identity (ID) | | +---------------------------------------------------> | | EAP-Request/ | | EAP-Type=EAP-EDHOC | | (EDHOC message 1) | | <---------------------------------------------------+ | | EAP-Response/ | | EAP-Type=EAP-EDHOC | | (EDHOC message 2) | | +---------------------------------------------------> | peer authenticated | EAP-Request/ | | EAP-Type=EAP-EDHOC | | (EDHOC message 3) | | <---------------------------------------------------+ | server authenticated eapKeyData = m.getKey() | | | | EAP-Response/ | | EAP-Type=EAP-EDHOC | | (EDHOC message 4) | | +---------------------------------------------------> | | | eapKeyData = m.getKey() | EAP-Success | | <---------------------------------------------------+ | + + With EDHOC message 2 the peer is authenticated; with EDHOC message 3 the server can be authenticated by the peer and it is an protected indication to the peer that the server authenticated it. In that moment, the key can be pushed to eapKeyData in the EAP peer state machine (see METHOD state in RFC 4137 in Fig. 3). EDHOC message 4 is used for key confirmation and as an protected indication the peer has authenticated the server. The server after verifying EDHOC message 4 makes the key available to eapKeyData. In this model, the EDHOC initiator is the server and the responder, the peer. If this is acceptable to solve the issue in EAP-EDHOC, we can update the document with this change. At least, it would cover the following text in 7.16 <https://tools.ietf.org/html/rfc3748#section-7.16>. Protected Result Indications in RFC 3748: "In a method supporting result indications, a peer that has authenticated the server does not consider the authentication successful until it receives an indication that the server successfully authenticated it. Similarly, a server that has successfully authenticated the peer does not consider the authentication successful until it receives an indication that the peer has authenticated the server.” Any opinion? Best Regards. > 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 > https://www.ietf.org/mailman/listinfo/emu ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es -------------------------------------------------------
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
