Re: [Emu] [EXTERNAL] Re: More TEAP issues

No, but I would ask that we still have an interim to close the errata.

Eliot

On 01.12.22 06:22, Joseph Salowey wrote:
> 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.com@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-bounces@ietf.org> On Behalf Of Jouni Malinen
>     Sent: Wednesday, November 30, 2022 10:33 AM
>     To: Alexander Clouter <alex+ietf@coremem.com
>     <mailto:alex%2Bietf@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
>     <http://rfc-editor.org>%2Frfc%2Frfc5422%23section-3.2.3&data=05%7C01%7CBruno.Vi
>     > dal%40microsoft.com
>     <http://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
>     <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