[Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

[John Mattsson <[e-mail]>]

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