Eliot
On 25.03.23 09:52, Alexander Clouter wrote:
On Sat, 25 Mar 2023, at 01:08, Heikki Vatiainen wrote:If you are using eapol_test prior to a few TEAP patches (reversed EAP-FAST MSK calculation and ordering of the Cryptobinding processing) then it should just work out the box.I think the case in question where the inner methods were two Basic-Password-Auths (e.g., machine and user type). eapol_test was from the latest git source exactly of the reasons you mentioned.Ahhh, we only implemented EAP-Payload and ignored Basic-Password-Auth.RFC 7170 is from 2014. It may have been useful at that time, but is this still the case? Is it reasonable to implement TEAP in 2020s but not having EMSK supported for an inner EAP that has EMSK defined.Conjuring up a scenario so it can be picked apart and discussed...Is it possible to build an implementation of something like EAP-TLS backed by an external system (ie. TPM/hardward-offload) and the EMSK material are not avaliable?RFC5247 section 1.2 has this to say about the EMSK: "...and is never shared with a third party." I read this to include any userspace code implementation (ie. Radiator, FreeRADIUS, hostapd, ...) as a 'third party' as section 1.5 there also labels the backend authentication server as a third party.If the other end was an implementation though that does provide the EMSK, we would have a legitimate split.Of course, if no one is doing this do we need to describe it? Otherwise could we describe it confidently? Probably not.Just to spice things up a bit, Vendor-Specific-TLVs also can be the authentication method here which means they could do anything they want, including not providing an EMSK.Thing is it looks like neither Cisco or Microsoft have implemented Vendor-Specific-TLVs in this way so one option could be to remove support for them for authentication and instead point to that they should be implemented via an vendor specific EAP method (wrapped in EAP-Payload-TLV).Removing Vendor-Specific-TLVs would then leave Basic-Password-Auth as the oddity...which leads to other than Radiator and hostapd ("pants may explode and here be dragons" labelling)...has anyone else implemented and use in the wild Basic-Password-Auth? Microsoft only do EAP-{TLS,MSCHAPv2} and it looks like Cisco too from https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/216510-eap-chaining-with-teap.html#anc6...maybe we can burn Basic-Password-Auth too?At the moment there is no way anyway for Windows to push the users plaintext password to the server anyway, so not sure if anything tangible would be lost in doing this. Also provides an opportunity to punt people towards EAP-PWD?TEAP can be implemented as the draft currently says. Mandatory EMSK would make it simpler, though.The PAC was removed as it turned out no one implemented it, so if this is tweak is also something that 'empirically' continues to work then I would support this.None of this is here because we want it, it is there as it looks to be how Windows implemented things.We haven't tried with Windows yet. Windows doesn't export EMSK for all methods that could support it?You are right, it does, so we could probably just do this. Means we could also burn the MSK CMAC if we burn Basic-Password-Auth :)Starting to think if it ever happens that TEAPv2 is going to look very different to TEAPv1...Ending up with different EMSK valuesI do not understand why the EMSK calculations would be different for the same method?In other words, because the peer and server do not know about each other's EMSK capabilities, they can end up calculating different tracking for EMSK derived compound values. Wouldn't this be the case with non-mandatory EMSK support?I see, yes, this would be problematic. Cheers _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
