Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3

Alan DeKok <aland@deployingradius.com> Mon, 15 February 2021 20:37 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 C718C3A110A; Mon, 15 Feb 2021 12:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-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 A1z8tnNyxmQX; Mon, 15 Feb 2021 12:37:21 -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 B187B3A1106; Mon, 15 Feb 2021 12:37:20 -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 86C96358; Mon, 15 Feb 2021 20:37:16 +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: <20210215024647.GD21@kduck.mit.edu>
Date: Mon, 15 Feb 2021 15:37:14 -0500
Cc: John Mattsson <john.mattsson@ericsson.com>, EMU WG <emu@ietf.org>, "TLS@ietf.org" <TLS@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F9A352D-E883-420D-AB59-EE1BF2503CEB@deployingradius.com>
References: <5AC5852A-118A-4FF5-9754-7693AC505F0C@ericsson.com> <20210215024647.GD21@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Sua8hniiuPUyimloWf4R5NStLio>
Subject: Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3
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, 15 Feb 2021 20:37:23 -0000

On Feb 14, 2021, at 9:46 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> On first look it seems like all of those will be able to achieve the
> required properties.  In some sense it is "probably" going to be "easier"
> for an application using TLS to use TLS application data (as opposed to
> alerts) to affect its behavior, though I believe that TLS implementations
> generally do provide the needed information about received alerts and
> flexibility in what alert to send that's needed for the (1) variants.

  close_notify seems to work fine for EAP-TLS with multiple peer / server implementations, and at least 2 TLS library implementations.

> Another potential factor that I'm not (currently) equipped to evaluate is
> the reusability of the machinery defined by EAP-TLS for use by other EAP
> mechanisms.  E.g., if we say that for EAP-TLS any application data is a
> protected success, would that be in conflict with any scenarios for the EAP
> mechanisms that do have to send some data on the TLS application data
> stream?

  Implementation so far shows no.  The patches to make PEAP / TTLS work with TLS 1.3 are relatively minor.  Mostly updating the key exporters.

  We have protected success / failure indicators for EAP-TLS 1.3.  I think that's a positive step.

  The question for the other EAP methods is "do we need protected success / failure indicators".   As Joe noted, TEAP already provides them in the inner tunnel, as does PEAP (with inner MS-CHAP), or TTLS (with inner MS-CHAP.  TTLS with inner PAP / CHAP doesn't provide them.

  If we're willing to live without those indicators for other TLS-based EAP methods, then draft-dekok-emu-tls-eap-types is essentially done.  It needs some minor updates, but there are no major protocol questions left open.

  Alan DeKok.