Re: [STDS-802-11] ranging privacy presentation 11-19-0898r0
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Chris,
On 5/15/19, 3:25 PM, "chartman@xxxxxxxxx on behalf of Chris Hartman" <chartman@xxxxxxxxx> wrote:
>
> Hi Dan,
>
> Thanks for your feedback!
>
> I’m not a security expert, so please let me know where I’m going off the rails. With that caveat, let me try to address the points you bring up in your email.
>
> I’d argue that the security case is different from ranging. In the security case, an AP cannot provide secure service to some STAs if it does not require it of all STAs. In >the ranging case, there is nothing that prevents an AP from providing this service to those STAs that are willing to share their location, as well as to those that wish to >not do so. Also to get network access, a user may be willing to provide authentication information, but not be willing to be tracked.
Yes, that's a good point. So are you willing to remove the I2R_LMR_NOT_REQUIRED bit in the extended
capabilities from your proposal since it acts as a global switch on an AP/RSTA?
> Also, with regard to authentication, I’d argue two (somewhat related) points:
> - It is my understanding that the STA does not give up its identity to the AP, but rather to the AAA server, which operates at a higher layer.
> - Also, the STA typically has some certificate that is installed with explicit consent of the end user, while the STA also has an opportunity to authenticate the network.
I didn't say authentication was identical to this case, just pointing out that the issues that were being asked in
the straw polls were worded in such a way to make it look as if this sort of thing had never been done before
when it's actually done all the time.
> It is my contention that STA location information should similarly be shared at a higher layer, since it’s all but impossible to identify a generic network by the >information that an AP can provide, and thus it is all but impossible to get end user consent to share this type of information at the MAC layer.
I hear that user consent to engage in this FTM exchange is required but I haven't heard why. Since you are randomizing
MAC addresses pre-association there are no privacy implications of emitting a finer location to an AP. The AP learns that
some thing out there that it already knows about (through the thing's other emissions) is within 1m from some location
instead of within 3m of some location. That's it. There are no privacy implications to this. And when your device changes
its MAC address again even that bit of knowledge is lost.
[Please don't say "GDPR". That is being used as a cudgel the way that Sarbanes-Oxley was a decade ago. In a former
company I asked IT why they decided I needed to change my password every 6 weeks now. "It's a Sarbanes-Oxley
requirement" was the answer. Of course there is nothing in Sarbanes-Oxley on the frequency of password changing,
it's just the trump card that makes any losing hand into an instant winner. "Sorry, this is required by GDPR" is the new
version.]
But if you feel it is necessary to get user consent then add a little checkbox widget in the settings to enable this
feature, leave it unchecked by default. Voila. If you are unwilling to make that little change to your UI then it seems
like your devices will NEVER offer up this information. You will always ask for information from the AP to improve
your knowledge but deny the AP the ability to improve its knowledge. That's not right.
regards,
Dan.
> Regards,
>
> Chris
>
> On May 15, 2019, at 1:07 PM, Harkins, Daniel <daniel.harkins@xxxxxxx> wrote:
>
> --- This message came from the IEEE 802.11 Working Group Reflector ---
>
> Hi Chris,
>
> Thanks for facilitating discussion. I have a conflict with PM1 today so I may not be able to be in the room
> when TGaz discusses this but I will make an effort to attend AM1 and PM2 tomorrow.
>
> With respect to the two issues raised in your presentation:
>
> 1. Should the execution of an 802.11 protocol be contingent on willingness of users to surrender their privacy?
> 2. Can a device declaring support of a feature refuse to execute the mandatory part of the feature solely because
> its communication peer doesn’t activate an optional part of the feature?
>
> I think we already have existence of an 802.11 protocol that answers yes to both of those: authentication. In
> order to authenticate yourself you must give up your identity and the privacy implications of giving up your identity
> are considerable. And yes, an AP can have policy that says "if you don't surrender your identity to me then you don't
> get access to the network."
>
> So I don't see the desire for reciprocity in location information being debated in TGaz as breaking new ground on
> that front.
>
> regards,
>
> Dan.
>
> On 5/15/19, 9:41 AM, "Chris Hartman" <00000da8c189cf4b-dmarc-request@xxxxxxxx> wrote:
>
> --- This message came from the IEEE 802.11 Working Group Reflector ---
>
> All,
>
> Even though we did not get a chance to present at the mid-week plenary, we request you to read the document 11-19-0898-r0, and we invite you to participate in the discussion in TGaz.
>
> The next TGaz session will be today, PM1 in Highland Ballroom IV/V – lobby level. There are additional sessions on Thursday AM1, Highland Ballroom I/II – lobby level, and Thursday PM2, Highland Ballroom I/II – lobby level.
>
> Regards,
>
> Qi and Chris
>
> _______________________________________________________________________________
>
> If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
>
> Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
>
> If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.
>
> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
> _______________________________________________________________________________
>
>
> _______________________________________________________________________________
>
> If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
>
> Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
>
> If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.
>
> Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
> _______________________________________________________________________________
_______________________________________________________________________________
If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.
Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.
If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________