Subject: Re: [Geopriv] Comments on draft-ietf-geopriv-policy-uri-00

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 6 May 2011 08:12:41 +0800

Thanks for the review Ben.

Comments inline.

Cheers
James

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Friday, 6 May 2011 9:21 AM
> To: [email-masked]; 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.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 6 May 2011 09:20:48 +0800

> > [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.
> >
> >
> 
> I think we are on the same page here, but I want to emphasize I'm talking
> about the referenced policy document, not the policy URL. So as long as,
> for every new location URI you get a new policy URI and a new policy
> _document_ that only applies to that particular URI pair, then I think
> it's fine.
>
[AJW] Thanks for making the distinction, and I think we probably need to make it clear that this is a mutual one to one relationship. A policy URI is associated with at most one policy document, and a policy document is identified by only one policy URI.

> > [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.
> >
> 
> Your residential gateway example is probably more compelling than my
> stolen device example.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 6 May 2011 09:40:26 +0800

On 2011-05-06 at 10:52:16, Ben Campbell wrote:
> 
> On May 5, 2011, at 7:12 PM, Winterbottom, James wrote:
> 
> >> 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.
> >
> >
> 
> I think we are on the same page here, but I want to emphasize I'm 
> talking about the referenced policy document, not the policy URL. So 
> as long as, for every new location URI you get a new policy URI and a 
> new policy _document_ that only applies to that particular URI pair, 
> then I think it's fine.

I find that it's helpful to distinguish between the resource and the thing that identifies it.  In all these cases, it is actually a new _resource_, not just a new identifier.  Naturally, that means a different identifier.

--Martin

---

From: Ben Campbell <[email-masked]>
Date: Thu, 5 May 2011 18:20:57 -0500

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?

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

Specifics Comments:

-- Section 3, Note: "...Location Server is also a Rule Holder."

Do you mean to require the rule holder and LS to be collocated? I assume not since this is about as non-normative of a statement as you can make.

Editorial Comments:

-- idnits complains about some outdated draft references. I assume those will all get fixed just-in-time

-- Section 1, paragraph 3: "...inform the Location Server with policy..."

... of policy? 

-- Section 3.2, first paragraph, last sentence: "...MUST be different to the location URI"

different "than"?

-- section 6, Acknowledgments

Any reason not to put this closer to the end? I don't know if it's wrong per SE, but it seems odd to find it in the middle.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 5 May 2011 19:52:16 -0500

> [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 d…

I think we are on the same page here, but I want to emphasize I'm talking about the referenced policy document, not the policy URL. So as long as, for every new location URI you get a new policy URI and a new policy _document_ that only applies to that particular URI pair, then I think it's fine.

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

Your residential gateway example is probably more compelling than my stolen device example.