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....@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
<mailto:alex%2bi...@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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
