On Mar 21, 2025, at 2:21 AM, Heikki Vatiainen <h...@radiatorsoftware.com> wrote:
> 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.
The EMSK is bound to the outer TLS session via:
IMSK[j] = First 32 octets of TLS-PRF(
EMSK[j],
"teapbind...@ietf.org",
0x00 | 0x00 | 0x40)
The MSK is not bound to the outer TLS session. However, the final MSK
Compound MAC (CMK) depends on the TLS-PRF:
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys",
IMSK[j])
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
> Just to clarify, is it correct to claim that MSK with TEAP for binding
> already prevents on-path attacks?
I think so, yes.
> 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?
I had thought there was no crypto binding with MSK only, but it now looks
like there is.
> 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 think the above slide was wrong.
> 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.
It's very difficult.
I'll post a separate message proposing derivations for TEAPv2. I think this
could be made substantially simpler.
I'll also note that TEAP doesn't define implicit challenges for EAP-MSCHAPv2,
while TTLS does. I suspect that it would be a good idea to do that, too.
Alan DeKok.
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
