On Sat, 2 Mar 2024, at 03:21, David Mandelberg via Datatracker wrote: > > (nit) If I understand the TEAP version negotiation and Crypto-Binding > correctly, the negotiated version is not cryptographically verified until > either (1) after the first inner method is completed or (2) just before the > final result, if there are no inner methods. Is that correct? Correct (section 4.2.13), these are when the peer sends a Intermediate-Result or Result TLV which must be accompanied with a Crypto-Binding TLV. > Does that mean > it's possible for an attacker to get both sides to speak a lower-than-ideal > TEAP version while performing the first inner method, and if so, does that > matter? Or could an attacker get one side to think it's using one version and > the other side to think it's using another version? What affect would that have > on the first inner method? I think it does but I do not think it matters as none of the inner methods are aware or coupled to the version of TEAP being used. In the future, if TEAPv2 came along, maybe the fallout could be that a non-superset of inner methods and attributes would be allowed and there would be no guards that may bump the state machine around. Not sure what could be done, as RFC7170bis describes what is already deployed. Maybe a TEAPv2 could use ALPN for the TLS jacket to avoid this..erk, I think I may have suggested something that could be retro fitted here without impacting existing implementations; assuming they would just ignore the ALPN. > (nit) Also, should section 4.2.20 recommend against using that TLV until after > the server is authenticated? For the unauthenticated server this means really a provisioning process is about to take place which limits what the client is allowed to do next by section 3.11.3. Those methods must provide mutual authentication as one of their requirements. I suspect we could limit the TLV to only be sent by *configured* clients as they would have verified the server always by that point using the outer TLS jacket. We though would be unable to do this if someone knows of a use case where two authentication methods for provisioning are required (user+machine auth?). > (nit, section 5.3) Is there any way to determine the border between (3) and > (4)? If not, then in theory a MITM might be able to remove the last > server-to-peer outer TLV and prepend it to the peer-to-server TLVs, or vice > versa, and the MAC would be the same. However, each side knows which outer TLVs > it sent before the MITM modified it, so I don't think this could accomplish > anything in practice? I do not think so as the crypto-bindings are validated back to back by each peer. Interesting angle of attack though, never occurred to me. Thanks Alex -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
