 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
I was thinking of a simple practical example.
I have a closed private/enterprise network with a bunch of location client devices to my LIS. My LIS has access to the bridge MIBs on all the switches in the building(s) and it has the wiremap that relates each switch port to the location of the wall jack or area of coverage of the wireless access point to which that port is connected. So – given a MAC address, the LIS can determine the associated switch/port and corresponding location by performing the bridge MIB query on the switches followed by a wiremap look up.
In this network the DHCP implementation is limited; it doesn’t support the DHCP lease query for example… and the IT department refuses to change or permit it to be patched to support the functionality. So, I’m stuck, not being able to translate the IP address of my requesting clients into the corresponding MAC address that allows me to provide them with location.
Now there are absolutely no interesting scenarios in this environment where anybody cares or is in any way at risk if a client offers a MAC address that isn’t its own. It’s simply not a problem.
In this particular trust arrangement, it’s acceptable for the LIS to return the location to the requester. This is a real situation; not just a hypothetical one.
Trust always involves nominating where risk is considered acceptable. Even if the DHCP server wasn’t so “challenged”, the LIS still has to trust the information acquired from it. In principle the DHCP server could be compromised… or have devious intent. In order to obviate this concern, the trust arrangement has to encompass the DHCP server as well.
Cheers,
Martin
From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, 8 November 2009 4:38 PM
To: fluffy at cisco.com; geopriv at ietf.org
Subject: Re: [Geopriv] Serious concerns about security of draft-ietf-geopriv-held-identity-extensions
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
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv