Reviewer: David Mandelberg Review result: Has Nits (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? 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? (nit) Overall this document seems to support two different modes, one where the TLS tunnel provides server authentication, and one where the tunnel doesn't but inner methods can provide it later and then use Crypto-Binding to verify the tunnel. There are a few sections that seem to be written as if the TLS tunnel always provides server authentication though: 7.1, 7.4.1 (2nd paragraph), and 7.8. Also, should section 4.2.20 recommend against using that TLV until after the server is authenticated? (nit, section 3.2) "[RFC9325] Section 4.2 for TLS 1.3." should say 4.3 instead, right? (nit, section 3.11.4) Is "WAP" a typo of "EAP"? (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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
