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 values
>> I 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
