Re: [secdir] [Emu] Secdir last call review of draft-ietf-emu-rfc7170bis-15

[Alan DeKok <[e-mail]>]

On Mar 1, 2024, at 10:21 PM, David Mandelberg via Datatracker <[e-mail]> 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?

  Yes.

  The semi-good news is that there is only one version of TEAP defined. 

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

  Since there's only one TEAP version, no other version can be negotiated.  So the issue is mostly theoretical.

  If an attacker modifies the headers to use a lower-than-ideal TEAP version, then the Crypto-Binding TLV will eventually discover this, and the entire authentication will be rejected.

  So it doesn't matter if any inner method is successful, the binding will prevent 

> 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 the answer is "yes" to the first question.  It wouldn't affect the first inner method.  But as above, the change will be discovered via Crypto-Binding, and the entire authentication will fail.

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

  I'll fix that and update the document.

> Also, should section 4.2.20 recommend against using that TLV until after
> the server is authenticated?

  I think so, yes.  I'll add a note.

> (nit, section 3.2) "[RFC9325] Section 4.2 for TLS 1.3." should say 4.3 instead,
> right?

  Yes.

> (nit, section 3.11.4) Is "WAP" a typo of "EAP"?

  Yes.

> (nit, section 5.3) Is there any way to determine the border between (3) and
> (4)?

  No.

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

  The server calculates the compound MAC using the outer TLVs it sent, and the outer TLVs it received from the peer.

  The peer calculates the compound MAC using the outer TLVs it sent, and the outer TLVs it received from the server.

  As a result, and modification in transit is detected, because the compound MAC will not be the same.