IETF Logo Mail Archive

Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Alan DeKok <aland@deployingradius.com> Thu, 01 July 2021 13:23 UTC

Return-Path: <aland@deployingradius.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 1D2D83A0652 for <emu@ietfa.amsl.com>; Thu, 1 Jul 2021 06:23:58 -0700 (PDT)
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 joXilvYh0hDt for <emu@ietfa.amsl.com>; Thu, 1 Jul 2021 06:23:54 -0700 (PDT)
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 C20963A0657 for <emu@ietf.org>; Thu, 1 Jul 2021 06:23:54 -0700 (PDT)
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 0BF3718F; Thu, 1 Jul 2021 13:23:51 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Thu, 01 Jul 2021 09:23:50 -0400
References: <DB6D339A-710C-4EC4-9F8E-4B8602632AE1@deployingradius.com> <CABXxEz8EBUz_y1FmQTE9C8cpF+3vqy-mPCx8CnyUMZ72pNifAA@mail.gmail.com> <SJ0PR00MB1038767373E0DE9E3D7BE0DA95039@SJ0PR00MB1038.namprd00.prod.outlook.com> <C7DBE2EB-82BF-4229-B0AF-4BA48B2D45BC@deployingradius.com> <7332.1624927848@localhost> <4F79B7DB-7E55-4564-88AE-C6E2AF8FD293@deployingradius.com> <26359.1625006432@localhost> <BFA8E5C4-D368-41BF-AFA9-BAA35B666F8A@deployingradius.com> <a02d4815-dbfa-e0a0-99fb-0f53127f2fd1@lear.ch>
To: Eliot Lear <lear@lear.ch>, EMU WG <emu@ietf.org>
In-Reply-To: <a02d4815-dbfa-e0a0-99fb-0f53127f2fd1@lear.ch>
Message-Id: <13DD39D5-57C4-48D2-868A-C4D530127095@deployingradius.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/NWs2TZisMW6s9tjaIhG8sgSVFKA>
Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
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, 01 Jul 2021 13:23:58 -0000

On Jun 30, 2021, at 9:52 AM, Eliot Lear <lear@lear.ch> wrote:
> I think we have to be a bit careful about using the term "TPM". What we care about are trust anchors, credentials, and operations on those.  Those objects might be stored in TPMs, but it seems to me that the protocol does not need to be aware of that.

  Yes.

> If we can be crisper on both the operations and the objects, I think we'll do better.  Some of that is on us with a TEAP update, but I think there's also a discussion to be had about that.
> 
> It's the T part of TEAP that is emphasized in the current work. The operations and objects beyond that are underdeveloped.  That has to be a lot cleaner as we move forward.

  My concern is that we need a way for an administrator to identify a particular device.  Either say "this particular phone", or "only this device has the given credentials."  Both use-cases are similar, but not the same.

  Once credentials are provisioned, then protocols like EAP can work without knowing where the credentials come from, or where they are stored.  But there's still a bootstrapping problem which remains unsolved.

  TEAP is one solution, but I don't think everyone is going to move to TEAP overnight.  It would be nice to have solutions for existing (and deployed) EAP methods.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email