On Fri, 24 Mar 2023 at 20:42, Alexander Clouter <alex+i...@coremem.com> wrote:
> On Fri, 24 Mar 2023, at 17:51, Heikki Vatiainen wrote: > > "A new contestant has entered the arena..." > Indeed. It's about the time we implement this too. > The implementation was done based on the RFC and the draft but required > tailoring to make it interoperable with wpa_supplicant's eapol_test with > certain configurations, but that wasn't the main concern. > > > If you are using eapol_test prior to a few TEAP patches (reversed EAP-FAST > MSK calculation and ordering of the Cryptobinding processing) then it > should just work out the box. > I think the case in question where the inner methods were two Basic-Password-Auths (e.g., machine and user type). eapol_test was from the latest git source exactly of the reasons you mentioned. > Section 5.2 in the RFC and the draft currently says: > > If an inner method supports export of an Extended Master Session Key > (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in > [RFC5295]. > > The SHOULD above would change to MUST. This paragraph could then be > removed completely: > > However, it is possible that the peer and server sides might not have > the same capability to export EMSK. In order to maintain maximum > flexibility while prevent downgrading attack, the following mechanism is in > place. > > > Is this not though why it all exists, because the other end may not have > access to an EMSK? > RFC 7170 is from 2014. It may have been useful at that time, but is this still the case? Is it reasonable to implement TEAP in 2020s but not having EMSK supported for an inner EAP that has EMSK defined. TEAP can be implemented as the draft currently says. Mandatory EMSK would make it simpler, though. I do not think it can in general just be ripped out. > > In other words, EMSK support would be mandatory and there would not be any > need to track _MSK and _EMSK derivations, as defined by end of section 5.2. > > > None of this is here because we want it, it is there as it looks to be how > Windows implemented things. > We haven't tried with Windows yet. Windows doesn't export EMSK for all methods that could support it? > Ending up with different EMSK values > ++++++++++++++++++++++++++++++++++++ > If the peer and server have different capability of EMSK calculation, > correctly working implementations will end up with an error 2001 'Tunnel > Compromise Error' (or some other error). This can happen, for example, with > two chained methods that are both EMSK capable. If the server doesn't > export EMSK for the first method but both export EMSK for the second > method, the peer and server end up with different values for the EMSK after > the second round. > > > I do not understand why the EMSK calculations would be different for the > same method? > To clarify what I meant: when two independent derivations if IMCK[j] are tracked, the EMSK based tracking would look different on peer and server. Client runs the derivation loop twice and the server only once. This is how I understood it the report I got a couple of days ago while away from the office. In other words, because the peer and server do not know about each other's EMSK capabilities, they can end up calculating different tracking for EMSK derived compound values. Wouldn't this be the case with non-mandatory EMSK support? > The language in sections 5.2, 5.3 and 5.4 have had some churn, and maybe > some more is needed, especially whilst this is all fresh in your colleagues > mind. > Yes, that's the intention. This is very new still and we're in a good position to clarify the findings. I've cut a lot from your reply and will think about it in more detail. Thanks, Heikki -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
