Re: [Emu] Review of draft-ietf-emu-eap-tls13-04

Eliot Lear <lear@cisco.com> Thu, 21 March 2019 12:14 UTC

Return-Path: <lear@cisco.com>
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 E04C1128661; Thu, 21 Mar 2019 05:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 QhH1uIAc8S6o; Thu, 21 Mar 2019 05:14:22 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABDE2131050; Thu, 21 Mar 2019 05:14:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5049; q=dns/txt; s=iport; t=1553170462; x=1554380062; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Rq1x5D1C6WDWV9TCC9vgcsADHteQ/c0smXYpUKz18/Q=; b=UsSPPVxM8846pbi3c+kpBZx8wCxVEg8f/1JmnchjBQ79+x8W64UzB8tp 1nTViRjCFEv2c6UCeUn7zrQJQaNAyoiSfb3h3WYxyYOJhpwj4Bvun/5AY jFzyv4Tvb+KTk+4ZtOK2/eX+PFQNYtoiG7WaBuPMlZDZke9GOCJ8rnBYo Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A2AABff5Nc/xbLJq1jGwEBAQEDAQEBBwMBAQGBVAMBAQELAYEOgm0njQmMTpJAh3INAQGEbAKFFDcGDQEBAwEBCQEDAm0ohUoBAQEDAXQFBQsLDgouVwYTgyKBbgisFYVGhGuBLwGLSIF/gREnH4JMPoQdEYNRgiYDpQcJi2uHTBmLHIhXm0WCcQIEBgUCFYFjIiiBLjMaCBsVZQGCQT6QDj4DMItKAiQHgiABAQ
X-IronPort-AV: E=Sophos; i="5.60,252,1549929600"; d="scan'208,217"; a="10881788"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Mar 2019 12:14:19 +0000
Received: from [10.61.162.28] ([10.61.162.28]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2LCEHKA027767 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Mar 2019 12:14:17 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <D2ACA920-FC92-407C-9E23-183F3630C625@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0ADA01D5-F0B0-40DB-92BB-881F555E94CC"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 21 Mar 2019 13:14:16 +0100
In-Reply-To: <011501d4df04$3147cf80$93d76e80$@augustcellars.com>
Cc: draft-ietf-emu-eap-tls13@ietf.org, EMU WG <emu@ietf.org>
To: Jim Schaad <ietf@augustcellars.com>
References: <011501d4df04$3147cf80$93d76e80$@augustcellars.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Outbound-SMTP-Client: 10.61.162.28, [10.61.162.28]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/EBmn9jzp4qs8Asd6mX4GOhKgkDY>
Subject: Re: [Emu] Review of draft-ietf-emu-eap-tls13-04
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: Thu, 21 Mar 2019 12:14:24 -0000

Hi

> On 20 Mar 2019, at 11:03, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> TLS 1.3 introduced early application data;  if a server receives a client
> hello with early application data it MUST abort the handshake with an
> EAP-Failure.  The server MAY generate a TLS-Alert as well.


This precise text actually may have implications for onboarding, where the notion is to validate the data retrospectively.  In particular this impacts the previous statement: The EAP server MUST authenticate with a certificate and SHOULD require the EAP peer to authenticate with a certificate.

draft-ietf-anima-bootstrapping-key-infra defers the authentication during onboaridng stages, which I would expect draft-lear-eap-teap-brski to do as well.  However, the purpose of the deferral is extremely limited, and the information exchanged must be authenticated in order for any state generated to be retained.

Some eyes on this particular aspect would be useful next week.

Eliot