It seems like this discussion has concluded, so I would like to wrap
up and move on.
What I'm taking from this discussion is that we should add some
security considerations around the use of policy URIs in cases where
DHCP is running over a shared medium (e.g., certain Ethernet or 802.11
cases). We can certainly do that.
I don't see any argument in this thread about the efficiency concerns
that were raised in Maastricht, so I'm assuming those are no longer
blocking.
Given that we ended in Maastricht saying that we would discuss Hannes
concerns on the list, and I think we've done that, could I suggest to
my co-chair that we call for adoption of this document?
--Richard
On Aug 2, 2010, at 11:06 AM, Marc Linsner wrote:
> Hannes,
>
> Shared medium networks are the place DHCP security (confidentiality)
> is
> weak. In today's world, this is 802.11 networks as shared Ethernet
> is now
> considered historical. Switched Ethernet does not have this problem.
>
> IEEE802 has a mechanism for 802.11 clients to discover their location.
>
> DHCP does not force every client to have the same location, in
> either a
> shared or non-shared mediums.
>
> -Marc-
>
> On 7/30/10 3:17 PM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
> wrote:
>
>> As you see, the DHCP story is very weak.
>> I am wonder who wants to deploy it.
>>
>> On 30.07.2010 15:13, Richard L. Barnes wrote:
>>> If the DHCP server is providing the same information to everybody --
>>> 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
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
