Minutes IETF112: madinas

Meeting Minutes MAC Address Device Identification for Network and Application Services (madinas) WG
Title Minutes IETF112: madinas
State Active
Other versions plain text
Last updated 2021-11-11

Meeting Minutes

# IETF 112 MADINAS WG Agenda

MAC Address Device Identification for Network and Application Services

Wednesday, November 10, 2021 (UTC)

12:00-14:00     Wednesday Session I     Room 3

## Welcome, Agenda Review and Status Update (WG Chairs) -- 15 mins
Juan-Carlos Zuniga, Sigfox, j.c.zuniga@ieee.org
Carlos J. Bernardos, Universidad Carlos III de Madrid, cjbc@it.uc3m.es

* Meeting opened at 12 UTC.
* Presentation of Note Well.
* No discussion on or objections to agenda as originally proposed.** Current
state of affairs:
    * Reached out to different SDOs (will hear more about this later).
    * Formal use-case and requirements document underway. Idea is to adopt them
    for the working group. * We will later on work on a BCP.

## Status update from other SDOs -- 30 mins
### WBA Wi-Fi Devices Identification, Tim Twell (10 min)

Tim presenting

Wireless broadband alliance is also working in this area.
Looking at the high-level use-cases, with a view to explaining and recommending
the use of technologies that are ideally already existing, and which contribute
to the continued functioning of WBA remit technologies.

WBA has studied a number of use-cases where permanent, plain-text MAC have been
used as a support. Following on from these use-cases we looked at requirements
that MAC addresses fulfilled. Uniqueness of user within a particular network,
with particular attention to long-term validity (where user has requested a
particular relationship with service provider).

Obvious existing solutions to preserve status quo are 802.1X, OpenRoaming,
Passpoint, private pre-shared key, device fingerprinting and other proprietary
identification mechanisms (apps, or similar) which can uniquely identify users
sometimes for years.

Could also do nothing. Lack of time and expertise has stopped looking into
802.1AR or Wi-Fi EasyConnect.

Steven Hartley: Has WBA come up with any proposed solutions.  Sounds like MAC
address is still the best way, have you considered using UUID.

Tim: Not considering MAC address is the best way.  For most larger networks,
suggesting that one of the 802.1X based methods are better approaches.  Don't
want to recommend a non-standardized solution.  There are things that we
haven't covered yet because we don't have the knowledge.

Steven: Will this whitepaper be made available to the public.

Tim: Summary is made public, but often shared with liaisons and XXX.

Juan-Carlos: WBA have made a good start.  Goal is not to do the work again, but
to work together.  Can consider other use cases.  Regarding solutions we will
consult with IEEE 802.  Plan is to work together and use liaisons to make it
official if possible.

### Updates from IEEE 802.1 , Glenn Parsons (10 min)

Glenn presenting, 802.1 WG chair, but presenting as an individual.

802.1 generally deals with the higher layer of the MAC.

Describing 802 reference model, defining interfaces and access points.  MAC
address is defined at the MAC access point, common to all 802 technologies.

Describing format of a MAC address.  MAC addresses can be universally
administered or locall administered.  Some addresses are allocated by the RAC.

Concern about exhaustion of MAC addresses due to virtualization, because a
single physical device could have multiple MAC addresses, which could be a
problem if the universal space was used.  Hence more structure of the local
space was defined.  Two extra bits added to local space to support an optional
structured local address plan. 4 regions defined: Extended Local, Standard
Assigned, Admin Assigned, and Reserved.

Idea is that randomization would be within Admin assigned space.

IEEE Std 802 formally defines MAC address.

Considering Unicast Space, we have Global space, and the Local space (4
quadrants).  Designing protocol to assign MAC addresses on bootup.  There is a
presumed gaurantee of uniqueness.  Facilitated with global addresses.  If local
space is used then it is the adminsitrators responsibility to ensure
uniqueness.  If there is not uniqueness then distruption may occur.

IEEE is looking to revise Std 802 (must be revised every 10 years, and current
standard expires at the end of 2024). Revision includes mapping of MAC
addresses to MSAPs.

Also reporting work on security happening in 802 that may be relevant to this
group.  Wanted to highlight MACsec and privacy (802E).  802E considers a threat
model against all 802 technologies.  On MACsec, on new project, is specifying
enhancements to MAC security that reduces ability for observers to corollate
information based on size and XXX.  It does this by padding data out.

P802.1AEdk hides MAC address from eavesdroppers.  Project is expected to
complete early next year.

Provides summary of information.

