Comments inline.
Cheers
James
> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: Friday, 6 May 2011 9:21 AM
> To: draft-ietf-geopriv-policy-uri.all@tools.ietf.org; GEOPRIV
> Subject: Comments on draft-ietf-geopriv-policy-uri-00
>
> Hi,
>
> Here are some WGLC comments on draft-ietf-geopriv-policy-uri-00. Please
> note that, like some others commenting, that I have not followed this
> draft prior to Richard asking if I could review it. I did a brief scan of
> the recent emails, but I apologize in advance if I beat any dead horses,
> ask questions that have already been answered, or show complete ignorance
> of the location conveyance architecture.
>
> General Comments
>
> 1. I find the document very readable and understandable. That's
> refreshing, given the potential complexity of the problem space :-)
>
> 2. I share some of the concerns about possession of a policy URI equaling
> authorization. I think the draft does a good job of discussing the
> security considerations of handing around a shared secret like this. My
> principle concern is the implied assumption that anyone with access to the
> device is automatically a rule maker. I realize there might not be much
> choice, given that someone with control of a device probably knows where
> that device is and could tell anyone he wants. But some use cases:
>
> -- My kid has a phone with location functions. Can he turn of my (his
> parent's) access?
> -- A thief has _my_ phone. Can he turn off my ability to track it? (short
> of turning it off, of course)
>
> Now, I realize those are mostly client behavior questions, not protocol
> issues--I just want to make sure they've been thought through. And my
> concern here is very much affected by my next concern
>
> 3. The draft talks quite a bit about the lifetime and validity of policy
> URLs. But (unless I missed it) it doesn't say as much about the scope and
> lifetime of the policy documents referenced by such URLs. I think, in
> order to get the security properties I think you contemplate for the
> policy URIs, you must have a distinct policy object for each URI. That is,
> two policy URIs for the same device are not aliases for the same policy
> document. If the policy docs are the same, it's just a coincidence, and
> changing one does not affect the other. Furthermore, each policy doc is
> only meaningful for the Location URI associated with the policy URI. If
> the LS mints a new Location URI and associated Policy URI, the referenced
> policy document is always a _new_ one set to the "default policy". Is this
> the idea?
[AJW] Yes this is the idea. Take a residential broadband situation for example, all device behind a residential gateway performing NAT will appear the same the LS, but clearly there maybe several different devices. In this case each time a new location URI is requested, a new policy URI is minted. Certainly I don't want my daughter changing my policy.
> My concern is that if an attacker somehow gets ahold of a policy URL,
> perhaps by gaining physical access to my device, he can't make
> _persistent_ changes to policy. (I'm assuming for the sake of argument
> such access doesn't also give him access to change the "default")
[AJW] I can't speak for the other authors, but I confess that I had not given much thought to stolen or hacked devices. The Policy URI is minted at the same time as the location URI, so to my mind these two things are linked. Having a persistent policy after the location URI has expired doesn't make a lot of sense to me, especially if the policy server doesn't have a real user of device identity associated with it beyond a URI. So maybe I am missing the point, but I am a little confused about what the actual concern is here.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
