On Mar 6, 2025, at 6:19 AM, Peter Yee wrote:
> We still have some time available in our time slot, so if you want to present
> something that I've missed, please let me know. And for those of you already
> on the agenda, let me know if I did not get the duration of your presentation
> right.
On Thu, 6 Mar 2025, at 18:19, Michael Richardson wrote:
>> That decision is informed by the additional knowledge that there's
>> really only one shipping / production supplicant for TEAP: MSFT. TEAP
>> is in hostap / wpa_supplicant, but hasn't been used in production
>> environments. Other suppli
Question for y'all, looking at the matrix:
Windows + hostapd + FreeRADIUS + tls[machine],tls[user] - note says "Supplicant
only supports MSK for EAP-TLS, User authentication fails as QEMU unable to
emulate usable Smartcard (Supplicant popup awaiting suitable user Smartcard
credential); Supplica
On Mar 6, 2025, at 3:48 PM, Sam Yun wrote:
> Question for y'all, looking at the matrix:
>
> Windows + hostapd + FreeRADIUS + tls[machine],tls[user] - note says
> "Supplicant only supports MSK for EAP-TLS, User authentication fails as QEMU
> unable to emulate usable Smartcard (Supplicant popup a
Hello,
On Thu, 6 Mar 2025, at 20:48, Sam Yun wrote:
>
> Is there a reason y'all are using an emulated smart card (which
> apparently doesn't work)? Why not install a TLS cert on the Windows
> client and update the profile to use that cert(s)?
We knew Windows would only utilise the MSK and did
Alan DeKok wrote:
> In short, for inner methods, the following combinations work for all
implementations:
> * EAP-MSCHAPv2
> * EAP-MSCHAPv2 followed by EAP-MSCHAPv2
> That's it.
> If the suppliant doesn't include the EMSK Compound-MAC in the
> Crypto-Binding TLV, then
