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
https://www.ietf.org/mailman/listinfo/emu

Reply via email to