On Fri, 24 Mar 2023, at 17:51, Heikki Vatiainen wrote:
> My colleague has been working on a TEAP implementation.
"A new contestant has entered the arena..."
> 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.
We stumbled on this whilst implementing TEAP in FreeRADIUS and had to use
Windows as the reference implementation...that produces no meaningful errors
when it gets upset.
Your colleague may appreciate
https://gist.github.com/jimdigriz/327ef6afa808a1b291d12d68857dec05 at Judgement
Day; advice on how to extract what Windows calculated in its implementation of
the TEAP crypto sausage making machine.
> The main concern was about EMSK. Because EAP-FAST doesn't use EMSK S-IMCK
> calculation, it's easier and more straight forward with its calculation than
> TEAP. Can this simplicity brought back to TEAP by making EMSK support
> mandatory as suggested below?
>
> Problem: Not mandating EMSK
> +++++++++++++++++++++++++++
> Can EMSK support be made mandatory?
7170bis is not about our hopes and dreams, it is about what we see happening in
the wild.
If it works for Windows it should not be a problem.
It is still not too late to change FreeRADIUS and hostapd's implementation is
still marked "may make pants explode".
> 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?
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.
The original errata for RFC7170 by Jouni covers alot of this confusion and I
guess when Microsoft and Cisco did interop they tried to do as much as they
could when
I suspect Jouni did not do any Windows interop testing at the time he built his
implementation, but the method he uses is mostly what FreeRADIUS uses and seems
to be what Microsoft/Cisco used.
That said, in practice other than doing EAP-TLS (EMSK) followed by EAP-MSCHAPv2
(also EMSK), I think any incompatibilities probably would have never been
triggered.
> 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?
If one end does not support EMSK, then MSK is used unless local policy dictates
this is not allowed. The flags for the Cryptobinding point to what each side
did.
> MSK and EMSK track inter-binding
> ++++++++++++++++++++++++++++++++
> Another thing to note with separate MSK and EMSK chains is that there's no
> binding between the two trackings (MSK vs EMSK tracking). This may also be a
> concern?
RFC7170bis details what it looks like Cisco and Microsoft implemented.
Note that this is completely empirical evidence and the only confidence here is
we managed to have {FreeRADIUS,hostapd}<->{wpasupplicant,Windows10/11}
seemingly working, and my liver surviving the stiff liquor necessary to make
that happen.
> Chaining is no longer full chaining
> +++++++++++++++++++++++++++++++++++
> Consider two methods: the first supports EMSK and the second supports only
> MSK. In this case there's no compounding because the first method gets the
> _EMSK suffixed results and the second gets the _MSK suffixed results.
The flags for the present CMACs in the Cryptobinding will be flagged as
'no-EMSK' and the two ends pick the highest option they have between them.
The intention of the last paragraph of section 5.4 is to read as:
* server sends MSK and EMSK, client replies with only MSK, then MSK moves us
* server sends EMSK only, client only has MSK, then failure
* server sends MSK and EMSK, client replies with MSK and EMSK, EMSK mo
> With longer chains there would be jumps to and from MSK and EMSK depending on
> what the methods support. Each time the next method has different EMSK
> capability than the previous method, the compound chaining jumps to the
> different tracking. There's no compound calculation for the full chain.
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.
It is subtle, but the use of "n" and "j" in these sections and the language
"The secret is S-IMCK[n] where n is the number of the last generated S-IMCK[j]
from Section 5.2." is meant to convey that there are two chains you jump
between but the tracking is handled by the Cryptobinding CMAC flags.
Cheers_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
