On Mar 3, 2024, at 2:05 PM, Alexander Clouter <alex+i...@coremem.com> wrote: > Took me a moment to figure out what David was pointing to but I think you are > incorrect. > > In Section 5.3 (Computing the Compound MAC), you are calculating the MAC > through blind concatenation and there is no machinery in there to distinguish > "this bit was in the server->peer" and "this bit was in the peer->server"; > unfortunately if only a NUL byte has been used to join the concatenation it > could have fixed this. > > So the idea is an attacker could strip off the *last* Outer-TLV and instead > graft it as an Outer-TLV to the following packet in the opposite direction. > The MACs would then match.
The attacker has to do this in both directions, as each end calculates the compound MAC using what it sent (cached locally), and what it received (potentially modified by the attacker). But as David said, I don't think this will accomplish anything in practice. The attacker can modify the server -> peer exchange to add an Outer-TLV, but can only add an Outer TLV which the peer is expected to send to the server. And the list of TLVs is limited by the table in Section 4.3.1: Request Response Success Failure TLVs 0-1 0 0 0 Authority-ID 0-1 0-1 0 0 Identity-Type 0+ 0+ 0 0 Vendor-Specific I'm at a loss for what bad things will happen here. If an on-path attacker wants to cause the session to fail, he can just mangle *all* of the data, and cause the session to fail that way. Why play games with outer TLVs? The only thing the attacker could do is add an Identity-Hint (server to peer) which the peer will send anyways. So that won't change anything. The Vendor-Specific TLVs might be more problematic. Perhaps we should just forbid them as Outer TLVs? > My proposal would be to just use a dummy (marked optional) Outer-TLV that > would be ignored by the other end to avoid this problem; sort of like > GREASE...but to fix an insecurity instead. I think that changes existing implementations. Unless the recommendation is for each end to add a dummy Outer-TLV which implementations are *known* to ignore. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
