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