On Mon, Apr 02, 2007 at 10:41:09PM -0400, Hao Zhou (hzhou) wrote: > > differently.. The main issue for me from the implementation > > view point has been lack of clear description of the protocol > > and existance of differently behaving and already deployed > > implementations.. > [HZ] That's not true. There are only two PEAP versions in deployment, > PEAPv0 and PEAPv1. They are different between them. But among PEAPv0 or > PEAPv1 implementations, they interoperate.
Have you run interop tests with PEAPv0 and PEAPv1 using a large set of different server implementations? I've tested with ten or so servers that supported various combinations of PEAPv0 and PEAPv1. There were at least six different combinations on behaviors that required peer workarounds to handle.. PEAPv1 is more problematic on this front since there is more than one IETF draft describing a protocol that uses version 1 and these drafts differ on number of areas and none of these drafts actually describe the exact behavior that most servers uses.. 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). Another difference is in how the negotiation is terminated. Some implementations require protected success indication by use of a tunneled EAP-Success. Some use just plain EAP-Success outside the tunnel without any protected success indication. Yet another interoperability issue. 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). In other words, PEAPv1 is not exactly something I would consider a good example of an interoperable or well-defined EAP method. I think that EAP-PEAP has caused more interop issues in my tests than all other methods combined.. Sure, this is partly due to most implementations supporting PEAP in one form or another so there are more test cases, but still, EAP-TLS and EAP-TTLS have been more or less problem free from the view point of seeing different behavior from implementations. > [HZ] That's the problem. We cannot add or take away functionalities and > maintain interoperability without incrementing the version. If we do > that, then how is that different than creating a new EAP method. The > design team is looking at approach similar to TTLS/PEAP/EAP-FAST, with a > much simpler inner data representation. Whatever the argument made for > TTLS, we can make it for PEAP and EAP-FAST. I haven't went through the details of what would be needed for the changes while trying to maintain backwards compatibility within the same version number, so I cannot comment on the first part, but I can agree with the second. Anyway, I certainly support the idea of using something existing as a starting point whether the end result ends up using the same method number and version or not. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
