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

[Hai Shalom <[e-mail]>]

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 <[e-mail]>
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?
>
> 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 <
> [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/madinas
>