Re: [Emu] More TEAP issues

[Jouni Malinen <[e-mail]>]

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://www.rfc-editor.org/rfc/rfc5422#section-3.2.3

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