Subject: Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 10 Dec 2020 21:07:40 +0000

On the question on what IETF can do, when there is established trust between the endpoint and the network, can the randomization be done in a coordinated manner, without leaking PII elements?

Sri

From: Madinas <[email-masked]> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked]>
Date: Thursday, December 10, 2020 at 12:46 PM
To: "[email-masked]" <[email-masked]>
Subject: [Madinas] MADINAS 2nd BoF at IETF-110 ?

After a good first BoF, I wonder whether the MADINAS participants (and especially the chairs and presenters of the first BoF) want to have a 2nd BoF that could potentially be WG forming.

See https://datatracker.ietf.org/meeting/important-dates/ for the dates

And https://trac.tools.ietf.org/bof/trac/wiki#TimeframeIETF110Online

Hope it helps

-éric

---

From: Tim Cappalli <[email-masked]>
Date: Thu, 10 Dec 2020 21:17:47 +0000

Yes, there are no issues when secure authentication methods are used (EAP, DPP, SAE Password ID, etc).

That's one of the reasons I think this issue is being a bit overblown. There are solutions, and have been for a number years. People need to implement them :)
________________________________
From: Madinas <[email-masked]> on behalf of Sri Gundavelli (sgundave) <sgundave=[email-masked]>
Sent: Thursday, December 10, 2020 4:07:40 PM
To: Eric Vyncke (evyncke) <evyncke=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?

Sri

See https://datatracker.ietf.org/meeting/important-dates/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2Fimportant-dates%2F&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C52c9e7aefd014822894c08d89d4fa86f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432312746584924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=s8o%2BOWBW6Vt%2BTkdDw9gYKWgOsyzuka9MLRBNSsWouoc%3D&reserved=0> for the dates

And https://trac.tools.ietf.org/bof/trac/wiki#TimeframeIETF110Online<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.tools.ietf.org%2Fbof%2Ftrac%2Fwiki%23TimeframeIETF110Online&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C52c9e7aefd014822894c08d89d4fa86f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432312746584924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=i1Hg3zTxYcDSbXlsUDLnH7MqS3xb1kkxO7QV8BpbNmo%3D&reserved=0>

Hope it helps

-éric

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 10 Dec 2020 22:31:10 +0000

One problem we are seeing is no alignment between ISP and manufacturers. Given that madinas impacts level-2 to level-7, IETF may consider to work on a BCP. From the design work perspective, I think there are values to discuss further how a network can provide a trusted identity and a list of services to the user so that a user can decide trust or not trust the network. If trusted, the user may provide some pseudo static information (could be per SSID) at the packet level so that lower-end device such as home gateway will be able to provide some network functions that user will enjoy. This should be light-touched and easy to troubleshoot when things go wrong.

From: Madinas <[email-masked]> on behalf of Tim Cappalli <Tim.Cappalli=[email-masked]>
Date: Thursday, December 10, 2020 at 16:18
To: "evyncke=[email-masked]" <evyncke=[email-masked]>, "[email-masked]" <[email-masked]>, "sgundave=[email-masked]" <sgundave=[email-masked]>
Subject: Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?

Sri

See https://datatracker.ietf.org/meeting/important-dates/<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fmeeting*2Fimportant-dates*2F&data=04*7C01*7Ctim.cappalli*40microsoft.com*7C52c9e7aefd014822894c08d89d4fa86f*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637432312746584924*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=s8o*2BOWBW6Vt*2BTkdDw9gYKWgOsyzuka9MLRBNSsWouoc*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!CQl3mcHX2A!SQfLFOQyQiN8KSxsooXQc_oN7zx90aq1m5h2X9HBP4tvAcogUTABvB4jBmIbpVE$> for the dates

And https://trac.tools.ietf.org/bof/trac/wiki#TimeframeIETF110Online<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftrac.tools.ietf.org*2Fbof*2Ftrac*2Fwiki*23TimeframeIETF110Online&data=04*7C01*7Ctim.cappalli*40microsoft.com*7C52c9e7aefd014822894c08d89d4fa86f*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637432312746584924*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&sdata=i1Hg3zTxYcDSbXlsUDLnH7MqS3xb1kkxO7QV8BpbNmo*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSU!!CQl3mcHX2A!SQfLFOQyQiN8KSxsooXQc_oN7zx90aq1m5h2X9HBP4tvAcogUTABvB4jEPVu7gA$>

Hope it helps

-éric

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Dec 2020 18:16:37 -0500

Sri Gundavelli \(sgundave\) <sgundave=[email-masked]> wrote:
    > On the question on what IETF can do, when there is established trust
    > between the endpoint and the network, can the randomization be done in
    > a coordinated manner, without leaking PII elements?

