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

Alan DeKok <aland@deployingradius.com> Tue, 05 January 2021 03:05 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 CF7813A0DC1; Mon, 4 Jan 2021 19:05: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 4hqZLGhvPbP3; Mon, 4 Jan 2021 19:05: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 DB52A3A0DC0; Mon, 4 Jan 2021 19:05:50 -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 25C298D; Tue, 5 Jan 2021 03:05:45 +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: <bddc3a92-acd1-46cc-84ad-aea013c544cf@www.fastmail.com>
Date: Mon, 04 Jan 2021 22:05:44 -0500
Cc: Mohit Sethi M <mohit.m.sethi@ericsson.com>, Benjamin Kaduk <kaduk@mit.edu>, "tls@ietf.org" <tls@ietf.org>, "emu@ietf.org" <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E1CF713-D917-4E9A-869F-21A4174D0562@deployingradius.com>
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>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/owQVDIV_qvchXgaiCIjYPjaWBWs>
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: Tue, 05 Jan 2021 03:05:54 -0000

On Jan 4, 2021, at 6:26 PM, Martin Thomson <mt@lowentropy.net> wrote:
> Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 and while it says "A peer MUST allow for this circumstance as described in this note.", I see no explanation of how to concretely make that allowance.  Are you saying that EAP methods don't really use EAP-Success and condition their behaviour on other signals?

  EAP-Success by itself is *not* a reliable indication of Success.  See RFC 3748 Section 4.2:

   Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.

  With TLS 1.3, we don't know if the authentication has completed until the TLS layer sees either (a) CloseNotify, or (b) application data.  So the EAP-TLS implementations cannot distinguish a "finished authentication" EAP-Success from a "spoofed" EAP-Success.  Because the EAP-TLS implementation has no idea of TLS is done, and therefore no way to tell that the EAP-Success is permitted at this point in the negotiation.

  Therefore, we need an explicit signal to the EAP-TLS layer that the EAP-TLS method has finished.  Discussion on the list went back and forth between CloseNotify and sending one octet of application data.  Implementations have done both.  The conclusion was that the one octet of application data was slightly easier to implement.

  Plus, sending CloseNotify precluded the TLS layer from sending a TLS Fatal Alert:  https://www.mail-archive.com/emu@ietf.org/msg03092.html, which says in part:

...
If the Commitment Message is changed to close_notify, the TLS Fatal Alert would 
have to be changed to an EAP-Failure instead. The difference is that The TLS 
Fatal Alert can contain information such as 

   bad_certificate,  unsupported_certificate,  certificate_revoked,  
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, 
access_denied, etc. while EAP-Failure must not contain any additional data.
...

  As someone who supports end users, I am very opposed to removing this information.  802.1X authentication is hard enough to deploy correctly as it is.  If we require the use of CloseNotify for EAP-TLS and TLS 1.3, then a whole host of useful error messages just go away.  Errors which are used to debug real-world certificate compatibility issues.

  I can't think of many things worse for EAP-TLS than to replace a set of descriptive messages with a simple "Failed".  Was your certificate revoked?  Failed.  Was it expired?  Failed.  Was the CA known?  Failed.  What went wrong?  Too bad for you, the only message you get is "Failed".

  End users and sysadmins will be cursing the standard for years.  And, trying to stick with something *useful*, such as TLS 1.2.

  My $0.02 is that the one byte of application data is less "pure" than a solution which relies on TLS negotiation.  But if using CloseNotify makes deployments substantially more difficult, then that is a very strong reason to avoid it.

  Alan DeKok.