On Thu, 20 Mar 2025 at 05:51, Alan DeKok <al...@deployingradius.com> wrote:
> On Mar 19, 2025, at 7:14 PM, Heikki Vatiainen <h...@radiatorsoftware.com>
> wrote:
>
> > Giving up on using EMSK does sound like giving up something important,
> but is it so? Can someone tell what's the importance of EMSK being used in
> TEAP? Does it provide, for example, additional integrity checks which are
> important enough that they couldn't wait for TEAPv2?
>
> It binds the inner session to the outer one, and prevents MITM attacks.
> Since implementers seem to be OK without that protection, there isn't much
> we can do.
>
We already have the protection MSK chaining provides. What I'm thinking is
that wouldn't that be enough? As I understand this, EMSK adds to the
binding but it seems the situation is (is it?) OK with just MSK.
> i.e. 7170bis should explain these issues, and state that it's
> documenting a pre-existing protocol which can't be changed. We can then
> fix issues with TEAPv2.
>
TEAPv2 could perhaps say that if an inner method supports EMSK, then EMSK
must be used for IMSK derivation. Now EMSK use is a SHOULD.
> > As far as I know, none of the other EAP methods (PEAP, TTLS, AKA', etc.)
> or related specifications define any use for EMSK. MSK is used, for
> example, creating 802.11i Pairwise Master Key (PMK). Many of the EAP
> methods define how EMSK is derived, but they don't seem to need it. Does
> use of EMSK make chained TEAP inner authentication methods significantly
> safer or EMSK used only because it's available and it was thought to be
> easy to mix in? Then again MSK-less inner methods, such as PAP, are fine
> without MSK.
>
> From 7170bis, for the Crypto-Binding TLV:
>
> >> This TLV cryptographically binds the inner method to the protected
> tunnel, and to the other fields which have been negotiated. The
> cryptographic binding prevents on-path attacks.
>
> I'm not aware of cryptographic proofs of this statement, though.
>
Just to clarify, is it correct to claim that MSK with TEAP for binding
already prevents on-path attacks? Using EMSK too would provide better
protection, but with just MSK the situation is quite similar, or better, to
what other EAP methods provide? I just want to be clear that the situation
is that without EMSK there's no crypto binding, or is it?
Also, the EMU slides from today say:
CHOICES - PICK 1 OF 2
- Crypto-Binding contains only the MSK Compound MAC, the EMSK Compound
MAC is always zero
- We lose Crypto-Binding for EAP-TLS inner methods
OR
- Allow EAP-TLS, but only as the first method
This is confusing because the slides say 'lose Crypto-Binding'. Does that
mean EMSK variant of IMSK, S-IMCK, and CMK calculation goes unused and any
help EMSK provides for crypto binding is lost?
I could study the implementations in more detail, for example
wpa_supplicant has extensive comments for the latest TEAP changes, but I've
tried to understand this by reading the RFC and drafts. It's hard.
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