If you have that established trust, you can run 802.1X and EAP-TLS
("WPA-Enterprise") and then you don't need to do any kind of deterministic
MAC address generation.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: <[email-masked]>
Date: Fri, 11 Dec 2020 11:18:43 +0000

You raise a key issue, that the solutions need to be light touch for the end user. While EAP and WPA2-Enterprise may be appropriate solutions for many enterprise and public Wi-Fi use cases, I fear that they will be too cumbersome for adoption by the residential consumer market.

Other alternatives, such as DPP or SAE Password ID might offer a way forward, but we would need to understand the feasibility of using these or other alternative approaches (particularly in the residential environment) and if appropriate drive industry adoption. ISPs cannot do this alone, as client implementations will be an essential component of any solution.

I see the purpose of MADINAS as being to help identify potential solutions and determine whether any new or altered IETF protocols are required.

Regards,

Simon.

From: Madinas <[email-masked]> On Behalf Of Lee, Yiu
Sent: 10 December 2020 22:31
To: [email-masked]
Subject: Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?

From: Madinas <[email-masked]<mailto:[email-masked]>> on behalf of Tim Cappalli <Tim.Cappalli=[email-masked]<mailto:Tim.Cappalli=[email-masked]>>
Date: Thursday, December 10, 2020 at 16:18
To: "evyncke=[email-masked]<mailto:evyncke=[email-masked]>" <evyncke=[email-masked]<mailto:evyncke=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "sgundave=[email-masked]<mailto:sgundave=[email-masked]>" <sgundave=[email-masked]<mailto:sgundave=[email-masked]>>
Subject: Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?

Yes, there are no issues when secure authentication methods are used (EAP, DPP, SAE Password ID, etc).
That's one of the reasons I think this issue is being a bit overblown. There are solutions, and have been for a number years. People need to implement them :)
________________________________
From: Madinas <[email-masked]<mailto:[email-masked]>> on behalf of Sri Gundavelli (sgundave) <sgundave=[email-masked]<mailto:sgundave=[email-masked]>>
Sent: Thursday, December 10, 2020 4:07:40 PM
To: Eric Vyncke (evyncke) <evyncke=[email-masked]<mailto:evyncke=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?

Sri

From: Madinas <[email-masked]<mailto:[email-masked]>> on behalf of "Eric Vyncke (evyncke)" <evyncke=[email-masked]<mailto:evyncke=[email-masked]>>
Date: Thursday, December 10, 2020 at 12:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Madinas] MADINAS 2nd BoF at IETF-110 ?

See https://datatracker.ietf.org/meeting/important-dates/<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fmeeting*2Fimportant-dates*2F%26data%3D04*7C01*7Ctim.cappalli*40microsoft.com*7C52c9e7aefd014822894c08d89d4fa86f*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637432312746584924*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3Ds8o*2BOWBW6Vt*2BTkdDw9gYKWgOsyzuka9MLRBNSsWouoc*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!CQl3mcHX2A!SQfLFOQyQiN8KSxsooXQc_oN7zx90aq1m5h2X9HBP4tvAcogUTABvB4jBmIbpVE%24&data=04%7C01%7Csimon.ringland%40bt.com%7C52ae3c4a52da4ca9bf0d08d89d5b5e16%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637432363046747125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yMT0GkyhuQbtzjRQWnRpPSYKKBE7jCU0%2BvHBZvyOWzo%3D&reserved=0> for the dates

And https://trac.tools.ietf.org/bof/trac/wiki#TimeframeIETF110Online<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Ftrac.tools.ietf.org*2Fbof*2Ftrac*2Fwiki*23TimeframeIETF110Online%26data%3D04*7C01*7Ctim.cappalli*40microsoft.com*7C52c9e7aefd014822894c08d89d4fa86f*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637432312746584924*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3Di1Hg3zTxYcDSbXlsUDLnH7MqS3xb1kkxO7QV8BpbNmo*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!CQl3mcHX2A!SQfLFOQyQiN8KSxsooXQc_oN7zx90aq1m5h2X9HBP4tvAcogUTABvB4jEPVu7gA%24&data=04%7C01%7Csimon.ringland%40bt.com%7C52ae3c4a52da4ca9bf0d08d89d5b5e16%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637432363046747125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ILaQdaH5ADSo3Pcx5af1RLlAcpZHDMTepaosUcWaZHQ%3D&reserved=0>

Hope it helps

-éric

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 11 Dec 2020 16:14:39 +0000

