Re: [Emu] More TEAP issues

[Alexander Clouter <[e-mail]>]

Hello,

On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> Based on interoperability testing, it looks like implementations 
> followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
>
> http://lists.infradead.org/pipermail/hostap/2022-July/040639.html
>
> http://lists.infradead.org/pipermail/hostap/2022-November/041060.html

EAP-FAST almost does not document this until you look at a latter RFC covering the provisioning component:

https://www.rfc-editor.org/rfc/rfc5422#section-3.2.3

Really easy to miss for an implementer, especially as when you start implementing FAST (or TEAP) you begin with authentication and think you can ignore the PAC component at first.

I suspect Microsoft and Cisco just cut'n'pasted from their FAST implementation and used it whilst implementing TEAP and never looked back. It worked as they may have both done this.

The other biggy is that it is easy to miss that for each EAP method in a sequence, you need to include an EAP Identity response along with the Identity-Type TLV to the peer.

Windows 10/11 wonderfully from their UI configure (as labelled) 'first' and 'second' method, but after completing the first if the server does not ask for the identity of the second, Windows will return a zero length identity and then refuse to go any further; well I was unable to persuade it.

Once you figure this out, it sort of makes sense (thinking of how a peer may have chosen to implement its state machine and that as a server you may want to proxy a given method) but EAP sequences themselves are not really well defined.

EAP (https://www.rfc-editor.org/rfc/rfc3748#section-2.1) only covers that outside a tunnel this is not supported.

FAST (https://www.rfc-editor.org/rfc/rfc4851#section-3.3.1) and TEAP (https://www.rfc-editor.org/rfc/rfc7170.html#section-3.3.1) states why they are allowed to use sequences and only because of Intermediate-Result/Crypto-Binding TLVs.

I have not yet found anything that provides guidance on how to actually do an EAP sequence.

FAST (https://www.rfc-editor.org/rfc/rfc4851#appendix-A.6) does not state you need to send a EAP Identity at the start of each method other than for the first one. I do not know if this is accurate as we never implemented for FreeRADIUS sequences for FAST.

TEAP (https://www.rfc-editor.org/rfc/rfc7170.html#appendix-C.6) also does not, but I know from the FreeRADIUS implementation it was needed to get sequences to work.

It took this implementer quite a while to realise that each EAP method in a sequence stands alone to the others and needs to be initiated with an EAP-Identity response.

> 3) declare 7170  irretrievably broken, and write 7170bis which 
> documents how TEAP version 1 operates in practice.

This is my preference too.

Whilst this is all in my head, having just done the FreeRADIUS/hostapd/Win10/Win11 interop work, I willing to kick off process by updating the existing RFC.

Fortunately during my work I also submitted fixes to Wireshark so since 4.0 you get TEAP decoding and inner EAP-TLS decryption so this allows us to share PCAPs of this in the wild. Hopefully with that people here can use it to fix up my notes to remove any further ambiguity if that sounds useful to others?

Thanks

Alex