Last Call Review of draft-ietf-emu-rfc7170bis-15
review-ietf-emu-rfc7170bis-15-secdir-lc-mandelberg-2024-03-01-00

(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?