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