There are multiple discussion points here. In general I agree, with all secure auth protocols (minimally with all EAP variants), the use of MAC rotation has no impact on the authenticated session; the network has the ability to identify the device that has completed authentication using a session identifier, and the ability to associate the session to a link-link identifier that the client chooses to use.  The issue in enterprise context is not just this. 

Today there are many deployed services in enterprises that rely on link-layer identifiers, which are now broken. It is true, many of the issues are more about implementation gaps and about moving away from defining policies and by not binding them to identifiers that are transient in nature.  But, there are also some other services which are not truly  about implementation gaps, but more about broken services due to MAC rotation, and again some may be due to privacy protection. 

The larger question is identifying those services and recommending proper technology options, or adding new semantics to protocols as needed.  Taking a simple service, that tracks the number of unique devices (associated and non-associated) in a given public hotspot based on unique MAC’s, wonder what is our answer? Or, the ability for the enterprise to apply distinct policies on two connected devices from the same user but using the same common enterprise identity; is the recommendation to burn a cert for each device? Services that are in user-plane path which do not have the ability to correlate packets from the same device before and after MAC rotation. I am sure, there are available tools for each of these issues, but understanding the service impact and proposing proper solutions will be a useful effort, IMO.

Sri

On 12/10/20, 3:16 PM, "Michael Richardson" <[email-masked]> wrote:

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 11 Dec 2020 17:05:34 +0000

*   That's one of the reasons I think this issue is being a bit overblown. There are solutions, and have been for a number years. People need to implement them :)

I agree to most part.

Sri

From: Tim Cappalli <Tim.Cappalli=[email-masked]>
Date: Thursday, December 10, 2020 at 1:18 PM
To: "Eric Vyncke (evyncke)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Sri Gundavelli (sgundave)" <[email-masked]>
Subject: Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?

Sri

Hope it helps

-éric

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 11 Dec 2020 11:14:28 -0600

Folks,

On Fri, Dec 11, 2020 at 11:05 AM Sri Gundavelli (sgundave) <sgundave=
[email-masked]> wrote:

>
>    - That's one of the reasons I think this issue is being a bit
>    overblown. There are solutions, and have been for a number years. People
>    need to implement them :)
>
>
>
> I agree to most part.
>
>
>

At this point, I think it is more productive to propose ways to enable what
Eric suggested.

Behcet

> Sri
>
>
>
> *From: *Tim Cappalli <Tim.Cappalli=[email-masked]>
> *Date: *Thursday, December 10, 2020 at 1:18 PM
> *To: *"Eric Vyncke (evyncke)" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Sri Gundavelli (sgundave)" <[email-masked]>
> *Subject: *Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?
>
>
>
> That's one of the reasons I think this issue is being a bit overblown.
> There are solutions, and have been for a number years. People need to
> implement them :)
> ------------------------------
>
> *From:* Madinas <[email-masked]> on behalf of Sri Gundavelli
> (sgundave) <sgundave=[email-masked]>
> *Sent:* Thursday, December 10, 2020 4:07:40 PM
> *To:* Eric Vyncke (evyncke) <evyncke=[email-masked]>;
> [email-masked] <[email-masked]>
> *Subject:* Re: [Madinas] MADINAS 2nd BoF at IETF-110 ?
>
>
>
> between the endpoint and the network, can the randomization be done in a
> coordinated manner, without leaking PII elements?
>
>
>
> Sri
>
>
>
>
>
> *From: *Madinas <[email-masked]> on behalf of "Eric Vyncke
> (evyncke)" <evyncke=[email-masked]>
> *Date: *Thursday, December 10, 2020 at 12:46 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Madinas] MADINAS 2nd BoF at IETF-110 ?
>
>
>
> After a good first BoF, I wonder whether the MADINAS participants (and
> especially the chairs and presenters of the first BoF) want to have a 2nd
> BoF that could potentially be WG forming.
>
>
>
> See https://datatracker.ietf.org/meeting/important-dates/
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2Fimportant-dates%2F&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C52c9e7aefd014822894c08d89d4fa86f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432312746584924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=s8o%2BOWBW6Vt%2BTkdDw9gYKWgOsyzuka9MLRBNSsWouoc%3D&reserved=0>
> for the dates
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.tools.ietf.org%2Fbof%2Ftrac%2Fwiki%23TimeframeIETF110Online&data=04%7C01%7Ctim.cappalli%40microsoft.com%7C52c9e7aefd014822894c08d89d4fa86f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432312746584924%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=i1Hg3zTxYcDSbXlsUDLnH7MqS3xb1kkxO7QV8BpbNmo%3D&reserved=0>
>
>
>
> Hope it helps
>
>
>
> -éric
> --
> Madinas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/madinas
>