Subject: [Geopriv] Comments on draft-barnes-geopriv-lo-sec-05 (part 3: Section 4+)

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Mar 2009 00:58:42 -0500

Author consortium,

As you might expect, this document is taking a while to review.  It's been a long week, so I apologise, I think I'm starting to come unhinged.

No highlights here.

Section 4.1

The consequence of the second is not that location servers are impaired - the real problem is that the privacy cannot be effectively safeguarded.

Section 4.1.1

Major omission here.  There is no mention of a technique that is extensively used.  That is, the use of an unlinked pseudonym, generated by LG or LS that effectively means that no identification information is tied to the location information.  There is still be possibility of a binding being made external to the LO, such as through the conveyance protocol (e.g. the From header in SIP indicates the associated identity).  I note (much later) that this appears in passing in Section 4.4.

I believe that the above is the only feasible approach, so it's a shame that no mention is made of it.  However, this only shifts the focus of techniques used to prevent attacks like Location Theft.

Section 4.2 

The parenthetical in the Rule Maker's assurances should be promoted to real text, just drop the parentheses and the "Note that".  <vspace blankLines="1"/> is your friend.

If you take the suggestions I made in part 2, then the Location Generator can be relegated to dumb animal status again and it only needs to become smart when it decides it wants to be an LS.  No need for it to have a stake in any of this aside from ensuring that the initial binding is correct - but that's a responsibility, not a required assurance.  The only impact that an error might have is on its reputation.

Section 4.3

This section mentions distribution for entities that have a "trust relationship" for the purposes of routing.  An important note here is that the intermediaries are only routing the location object, they should not be actual location recipients unless they are authorized.

I like Section 4.4.

Section 5.1

Move the LS decision to the distribution step, i.e.:

  O Positioning: Target-based, Target == LG
  O Distribution: Target becomes LS, HTTP UA -> web service, LO contains all rules
  O Receipt (Use): Web services uses location information to generate response.  No retransmission or retention.

I'd like to see the first key point properly blessed in earlier text (as I commented earlier).

Section 5.2

XMLHttpRequest isn't necessarily the only way to move the information - the information might just be used to fill defaults in a form.  We just have to ensure that there are fields for the privacy rules at the same time as lat/lng.

There are two distribution hops here if we have a separate LG (don't use "positioning server").  The first hop uses LCP policy, the second uses a policy provided by the Target-Rule Maker.  You've argued that moving from the page to the server isn't distribution, which comes off as sophistry.  That doesn't mean that it's wrong, maybe you are just over-analysing.

It's important to note that transmissions of location information that are considered "internal to an LR" can only be if the transmission is adequately protected - through the application of authentication and confidentiality protections.

Section 5.3 and 5.4 will have to await review - my patience just ran out.  So my last comment is: this document is a little too long.

Cheers,
Martin

------------------------------------------------------------------------------------------------
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]