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

[Michael Richardson <[e-mail]>]

Alan DeKok <[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide