effectively providing a value by reference -- then there's no reason
to have a policy URI. You just wouldn't do it.
Adding a policy URI does introduce another attack vector. However, if
the client doesn't trust the local network to be secure enough, he can
always irrevocably kill the URI by sending a DELETE request.
--Richard
On Jul 30, 2010, at 2:50 PM, Hannes Tschofenig wrote:
> Hi Richard,
>
> I have my doubts that this mechanism gets used for the DHCP based
> solution.
>
> DHCP does not provide confidentiality protection as a built-in
> feature. As Marc mentioned in response to issue#23 (see http://trac.tools.ietf.org/wg/geopriv/trac/ticket/23)
> I raised every target would be given the exact same location
> information on a shared medium. So, this is draft-ietf-geopriv-
> rfc3825bis.
>
> Note: The draft that was forwarded to the IESG does not point out
> this important security aspect, I believe.
>
> If you don't make the same assumption for the DHCP-URI draft then
> you suddenly allow others to modify your policies. This would be
> really bad.
>
> If you make the assumption that everyone on a shared medium gets the
> same pointer to location and also pointer to policy then you still
> allow others to modify the policy but there is at least no privacy
> harm with revealing location but rather denial of service.
>
> Ciao
> Hannes
>
> On 30.07.2010 14:23, Richard L. Barnes wrote:
>> Simplicity: This document does everything that HELD-Context does
>> (except for <snapshot>), without requiring any new XML. (And
>> <snapshot> should be a policy extension, anyway.)
>>
>> Generality: This document is not specific to HELD, so that, e.g.,
>> it can be used with DHCP.
>>
>>
>>
>> On Jul 30, 2010, at 2:07 PM, Hannes Tschofenig wrote:
>>
>>> Why not use the existing HELD Context document?
>>>
>>>
>>> On 30.07.2010 14:05, Richard L. Barnes wrote:
>>>> The only concern raised in the meeting with regard to draft-
>>>> barnes-geopriv-policy-uri was when Hannes noted that the exchange
>>>> could be made more efficient (in the HELD context) overlaying the
>>>> policy interactions on a HELD transaction. For example, the
>>>> client could provide policy data in a <locationRequest> object,
>>>> and the server could specify policy it intends to use in the
>>>> <locationResponse>. I think we should not do this.
>>>
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
