THURSDAY, November 10, 2022
1700-1800 Session IV Richmond 1
Scribe: Mathieu Cunche
Juan-Carlos Zuniga, CISCO, juzuniga@cisco.com
Carlos J. Bernardos, Universidad Carlos III de Madrid, cjbc@it.uc3m.es
Juan Carlos (JC) presents the agenda.
Randomized and Changing MAC Address Use Cases, Jerome Henry, Yiu Lee
https://datatracker.ietf.org/doc/draft-ietf-madinas-use-cases/
Jerome Henry (JH) presents current states of
draft-ietf-madinas-use-cases
JH: This document aims at defining the terminology (threat actors,
environments, level of trust)
JH: documents has evolved : typo fixing and adding solutions to the
draft
JH presents the proposed steps for the evolution of the document.
Section 7 on solution can be moved in annex or to a BCP document.
Section 6.3 could be removed from the draft.
Carlos Bernados (CB): Suggests removing the requiremetns to the WG, but
leaving the ones about identification. Suggests changing the name to
"use cases and requirements". Suggests explicitly listing the use cases.
Eric Vyncke (EV): Moving the section 7 to get the basis of a BCP
document is a good idea.
Yiu Lee (YL): Regarding the BCP document, will it based on environments
or use cases?
CB: The BCP is more focused on the solutions. The use case and
requirements should be placed in a different doc.
JC: We need to identify the use cases, the requirements for those use
cases.. then what are the available solutions, and link solutions to use
cases. These are the BCP. If we identify gaps, we would then decide if
we need to discuss with another WG, SDO, or if we need to recharter.
MAC address randomization, Carlos J. Bernardos
https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/
CB is presenting the slides.
CB: since last IETF meeting, changes have been made in section 8
(Taxonomy of MAC addr selection policies).
There are 5 different policies for MAC address selection.
CB Presents the evolution of the document.
Michael Richardson (MR): Some of those policies are stupid, but it is
important to list them in order to discuss why they are bad ideas.
CB: mobile OSes are combining two policies. Do we need to define another
policy to designate that behavior ?
Discussion on the current approaches by OSes to use random addresses.
There may be another policy that is "per-session".
MR: even weird behaviors need to be documented.
EV: the name of the draft is address randomization but the name of the
other draft is random and changing addresses. Need to fix this.
Mathieu Cunche(MC): per-session-address is a good name for addresses
changing at each connection to an network.
Chairs, open discussion
JC: the WG is missing a third document : BCP (Best Current Practices)
JC reminds the corresponding objectives of the WG.
JC: We are not limited to IETF solutions, we can recommend solutions
from outside (WBA, IEEE 802, ...).
JC: BCP is a followup of the two first documents.
MR: There are some practices that needs to stop. There are many
solutions that are negatively affecting privacy. WPA enterprise could be
a good solution (provides the concept of device identity).
JC: Are you suggesting we need to work on both the dos and the don't ?
MR: Yes. We need to explain why some solutions do not work. use TLS EAP
1.3 instead of 1.2 as it does not expose the certificate in clear.
MR volunteered to work on the BCP document, but will need some help.
Mackermann: How is the randomization of the address working ? All 48
bits only 24 bits ?
JC: there are different practices depending on the vendors. There are
recommandation in 802 on how to generate those addresses. Those
recommandations are not always followed.
CB: there is a quadrant that can be used to randomize the lower part of
the address. Some details are described in the informational draft.
JC presents the slides.
OpenRoaming is similar to the solution used in the Eduroam network.
Allow multiple network providers to authenticate users through multiple
identity providers.
There are plans to test the openroaming system during future IETF
meetings.
EV: We are going in good direction. If we get the documents in a decent
form, and there are no more actions, we can declare success and close
the WG.