We've had some discussion on this topic before. The answer probably involves
one or more of the following:
1. Use within an architecture (such as that being discussed in the IEEE 802
Emergency Services Study Group) in which the LIS is only one hop from
the client. In that case, the LIS would know that the MAC being requested
is the same as the originator of the request.
2. Use within an architecture (such as WiMAX or 802.1ar) in the HELD server
could potentially verify that the MAC address being requested corresponds
to the MAC address in the client certificate, and that the client certificate
chains to a pre-established trust anchor.
3. Where the MAC being requested cannot be verified, the LIS could only provide
responses to queries for a set of pre-arranged MAC addresses
for whom location is already made publicly available via existing LCPs.
For example, LLDP-MED and IEEE 802.11k provide geospatial
coordinates corresponding to AP or switch ports. 11k and LLDP frames
are neither authenticated nor encrypted and are available to any host
with access to the medium; as a result, this information can be
considered public.
> From: fluffy@cisco.com
> Date: Sun, 8 Nov 2009 13:28:23 +0900
> To: geopriv@ietf.org
> Subject: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions
>
>
> I really hope we get some discussion on this at this meeting. Take for
> example using a MAC address as an identifier. A request arrives and
> requests the location of device with a given MAC. How does the server
> know if it should answer this or not? If it has an IP to MAC mapping,
> why did it need the MAC, and why not use use IP.
>
> I don't think the answer can be it knows due to something that will
> described some time later. That answer seems like it would not meet
> the IETF goals of security that can be implemented (even it it is not
> used) or the general charter of this WG.
>
> I don't understanding how the privacy part of this is protected. I
> need to understand that or I worry that this work is not appropriate
> for geopriv WG.
>
> Cullen <in my RAI AD role>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
