For example, at least one server uses "client PEAP encryption" as the label for PRF whereas most use "client EAP encryption". That is clearly an interoperability issue (I've only seen this with PEAPv1 and one RADIUS server, but anyway that is the label described in some of the drafts).
Using the same label string as EAP-TLS (e.g. "client EAP encryption") enables an attacker to modify the PEAP Type Code without detection, since the Type field is not included in the MIC.
One strange case was an implementation that uses incorrect version negotiation and in practice ends up always using v0 (which itself interoperates relatively well, so this is not a major problem).
The PEAP version negotiation assumes that implementations support all the downward compatible versions, so that a server advertising PEAPv1 also can negotiate (and support) PEAPv0. However, this assumes that endpoints will negotiate the highest available version. Unfortunately, there are now multiple versions of PEAPv0, some of which include functionality not supported by PEAPv1, so that this assumption is not really valid.
I think that PEAP has caused more interop issues in my tests than all other methods combined..
Right. Not surprisingly, PEAP also been the source of a huge number of customer complaints.
Still, EAP-TLS and EAP-TTLS have been more or less problem free from the view point of seeing different behavior from implementations.
At least this was true prior to the deployment of TLSv1.1 implementations. I'm afraid that since then we are seeing a substantial rise in interoperability problems with all TLS-based EAP methods. Hopefully this will subside once broken TLS v1.0 implementations are fixed in the field.
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
