It sounds like we are gaining consensus to create a revision of TEAP. The emphasis would be (in priority order):
- Aligning specification with current implementations - Clarifying the existing specification - Adding missing TLVs to make existing use cases work better The goal is to get this revision done quickly to prevent further implementation divergence. Changes will need to go through the working group process. Errata should be addressed when relevant portions of the document are updated. Does anyone object to this approach? Thanks, Joe and Peter On Wed, Nov 30, 2022 at 12:48 PM Bruno Pereira Vidal <Bruno.Vidal= 40microsoft....@dmarc.ietf.org> wrote: > I also think option 3 is the preferred one at this point, given the > interoperable implementations that have already shipped. In addition to > Cisco ISE, the Windows TEAP implementation has also been validated against > Aruba ClearPass. > > The person who implemented the Windows client code is no longer at > Microsoft and, unfortunately, I don't recall why this ended up being > implemented like this. It is likely that it was inadvertently inherited > from EAP-FAST as mentioned below. > > Thanks, > Bruno > > -----Original Message----- > From: Emu <emu-boun...@ietf.org> On Behalf Of Jouni Malinen > Sent: Wednesday, November 30, 2022 10:33 AM > To: Alexander Clouter <alex+i...@coremem.com> > Cc: EMU WG <emu@ietf.org> > Subject: [EXTERNAL] Re: [Emu] More TEAP issues > > On Wed, Nov 30, 2022 at 03:01:08PM +0000, Alexander Clouter wrote: > > On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote: > > > Based on interoperability testing, it looks like implementations > > > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170: > > > EAP-FAST almost does not document this until you look at a latter RFC > covering the provisioning component: > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc-editor.org%2Frfc%2Frfc5422%23section-3.2.3&data=05%7C01%7CBruno.Vi > > dal%40microsoft.com%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f14 > > 1af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > > 7C3000%7C%7C%7C&sdata=PqpDLwSPz0sh%2BsSlXadTZCAWI2835mdqgZvR2jN1Vgw%3D > > &reserved=0 > > And that section has a history of its own.. If you take a look at the > latest draft (-10), that language is not there, i.e., it got added quite > late in the process and the related discussions were not exactly > considering this positively. If I remember correctly, this mismatch with > how EAP-MSCHAPv2 was defined was seen as something that should not really > have been done and the EAP-FAST-MSCHAPv2 was named such to be distinguished > from EAP-MSCHAPv2 and also as a reminder not to use this variant for > anything else than EAP-FAST (which had already been deployed with it). > Nevertheless, here we are 15 years later hitting this exact same thing with > TEAP having been deployed with the design that was not supposed to be > repeated.. > > > Really easy to miss for an implementer, especially as when you start > implementing FAST (or TEAP) you begin with authentication and think you can > ignore the PAC component at first. > > While I started working on TEAP implementation by copying FAST > implementation to be the starting point, one of my first steps was to try > to remove all the hacks needed to get EAP-FAST interoperable since I was > familiar with the history.. But yes, it would be next to impossible to > implement either EAP-FAST or EAP-TEAP based on just the RFCs and get to > something that interoperates with anything already deployed. > > > The other biggy is that it is easy to miss that for each EAP method in a > sequence, you need to include an EAP Identity response along with the > Identity-Type TLV to the peer. > > And that will hopefully not include another instance of Crypto-Binding for > the EAP-Identity exchange. This is related to one of my errata comments on > EAP method vs. EAP authentication method (the latter needs crypto binding; > the former probably does not, but RFC 7170 is not clear). > > > > 3) declare 7170 irretrievably broken, and write 7170bis which > > > documents how TEAP version 1 operates in practice. > > > > This is my preference too. > > While this might not result in the cleanest protocol design, I'd agree > that this is likely the best approach from the view point of getting > something useful out there and into wider use. > > > Regarding a separate comment about new TLVs (and new functionality in > general, I'd guess), I have no significant issues including that in a new > RFC, but I do hope that the initial focus would be in addressing the > existing areas and already identified issues to get to a point where there > is a clearly identifiable Internet-Draft describing how one can > successfully implement EAP-TEAP in a manner that interoperates with > deployed implementations. > > -- > Jouni Malinen PGP id EFC895FA > > _______________________________________________ > Emu mailing list > Emu@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=05%7C01%7CBruno.Vidal%40microsoft.com%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pz4lgBHc0Y37IWf6EJ5Dr%2BaR7COUYesNVhomKHmNrIs%3D&reserved=0 > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
