 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
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 at cisco.com > Date: Sun, 8 Nov 2009 13:28:23 +0900 > To: geopriv at 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 at ietf.org > https://www.ietf.org/mailman/listinfo/geopriv |