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

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jun 2021 09:21:30 -0400

One thing missing in the current document is how to address the modern issue of MAC address randomization.

  i.e. admins would like to ensure that only certain devices access the network.  But with MAC address randomization, it's difficult to have a static device identifier.  Even client certificates can be installed on multiple machines, if they're just sent to the user.

  Would it be worth adding a note that systems SHOULD implement RFC 6677 channel bindings to address this issue?  And that the Calling-Station-Id inside of the channel bindings MUST be the actual physical MAC, and not the public / randomized MAC?

  I've seen this problem more and more in customer deployments.  It's becoming a serious security issue.

  Alan DeKok.

---

From: Oleg Pekar <[email-masked]>
Date: Mon, 28 Jun 2021 18:18:43 +0300

Alan, agree on the MAC randomization problem. Is there any existing
standard or proposal for the network deployments where the Network Access
Control server needs to track the device with randomized MAC moving between
intranet SSIDs?

About usage of physical MAC address - maybe some client systems will not
have access to the physical MAC rather than just to a randomized MAC.

Regards,
Oleg

On Mon, Jun 28, 2021 at 4:21 PM Alan DeKok <[email-masked]>
wrote:

>   i.e. admins would like to ensure that only certain devices access the
> network.  But with MAC address randomization, it's difficult to have a
> static device identifier.  Even client certificates can be installed on
> multiple machines, if they're just sent to the user.
>
>   Would it be worth adding a note that systems SHOULD implement RFC 6677
> channel bindings to address this issue?  And that the Calling-Station-Id
> inside of the channel bindings MUST be the actual physical MAC, and not the
> public / randomized MAC?
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Tim Cappalli <[email-masked]>
Date: Mon, 28 Jun 2021 18:20:50 +0000

The industry is moving away from any hardware identifier being sent off device. I don’t think the physical MAC should ever be used as a device identifier, even for channel binding.

If a strong hardware-bound identifier is required, the organization should use the TPM/SE for private key generation during provisioning/onboarding.

From: Oleg Pekar<mailto:[email-masked]>
Sent: Monday, June 28, 2021 11:19 AM
To: Alan DeKok<mailto:[email-masked]>
Cc: EMU WG<mailto:[email-masked]>
Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Alan, agree on the MAC randomization problem. Is there any existing standard or proposal for the network deployments where the Network Access Control server needs to track the device with randomized MAC moving between intranet SSIDs?

About usage of physical MAC address - maybe some client systems will not have access to the physical MAC rather than just to a randomized MAC.

Regards,
Oleg

On Mon, Jun 28, 2021 at 4:21 PM Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:
  One thing missing in the current document is how to address the modern issue of MAC address randomization.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=04%7C01%7Ctim.cappalli%40microsoft.com%7Ce5271f5f556b451a09bd08d93a4812ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604903581345612%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=73wWIXCtD%2BLZz6IEsxzLgHDDUs0Jj64sdyHH56DSFWU%3D&reserved=0>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jun 2021 15:52:26 -0400

> Alan, agree on the MAC randomization problem. Is there any existing standard or proposal for the network deployments where the Network Access Control server needs to track the device with randomize…

  Not that I know of.

> About usage of physical MAC address - maybe some client systems will not have access to the physical MAC rather than just to a randomized MAC. 

  That is true.  My goal here is not to make things perfect, but to be able to manage a device, when that's possible.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jun 2021 16:00:00 -0400

> The industry is moving away from any hardware identifier being sent off device. I don’t think the physical MAC should ever be used as a device identifier, even for channel binding.

  It's globally unique, which is a pretty useful identifier.

> 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.

  Alan DeKok.

---

From: Tim Cappalli <[email-masked]>
Date: Mon, 28 Jun 2021 20:05:09 +0000

It has very little value as it can be easily changed on most platforms.

Modern authorization is done using certificate properties as a lookup value. Correlation of an individual piece of hardware to a certificate property needs to be done during provisioning (which is the case in many deployments today).

tim

From: Alan DeKok<mailto:[email-masked]>
Sent: Monday, June 28, 2021 4:00 PM
To: Tim Cappalli<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jun 2021 18:37:12 -0400

> Modern authorization is done using certificate properties as a lookup value. Correlation of an individual piece of hardware to a certificate property needs to be done during provisioning (which is…

  And in the deployments where people don't do such provisioning?  I would very much prefer to have a solution there.

  The solution right now is "intrusive MDM software".  Not everyone can do (or afford) that.  And MDM configuration is becoming more and more complex.  Vendors randomly change APIs, UIs, and workflows.  It's all a horrible bodge which is productive for no one.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jun 2021 20:50:48 -0400

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Jun 2021 21:56:58 -0400

> image is installed.  So, the TPM identity is actually known to them by construction.

  And... if I have my own phone?  Or if a university wishes to tie devices to student accounts?  So that they can limit (somewhat) abuses?

  For now, the answer is "too bad".  Or maybe "buy a $$$$ MDM solution".

  As someone who bought my own phone, I'm not going install some MDM solution which lets my employer wipe my personal device.  I would much prefer to be able to prove (a) it's my device, and (b) it has a unique device identifier.  The simpler the method, the better.

> There are other ways too, and most wind up with an LDevID deployed.

  That's good, but I suspect it will take a while to get implemented and/or popular.

  Alan DeKok.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Jun 2021 18:40:32 -0400

> And... if I have my own phone?  Or if a university wishes to tie
    > devices to student accounts?  So that they can limit (somewhat) abuses?

    > For now, the answer is "too bad".  Or maybe "buy a $$$$ MDM solution".

I think that today, the answer is probably too bad because too complex.
But, I think that most phones can do "Enterprise" WPA, and so a certificate
can be loaded in to do EAP-TLS.

    > As someone who bought my own phone, I'm not going install some MDM
    > solution which lets my employer wipe my personal device.  I would much
    > prefer to be able to prove (a) it's my device, and (b) it has a unique
    > device identifier.  The simpler the method, the better.

If I were a student, I would also not allow a university (or employer) MDM
solution onto my phone, and I'm not actually sure that it directly helps; it
just makes loading that certificate easier.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 30 Jun 2021 09:38:07 -0400

> I think that today, the answer is probably too bad because too complex.

  Yes.

> can be loaded in to do EAP-TLS.

  ... somehow.  :(  Phone vendors are making this more difficult as time progresses.  I've heard from MDM vendors who are largely giving up, as the APIs, limitations, and capabilities keep changing.

  Which is why I'm trying to find something which is useful, and which doesn't require massive new infrastructure.

  If the answer is "use TPM", then that doesn't meet peoples existing needs.  It will also take many years for it to become standardized, much less ubiquitous.  As an example, here's an EAP / TPM paper from 2010:

https://www.semanticscholar.org/paper/EAP-TPM-%3A-A-New-Authentication-Protocol-for-IEEE-.-Latze/6d755cf4d1ac1da25c8d02a2e5cba56212149d69

  So we've had this capability for a decade.  But no one has found time / interest in moving forward with it.  This makes me think that TPM is not really the best choice here.

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Jun 2021 15:52:21 +0200

Hi Alan

Slight segue..

> https://www.semanticscholar.org/paper/EAP-TPM-%3A-A-New-Authentication-Protocol-for-IEEE-.-Latze/6d755cf4d1ac1da25c8d02a2e5cba56212149d69

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.

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.

Eliot