Interop Testing - emu-wg/rfc7170bis GitHub Wiki
TEAP Interop Testing
For logs, in the table below, the links correspond to:
- Supplicant (Client):
- for Windows 10 and 11 this is the
.etlcapture file - the
.txtfile in the ZIP is the dumped text format (converted fromUTF-16LEtoUTF-8), for the interesting lines filter forEapTeap
- for Windows 10 and 11 this is the
- Authentication Server:
- for FreeRADIUS this is effectively the output captured from
-X
- for FreeRADIUS this is effectively the output captured from
- Result:
- packet capture of the RADIUS traffic from the Authenticator to the Authentication Server
- RADIUS client secret is
testing123
TODO
- grab packet captures of Windows refusing to do Basic Password Authentication
- add
hostapdas 'Authentication Server' - add
eapol_test(pretending to bewpa_supplicant) as 'Supplicant (Client)'
Conclusions
- Windows does not implement EMSK at all for the inner EAP-TLS methods (confirmed also by Microsoft)
- as the only(?) supplicant supporting TEAP in production it may be possible to resolve the confusion here and remain 'backwards compatible'
- there are a few server implementations that may get upset if they implemented handling EMSK differently though
- Windows does not implement Basic Password Authentication (confirmed also by Microsoft)
- Both FreeRADIUS and Windows allow
machine + machineauthentication, duplicating the first authentication run- FreeRADIUS fixed as of
6709ef6to prevent this
- FreeRADIUS fixed as of
MSK and EMSK
It looks like all implementations are compatible when only the MSK Compound MAC is used.
It looks like all implementations are compatible when the inner method is only EAP-TLS. The EMSK Compound MAC calculations are clear, and can be done without any ambiguity.
It looks like all of the implementations are compatible when the inner methods are EAP-TLS, followed by EAP-MSCHAPv2. Again, there is no ambiguity in the calculations of the EMSK Compound MAC. The second inner method is MSK only, and therefore doesn't use the EMSK Compound MAC.
However, once the second method is EAP-TLS, the EMSK Compound MAC calculation depends on the earlier data, where therefore is subject to ambiguity. It looks like everyone did something different.
Results
.pcapng Notes
To decode the .pcapng (includes the TLS key log) correctly with Wireshark, it is recommend you use version 4.1.x or 4.2.x as:
- later than v4.3.0rc1 requires a hack applied
- earlier than (though not inclusive of) version 4.3.0rc1 works
6b95c52prevents dissection (though the TLS layer is decrypted) of the inner methods (also affects EAP-TTLS, PEAP, ...)
- version 4.1.0 or later is required to decoding TEAP for you
- version 3.7.0 or later if you only require the TLS layer is decrypted and are happy to decode by TEAP by hand
Microsoft Windows
Testing was done using QEMU with the WinCI project and its 802.1X test bed.
| Supplicant (Client) | Authenticator | Authentication Server | (Inner) Methods | Result | Notes |
|---|---|---|---|---|---|
| Windows 11 (24H2 x64) | N/A | N/A | Basic Password Authentication | Not Implemented | Supplicant does not implement non-EAP based authentication |
| Windows 10 (22H2 x64) | N/A | N/A | Basic Password Authentication | Not Implemented | Supplicant does not implement non-EAP based authentication |
| Windows 11 (24H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
eap-mschapv2[user] |
Success | |
| Windows 10 (22H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
eap-mschapv2[user] |
Success | |
| Windows 11 (24H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
eap-mschapv2[user], eap-mschapv2[machine] |
NOT TESTED | |
| Windows 10 (22H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
eap-mschapv2[user], eap-mschapv2[machine] |
NOT TESTED | |
| Windows 11 (24H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
eap-mschapv2[user], tls[machine] |
Success | Supplicant only supports MSK for EAP-TLS |
| Windows 10 (22H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
eap-mschapv2[user], tls[machine] |
Success | Supplicant only supports MSK for EAP-TLS |
| Windows 11 (24H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine] |
Success | Supplicant only supports MSK for EAP-TLS |
| Windows 10 (22H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine] |
Success | Supplicant only supports MSK for EAP-TLS |
| Windows 11 (24H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine], tls[machine] |
Success | Duplicates First Authentication; Supplicant only supports MSK for EAP-TLS |
| Windows 10 (22H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine], tls[machine] |
Success | Duplicates First Authentication; Supplicant only supports MSK for EAP-TLS |
| Windows 11 (24H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine], tls[user] |
Unsupported | Supplicant only supports MSK for EAP-TLS, User authentication fails as QEMU unable to emulate usable Smartcard (Supplicant popup awaiting suitable user Smartcard credential); Supplicant sends null identity (indicating no credentials available?) |
| Windows 10 (22H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine], tls[user] |
Unsupported | Supplicant only supports MSK for EAP-TLS, User authentication fails as QEMU unable to emulate usable Smartcard (Supplicant popup awaiting suitable user Smartcard credential); Supplicant sends null identity (indicating no credentials available?) |
| Windows 11 (24H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine], eap-mschapv2[user] |
Success | Supplicant only supports MSK for EAP-TLS |
| Windows 10 (22H2 x64) | hostapd (25876e9) |
FreeRADIUS (3.2.x:93a87d4) |
tls[machine], eap-mschapv2[user] |
Success | Supplicant only supports MSK for EAP-TLS |
Aruba / HP ClearPass
Discussion with the Aruba team indicates that they are compatible with Windows.
They support:
- EAP-TLS for both inner methods
- EAP-MSCHAPv2 for both inner methods
- Mixed EAP-TLS / EAP-MSCHAPv2
They do not support:
- EAP-TLS only for inner method
- Basic-Password
Result matrix, using recent git clone of hostap, and the temporary flag teap_compat=freeradius
| Method-1 | Method-2 | flag | Results |
|---|---|---|---|
| EAP-MSCHAPv2 | EAP-MSCHAPv2 | Enabled freeradius | ACCEPT |
| EAP-MSCHAPv2 | EAP-MSCHAPv2 | Disabled freeradius | ACCEPT |
| EAP-MSCHAPv2 | EAP-TLS | Enabled freeradius | Reject |
| EAP-MSCHAPv2 | EAP-TLS | Disabled freeradius | Reject |
| EAP-TLS | EAP-MSCHAPv2 | Enabled freeradius | ACCEPT |
| EAP-TLS | EAP-MSCHAPv2 | Disabled freeradius | ACCEPT |
| EAP-TLS | EAP-TLS | Enabled freeradius | Reject |
| EAP-TLS | EAP-TLS | Disabled freeradius | Reject |
Cisco ISE
Version 3.4.0.608 (released 2024-12-18) was used during testing.
| Authenticator | teap_compat |
Authentication Server | (Inner) Methods | Result | Notes |
|---|---|---|---|---|---|
eapol_test (25876e9) |
Default | Cisco ISE (v3.4.0.608) | eap-mschapv2[user] |
Success | |
eapol_test (25876e9) |
freeradius |
Cisco ISE (v3.4.0.608) | eap-mschapv2[user] |
Success | |
eapol_test (25876e9) |
Default | Cisco ISE (v3.4.0.608) | tls[user] |
Failed | Access-Accept but eapol_test detects 'PMK mismatch' |
eapol_test (25876e9) |
freeradius |
Cisco ISE (v3.4.0.608) | tls[user] |
Failed | Access-Accept but eapol_test detects 'PMK mismatch' |
eapol_test (25876e9) |
Default | Cisco ISE (v3.4.0.608) | eap-mschapv2[user], tls[machine] |
Failed | Access-Reject due to 'cryptobinding verification failed' |
eapol_test (25876e9) |
freeradius |
Cisco ISE (v3.4.0.608) | eap-mschapv2[user], tls[machine] |
Failed | Access-Accept but eapol_test detects 'PMK mismatch' |
eapol_test (25876e9) |
Default | Cisco ISE (v3.4.0.608) | tls[user], tls[machine] |
Failed | eapol_test states 'MSK Compound MAC did not match' |
eapol_test (25876e9) |
freeradius |
Cisco ISE (v3.4.0.608) | tls[user], tls[machine] |
Failed | Access-Accept but eapol_test detects 'PMK mismatch' |
Observations
- When chaining is enabled, Cisco ISE sends
Identity-Type-TLV - Does send a PAC-TLV (when EAP-FAST+PAC is enabled, no explict option for TEAP)