On Sat, 31 Dec 2022, at 17:14, Oleg Pekar wrote:
> Few initial comments:
>
> [snipped EAP sequences scene setting]
>
> Thus we considered in one of the previous discussions to say in Section 3.3.1
> of TEAP "Upon completion of each EAP __authentication__ method in the tunnel,
> the server MUST send an Intermediate-Result TLV...". And then "EAP
> authentication method is EAP type 4 or greater".
I flagged earlier how EAP sequences are very poorly defined in general for any
EAP method and for TEAP it is no different. I would like to see some language
to help steer implementers in the right direction.
To interop with Windows 10/11, the server needs to front load every
EAP-Payload-TLV sequence with an EAP-Request/Identity (in addition to the
Identity-Type-TLV) otherwise things will not work; similarly if you omit the
Identity-Type-TLV Windows will just stall and reply with the empty EAP Identity
and go no further.
This sort of makes sense when you view each EAP-Payload-TLV sequence as a
standalone authentication, but it is easy to miss that you need to rollback
your EAP state machine all the way to the beginning rather than just fly
straight into EAP-TLS/EAP-FAST-MSCHAPv2/whatever.
Appendix C.6 (Sequence of EAP Methods) will need to be updated to show this too.
For those who want to see it, if you use Wireshark 4.x it includes some EAP and
TLS fixes I submitted so you can decode TLS records into cleartext and explore
the inner methods directly. I have uploaded[1] a sample capture showing TEAP
with chaining EAP-TLS[machine] and EAP-MSCHAPv2[user].
So section 3.3.1 should have something like:
"Implementers should treat EAP-Payload-TLV as a separate/isolated EAP
authentication which means your state machine has to be rolled back to
sending/expecting an EAP-Identity request/response. This is in addition to the
Identity-Type-TLV, Intermediate-Result-TLV and Cryptobinding-TLV".
> 5) Regarding "3.3.3. EAP-MSCHAPv2" I would suggest to explicitly mention the
> document where EAP-MSCHAPv2 MSK 16-octets blocks order is defined (the order
> that is different from EAP-FAST-MSCHAPv2). We should also mention that in
> PEAP and maybe some other protocols the original (non EAP-FAST-MSCHAPv2)
> order is used.
This would be good to see. When trying to implement a TEAP server, it was a
mystery why Windows was rejecting the request until I had figured out[2] the
(undocumented) way to explore EAP Tracing under Windows.
Thanks
[1] https://stuff.digriz.org.uk/dump.pcapng
[2] https://gist.github.com/jimdigriz/327ef6afa808a1b291d12d68857dec05
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
