[PATCH] EAP-TEAP peer: keep inner EAP method when processing Identity method

[Jouni Malinen]

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