Subject: Re: [Geopriv] HELD Dereference: Draft Update

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 01 Jul 2008 23:08:34 +0300

Hi James,

thanks for the timely response.

James M. Polk wrote:
> 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
>> * re-written the authorization model section
>
> 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.

I thought that my description is inline with draft-barnes-geopriv-lo-sec 
and it is fine to call the End Host that receives the Location URI with 
the Location Configuration Protocol the Target in this case.

I do, however, believe that we might want to discuss the case of LbyR 
distribution via the Location Configuration Protocol in 
draft-barnes-geopriv-lo-sec as well.
Currently, only the LbyV is covered.

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

The entire communication between the Location Information Server (a 
special form of Location Server), the Target and the Location Recipient 
is, in Richard's document, just a dissemination channel.

>
> Location seekers seek. Location Targets have their location sought.

The location seeker terminology is gone. The Location Generator, btw, is 
also just a special form of a Location Server.

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

How should a URI have any information of the history regarding where it 
came from?

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

I made a mistake -- wrong reference.

This sentence should point to reference [4] rather than [14].

   [4]   Marshall, R., "Requirements for a Location-by-Reference
         Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work in
         progress), February 2008.

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

Actually, if the body of the document gives that impression than I need 
to work on it. There is always server-side authentication. However, the 
LIS needs to decide whether it also wants to run client-side 
authentication as well.

This is not different than HTTP; where you are given a URL and that URL 
may require client-side authentication or maybe not. The decision 
whether client side authentication is required is a decision the Target 
makes by providing the policies.

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

The Target decides what it wants. For example, I might want to provide 
my location only to my presence server where all my detailed 
authorization policies are located. I can, for example, do this by 
uploading authorization policies that contain identity based conditions 
(namely the presence server's identity) or I could create a reference 
that I only make available to my presence server.

Further access to my location info is the controlled via the presence 
server in the usual fashion.

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

[14] is not a normative reference. I could mention the additional 
security benefits -- that would be good writing practice.

For example, it might make more sense to use the following paragraph:

"
   Furthermore, the ability of the Rule Maker
  to put constraints on the dereferencing step, as described in [14],
  provides the ability to restrict how often
   location can be accessed through a location URI, how long the URI is
   valid for, and the type of location information returned when a
   location URI is accessed.
"

Does that sound better?

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

The Rule Maker can always decide whether it wants to put some 
authorization policies in place or not. This is no different from the 
presence authorization model. If I happen to include a rule that 
provides information to everyone then my policies did not provide a lot 
of "protection".

This is no different. The Rule Maker can decide what it wants todo --- I 
can use authorization policies or it can omit them.

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

It is true that the URI itself does not carry meta data. However, when 
the reference is conveyed using  SIP Location Conveyance then this 
reference may carry meta data. When it is carried with a protocol that 
does not provide this property then this obviously does not work.

>
> 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.
This is no different than passing around location by value where you 
might hand it out to everyone or only selectively.

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

I believe that this is a very practical model. An option that should be 
allowed.
In fact, one can easily come to a possession model with the help of the 
access control model. The trick is to upload policies that provide a 
response to everyone who asks; you just omit the identity condition.

As such, we already allow this functionality with our previous presence 
work as well.

Do you see strong warning signs with the presence authorization RFC?

The issue is that most of the stuff we are talking about is really about 
policies -- not really about new protocol mechanisms as such.

Ciao
Hannes

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

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