>> 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.
>
>
>> 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.
>
Your residential gateway example is probably more compelling than my stolen device example.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
