IETF Logo Mail Archive

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Alan DeKok <aland@deployingradius.com> Mon, 01 February 2021 11:55 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149F73A108E; Mon, 1 Feb 2021 03:55:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIffueKcJwaz; Mon, 1 Feb 2021 03:55:44 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B5D3A1072; Mon, 1 Feb 2021 03:55:43 -0800 (PST)
Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id C61F1381; Mon, 1 Feb 2021 11:55:40 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAOgPGoD6pp_XD1xj5RFbbXHh1C-CtzioAkZDhrrCFa2uBfYhNw@mail.gmail.com>
Date: Mon, 01 Feb 2021 06:55:39 -0500
Cc: Benjamin Kaduk <kaduk@mit.edu>, "<tls@ietf.org>" <tls@ietf.org>, EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CDFE02F-CADE-4DB2-948D-00B11E969D9B@deployingradius.com>
References: <CAOgPGoA3U+XpZMY7J+KGovNx6MtAdEzRaGW33xVJdQNWSi4LVg@mail.gmail.com> <770e6a49-52fc-4e8b-91af-48f85e581fbb@www.fastmail.com> <CAOgPGoBGOMXH-kMhQSujWxnACdmBL845u0ouE0fUYc4rWtUrZg@mail.gmail.com> <ca4c526e-79a0-4fa7-abda-2b626795f068@www.fastmail.com> <3409F71E-4CE4-46BB-8079-BFBE9BE83C9A@deployingradius.com> <66157321-55DC-4831-8EF2-D75934D9024C@deployingradius.com> <20210129183220.GI21@kduck.mit.edu> <1A830492-3404-4BCC-844B-D7D950458BD9@deployingradius.com> <CAOgPGoAoFL0aL8-g2waWny=BCod4tN9R==jR_N3kuLPFzvNGOg@mail.gmail.com> <60EE664C-025B-4409-AE62-49C7DCF77FF3@deployingradius.com> <20210201021644.GW21@kduck.mit.edu> <CAOgPGoD6pp_XD1xj5RFbbXHh1C-CtzioAkZDhrrCFa2uBfYhNw@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/9FquXqHXiR9sj8f0dq8oKIXEOLw>
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Mon, 01 Feb 2021 11:55:48 -0000

On Feb 1, 2021, at 1:00 AM, Joseph Salowey <joe@salowey.net> wrote:
[ re: commitment message ]

> [Joe]  I'm not sure why it's needed. It's not clear to me why the peer can't hold the TLS session open until it receives more TLS messages (handshake or alert) or an EAP failure or EAP Success.  

  I suspect that it can.

  The larger issue for me is that in EAP + TLS 1.2, the "TLS Finished" message comes after the client certificate has been validated.  See Page 6 of https://tools.ietf.org/html/rfc5216

  In EAP + TLS 1.3, the proposal is that the "TLS Finished" message comes before the client certificate has been validated.

  To me, this means that the client has absolutely no idea whether or not it's certificate has been verified.  Any malicious actor could forge an EAP-Success (as it is entirely unauthenticated).  This seems to be a major difference from TLS 1.2, and potentially a major problem.

  There is a goal to get EAP-TLS working in 3.5 rounds.  That's a good goal, but I'd like to be sure that it doesn't come at the expense of security.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email