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

[Alexander Clouter]

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.

This is something that is described in RFC7170, in section 4.2.3, 4.3 and in particular is shown in appendix C.6.

Windows 11 needs to be prompted on what to use, otherwise it replies with a null identity which opens a whole world of pain.

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().

Cheers