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

Benjamin Kaduk <kaduk@mit.edu> Tue, 05 January 2021 17:53 UTC

Return-Path: <kaduk@mit.edu>
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 55ECF3A1178; Tue, 5 Jan 2021 09:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ItVX9jZCvSN1; Tue, 5 Jan 2021 09:53:49 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873793A1168; Tue, 5 Jan 2021 09:53:47 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 105HrXxM032461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Jan 2021 12:53:38 -0500
Date: Tue, 05 Jan 2021 09:53:32 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alan DeKok <aland@deployingradius.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Martin Thomson <mt@lowentropy.net>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, "emu@ietf.org" <emu@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20210105175332.GV93151@kduck.mit.edu>
References: <160815821055.25925.15897627611548078426@ietfa.amsl.com> <20201216223842.GR64351@kduck.mit.edu> <0f2b05db-5c98-43d4-aae3-cf620814bacc@www.fastmail.com> <7745bb87-a946-c739-007d-9d3be1212e19@ericsson.com> <bddc3a92-acd1-46cc-84ad-aea013c544cf@www.fastmail.com> <5E1CF713-D917-4E9A-869F-21A4174D0562@deployingradius.com> <28008.1609862746@localhost> <FD8C4D2F-8F51-4FD5-9D49-3F143B93CDD7@deployingradius.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <FD8C4D2F-8F51-4FD5-9D49-3F143B93CDD7@deployingradius.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/qS9472n02YoCSG3jGZj1orecYoQ>
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: Tue, 05 Jan 2021 17:53:57 -0000

On Tue, Jan 05, 2021 at 11:12:21AM -0500, Alan DeKok wrote:
> On Jan 5, 2021, at 11:05 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> > 
> > Alan DeKok <aland@deployingradius.com> wrote:
> >> Therefore, we need an explicit signal to the EAP-TLS layer that the
> > 
> > Do you mean, "to the EAP layer"?
> > s/EAP-TLS layer/EAP/ ??
> 
>   If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS layer needs to have a way to say "we're done, EAP-Success is now OK".
> 
>   It's really nested:  EAP ( EAP-TLS ( TLS ) ) 
> 
>   We can't finish EAP until we know that EAP-TLS is finished.  We can't finish EAP-TLS until we know that TLS is finished.

Okay.  What step suffices to determine that "TLS is finished" for your use
case.  The natural definition is "the handshake is complete", which would
be incompatible with the text currently in the draft (and with 0.5-RTT
entirely).

-Ben