Re: [Emu] RFC 7170 (TEAP) errata

[Jouni Malinen <[e-mail]>]

On Mon, Jul 22, 2019 at 03:12:15PM -0400, Joseph Salowey wrote:
> On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen <[e-mail]> wrote:
> > (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive
> > both MSK and EMSK (or even more complicated, if there are multiple inner
> > EAP authentication methods that have difference in whether they derive MSK
> > or EMSK):
> > https://www.rfc-editor.org/errata/eid5770

> [Joe]  I'd like to hear from implementers on this one.

My current implementation derives two copies of S-IMCK[i] values (one
based on MSK and the other one based on EMSK from the inner EAP method).
Both of these are initialized to session_key_seed. If the inner EAP
method derives EMSK, EMSK Compound MAC gets included in crypto-binding.
MSK is assumed to be derived for all cases where EMSK is derived. If
neither MSK nor EMSK is derived, the "MSK" S-IMCK[j] is derived based on
the all-zeros-IMSK and that is then used to calculate the MSK Compound
MAC field. This implementation does not support a sequence of more than
one inner EAP authentication method that derives keys, so the more
complicated mixes do not show up. Or well, in theory, there is support
for EAP-TNC, so that could show these cases (e.g., with EAP-MSCHAPv2
deriving MSK and that followed by EAP-TNC not deriving any keys), but I
have not tested that combination yet.

I'm currently deriving the TEAP MSK and EMSK based on the MSK-based
S-IMCK[j], but that would be trivial to change to use EMSK-based
S-IMCK[j] (if available) for TEAP EMSK derivation. However, this part
would need to be done based on whether both ends actually claimed to
derive EMSK from the inner EAP method(s) (and with even more complex
rules if only a subset of the inner EAP methods derive EMSK while
another subset does not and those subsets are different at each end).

> I think the intent is that section 5.4 should say the S-IMCK is generated
> as specified  as described in section 5.2.
> 
> Section 5.2 does provide a mechanism to derive the S-IMCK at the end of the
> section.  Each IMCK can be derived in one of 3 ways:
> - MSK
> - EMSK
> - 0s if the method is not key generating

Well, yes, but this is not very helpful now that TEAP added two Compound
MAC values into crypto-binding. There is clearly an assumption that
different IMSK[j] values (and from that, two different S-IMSK[j] values)
are derived if the inner EAP method derives both an MSK and EMSK, but
the sections describing derivations and use of these keys do not take
into account that need for two independent values.

> There is ambiguity on how to derive each IMSK in the case that both sides
> do not have the same capability to export the EMSK.   I think the steps
> involving the compound MAC are meant to disambiguate this situation.

They were probably meant to do that, but they did not really.

> Is the problem that the section does not explicitly say how to use the
> compound MAC sent to determine which IMCK derivation to use?

No, the problem is in one of the design (crypto-binding
construction/validation) assuming there are two values (MSK-based and
EMSK-based) while the IMSK[j]/IMCK[j] derivation part assuming only one
value (EMSK-based, if available, otherwise MSK-based) is derived.
Furthermore, the TEAP MSK/EMSK derivation rules assumes there is only
one S-IMCK[j]. This would have all worked fine if the crypto-binding
design from EAP-FAST had not been extended to cover the EMSK case, but
I'd guess that addition was done based on some review, but that did not
end up getting fully baked into the TEAP design to make it work.

-- 
Jouni Malinen                                            PGP id EFC895FA