Please see inline. > -----Original Message----- > From: Jouni Malinen [mailto:[EMAIL PROTECTED] > Sent: Monday, April 02, 2007 10:07 PM > To: Bernard Aboba > Cc: [email protected] > Subject: Re: [Emu] Thoughts on Password-based EAP Methods > > On Mon, Apr 02, 2007 at 03:45:44PM -0700, Bernard Aboba wrote: > > > I would agree that "versioning" is not a good idea. However, as I > > understand it, EAP-TTLSv0 is the only deployed version of > TTLS; v1 has > > never been implemented. So currently there is no > versioning issue with > > TTLS, and if possible, it would be best if the IETF would > not create > > such a problem. > > I'm aware of at least one, though maybe partial, > implementation of TTLSv1. Anyway, I don't think it has been > deployed anywhere. > > > It is not clear to me that EAP-TTLS needs "versioning" in order to > > enable addition of new features in a backwards compatible > way, since > > it already supports a TLV-based extension mechanism. > > If this can be done in backwards compatible way, staying with > the v0 sounds reasonable assuming features from TTLSv1 are > not desired and I don't think would necessarily like to > mandate TLS/IA support for the method to be standardized. > [HZ] My point is that we cannot do it in a backward compatible way. First of all, not sure we need the Diameter AVP complexity inside the tunnel. Second of all, TTLSv0 doesn't have crypto-binding and agility, which mostly require changes that are not backward compatible. > In general, the PEAP version negotiation itself works fine, > but one of the problems is that number of different > implementations _within_ the same version number work > 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. > > EAP-TTLSv0 is in better situation from the viewpoint of most > implementation behaving more or less in the same way. > However, this can get interesting if new extensions are added > and if some of the implementations are not exactly prepared for this. > [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.
> -- > Jouni Malinen PGP > id EFC895FA > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
