Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

Jouni Malinen <j@w1.fi> Sun, 28 July 2019 19:58 UTC

Return-Path: <j@w1.fi>
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 DEEE6120094 for <emu@ietfa.amsl.com>; Sun, 28 Jul 2019 12:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7VcAqgjD-W0g for <emu@ietfa.amsl.com>; Sun, 28 Jul 2019 12:58:01 -0700 (PDT)
Received: from li674-96.members.linode.com (mail.w1.fi [212.71.239.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39525120041 for <emu@ietf.org>; Sun, 28 Jul 2019 12:58:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by li674-96.members.linode.com (Postfix) with ESMTP id 7FA3711BAC; Sun, 28 Jul 2019 19:57:59 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at w1.fi
Received: from li674-96.members.linode.com ([127.0.0.1]) by localhost (mail.w1.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKhq4QTvfPjh; Sun, 28 Jul 2019 19:57:58 +0000 (UTC)
Received: by jm (sSMTP sendmail emulation); Sun, 28 Jul 2019 22:57:50 +0300
Date: Sun, 28 Jul 2019 22:57:50 +0300
From: Jouni Malinen <j@w1.fi>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: Alan DeKok <aland@deployingradius.com>, Jim Schaad <ietf@augustcellars.com>, EMU WG <emu@ietf.org>
Message-ID: <20190728195750.GA5671@w1.fi>
References: <CAOgPGoCB7VOzjo+ckDhNiApa6ozCDr3zfj6pMVG3ZRfV4RP6mQ@mail.gmail.com> <20190712210819.GA26853@w1.fi> <05B92C31-6CFB-4DFD-BCBD-EE5F3472D7B2@deployingradius.com> <20190713142127.GA32230@w1.fi> <DA0799BE-3F63-4214-9FF6-68CEF4D743C1@deployingradius.com> <56CF04D0-D093-43EF-A467-0163DA5F9160@ericsson.com> <C2583658-3506-4BE8-A6CA-8FFE5B798894@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C2583658-3506-4BE8-A6CA-8FFE5B798894@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/-NgAxWmX4BvLW5EmJSI5LvB_nUY>
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05
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: Sun, 28 Jul 2019 19:58:03 -0000

On Thu, Jul 25, 2019 at 10:49:40AM +0000, John Mattsson wrote:
> Question: How will the use of Application data with TLSPlaintext.fragment = 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I assume they will need to send the same 0x00 to commit to not sending any more handshake messages as well as using application data for other purposes. I do not know exactly how the TLSPlaintext fragments look like in EAP-TTLS, PEAP, and TEAP. The TLSPlaintext fragment for commit need to be chosen so that the string does not collide with any other strings used.

I don't see why TTLS, PEAP, or TEAP would need to use this specific 0x00
indication for this since they end up using the tunnel for Phase 2 (or
at least protected result indication if Phase 2 authentication is
skipped) and that can be implicitly used for the same purpose.

EAP-TLS needs this workaround because without it, the NewSessionTicket
message changes in TLS 1.3 are quite inconvenient for EAP. With TTLS and
PEAP, it would seem fine to send out the NewSessionTicket before
concluding Phase 2. With TEAP, there is some more discussion about use
of the NewSessionTicket option for provisioning the new PAC (which seem
a bit inconvenient for some use cases IMHO, but nevertheless, I don't
see this needing any additional mechanism for indicating when the
NewSessionTicket is not going to be showing up).

-- 
Jouni Malinen                                            PGP id EFC895FA