I've taken a sweep through and each of these represents an improvement. Apart from some very minor editorial changes, I've taken all these proposals verbatim.
I'll post an update to the draft shortly, after responding on the other issue.
Thanks,
Martin
> -----Original Message-----
> From: Alissa Cooper [mailto:acooper@cdt.org]
> Sent: Sunday, 11 October 2009 6:41 AM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] [geopriv] #19: Distinguish identity cases as
> being LCP-like, not LCP
>
> Martin,
> 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
> >
>
>
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
