IETF Logo Mail Archive

Re: [TLS] [Emu] 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 20:04 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB43A142E; Mon, 1 Feb 2021 12:04:53 -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 JTtBr3se4eV6; Mon, 1 Feb 2021 12:04:51 -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 4E0C23A142D; Mon, 1 Feb 2021 12:04:51 -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 DB6DC384; Mon, 1 Feb 2021 20:04:47 +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: <CAOgPGoA1boAcWyV9cn6_uXvCRPEBkAUeg2f8u8FaPPk=54tRSw@mail.gmail.com>
Date: Mon, 01 Feb 2021 15:04:46 -0500
Cc: Eric Rescorla <ekr@rtfm.com>, EMU WG <emu@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "<tls@ietf.org>" <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C98C5488-0401-4DB5-9EB2-9AD44287BA7C@deployingradius.com>
References: <e669002f-caff-1e6e-e28b-d09157eb0c07@ericsson.com> <6241F0B6-C722-449E-AC3A-183DE330E7B5@deployingradius.com> <9ddd1593-3131-f5cc-d0db-74bf3db697bf@ericsson.com> <3CB58153-8CCA-4B1E-B530-BA67A6035310@deployingradius.com> <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> <CABcZeBMAtmPfG0rctvO8UvnhPqY1etk=SxnonP_t6ysNxH7hVA@mail.gmail.com> <D6AAF668-86C8-4C5D-AF1E-B37F106A4D1C@deployingradius.com> <CABcZeBPES99+xo16=aSDJQbGpzM_Q+k-pWtg424Gu4UAcFbo9Q@mail.gmail.com> <FFE1B807-B055-45DF-84FA-A0D63C058729@deployingradius.com> <CABcZeBMeR-kH_P_Lq9X8sOCvZ=u8_tGEOE2QErKX--Tk3cEg=Q@mail.gmail.com> <9E25ADFC-16F2-4719-B223-E34598633D2B@deployingradius.com> <CAOgPGoCANLd0hisu5cLtb=FKa-TKy2ixrSvJ0dAUVLef9F1L0A@mail.gmail.com> <34757A81-4918-4B48-9ECC-533DB861992A@deployingradius.com> <CAOgPGoA1boAcWyV9cn6_uXvCRPEBkAUeg2f8u8FaPPk=54tRSw@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/tls/jwYhM7epuGf_JyktUx9F7mg4Aqs>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2021 20:04:53 -0000

On Feb 1, 2021, at 3:00 PM, Joseph Salowey <joe@salowey.net> wrote:
> [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require CloseNotify. 

  With TLS 1.2, the server sends TLS Finished to the client *after* it sees the client cert.

  With TLS 1.3, the server sends TLS Finished to the client *before* it sees the client cert.

  So the question is: when the client sees EAP-Success, has it's certificate been verified?  If there's no more TLS exchange server -> client, then malicious parties can forge an EAP-Success, and the client doesn't know any better.

  This attack isn't possible in TLS 1.2, because the client receives the TLS Finished from the server, as a *positive* acknowledgement that the server has authenticated the client.  In addition, the TLS exporter keys are not available until after the server sends TLS Finished.

  With TLS 1.3, the exporter keys are available *before* the client cert has been validated.  This "fast path" helps with non-EAP protocols.  But makes life more difficult for EAP.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email