On Jul 23, 2025, at 9:31 AM, Heikki Vatiainen <[email protected]> wrote: > > On Thu, 19 Jun 2025 at 22:36, Alan DeKok > <[email protected]> wrote: > ... > Do implementations set / check the Nonce field as discussed above? Would > it make sense to just ignore this field? > > See section '5.3. Computing the Compound MAC' in the original TEAP RFC and > step 1 therein. > https://datatracker.ietf.org/doc/html/rfc7170#section-5.3 > > 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK > Compound MAC fields zeroed out. > > This could be clarified to say something like this: > > 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK > Compound MAC fields zeroed out. Nonce is used untouched. > > If flip a bit in received or sent nonce right when it's packed into a > message, I see, for example, in eapol_test this before failure: > > EAP-TEAP: MSK Compound MAC did not match > > Or do you mean something else about nonce?
I'm not sure what it's used for. If it's just a random field, why have this text: The nonce in a request MUST have its least significant bit set to zero (0), and the nonce in a response MUST have the same value as the request nonce except the least significant bit MUST be set to one (1). ? If it's just a nonce, there should be no reason to set / clear that bit. And if TLS is protecting the TLS tunnel, why use a Nonce? The key chaining and derivation should ensure that the Crypto-Binding field is secure. The Nonce field seems to be there "just in case". Adding a nonce isn't bad, but it's not clear if it's a solution to anything. What problem is created by not having a Nonce? Alan DeKok. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
