Subject: [Madinas] identities for legitimate devices

From: Qin Wu <[email-masked]>
Date: Wed, 4 Nov 2020 12:26:08 +0000

<[email-masked]<mailto:[email-masked]>> wrote:
    > The slides you are referring to are not intended to articulate the
    > overall problem space but to illustrate a use case where ** means to
    > unambiguously and persistently identify devices within the home are
    > required ** to protect the Internet but also to avoid collateral damage
    > for subscribers hosting such compromised devices. Filtering at the
    > network is suboptimal. The question then is:

Reading the slides, I understood:
        "Doctor it hurts when I put my foot in the blender"

me: "don't put your foot in the blender"

    > ** how to reliably achieve this without mandating a given network setup
    > and while minimizing subscriber involvement? **

    > Many ISPs offer apps to seek for an ACK from the subscribers whenever a
    > new device connects to the home network. The identification is usually
    > based on the MAC@. Notifications will be generated each time a new MAC@
    > is generated, which may be disturbing for the subscriber and may lead
    > to deactivate the app or accept by default all devices. These
    > considerations (and others) are not discussed in these slides because
    > this is supposed to be handed in other use cases (device
    > identification).

Yes, it's is good that you agree with me that the real problem is not
tracking malicious devices that change evade ACL by changing address, but
rather positively identifying legitimate devices so that their MAC address
changes can be transparently tracked.

[Qin]: This reminds me to think the identity and locator concept, whatever Mac address you changes, the identity of the device
doesn't change. If the device frequently changes MAC address, I am wondering whether this device will be seen as attacking device.
So the question is when the device needs to change MAC? Changing MAC when the device is moving or change MAC every 20 minutes,
My impression in the home network, even the device have the capability to change MAC,
if the device is still attaching to the same WLAN, MAC address should stay same. Only when you change from one AP to another one,
MAC address change makes sense. Still, one MAC per one WLAN AP.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 11:54:49 -0500

[email-masked]<mailto:[email-masked]>> wrote:
    med> The slides you are referring to are not intended to articulate the
    med> overall problem space but to illustrate a use case where ** means to
    med> unambiguously and persistently identify devices within the home are
    med> required ** to protect the Internet but also to avoid collateral damage
    med> for subscribers hosting such compromised devices. Filtering at the
    med> network is suboptimal. The question then is:

    mcr> Reading the slides, I understood:
    mcr> "Doctor it hurts when I put my foot in the blender"

    mcr> me: "don't put your foot in the blender"

    med> ** how to reliably achieve this without mandating a given network setup
    med> and while minimizing subscriber involvement? **

    med> Many ISPs offer apps to seek for an ACK from the subscribers whenever a
    med> new device connects to the home network. The identification is usually
    med> based on the MAC@. Notifications will be generated each time a new MAC@
    med> is generated, which may be disturbing for the subscriber and may lead
    med> to deactivate the app or accept by default all devices. These
    med> considerations (and others) are not discussed in these slides because
    med> this is supposed to be handed in other use cases (device
    med> identification).

    mcr> Yes, it's is good that you agree with me that the real problem is not
    mcr> tracking malicious devices that change evade ACL by changing address, but
    mcr> rather positively identifying legitimate devices so that their MAC address
    mcr> changes can be transparently tracked.

Qin Wu <[email-masked]> wrote:
    qin> [Qin]: This reminds me to think the identity and locator concept,
    qin> whatever Mac address you changes, the identity of the device doesn't
    qin> change. If the device frequently changes MAC address, I am wondering
    qin> whether this device will be seen as attacking device.  So the
    qin> question is when the device needs to change MAC? Changing MAC when
    qin> the device is moving or change MAC every 20 minutes, My impression
    qin> in the home network, even the device have the capability to change
    qin> MAC, if the device is still attaching to the same WLAN, MAC address
    qin> should stay same. Only when you change from one AP to another one,
    qin> MAC address change makes sense. Still, one MAC per one WLAN AP.

You are exactly right:  the identity doesn't change.
WiFi devices will re-authenticate when they change their MAC address.
With WPA-PSK using a single key (a la "coffee shop" internet), then nobody
can tell which device if which.

WPA-PSK can be deployed with a PSK-per-device, but configuring those
additional keys is difficult because we lack interfaces into home routers.
(The device wouldn't configure the keys, the home owner would, using their
phone)