Michael Richardson: As people move to random addresses, they no longer need any
IEEE assigned space.  For industrial uses we would like more clear identites
for IOT devices.  Would the IEEE ever consider SIDR-like assignment of MAC
addresses, that is, with delegation to certificates?

Glenn: This sounds like 802.1AR (DevIds).

Michael: We would be using .1AR, but what identity is being asserted, because
we only see MAC address.  Can we validate the OUI?  For some devices want more
randomization, in other cases

Glenn: I.e., you are looking at trust model for MAC addresses.  We are working
.1Cq, which is MAC adddress assignment. One option within that includes a trust
relationship.  Not decided if IEEE would be one of the trusted assigners. 
Assumption that this would be within an adminsitration (e.g., factory)

Michael: They (factories) are not competent to insert certificates into devices.

Glenn: Good point.  I can take that back to IEEE. This would require creating a
registration authority.  Have been focusing on the protocols.

### Updates from IEEE 802.11bh/bi, Jerome Henry (10 min)

Jerome presenting, as a participant in 802.

Commenting on 802.11

Randomizing addresses has been around for a while.  802.11aq considers some of
this.  Once you connected to an access point, should not change your MAC
address because you break state.

Outcome of study group was the creation of two WGs:

802.11bh - Enhanced service with randomized MAC addresses
  - How to maintain services.
  - E.g., services that were possible before MAC address randomization but are
  not possible now. - See if they can provide recommendation on how to mitigate
  that. - Aiming to be done by 2023. - Looking at use cases that are broken. 
  Lots of cases considered, but they are outside 802.11.  This is relevant to
  MADINAS. - Now have a good view of use cases that are broken.

802.11bi - Enhanced service with Data Privacy Protection:
 - Anyone can observe the signal, how to keep the data secure.
 - Goal is about what we should improve in 802.11, if they have an impact on
 privacy. - Aiming/expecting something by 2025. - Trying to list privacy
 related issues. - Lots of thing in the frame that may be usable to identify an
 end station in the crowd. - Already some thoughts on how to fix point issues. 
 Not being worked on currently, but being saved for future work.

Any questions on these groups?

Steven: What WBA is working on is close to .11bh, so are the two groups

Jerome: Yes, we are talking, but the goals are not quite the same.  IEEE is
looking at the mechanics, but WBA is looking at who is impacted.

Bob Moskowitz: My work in unmanned aircraft has oppostite problem.  Identity
must be known because you are in a public space. Must use MAC address at the
same time.  Receiver has to get the MAC address associated the messages
toegether.  Have been finding on Smartphones, the API doesn't send the MAC
address up the stack.  Using WiFi beacons. The API puts a pseudo MAC address up
the stack that breaks the intent.  Hence here is an example where identity is
required where privacy is basically not allowed.

Jerome: I will look it up, it is an interesting case.  We looking at 802.11
side, but what you describe sounds more like the application size.

Bob: Also have problem with the GPS information on the smartphones.

Amelia: In many updates, the problems identified in terms of identification and
privacy are overlapping.  How do we move ahead with the correct technical
circumstances to address the right problem.

Jerome: We need to continue to have liaisons between the different groups.  We
spent a lot of time considering usecases, but we are focussed on a particular
place in the network stack.  If we work in isolation we will fail.

## Use cases and Problem statement -- 30 mins
Randomized and Changing MAC Address Use Cases, Jerome Henry

Jerome presenting.

Considering with RCM affects services.  Vocab is a problem.

Smartphones are typically associated with a user.  But look at the traffic at a
switch, cannot easily identify the traffic to a single user.

Trying to look at where MAC address is a problem and where it is not.  Need to
consider trust.  E.g., consider environments where MAC address might be used
against you.  Two extremes are clear (trust vs zero-trust), but there are also
cases that might be in the middle.

