I will add some text on this vulnerablity, which is enabled because some TLS-based methods share the same key-derivation formula.
How about this?
"4.6. Packet Modification Attacks The integrity protection of EAP-TLS packets does not extend to the EAP header fields (Code, Identifier, Length) or the Type or Flags fields. As a result, these fields may be modified by attacker. In most cases modification of the Code or Identifier fields will only result in a denial of service attack. However, it may be possible for an attacker to add additional data to an EAP-TLS packet so as to cause it to be longer than implied by the Length field. An implementation that does not check for this could be vulnerable to a buffer overrun. It is also possible for an attacker to modify the Type or Flags fields. By modifying the Type field, an attacker could cause one TLS-based EAP method to be negotiated instead of another. For example, the EAP-TLS Type field (13) could be changed to indicate another TLS-based EAP method. Unless the alternative TLS-based EAP method utilizes a different key derivation formula, it is possible that an EAP method conversation altered by a man-in-the-middle could run all the way to completion without detection. Unless the ciphersuite selection policies are identical for all TLS-based EAP methods utilizing the same key derivation formula, it may be possible for an attacker to mount a successful downgrade attack, causing the peer to utilize an inferior ciphersuite or TLS-based EAP method." _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
