Alan DeKok <al...@deployingradius.com> wrote:
> In short, for inner methods, the following combinations work for all
implementations:
> * EAP-MSCHAPv2
> * EAP-MSCHAPv2 followed by EAP-MSCHAPv2
> That's it.
> If the suppliant doesn't include the EMSK Compound-MAC in the
> Crypto-Binding TLV, then all combinations of EAP-MSCHAPv2 and EAP-TLS
> work, either one at a time, or in any combination.
> Subject to a bug fix in one implementation, the following also works:
> * EAP-TLS
> * EAP-TLS followed by EAP-MSCHAPv2
> EAP-TLS all by itself works because the derivation of the EMSK Compound
> MAC for the first round is clear.
> EAP-TLS following by EAP-MSCHAPv2 works because for EAP-TLS, the EMSK
> Compound MAC works as above. And EAP-MSCHAPv2 uses only the MSK
> Command MAC. Any issues with deriving different ESMK Compound MAC for
> the second inner method are therefore avoided.
Assuming that this one implementation fix is easy to do and to deploy[%]
ubiquitously, then I suggest that RFC7170 document *the above* and the above
*only* for TEAPv1. You say as much below.
[%]-if it's something that 70% of smartphones older than 2022 or something
will never get fixed, then I'd say it's not easily deployed. If it's
a server side fix that everyone is motivated to deploy, that'd different.
> Nothing else works across all implementations.
Then that's what the document should say.
> The issue seems to be that all implementations did something different
> to derive the EMSK Compound MAC for the second inner method. As a
> result, we have shipping code from multiple vendors which doesn't
> interoperate.
> This is about the worst outcome I could think of. We now need to decide
what to do about it.
> That decision is informed by the additional knowledge that there's
> really only one shipping / production supplicant for TEAP: MSFT. TEAP
> is in hostap / wpa_supplicant, but hasn't been used in production
> environments. Other supplicants either don't exist, or their vendors
> aren't participating here.
This is a client/desktop/laptop implementation then?
How far back does it go? Win10? Win7? WinXP?
> The simplest way forward that I can think of is the following:
> 1) declare the MSFT behaviour TEAPv0. Crypto-Binding contains only the
> MSK Compound MAC, the EMSK Compound MAC is always zero
Is version 0 even valid?
What do these old versions declare as their version?
> 2) decide what we want to do to derive the EMSK Compound MAC. Write it
> down. Test it with implementations.
> 3) issue TEAPv1 which defines the EMSK Compound MAC, and uses it in the
> Crypto-Binding TLV.
I'm confused by v0/v1 vs v1/v2, but it seems like the right plan to me.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