It also depends on who owns the device (in terms of privacy and who is doing

In the end try and list the requirements, and possible steps that we could take.

Some things currently not in the draft:
 - Lot looking at IOT yet, but perhaps need to consider that case (e.g.,
 Michael).  What is the effect of IOT changing your MAC.

Thanks everyone for providing feedback on the doc:
 - Is home a trusted environment?  Depends on how many people are listening.
 - Question do you think that home could be a full trust environment.  Or if
 not, then do you think of any places that would be a
full trust environment.

Michael R: I don't think that you want to expose your MAC address to people
driving up to your house.  Enterprise could be a full trusted environments. 
Home is never going to a full trust env.

Joey: Agree with what Michael says.  Not just attackers.  Also because of a
lack of security mechanisms.  In these scenarios, enterprises could be much
more secure.

Jerome: We will correct that section of the draft and provide a different view.

Mathieu: Cannot trust anyplace in the world that has other devices.  Lots of
smartphones are running apps that are scanning devices around you. Even if this
is just comercial entities.  Cannot really trust the enviroment.  Do we really
need a specific scenario when full trust is a requirement.  Can't we apply the
rules for non-fully trusted environemnts to these cases as well.

Jerome: Not sure that there is a place that is a full trust environment. 
Enterprises might have physical security.  Perhaps just say that there is no
such place.

Bob Hinden: The notion that enterprises are secure is wrong.  Some are very
open, some are very closed.  Cannot be generalized. It is the user who
identifies the device - they need to do this as a user level not just at the
network layer.  May have been a convenient way to track people before, but this
doesn't work any more.  Cannot assume enterprises are secure because they are
not (e.g., consider ransomware)

Jerome: Not saying that all enterprises are full trust, but if there is no PII
on a device then it might not matter.

Now talking about Race Conditions:

 - From 2018, if you want to be the same device must keep same MAC address.
 - Now may want to out to lunch then come back with a different MAC and come
 back with the same state. - Do not make any assumptions in the draft that the
 MAC address has to stay stable.  We don't know if this will remain true in
 future. - Do you think that it is okay to allow this?  Or should we tie to
 current state of play now?

Dan Harkins: 802.11aq assumes a single MAC address.  But that is likely to be
address in 802.11bi once privacy has been addressed. Madinas should do nothing,
leave this to .bh/.bi

Jerome: So we should not make any assumption about behaviour?

Dan: Yes, that is my suggestion.

Juan-Carlos: For this document, I think it doesn't hurt to indicate these types
of converstations or next steps, just to remind readers that this is not set in
stone.  It is fair to document that this conversation is taking place and where.

Jerome: Thanks.  That makes sense.

Will update the draft in the next few weeks.

Juan-Carlos: Plan is to adopt this draft (but will do this at the end of this

## MAC Address Randomization current state-of-affairs -- 20 mins
MAC address randomization, Amelia Andersdotter

Amelia presenting.

Updated version of what was presented in the July meeting.

Goal of draft is to document current state of affairs.

Moving to slide 7
 - Describing how current OSes randomize MAC addresses.

Slide 8 describes the different capabilies for different OSes.

Any comments or further reviews?

Carlos: As an author, made some editorial changes to better match the Madinas
charter.  On OS changes, this describes what they are doing today, and these
practices are changing.  Also what they are doing when scanning.  Please can we
have more feedback not just on the content, but also how it is documented.  May
also want to document the evolution.

Juan-Carlos: (As chair) This is a useful informational document.

## Next Steps (WG Chairs w/AD Support) -- 15 mins

Juan: The idea is to adopt these two drafts.

- Any questions regarding adopting draft-henry-madinas-framework (will confirm
on list).  Any in favour or against?

Rich: My only concern is about information slides.  The stuff about what OSes
do has a habit of going out of date.  Also need to consider which OSes and
devices are being considered.

Juan: I think that your comment applies to the second draft rather than this

Bob Moskowitz: Don't want these tables to be locked down in the RFC.  Can
reference these it github.

Juan: Thanks, but this comment also applies to the other draft.  Moving back to
the first draft, one last call for comments.

No more comments.

- On draft-zuniga-madinas-mac-address-randomization-01:

Juan: I've co-authored, will hand off the Call of Adoption to Mathieu Cunche

(Mathieu Cunche chairing)

Joey: Want to comment on the previous draft.  I would support adoption after
making changes about the trust and levels of trust.

Michael: I will echo what Bob says about the tables.  But one of the useful
things that this doc could do, but give names to the differnet policies that
have been seen. Instead we should use generic name such as Type I and define
the behavior of each type. That way we can have a better conversation about

Dave Thaler: Going to the same thing as Michael.  No personal opinion as to
whether there is a snapshot or a refrence. But seeing the types of behavior
that are out there are useful.  Hence if you can define the taxonomy that is
helpful in itself.

Mathieu: Will continue discusion on mailing list and there will be a call for
adoption on the mailing list.

(back to Juan & Carlos as chairs)

Juan: Any last questions/comments

Eric Vyncke: Good number of participants (60-70).  Would like to thank the
other SDOs presenting there points of view (namely Tim for WBA and Glenn for

As a participant, would really like to get this adoption done.  I don't feel
strongly about a snapshot or not.  Let's continue the job.

Meeting closed.