It has been awhile in coming, but I've taken a look at the new text
you suggest and also a look back at the rest of the text of identity-
extensions. I have some thoughts below about how to clarify the
effects of identity extensions in the context of the current
discussion about what LCPs and "LCP policy" are and are not. I don't
think this document can be written without mentioning LCPs or LCP
policy, but on the other hand I've made some recommendations for how
to make it clearer that HELD with identity extensions implemented is
not an LCP.
Thoughts?
Best,
Alissa
== Section 1 ==
> In a location configuration protocol (LCP), the location
> being requested is the requestor's location. This fact can make
> the
> problem of identifying the Device simpler for LCPs,
s/simpler/simple
> An important characteristic of this addition to the HELD protocol is
> that it also expands the potential scope of HELD beyond that of an
> LCP. The scope of an LCP is limited to the interaction between a
> Device and a LIS. That is, an LCP is limited to the Device
> retrieving information about their own location. With this
> addition,
> authorized third party location recipients (LRs) are able to make
> requests that include identifiers to retrieve location information
> about a particular Device.
Replace with:
An important characteristic of this addition is that the HELD protocol
with identity extensions implemented is not considered an LCP. The
scope of an LCP is limited to the interaction between a Device and a
LIS, and LCPs can guarantee the identity of Devices without additional
authorization checks. Neither of these is true for HELD with identity
extensions. Furthermore, identity extensions allow authorized third
party location recipients (LRs) to make requests that include
identifiers to retrieve location information about a particular Device.
> The usage of HELD for purposes beyond the Device-LIS interaction
Replace with: The usage of HELD identifiers
== Section 1.1 ==
> The use of additional identifiers in HELD falls into two categories.
> A Device can use these parameters to provide additional
> identification information to a LIS. Identification information,
> such as the MAC address of the interface card of a Target, can be
> used to reduce the time required to determine the location by a LIS.
> In other cases, a LIS might require Device identification before any
> location information can be generated.
> A third party LR can be granted authorization to make requests for
> a given Device. In particular, network services can be permitted to
> retrieve location for a Device that is unable to acquire location
> information for itself (see Section 6.3 of [I-D.ietf-ecrit-
> phonebcp]). This allows use of location-dependent applications -
> particularly essential services like emergency calling - where
> Devices do not support a location configuration protocol (LCP) or
> they are unable to successfully retrieve location information.
Replace with:
The use of additional identifiers in HELD falls into two categories:
1. A Device can use these parameters to provide additional
identification information about itself to a LIS. [leave remaining
para as is]
2. A third-party LR can be granted authorization ... [leave remaining
para as is]
== Section 5 (based on text suggested below) ==
> 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".
Replace with:
Location configuration protocols make use of an authorization model
known as "LCP policy," which permits only Targets to be the recipients
of their own locations.
== Section 5.1 ==
I think Section 5.1 should be about Target requests, and section 5.2
should be about third-party requests. That is the order that the two
are in for the entire document, so no sense in switching them in this
section.
I would recommend naming section 5.1 "Target Requests" or "Targets
Requesting Their Own Locations."
> 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.
Replace with:
When a Target uses identity extensions to obtain its own location,
HELD can no longer be considered an LCP. The authorization policy that
the LIS uses to respond to these requests must be provisioned by one
or more Rule Makers. In the case that the LIS exclusively provides
Targets with their own locations, the LIS can still be said to be
following the "LCP policy." In all cases, the Geopriv security and
privacy considerations [I-D.ietf-geopriv-arch] are applicable.
> 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.
I don't understand what this means. All aspects? Some aspects? If so,
which ones?
> 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.
Replace with:
The spoofing protections provided when using HELD with identity
extensions to provide Targets with their own locations differ from the
protections inherent in an LCP. For LCPs, return routability is
considered
sufficient protection against spoofing.
> 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
Replace with:
If identifiers are not identical, the use of HELD identity
extensions to provide Targets with their own locations could be
exploited by an
attacker.
For example, it is not appropriate to provide Targets with their own
locations under these terms
== Section 6 ==
> These protections apply to both LCP requests and the requests made
> by third parties.
Replace with:
These protections apply to both Target requests for their own
locations and requests made by third parties.
== Section 6.2 ==
Again, I would leave the old order (Target requests first) and call
this "Target Requests" or "Targets Requesting Their Own Locations."
> 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.
Replace with:
Requests made by a Device for its own location are
covered by the same set of protections offered by HELD. These
requests might be limited by an authorization policy similar to the
"LCP policy"
that permits only a Target with access to location information
about itself.
== Section 6.3 ==
> Requests from third parties have the same requirements for server
> authentication, confidentiality and protection from modification as
> LCP requests.
Replace with:
Requests from third parties have the same requirements for server
authentication, confidentiality and protection from modification as
Target requests for their own locations.
On Sep 16, 2009, at 9:38 PM, 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.
>
> --
> 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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
