Subject: [Geopriv] policy-uri

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 30 Jul 2010 14:05:33 +0200

<hat type="individual"/>

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.

The problem is that it introduces weird failure cases: Consider the  
following request:
<locationRequest>
   <locationType>civic geodetic locationURI</locationType>
   <ruleset> ... </ruleset>
</locationRequest>

Suppose a server receives this request, and the server is happy to  
provide all three types of location, but it doesn't want to accept the  
policy.  What should happen is that the server can provide location  
and indicate that it has rejected the policy.  With the current HELD  
syntax, the rejection of policy could only be indicated with an  
<error> response, which would mean that location wouldn't get  
delivered.  So we would need to introduce a separate, "non-critical"  
error reporting mechanism.

Handling policy in a separate channel allows policy negotiations not  
to interfere with basic delivery -- we can benefit from the error- 
handling mechanisms in HTTP, without having to re-implement it inside  
the HELD XML.  An extra HTTP request is not that expensive.

As was said on another topic in the meeting: Let's just have one way.

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jul 2010 14:07:59 +0200

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jul 2010 14:13:19 +0200

Another question:

there was some work to do a non-XCAP (REST/HTTP) based approach to 
configure call handling (forward etc.) rules on a server. It was not to 
replace XCAP but that work run into "who's going to implement it" type 
of issues.

What happened with that work? Seems to be relevant to me.

Ciao
Hannes

On 30.07.2010 14:05, Richard L. Barnes wrote:
> to interfere with basic delivery -- we can benefit from the 
> error-handling mechanisms in HTTP, without having to re-implement it 
> inside the HELD XML.  An extra HTTP request is not that expensive.
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 30 Jul 2010 14:21:00 +0200

What's in the policy URI draft *is* REST/HTTP, and could easily be re- 
used in other contexts.  So if the other work stalled, we can replace  
it with this.

Could you provide a more specific reference?  Otherwise, it doesn't  
seem like this issue should be blocking for this draft.

--Richard

On Jul 30, 2010, at 2:13 PM, Hannes Tschofenig wrote:

> configure call handling (forward etc.) rules on a server. It was not  
> to replace XCAP but that work run into "who's going to implement it"  
> type of issues.
>
>> could specify policy it intends to use in the <locationResponse>.   
>> I think we should not do this.
>>
>> provide all three types of location, but it doesn't want to accept  
>> the policy.  What should happen is that the server can provide  
>> location and indicate that it has rejected the policy.  With the  
>> current HELD syntax, the rejection of policy could only be  
>> indicated with an <error> response, which would mean that location  
>> wouldn't get delivered.  So we would need to introduce a separate,  
>> "non-critical" error reporting mechanism.
>>
>> Handling policy in a separate channel allows policy negotiations  
>> not to interfere with basic delivery -- we can benefit from the  
>> error-handling mechanisms in HTTP, without having to re-implement  
>> it inside the HELD XML.  An extra HTTP request is not that expensive.
>>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 30 Jul 2010 14:23:00 +0200

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.

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jul 2010 14:34:57 +0200

I did not follow the work; maybe some of the hardcore SIP guys may know 
the status of this work.

On 30.07.2010 14:21, Richard L. Barnes wrote:
> What's in the policy URI draft *is* REST/HTTP, and could easily be 
> re-used in other contexts.  So if the other work stalled, we can 
> replace it with this.
>
>>> 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 
>>> current HELD syntax, the rejection of policy could only be indicated 
>>> with an <error> response, which would mean that location wouldn't 
>>> get delivered.  So we would need to introduce a separate,

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jul 2010 14:50:19 +0200

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 30 Jul 2010 15:13:19 +0200

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:

> 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.
>
> 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
>
>> Generality: This document is not specific to HELD, so that, e.g.,  
>> it can be used with DHCP.
>>
>>
>>
>>>> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jul 2010 15:17:42 +0200

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:
>> feature. As Marc mentioned in response to issue#23 (see 
>>>>> 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.
>>>>
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 30 Jul 2010 23:15:40 +0800

Actually - the policy URI doesn't make things worse at all.  If the confidentiality of the policy URI is compromised in transit with DHCP, then so is the confidentiality of the corresponding location URI.  It is true that the DHCP security story is weak, but this certainly doesn't make it any worse.  In the general case, it will make it better, as only an authorization policy can.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Friday, 30 July 2010 3:18 PM
> To: Richard L. Barnes
> Cc: [email-masked]
> Subject: Re: [Geopriv] policy-uri
> 
> you
> it