Subject: Re: [Madinas] Call for adoption: draft-henry-madinas-framework

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Thu, 20 Jan 2022 11:46:09 +0100

Dear all,

Based on the comments received, we declare consensus in
adopting draft-henry-madinas-framework-03 as MADINAS WG document.

Based on the discussion, can you please consider updating the name of the
draft to better reflect its content and purpose?

Authors, please submit this as draft-ietf-madinas-***-00

Thanks,

Carlos and Juan-Carlos
MADINAS chairs

On Wed, Nov 10, 2021 at 2:56 PM Juan Carlos Zuniga <
[email-masked]> wrote:

> Dear all,
>
>
>
> Confirming what was said at the meeting, we are starting a Call for
> Adoption of
> https://datatracker.ietf.org/doc/html/draft-henry-madinas-framework-03
>
>
>
> Please let us know if you support or oppose the adoption. Likewise, please
> let us know if you have any comments or suggestions.
>
>
>
> Best,
>
>
>
> Juan-Carlos & Carlos
>
> MADINAS chairs
>
>
>
> Your privacy is important to us. Please see our Privacy Notice
> <https://www.sigfox.com/en/privacy-and-cookies-policy> for further
> details. The information contained in this Message is confidential. If you
> are not the addressee, you may not copy, forward, disclose or use any part
> of it. If you have received this Message in error, please delete it and all
> copies from your system and notify the sender immediately by return
> message. Any use of information contained in this Message not in accordance
> with its intended purpose, any dissemination or disclosure (either whole or
> partial), is prohibited unless expressly authorized. Email communication
> cannot be guaranteed to be timely secure, error or virus-free. The sender
> cannot be held responsible for any alteration, errors or omissions, which
> arise as a result.
>
>
> ..................................................................................................................
>
> La protection de vos données personnelles est primordiale pour notre
> établissement. Merci de consulter notre notice sur la protection des
> données personnelles
> <https://www.sigfox.com/en/privacy-and-cookies-policy>pour plus
> d’informations. Ce message et toutes les pièces jointes (ci-après le
> 'Message') sont établis à l'intention exclusive des destinataires. Les
> informations qui y figurent sont confidentielles. Si vous n'êtes pas le
> destinataire de ce Message, il vous est interdit de le copier, de le faire
> suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu
> ce Message par erreur, merci de le supprimer de votre système, ainsi que
> toutes ses copies, et de n'en garder aucune trace sur quelque support que
> ce soit. Veuillez également en avertir immédiatement l'expéditeur par
> retour du Message. Toute utilisation de ce Message non conforme à sa
> destination, toute diffusion ou toute publication totale ou partielle, est
> interdite sauf autorisation expresse. Il est impossible de garantir que les
> communications par messagerie électronique arrivent en temps utile, soient
> sécurisées ou dénuées de toute erreur ou virus. L'expéditeur ne peut être
> tenu responsable des modifications, erreurs ou omissions qui pourraient en
> résulter.
>
>

---

From: Hai Shalom <[email-masked]>
Date: Tue, 25 Jan 2022 19:28:36 -0800

I apologize, but I do not follow this working group due to time zone
differences. However, I would like to comment about the following comments,
thanks in advance for your time and consideration!

In other contexts, operators assign network resources based
>    on contractual conditions (e.g., fee, bandwidth fair share).  In
>    these scenarios, these operators may attempt to identify the devices
>    and the users of their networks.  They can use the MAC address to
>    represent an identified device.
>
>
I believe that such operators are aware that this is a "happy accident" and
that associating liability and payments to a weak identifier that can be
easily spoofed was already a flawed concept, even before RCM was
introduced. RCM just expedited this realization. Shouldn't the text
recommend other means, or point to current activities in IEEE that are
trying to solve it?

   In wireless contexts, 802.1X authenticators rely on the device and
>    user identity validation provided by a AAA server to open their port
>    to data transmission.  The MAC address is used to verify that the
>    device is in the authorized list, and the associated key used to
>    decrypt the device traffic.  A change in MAC address causes the port
>    to be closed to the device data traffic until the AAA server confirms
>    the validity of the new MAC address.  Therefore, MAC rotation can
>    interrupt the device traffic, and cause a strain on the AAA server.
>
>
This is only true if the device rotates its MAC address during an active
session, but current 802.11 text specifies that in order to keep the state
of a session, a non-AP STA shall keep its MAC address. So it looks like
this text is irrelevant because this will never happen while the device is
connected. If it does happen, the specs will define a secure way for a
non-AP STA to communicate with the AP STA about the change.

