On Sun, Nov 27, 2022 at 03:21:11PM +0000, Alexander Clouter wrote: > On Sun, 27 Nov 2022, at 14:47, Jouni Malinen wrote: > > On Sun, Nov 27, 2022 at 02:13:33PM +0000, Alexander Clouter wrote: > >> We need the inner EAP method's MSK/EMSK material to verify/calculate > >> the Cryptobinding CMACs so do not dispose of them when seeing an > >> Identity request; this occurs duing EAP sequences (machine+user auth) > > > > Why would this be needed for the Identity method? It is not an EAP > > authentication method and it is not followed by the > > Intermediate-Result/Crypto-Binding exchange (unlike the actual EAP > > authentication methods would be). Unless I missed something here, this > > seems to be related to this errata entry on the RFC 7170: > > https://www.rfc-editor.org/errata/eid5767 > When EAP chaining (eg. EAP-TLS[machine] followed by EAP-MSCHAPv2[user]) in TEAP, the server sends to the client (along with the cryptobinding and interediate-status TLVs) an EAP Identity-Type to ask the peer for the correct type of identity. OK, but that Identity-Type TLV is not another instance of Identity method (behavior of which is what this patch is proposing to change).. > This is something that is described in RFC7170, in section 4.2.3, 4.3 and in particular is shown in appendix C.6. That Appendix C.6 example is explicitly noting that an identity request is not sent before negotiating EAP-Type=Y. > Windows 11 needs to be prompted on what to use, otherwise it replies with a null identity which opens a whole world of pain. I'm not completely sure what "replies with a null identity" means in this context. Are you about EAP Payload TLV, not Identity-Type TLV here? I.e., there is actually two instances of EAP-Request/Identity within the tunnel? > Back to hostapd though, the presence of that second inner EAP Identity causes it to remove reference to the phase2 method just completed (ie. EAP-TLS) and so results in the fall back onto using eap_teap_derive_cmk_basic_pw_auth() when calculating the CMK in eap_teap.c:eap_teap_get_cmk(). Would you be able to share a debug log showing this? I'm testing this with EAP-MSCHAPv2 for user authentication followed by EAP-MSCHAPv2 for machine authentication and when the second EAP-Request/Identity message is processed between those, the IMSK for the first EAP-MSCHAPv2 has already been fetched and used for CMK calculation. As such, this works fine with the first phase 2 authentication method being cleared after that point. I do not see how eap_teap_derive_cmk_basic_pw_auth() would come into picture here since CMK was already derived before processing the EAP-Request/Identity. It sounds like there is something else happening in the sequence if eap_teap_get_cmk() is reached with data->phase2_method == NULL.. Maybe you are sending out the second EAP-Request/Identity in an EAP-Payload-TLV before the Crypto-Binding-TLV for the previously completed EAP authentication method? If so, I would suggest reordering that (see that C.6 example for an example when moving from EAP-Type X to Y) so that the crypto binding and CMK derivation is completed prior to starting any additional EAP methods, including the Identity method. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