A number of IETF irregulars wrote a document for the RIPE IoT WG:
   https://www.ripe.net/ripe/mail/archives/iot-wg/2020-October/000537.html

WPA-Enterprise, using client certificates is also certainly possible, but it
requires an onboarding protocol (such BRSKI) so issue an appropriate LDevID.

But, the key (pun intended), in my opinion, is to change the device identity
from being a MAC address to being a key.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Nov 2020 17:23:47 +0000

Hiya,

> from being a MAC address to being a key.

While agreeing with the goal (for home networks
and similar) I'd word it differently - such n/w's
often do not need to identify a specific device,
they only need to authorise access to the network.
A common PSK can be fine for that.

S.

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 18:03:29 +0000

Hi Stephen, 

> such n/w's often do not need to identify a
> specific device, they only need to authorise access to the network.

I'm afraid that more is needed for the home network. Think about all the CPEs that display the map of connected devices (and that a user can manage), assign a static IP address for specific machines, program time slots when connectivity access is allowed for some devices, or future deployments where a specific DoH URI Template can be returned to one child PCs, etc. 

Cheers,
Med

> -----Message d'origine-----
> De : Madinas [mailto:[email-masked]] De la part de Stephen
> Farrell
> Envoyé : mercredi 4 novembre 2020 18:24
> À : Michael Richardson <[email-masked]>; Qin Wu
> <[email-masked]>; [email-masked]
> Objet : Re: [Madinas] identities for legitimate devices
> 
> 
> Hiya,
> 
> > But, the key (pun intended), in my opinion, is to change the
> device
> > identity from being a MAC address to being a key.
> 
> While agreeing with the goal (for home networks and similar) I'd
> word it differently - such n/w's often do not need to identify a
> specific device, they only need to authorise access to the network.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 14:20:23 -0500

>> But, the key (pun intended), in my opinion, is to change the device

Stephen Farrell <[email-masked]> wrote:
    > While agreeing with the goal (for home networks and similar) I'd word
    > it differently - such n/w's often do not need to identify a specific
    > device, they only need to authorise access to the network.  A common
    > PSK can be fine for that.

A common PSK means that one can not determine which device has become infected.

Is your objection based upon privacy implications of a device doing EAP-TLS
with a home router?  The device would reveal it's client certificate to an
on-path/MITM/malicious-messenger attacker.
Noting that the identity in an LDevID could be arbitrary, but of course, the
public key would still identity the device.

A unique-per-device PSK does not suffer the same, but is presently hard to
provision.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Nov 2020 19:56:42 +0000

Hi Michael, Med,

On 04/11/2020 19:20, Michael Richardson wrote:
> with a home router?

I didn't make an "objection" - I noted that in many
cases authorisation without identification is possible
and sufficient. I do think that, in general, we ought
be far slower than we are to try create new identifiers
or identifications, if those aren't needed. Indeed,
MAC address randomisation is an example of removing a
long-lived hard-coded hard-to-change identifier that
no user even knows exists, and that's one non-trivial
reason to like MAC address randomisation.

Separately, yes, I'm quite skeptical of the practicality
of any complex authentication scheme when proposed for use
in home networking. (Not objecting, just skeptical:-)

On 04/11/2020 18:03, [email-masked] wrote:
 > I'm afraid that more is needed for the home network. Think about all
 > the CPEs that display the map of connected devices (and that a user
 > can manage), assign a static IP address for specific machines,
 > program time slots when connectivity access is allowed for some
 > devices,

I don't have any data on how many such CPEs are deployed,
but especially not on how much such features are used.
Data on that could be a useful input to the discussion. I
don't believe usage is common for ISPs with which I'm
familiar, but that could vary from place to place and/or
I could be wrong.

Personally, I have played with such features on home routers,
but have so far never ended up depending on any of 'em as
they weren't really useful.

On 04/11/2020 18:03, [email-masked] wrote:
 > or future deployments where a specific DoH URI Template can
 > be returned to one child PCs, etc.

I'm just making a wild guess here - but I'd say this BoF
might be easier if we avoid the third rail of DoH deployment
arguments and leave discussion of those to the ADD WG:-)

Cheers,
S.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 17:43:33 -0500

Stephen Farrell <[email-masked]> wrote:
    >> Is your objection based upon privacy implications of a device doing
    >> EAP-TLS with a home router?

    > I didn't make an "objection" - I noted that in many cases authorisation
    > without identification is possible and sufficient. I do think that, in
    > general, we ought be far slower than we are to try create new
    > identifiers or identifications, if those aren't needed. Indeed, MAC
    > address randomisation is an example of removing a long-lived hard-coded
    > hard-to-change identifier that no user even knows exists, and that's
    > one non-trivial reason to like MAC address randomisation.

