Subject: [Geopriv] HELD Dereference: Draft Update

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 29 Jun 2008 19:12:39 +0300

Hi all,

I have updated the HELD Dereference draft based on the feedback we got 
at the GEOPRIV interim meeting. In particular, I have
* re-written the authorization model section
* fixed the examples; they were indeed a bit messed up as discovered 
during my presentation at the interim meeting.
* adjusted the rest of the document

Here is a snapshot:
http://www.tschofenig.priv.at//svn/draft-winterbottom-geopriv-held-http-using-protocol/draft-winterbottom-geopriv-deref-protocol-01.txt

I will resubmit the document after a bit of proof-reading.

A couple of folks did not like the content of the security related 
sections of the previous document. Let me know if you like it better now.
Section 3 is probably the most important one to look at.

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 01 Jul 2008 02:45:37 -0500

At 11:12 AM 6/29/2008, Hannes Tschofenig wrote:
>Hi all,
>
>I have updated the HELD Dereference draft based on the feedback we 
>got at the GEOPRIV interim meeting. In particular, I have

IMO - any way you want to spin section 3.1, bullet #2, you are *not* 
talking about a target, you are talking about a Location Recipient, 
and the text ought to treat the recipient of a locaitonURI as a 
Location Recipient.

the Target does request for location, the target *may* hand out 
location if it is a Location Generator, but it cannot get a location 
from another entity.  This document is confusing the function an 
entity is performing with who is asking for the location.

Location seekers seek. Location Targets have their location sought.

If the entity that is seeking location is a target, then it is an LR 
*in that function being performed*, regardless of the protocol used 
in that function.

In the Security Considerations section 6, they fail to account for 
security of possession

6. Security Considerations

   This document assumes that the use of TLS to protect HTTP is
   sufficient to protect the privacy of the PIDF-LO content while in
   flight. When access control at the LIS is not applied, as described
   in Section 3.1, then the possession of the location URI is equal to
   the possession of location information.

This is not a security consideration, this is a warning - but not 
written as a warning.  This is a gap, a hole in the design of the 
possession model. Because there are zero considerations in the 
locationURI itself to know if it has been passed to another party, 
there can be no knowledge if this URI was learned when it should not 
have been.  This is not mentioned in this section - and must be.

    When the requirements for
   creating a location URI, as described in [14], are met,

This is making an individual draft a normative reference, which 
cannot be - without this document relinquishing its independent 
status, and becoming dependent on ref [14] to be published 
concurrently or prior to this document being published (because 
what's in that other do must be understood in order to accomplish 
this security consideration.

But the body of this document states clearly that only server side 
authentication is needed (and no client side authentication is 
attempted), which is not mentioned in this security considerations 
section either, which is bad.

    then the
   reference provides sufficiently high security guarantees for most
   location-based applications.

I don't understand how this can be true. What device can't meet 
server side authentication of TLS? If there really are no devices 
that are thus contrained, then is this really a security mechanism 
for a possession model? IMO no

    Furthermore, the ability of the Target
   to put constraints on the dereferencing step, as described in [14],
   provides additional security properties.

this document should not be referenced normatively (i.e., unless an 
implementor really understands this reference, one fails to gain the 
benefits of this added functionality - which is the rule of normative 
references, and clearly stated here by saying "...provides additional 
security properties." This is not a valid claim within this document.

    If this is still not
   sufficient then the Target is able to put authorization policies
   either to the LIS or uploads the Location URI to a presence server
   that hosts authorization policies, as described in [15].

IMO this last part is applying security properties to something that 
is void of any security properties as long as the possession model is 
allowed.  What header or URI parameter limits redistribution? That's 
what this is attempting to limit, right?

How can I know that who is asking for my locationURI, under the 
possession model will not pass this URI along?  At least the 
Geolocation header value within Conveyance incorporates a specific 
header parameter to attempt to limit any damage.  Unless I've missed 
a header parameter that limits visibility somehow to anyone that 
possesses it (which I have  not seen to date) - this URI here from section 5
https://lis.example.com/357yc6s64ceyoiuy5ax3o

might as well be freely handed out to everyone, because merely 
learning it by accident gains knowledge of exactly where someone is - 
with their identity.

There isn't even sufficient warning about this possibility in this doc.

I fail to see how this can ever get through the IESG

I recommend the possession model be deprecated from this, and other 
documents within this WG.