Minutes IETF113: madinas
minutes-113-madinas-00

* 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