[Emu] Secdir last call review of draft-ietf-emu-rfc7170bis-15
David Mandelberg via Datatracker <noreply@ietf.org> Sat, 02 March 2024 03:21 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: emu@ietf.org
Delivered-To: emu@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD434C14F710; Fri, 1 Mar 2024 19:21:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: David Mandelberg via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-emu-rfc7170bis.all@ietf.org, emu@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170934966282.22720.15728977796194077360@ietfa.amsl.com>
Reply-To: David Mandelberg <david@mandelberg.org>
Date: Fri, 01 Mar 2024 19:21:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/JGvIec33e0z7TL3aVeu88MUSFIg>
Subject: [Emu] Secdir last call review of draft-ietf-emu-rfc7170bis-15
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Mar 2024 03:21:02 -0000
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?
- [Emu] Secdir last call review of draft-ietf-emu-r… David Mandelberg via Datatracker
- Re: [Emu] Secdir last call review of draft-ietf-e… Alexander Clouter
- Re: [Emu] Secdir last call review of draft-ietf-e… David Mandelberg
- Re: [Emu] [secdir] Secdir last call review of dra… Alan DeKok
- Re: [Emu] Secdir last call review of draft-ietf-e… Alexander Clouter
- Re: [Emu] Secdir last call review of draft-ietf-e… Alan DeKok
- Re: [Emu] Secdir last call review of draft-ietf-e… Alexander Clouter
- Re: [Emu] Secdir last call review of draft-ietf-e… Alan DeKok
- Re: [Emu] Secdir last call review of draft-ietf-e… Alexander Clouter