DHCP servers, without a unique identification of the device, lose
>    track of which IP address is validly assigned. ....
>
>
The text abstract says "this document examines solutions to maintain user
privacy...". It can recommend short leases to requests that come from the
wireless LAN interface (although MAC addresses can be changed by stationary
devices). Was the intention of this text to just specify issues?

device recognition and ranging may be
>    used for IoT-related functionalities (door unlock, preferred light
>    and temperature configuration, etc.)  These functions often rely on
>    the detection of the device wireless MAC address.  MAC address
>    rotation breaks the services based on such model.
>
>
Using MAC addresses to range devices and implement security operations is
something that should not be mentioned or encouraged, other than explaining
what NOT to do. If a door lock unlocks by detecting a MAC address presence
in the area getting closer - this is considered a critical security
vulnerability, so saying "often rely" on MAC address is not true. There are
new standards that are being worked on to solve these problems in a secure
way.

For example: a Home network is considered to be trusted and safe.
>    Users expect a simple procedure to connect to their home network.
>    All devices in the home network trust each other.  Privacy within the
>    Layer 2 domain is not a major concern.
>
>
I agree that this is the perception of the non-technical, naive user.
However, this text ignores the fact that the RF is not confined to the
walls of the structure, such that an attacker can detect the presence of a
particular device in the home at any given time (e.g. can detect when a
person leaves for work while waiting hidden in an adjacent apartment).
Additionally, IoT devices that use constant OUIs allow attackers to deploy
attacks on known vulnerabilities of particular devices, and detect if they
are offline (e.g. the doorbell is offline, so someone can now approach the
front door without being detected). So while the trust in the network is
high, the network is not immune from privacy related issues, and this is
not reflected in table 1 (or in "Trust" of the network).

And last word about address collisions: 1 in 2^46. So even in a crowded
airport, the probability is negligible.

Thanks in advance.

- Hai

On Thu, Jan 20, 2022 at 2:46 AM CARLOS JESUS BERNARDOS CANO <[email-masked]>
wrote:

>> Please let us know if you support or oppose the adoption. Likewise,
>> please let us know if you have any comments or suggestions.
>>
>>
>>
>> Best,
>>
>>
>>
>> Juan-Carlos & Carlos
>>
>> MADINAS chairs
>>
>>
>>
>> --
> Madinas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/madinas
>

---

From: "Jerome Henry (jerhenry)" <[email-masked]>
Date: Wed, 26 Jan 2022 18:44:34 +0000

Hey Hai,

Welcome to the group!

Answering your questions below as one of the authors. I would encourage you to read the group charter and the mailer exchanges, many of the points below are also addressed there.
Take care

Jerome

From: Madinas <[email-masked]> on behalf of Hai Shalom <haishalom=[email-masked]>
Date: Tuesday, January 25, 2022 at 10:29 PM
To: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Cc: Juan Carlos Zuniga <[email-masked]>, "[email-masked]" <[email-masked]>, Juan Carlos Zuniga <[email-masked]>
Subject: Re: [Madinas] Call for adoption: draft-henry-madinas-framework

I apologize, but I do not follow this working group due to time zone differences. However, I would like to comment about the following comments, thanks in advance for your time and consideration!

I believe that such operators are aware that this is a "happy accident" and that associating liability and payments to a weak identifier that can be easily spoofed was already a flawed concept, even before RCM was introduced. RCM just expedited this realization. Shouldn't the text recommend other means, or point to current activities in IEEE that are trying to solve it?
[jh] This is not the goal of this document at this point. It is listing scenarios and use cases where MAC addresses are used in relation to device identification. The outcome of the group’s work will be to recommend existing methods around problems that will have been identified, likely from the IETF and other SDOs. The group charter may help see where we are and what the current streams goals are.

