* Welcome, Agenda Review and Status Update (WG Chairs) -- 10 mins (13:00) Juan-Carlos Zuniga, CISCO Carlos J. Bernardos, Universidad Carlos III de Madrid - no comment on the agenda. * Use cases and Problem statement -- 15 mins (13:10) Randomized and Changing MAC Address Use Cases, Jerome Henry https://datatracker.ietf.org/doc/draft-ietf-madinas-use-cases/ - Jerome: Update on use-cases document - define the use case for RCM - defines the devices [IEEE and ISO terminology] - defines the actors (networks functional entities and human related entities) - define a level of trust - becomes a WG document, ID 01 addresses comments on previous F2F - Feedback and comments are very welcome - proposed steps: - survey current standards that use MAC addresses (DHCP, EAP, RADIUS ...) - make recommandation to WG to remove dependencies - go to the list to give protocols that use MAC addresses inside and outside IETF - Carlos Bernardos: on this point aboiut protocols using MAC, we need to make sure we don't miss any, I think about mobility protocols, we should ask other WG to helps us on this. - Jerome: I think you're rigth, we need to search for that, i already find like 200 references. Ask for experts. - Robert Moskowitz: Broadcast remote ID?, in aircraft communication. Apple is changing the MAC address. - Jerome: Interesting case, please post references on this. - Robert: Yes, I'll get active here to make sure it's covert in your work - Tim: use managed or unmanaged - Michael: what is the point of referencing all this uses, I dont know what the cost of missing one protocol?, Bob bring a more important point, Apple is removing those MAC for the sake of your own privacy, we need to write down why randomize MAC is a good Idea but in fact it isn't, We shall rather say which uses are subject to security leaks. I need to look for IoT appliances, ie. I need to know the MAC of my refigerator. - JCZ: it is in the charter, we want to list use case such as randomization. After characterization we can state if it make sense or not. Is MAC address the right identifier. * MAC Address Randomization current state-of-affairs -- 10 mins (13:25) MAC address randomization, Carlos J. Bernardos https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/ - Carlos: unique MAC address is a threat and many vendors are implementing some mitigations - a section on current practices - early work on IETF91 - other documents related to privacy RFC7217 - Now using random in MAC address is the default standard - Activities at the IEEE - section WBA - description of OS behavior [Android 10+, iOS, Linux, ....] - -01 includes some feed back - Question to WG: how we tacke the feedback on sec 7 : 1) keep it as it is, in section 7, 2) as an annex and then update to a wiki, 3) everything in the wiki, others ) - JCZ: I prefer for not option 1, btw 3 or 2 depends on the goals of the document, mainly if it will be only informational or not. Things change quickly, we need smething dynamic - carlos: agree, look at other examples at IETF - Eric: Github for main document and IETF repo - Mathieu : Regarding the table were you list OS, I understand that for iOS is monolitic, on the contrary, in android this is not the case., should we mention, underline on the application using the OS ?. The vendor may decide ?. - carlos: in linux is more user driven, but we may try to improve that based on the options. For android I also agree, we put the official vanilla, but the variations of vendors change everithing. * Updates from WBA (Bruno Tomas) -- 10 mins (13:35) - Luther: quick summary of last conversation. - we agreed on having a white paper defining use cases, how the MAC was used. Suggested solutions for different use cases - liaise the completed paper with other standard bodies - started 2021-02-23 - Liaison with MADINAS - we already finalize the white paper - give a summary of the finding included - MAC is used by different aspect. The MAC address was not defined for this. - MAC change brokes trouble shouting, ... - there is not a single solution, but some solutions may conflicts. - Findings are in the white paper, made available to the group. The document may be public in a 3 month period. - JCZ: we really appreciate the report for WBA and the fact that WBA in communicate with MADINAS. We have to lake sure that the use cases that you mention are correct, the idea is not to redo this you already included. We can review JŽr™me's draft with the outcomes.. The puspuse of the group is to find the gaps. - Luther: it was interesting to see where the gaps are indeed. * Updates from IEEE 802.11bh/bi (Jerome Henry) -- 10 mins (13:45) - jerome: several groups 802E focuses on privacy - 802.11dh: short term group, what is the impact of RCM on services. The MAC address can change between session, what happens if it change during session. Identified services broken by RCM. - 802.11bi is long term. identify a way to augment privacy in 802.11 networks. Focus on L1 and L2. * Next Steps (WG Chairs w/AD Support) -- 5 mins (13:55) - JCZ: we have the pieces of the puzzle, we have to put them together to get the full picture and idenfiy the gaps. - homework to do and participate to the list. JCZ: adjourned