the distinction between "LCP" and "LCP-like" seems unnecessary.
Whenever it's used, the LCP policy requires authentication that the
requestor is the target of the requested location. When the identifier
is identified by IP address (as in DHCP and (base) HELD)
return-routability provides sufficient authentication; this document
just requires the equivalent for other identifiers.
--Richard
geopriv issue tracker wrote:
> #19: Distinguish identity cases as being LCP-like, not LCP
> ---------------------------------------+------------------------------------
> 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.
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