This is only true if the device rotates its MAC address during an active session, but current 802.11 text specifies that in order to keep the state of a session, a non-AP STA shall keep its MAC address. So it looks like this text is irrelevant because this will never happen while the device is connected. If it does happen, the specs will define a secure way for a non-AP STA to communicate with the AP STA about the change.
[jh] The 802.11 standard does not define how 802.1X port release functions. 802.11 (as of 802.11me draft 1) does not say what you write either. Even if it did, the point of the text is to underline that if you change your MAC, the port control (as defined by 802.1X, not by 802.11 or other standards) fails.

The text abstract says "this document examines solutions to maintain user privacy...". It can recommend short leases to requests that come from the wireless LAN interface (although MAC addresses can be changed by stationary devices). Was the intention of this text to just specify issues?
[jh] yes, please see the group charter.

Using MAC addresses to range devices and implement security operations is something that should not be mentioned or encouraged, other than explaining what NOT to do. If a door lock unlocks by detecting a MAC address presence in the area getting closer - this is considered a critical security vulnerability, so saying "often rely" on MAC address is not true. There are new standards that are being worked on to solve these problems in a secure way.
[jh] Probably, and the group will point to them as it performs its work.

I agree that this is the perception of the non-technical, naive user. However, this text ignores the fact that the RF is not confined to the walls of the structure, such that an attacker can detect the presence of a particular device in the home at any given time (e.g. can detect when a person leaves for work while waiting hidden in an adjacent apartment). Additionally, IoT devices that use constant OUIs allow attackers to deploy attacks on known vulnerabilities of particular devices, and detect if they are offline (e.g. the doorbell is offline, so someone can now approach the front door without being detected). So while the trust in the network is high, the network is not immune from privacy related issues, and this is not reflected in table 1 (or in "Trust" of the network).
[jh] agree, this is changed in the new version of the text, please refer to the mailing list where this issue was discussed extensively.

And last word about address collisions: 1 in 2^46. So even in a crowded airport, the probability is negligible.
[jh] It is not 1 in 2^46, please check the birthday paradox. This assumption also assumes a linear distribution of the allocation methods, which is not granted in real life. Even the set of possibilities is large, collisions may happen (this was the whole purpose of globally unique addresses 30 years ago), the group may decide that the collision are sufficiently unlikely and their effect minor enough that no recommendation needs to be made to address this case, but both elements need to eb considered before brushing aside the problem, imho.

Thanks in advance.

- Hai

On Thu, Jan 20, 2022 at 2:46 AM CARLOS JESUS BERNARDOS CANO <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Based on the comments received, we declare consensus in adopting draft-henry-madinas-framework-03 as MADINAS WG document.

Based on the discussion, can you please consider updating the name of the draft to better reflect its content and purpose?

Thanks,

Carlos and Juan-Carlos
MADINAS chairs

On Wed, Nov 10, 2021 at 2:56 PM Juan Carlos Zuniga <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Confirming what was said at the meeting, we are starting a Call for Adoption of https://datatracker.ietf.org/doc/html/draft-henry-madinas-framework-03

Please let us know if you support or oppose the adoption. Likewise, please let us know if you have any comments or suggestions.

Best,

Juan-Carlos & Carlos
MADINAS chairs

Your privacy is important to us. Please see our Privacy Notice<https://www.sigfox.com/en/privacy-and-cookies-policy> for further details. The information contained in this Message is confidential. If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this Message in error, please delete it and all copies from your system and notify the sender immediately by return message. Any use of information contained in this Message not in accordance with its intended purpose, any dissemination or disclosure (either whole or partial), is prohibited unless expressly authorized. Email communication cannot be guaranteed to be timely secure, error or virus-free. The sender cannot be held responsible for any alteration, errors or omissions, which arise as a result.

La protection de vos données personnelles est primordiale pour notre établissement. Merci de consulter notre notice sur la protection des données personnelles <https://www.sigfox.com/en/privacy-and-cookies-policy> pour plus d’informations. Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires. Les informations qui y figurent sont confidentielles. Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Veuillez également en avertir immédiatement l'expéditeur par retour du Message. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse. Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, soient sécurisées ou dénuées de toute erreur ou virus. L'expéditeur ne peut être tenu responsable des modifications, erreurs ou omissions qui pourraient en résulter.
--
Madinas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/madinas