# 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 (12:00) 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 (12:15) ### 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 collaborating. 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 (12:45) Randomized and Changing MAC Address Use Cases, Jerome Henry https://datatracker.ietf.org/doc/draft-henry-madinas-framework/ 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 what). 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 meeting). ## MAC Address Randomization current state-of-affairs -- 20 mins (13:15) MAC address randomization, Amelia Andersdotter https://datatracker.ietf.org/doc/draft-zuniga-madinas-mac-address-randomization/ 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 (13:35) 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 one. 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 this. 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 IEEE). 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.