Thank you.
And your skepticism is noted.

    >> can manage), assign a static IP address for specific machines, program
    >> time slots when connectivity access is allowed for some devices,

    > I don't have any data on how many such CPEs are deployed, but
    > especially not on how much such features are used.  Data on that could
    > be a useful input to the discussion. I don't believe usage is common
    > for ISPs with which I'm familiar, but that could vary from place to
    > place and/or I could be wrong.

I think that that many of us techies are isolated from this kind of thing
because we deal with ISPs that don't force this on us.
These CPE features are becoming more common among ISPs that have a more
captive market, and it is because they can push things on relucant users.
Sometimes it's for their benefit, sometimes not.

    >> or future deployments where a specific DoH URI Template can be
    >> returned to one child PCs, etc.

    > I'm just making a wild guess here - but I'd say this BoF might be
    > easier if we avoid the third rail of DoH deployment arguments and leave
    > discussion of those to the ADD WG:-)

Yes, we don't have to discuss the plus or negative of a specific policy, but
we do need to agree that we need a hook on which to hang per-device policy.

I have regularly banned my child's devices by MAC address at certain times of
the evening ("school nights") to enforce no-screen-after-supper (But, he can
watch "TV" with us).
I have stopped this for three reasons:
  0) does bedtime have any meaning in a pandemic?
  1) I can not ban youtube while enabling google docs for school
  2) his phone has a data-SIM card, and the damn LTE provider won't give me
     a time-of-day-use-restriction
  3) nobody else knows how to override it on a single-use case basis
     [see #1]

I sure wish that there was a standard API for this.

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Thu, 5 Nov 2020 15:16:52 +0000

> Yes, we don't have to discuss the plus or negative of a specific policy, but we
> do need to agree that we need a hook on which to hang per-device policy.
> 

[JCZ] I share the views here, as I have the same problem to solve at home.

However, seeing the evolution of the MAC address randomization usage and all the Privacy problems that we have been solved, I think that dealing with such policy scenarios will have to be done assuming that there -will- be MAC address randomization. Not to abuse the nowadays common term, this is to me the "new normal."

I personally have found application-level policies much more efficient to solve these issues. Most OSs on the kids' devices allow a per-app policy that you can set for specific times (max usage per day, bedtime hours, etc.), and some can even send the associated parent account a time-extension request if the kid asks for it. I find these type of solutions much more efficient to control different applications (e.g. Google Classroom vs Youtube is a good one), as compared to me setting up network policies at MAC/IP level.

I think that we need to take a system view of the issues and look for solutions also at system level, without necessarily concentrating all the burden on one layer.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Nov 2020 15:35:33 +0000

Hiya,

I agree with Juan-Carlos' answer to this btw, but also...

>    3) nobody else knows how to override it on a single-use case basis

4) Don't bother - just talk to the kid. (Possibly
convincing them to behave by fibbing that you can
spy on all they do if you really want:-)

FWIW, when mine were young, I did #4. I suspect it
worked as well as anything.

S.

---

From: Juan Carlos Zuniga <[email-masked]>
Date: Thu, 5 Nov 2020 16:02:20 +0000

> -----Original Message-----
> From: Madinas <[email-masked]> On Behalf Of Stephen Farrell
> Sent: November 5, 2020 10:36 AM
> To: Michael Richardson <[email-masked]>; [email-masked]
> Subject: Re: [Madinas] identities for legitimate devices
> 
> 
> Hiya,
> 
> > I have regularly banned my child's devices by MAC address at certain
> > times of the evening ("school nights") to enforce
> > no-screen-after-supper (But, he can watch "TV" with us).
> 4) Don't bother - just talk to the kid. (Possibly convincing them to behave by
> fibbing that you can spy on all they do if you really want:-)
> 
> FWIW, when mine were young, I did #4. I suspect it worked as well as
> anything.
> 
> S.

[JCZ] FWIW2: It's true Stephen. That used to work fine, up until certain pandemic required homework to be delivered over cloud-based apps and (younger to my taste) kids started spending too much time in front of a screen :(  
I still strongly believe that education is better than policing, both at home and country levels. Nonetheless, at the IETF we need to focus on L7 & below solutions ;)

Jc