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

Alan DeKok <> Mon, 15 February 2021 20:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C718C3A110A; Mon, 15 Feb 2021 12:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A1z8tnNyxmQX; Mon, 15 Feb 2021 12:37:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B187B3A1106; Mon, 15 Feb 2021 12:37:20 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 86C96358; Mon, 15 Feb 2021 20:37:16 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Mon, 15 Feb 2021 15:37:14 -0500
Cc: John Mattsson <>, EMU WG <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Benjamin Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.