---------------------------------------+------------------------------------
Reporter: martin.thomson@andrew.com | Owner: martin.thomson@andrew.com
Type: defect | Status: new
Priority: major | Milestone:
Component: held-identity-extensions | Version:
Severity: Active WG Document | Resolution:
Keywords: identity lcp |
---------------------------------------+------------------------------------
Comment(by martin.thomson@andrew.com):
= Proposed changes summary =
I've taken some of this from the current debate on identity. I think that
this addresses the shared concerns without falling into the traps that
Richard identified. It's somewhat generic guidance, but I think that it
hits the all the necessary points.
This primarily affects Section 5 ([http://tools.ietf.org/html/draft-ietf-
geopriv-held-identity-extensions-00#section-5 Privacy]). Section 5.2 is
largely rewritten with this goal in mind.
Minor changes also in Section 6.2 ([http://tools.ietf.org/html/draft-ietf-
geopriv-held-identity-extensions-00#section-6.2 Security/LCP]).
== 5 Privacy ==
''Unchanged text; minor editorial/stylistic change in the note, which will
likely be removed once the geopriv-arch document is updated with the
Device/Target clarifications''
The authorization model for a location configuration protocol assumes
that
the LR is also the Target, and that providing that LR with information
about its own location is allowed. We call this property "LCP policy".
In effect, an LCP server (that is, the LIS) follows a single rule policy
that states that the Target is the only authorized Location Recipient.
Note: HELD explicitly states that the Target is a Device and not a
person. When discussing privacy, Targets other than a Device have a
stake in protecting privacy. Therefore, the more general term of
Target - any potential subject of location information - is used in
place of Device.
=== 5.1 Third Party Requests ===
''Unchanged text, moved from the bottom of the old Section 5''
The LCP policy does not allow requests made by third parties. If a LIS
permits requests from third parties using Device identity, it assumes
the
rule of a Location Server (LS). As a Location Server, the LIS MUST
explicitly authorize requests according to the policies that are
provided
by Rule Makers, including the Target. This includes authentication of
requesters where required by the authorization policies.
An organization that provides a LIS that allows third party requests
must
provide a means for a Rule Maker to specify authorization policies as
part of the LIS implementation (e.g, in the form of access control
lists). Authorization must be established before allowing third party
requests for the location of any Target. Until an authorization policy
is established, the LIS MUST reject requests by third parties (that is,
the default policy is "deny all").
When the LIS is operated by an access network, the relationship between
the Target and the LIS can be transient. However, the process of
establishing network access usually results in a form of agreement
between the Target and the network provider. This process offers a
natural vehicle for establishing location privacy policies.
Establishing
authorization policy might be a manual process, an explicit part of the
terms of service for the network, or an automated system that accepts
formal authorization policies (see [RFC4745], [RFC4825]). This document
does not mandate any particular mechanism for establishing an
authorization policy.
=== 5.2 Location Configuration-like Requests ===
''Changed text''
When Device identity is used, the "LCP policy" not applicable when
identity information is provided. The Geopriv security and privacy
considerations [I-D.ietf-geopriv-arch] are applicable.
A policy that is similar to the LCP policy might be appropriate if the
Device identity provided can be determined to be the same as the
authenticated requester identity. A Rule Maker, in setting local
policy,
might choose to permit such a request based on similar basic
motivations.
Aspects of the security and privacy considerations of the base HELD
protocol [I-D.ietf-geopriv-http-location-delivery] are applicable if an
LCP-like policy is used. Issues related to construction of the PIDF-LO
document and the security protections provided by transport are
identical.
The spoofing protections provided when using LCP-like policy differ from
an LCP policy. In the LCP policy return routability is considered
sufficient protection against spoofing. A similar degree of assurance
is
required if a similar policy is to be used.
A Rule Maker might require additional verification that the identifier
is
owned by the requester. Verification that depends on return routability
can only provide weaker assurances than those provided by return
routability; therefore, policy might require the use of additional,
independent methods of verification.
Care is required where a direct one-to-one relationship between
requester
and Device identity does not exist. If identifiers are not identical,
then the existence of an LCP-like policy could be exploited by an
attacker.
For example, it is not appropriate to apply LCP-like policy under
these
terms where a requester is authenticated by NAI and the supplied
Device
identity is a MAC address, even if that MAC address is currently
registered with the network under the given NAI. In this case, the
requester might be requesting from a different MAC address registered
under the same NAI. The correct way of gaining authorization is to
establish a policy that permits this particular request as a third
party request.
== 6.2 Location Configuration Protocol-like Requests ==
''To retain consistent ordering, this will be switched with Section 6.3
(Third Party Requests)''
Requests made by a Device in the context of a LCP-like requests are
covered by the same set of protections offered by HELD. LCP-like
requests might be authorized under a policy similar to the "LCP policy"
that permits a Target access to location information about itself.
''Unchanged''
Identity information provided by the Device is private data that might
be
sensitive. The Device provides this information in the expectation that
it assists the LIS in providing the Device a service. The LIS MUST NOT
use identity information for any other purpose other than serving the
request that includes that information.
--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/19#comment:1>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
