I have a slightly different perspective on this issue. Richard
and I just discussed this briefly and came to a different viewpoint that
matches with Hannes’ prior expressed opinion.
I tend to see identity parameters in the first-party/LCP case as
being superfluous, but harmless. There is no benefit in preventing the use of
identity in first-party/LCP requests. There are almost always mechanisms where
the identifier provided could be determined by other means (as cited). For
instance, there are many ways by which an IP-MAC linkage can be determined; there
are simple means in 3GPP for their identifiers; and so on.
These mechanisms could, in the case where an identifier is
provided, be used to authenticate the identity and authorize a request under
LCP terms. If a LIS implementation chooses to allow this, and authenticate by
using these mechanisms, then applying the LCP policy as described is acceptable.
--Martin
From: geopriv-bounces at ietf.org
[mailto:geopriv-bounces at ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, 8 November 2009 2: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
