On Mon, Jul 22, 2019 at 03:12:15PM -0400, Joseph Salowey wrote: > On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen <jkmali...@gmail.com> 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
