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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 29 June 2021 00:50 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 9B3EA3A1DD6 for <emu@ietfa.amsl.com>; Mon, 28 Jun 2021 17:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 b5Fy1NIJ23Ux for <emu@ietfa.amsl.com>; Mon, 28 Jun 2021 17:50:53 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8824A3A1DD2 for <emu@ietf.org>; Mon, 28 Jun 2021 17:50:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D85C13897F; Mon, 28 Jun 2021 20:52:50 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Lhu-TKGh1MNS; Mon, 28 Jun 2021 20:52:48 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 94DED3897E; Mon, 28 Jun 2021 20:52:48 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 52BC3885; Mon, 28 Jun 2021 20:50:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alan DeKok <aland@deployingradius.com>, "emu\@ietf.org" <emu@ietf.org>
In-Reply-To: <C7DBE2EB-82BF-4229-B0AF-4BA48B2D45BC@deployingradius.com>
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>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Mon, 28 Jun 2021 20:50:48 -0400
Message-ID: <7332.1624927848@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/Nwg28t44bM6KoqfMoDIhMmMXMSY>
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: Tue, 29 Jun 2021 00:50:59 -0000

Alan DeKok <aland@deployingradius.com> wrote:
    >> If a strong hardware-bound identifier is required, the organization
    >> should use the TPM/SE for private key generation during
    >> provisioning/onboarding.

    > From my reading of TCG / TPM / etc. stuff, the private key describes a
    > *particular* device.  Not a *known* device.  i.e. the key is tied to a
    > device, so it's a unique token. But it's not an *identifying* token, in
    > that the administrator can tell which device is being provisioned.

    > There still needs to be a way for the administrator to know which
    > device is being used.  Identifying a particular device is done via
    > physical examination in a secure network, or via some unique hardware
    > identifier.  I might be missing something from the whole TPM
    > infrastructure, tho.

To date, Enterprises with laptops and PCs have provisioned the IDevID into
the TPM, themselves, at the same time the device is wiped and the golden
image is installed.  So, the TPM identity is actually known to them by construction.

Smartphones do not get provisioned that way, but at the factory.
Ditto IoT devices, and routers that have IDevID.
RFC8995(BRSKI) can help, and Eliot has a proposal about how to run that over TEAP.
There are other ways too, and most wind up with an LDevID deployed.

MAC address randomization makes use of EAP-TLS methods that have unique
IDevID as their client identifier much easier than WPA-PSK, where get
nothing.   I expect that is where things will go, but at this point, the
major new "home" mechanism (CHIP/MATTER), seems stuck at sending WPA-PSKs
out, despite actually having a mechanism to deploy LDevIDs to devices.

As many of you know, TLS1.3 is a major win because the client certificate is
not transmitted in the clear during the handshake.  If the supplicant can
validate the server certificate, then a Mallory-in-the-Middle (onpath) attack
also does not get the identity.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide