Subject: [Geopriv] Policy-uri comments

From: Ted Hardie <[email-masked]>
Date: Mon, 2 May 2011 10:41:20 -0700

Howdy,

Sorry for the delay in reviewing this document.  I do have some comments.

First is on authorization methods:

   Knowledge of the policy URI can be considered adequate evidence of
   authorization.  A Location Server SHOULD allow all requests, but it
   MAY deny certain requests based on local policy.  For instance, a
   Location Server might allow clients to inspect policy (GET), but not
   to update it (PUT).

For baseline HTTP requests, the policy URI will show up in both proxy
caches and local logs, so there is some reason to doubt that relying
on a proof-of-possession model will make sense.  I think the authors'
"allow to inspect" but not update is a reflection of the unease that
simply knowing the URI is enough to allow you to change the polcy.
Since the policy document itself can leak privacy sensitive data, I
think the same issue applies to GET, though I agree that the threat is
less.

I don't personally find the text here and in 8.2 to address this
complete enough, partly because the parallel to RFC 5808 isn't
justified and partly because the issue isn't tackled head on.  At
minimum, I think the doc should review the reasons for this choice in
more detail.  I personally think that a stronger authentication regime
should be considered as a SHOULD, with a MAY for the less stringent
mechanisms when other conditions are met.

It's also not clear whether a location server that allows clients to
inspect policy but not update actually meets the goals of this
document, since it either then requires some other side-loading
mechanism or is incomplete.

This statement about DELETE:

   If the request is authorized, then the Location Server
   deletes the policy referenced by the URI and disallows any further
   access to the location resource it governs.

seems to imply that once a policy URI is DELETEd, it cannot be
re-created with a PUT.  If this is the intent, then this may need to
be more explicit.  Otherwise,a client may try to DELETE then PUT,
rather than just PUTting over the URI.  I don't think this is
otherwise forbidden.

Given the extensions in section 4.1, should this draft be listed as
updating 5985?

I'd suggest changing the header for section 8.3.  The meat of the
statement appears to me to be:

   To allow for the creation of Target-specific authorization policies
   that are adequately privacy-protected, every location URI and policy
   URI that is issued to a different Target MUST be different.  That is,
   no two client can receive the same location URI or policy URI.

The current header is simply: Location URI Allocation.

Would it not be better to use something like:

"Providing distinct Location and Policy URIs"?

 regards,

Ted Hardie

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 3 May 2011 15:08:20 +0200

Hey Ted,

Thanks a lot for your review.  Some comments inline:

> For baseline HTTP requests, the policy URI will show up in both proxy caches and local logs, so there is some reason to doubt that relying on a proof-of-possession model will make sense.  I think the authors' "allow to inspect" but not update is a reflection of the unease that simply knowing the URI is enough to allow you to change the polcy.  Since the policy document itself can leak privacy sensitive data, I think the same issue applies to GET, though I agree that the threat is less.  

I have a hard time taking the proxy/log case as a huge threat, given that there are multiple widely-deployed privacy mechanisms out there that rely on possession.  For example, every HTTP service that uses API keys in query parameters is subject to this risk, but there are huge numbers of such services.  Indeed, OAuth carries tokens in URI parameters.

> I don't personally find the text here and in 8.2 to address this complete enough, partly because the parallel to RFC 5808 isn't justified and partly because the issue isn't tackled head on.  At minimum, I think the doc should review the reasons for this choice in more detail.  I personally think that a stronger authentication regime should be considered as a SHOULD, with a MAY for the less stringent mechanisms when other conditions are met.  

I thought the base problem was that you wanted to provide some basic level of protection to a hosts that connect to a network without having a shared key with the LS.  Clearly, a server MAY require authentication, but it doesn't seem to me like there's enough likelihood of an appropriate authentication system being present to make it a SHOULD.  Am I missing some obvious cases?

> It's also not clear whether a location server that allows clients to inspect policy but not update actually meets the goals of this document, since it either then requires some other side-loading mechanism or is incomplete.

Being pragmatic about this, we can't really legislate what policies LS provider will apply.  We could have a requirement that servers allow changes to policy, but that just risks that portion of the spec being unused.   IMO, even being able to inspect policy is an improvement over the current state of the art.

> seems to imply that once a policy URI is DELETEd, it cannot be re-created with a PUT.  If this is the intent, then this may need to be more explicit.  Otherwise,a client may try to DELETE then PUT, rather than just PUTting over the URI.  I don't think this is otherwise forbidden.

That was the intended semantic.  This also relates to a comment from Hannes, which we tried to address with the following explanatory note:
"
A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the HELD-specified validity interval. The former is temporary, since the policy URI can be used to update the validity interval in the policy; the latter two are permanent.
"
Does that make sense?

> Given the extensions in section 4.1, should this draft be listed as updating 5985?

That would make sense to me.  I'll try to figure out how to do it in xml2rfc :)

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 May 2011 13:45:17 -0700

On Tue, May 3, 2011 at 6:08 AM, Richard L. Barnes <[email-masked]> wrote:

> <snip>

> I have a hard time taking the proxy/log case as a huge threat, given that
> there are multiple widely-deployed privacy mechanisms out there that rely on
> possession.  For example, every HTTP service that uses API keys in query
> parameters is subject to this risk, but there are huge numbers of such
> services.  Indeed, OAuth carries tokens in URI parameters.
>
>
Then I suggest that the policy URI "age out" over time.  As it stands, the
policy URI is created by the location server and effectively never changes
during the validity interval set for that location.  Whenever it is used to
get or set policy through a proxy (like a friendly interception proxy, let's
say), it may be revealing itself.  If the validity interval is long, this
may be a problem (my employer may get or my ex-employer may retain access to
the policy URI for my "home" location).

I am assuming that a location may be fairly long lived-e.g. created by my
cable company for my "home" location and re-used with its policy URI for
long periods.  If the validity intervals are short and the LS does not
re-use the policy URI when a new location URI for that same location is
created, this is less of a problem (this latter problem may require some
thought in the inputs to a hash-based mechanism for the creation of a policy
URI, especially if an LS re-used the random entropy in a new run.  It can
neither use the location URI nor the location description, I'd guess).

<snip>

> inspect policy but not update actually meets the goals of this document,
> since it either then requires some other side-loading mechanism or is
> incomplete.
>
> Being pragmatic about this, we can't really legislate what policies LS
> provider will apply.  We could have a requirement that servers allow changes
> to policy, but that just risks that portion of the spec being unused.   IMO,
> even being able to inspect policy is an improvement over the current state
> of the art.
>
>
No, but we can say that it is recommended for cases where there is no other
way to set policy.

> > seems to imply that once a policy URI is DELETEd, it cannot be re-created
> with a PUT.  If this is the intent, then this may need to be more explicit.
>  Otherwise,a client may try to DELETE then PUT, rather than just PUTting
> over the URI.  I don't think this is otherwise forbidden.
>
> That was the intended semantic.  This also relates to a comment from
> Hannes, which we tried to address with the following explanatory note:
> "
> A location URI can thus become invalid in three ways: By the expiration of
> a validity interval in policy, by the removal of a policy document with a
> DELETE request, or by the expiry of the HELD-specified validity interval.
> The former is temporary, since the policy URI can be used to update the
> validity interval in the policy; the latter two are permanent.
> "

Does that make sense?
>
> Not really, no.  I was pointing out that some other systems might allow a
DELETE of resource X followed by a PUT to resource X as a valid update
method, rather than using a PUT to overwrite.  This gives those two
operations two different semantics, which I find personally confusing.  The
document says:

A DELETE request to a policy URI is a request to delete the
referenced policy document and terminate access to the protected
resource. If the request is authorized, then the Location Server
deletes the policy referenced by the URI and disallows any further
access to the location resource it governs.

Overloading removing the policy URI with "delete access to the resource"
seems like an un-needed optimization to me.  As a client writer, I'd update
the policy with a validity interval that is gone, set provide-location to
false or something similar.  That's just my personal take on this obviously,
and if other folks feel that this is the optimization to make, I can live
with it.

regards,

Ted

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 4 May 2011 10:21:58 +0200

> Then I suggest that the policy URI "age out" over time.  As it stands, the policy URI is created by the location server and effectively never changes during the validity interval set for that location.  Whenever it is used to get or set policy through a proxy (like a friendly interception proxy, let's say), it may be revealing itself.  If the validity interval is long, this may be a problem (my employer may get or my ex-employer may retain access to the policy URI for my "home" location).
> 
> I am assuming that a location may be fairly long lived-e.g. created by my cable company for my "home" location and re-used with its policy URI for long periods.  If the validity intervals are short and the LS does not re-use the policy URI when a new location URI for that same location is created, this is less of a problem (this latter problem may require some thought in the inputs to a hash-based mechanism for the creation of a policy URI, especially if an LS re-used the random entropy in a new run.  It can neither use the location URI nor the location description, I'd guess).

We should keep in mind that there are at least three different validity intervals here:
1. The validity interval of the location value
2. The validity interval of the location URI
3. The validity interval of the policy URI

Would it address your concern to require (2) and (3) to be equal?  This seems sensible and implementable to me.  Proposed text:
"
A policy URI is only valid while the corresponding location URI set is valid.  A location server MUST NOT respond to any requests to a policy URIs once the corresponding location URI set has expired.  This expiry time is specified by the 'expires' attribute in the HELD locationResponse or the 'Valid-For' LuriType in DHCP.
"

> No, but we can say that it is recommended for cases where there is no other way to set policy.

Proposed text: 
FROM
"
A Location Server SHOULD allow all requests, but it MAY deny certain requests based on local policy. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT).
"
TO
"
A Location Server MUST allow GET requests to allow clients to inspect policy.  A Location Server SHOULD support PUT and DELETE requests to allow clients to control policy, especially if clients cannot set policy through other means. 
"

> Overloading removing the policy URI with "delete access to the resource" seems like an un-needed optimization to me.  As a client writer, I'd update the policy with a validity interval that is gone, set provide-location to false or something similar.  That's just my personal take on this obviously, and if other folks feel that this is the optimization to make, I can live with it.

Ok, I think I understand you better now.  I can agree that overloading DELETE makes sense, especially in light of the fact that we have two other ways of invalidating location URIs (policy-based validity intervals and the global expiration of the URI).  It still seems like an LS shouldn't respond to requests for the location URI while there's no policy document (after a DELETE).

Proposed text:
FROM
"
A DELETE request to a policy URI is a request to delete the referenced policy document and terminate access to the protected resource. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow any further access to the location resources it governs.

A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the HELD-specified validity interval. The former is temporary, since the policy URI can be used to update the validity interval in the policy; the latter two are permanent.
"
TO
"
A DELETE request to a policy URI is a request to delete the referenced policy document.  If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow access to the location URIs it governs until a new policy document has been put in place via a PUT request.

A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the LCP-specified validity interval. The former two are temporary, since the policy URI can be used to update the policy.  The latter one is permanent, since the expiry causes the policy URI to be invalidated as well.  
"

---

From: Ted Hardie <[email-masked]>
Date: Wed, 4 May 2011 09:02:37 -0700

In-line responses,

Ted
On Wed, May 4, 2011 at 1:21 AM, Richard L. Barnes <[email-masked]> wrote:

> > Then I suggest that the policy URI "age out" over time.  As it stands,
> the policy URI is created by the location server and effectively never
> changes during the validity interval set for that location.  Whenever it is
> used to get or set policy through a proxy (like a friendly interception
> proxy, let's say), it may be revealing itself.  If the validity interval is
> long, this may be a problem (my employer may get or my ex-employer may
> retain access to the policy URI for my "home" location).
> >
> Would it address your concern to require (2) and (3) to be equal?  This
> seems sensible and implementable to me.  Proposed text:
> "
> A policy URI is only valid while the corresponding location URI set is
> valid.  A location server MUST NOT respond to any requests to a policy URIs
> once the corresponding location URI set has expired.  This expiry time is
> specified by the 'expires' attribute in the HELD locationResponse or the
> 'Valid-For' LuriType in DHCP.
> "
>
>
This works.  I would add "Re-use of policy URIs with subsequent location
URIs is NOT RECOMMENDED even if the rule maker and location are the same."
That may be me being paranoid, so I'm okay if you prefer to leave it out.  I
can't really see this being done by anyone following the spirit of the other
recommendations, but paranoia is paranoia, you know?

> A Location Server SHOULD allow all requests, but it MAY deny certain
> requests based on local policy. For instance, a Location Server might allow
> clients to inspect policy (GET), but not to update it (PUT).
> "
> TO
> "
> A Location Server MUST allow GET requests to allow clients to inspect
> policy.  A Location Server SHOULD support PUT and DELETE requests to allow
> clients to control policy, especially if clients cannot set policy through
> other means.
> "
>
>
>
Works for me.

> Ok, I think I understand you better now.  I can agree that overloading
> DELETE makes sense, especially

Was this "does not make sense"?

> in light of the fact that we have two other ways of invalidating location
> URIs (policy-based validity intervals and the global expiration of the URI).
>  It still seems like an LS shouldn't respond to requests for the location
> URI while there's no policy document (after a DELETE).
>
>
Agreed.

> Proposed text:
> FROM
> "
> A DELETE request to a policy URI is a request to delete the referenced
> policy document and terminate access to the protected resource. If the
> request is authorized, then the Location Server MUST delete the policy
> referenced by the URI and disallow any further access to the location
> resources it governs.
>
> A DELETE request to a policy URI is a request to delete the referenced
> policy document.  If the request is authorized, then the Location Server
> MUST delete the policy referenced by the URI and disallow access to the
> location URIs it governs until a new policy document has been put in place
> via a PUT request.
>
> DELETE request, or by the expiry of the LCP-specified validity interval. The
> former two are temporary, since the policy URI can be used to update the
> policy.  The latter one is permanent, since the expiry causes the policy URI
> to be invalidated as well.
> "
>
>
>
This works for me.

Thanks,

Ted

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 4 May 2011 18:20:39 +0200

Thanks for following up.  I'll implement the agreed changes.  Two quick reactions:

> This works.  I would add "Re-use of policy URIs with subsequent location URIs is NOT RECOMMENDED even if the rule maker and location are the same." That may be me being paranoid, so I'm okay if you prefer to leave it out.  I can't really see this being done by anyone following the spirit of the other recommendations, but paranoia is paranoia, you know?

I think it would actually be simpler to say that the location server MUST generate a new policy URI for a new location URI.  Since that's how I would implement it anyway :)

> Ok, I think I understand you better now.  I can agree that overloading DELETE makes sense, especially
> 

Yep.

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Wed, 4 May 2011 09:24:24 -0700

On Wed, May 4, 2011 at 9:20 AM, Richard L. Barnes <[email-masked]> wrote:

> I think it would actually be simpler to say that the location server MUST
> generate a new policy URI for a new location URI.  Since that's how I would
> implement it anyway :)
>
>
Even better.

thanks,

Ted

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 5 May 2011 07:43:36 +0800

I was going to respond to this thread with a more detailed response, but it looks like you have everything in hand.

I did follow up on logging, in particular intermediary logging.  The conclusion: our standing advice on using HTTP over TLS stands - intermediaries will log if you allow them to and TLS limits what they can log.

--Martin

On 2011-05-05 at 02:24:24, Ted Hardie wrote:
> On Wed, May 4, 2011 at 9:20 AM, Richard L. Barnes <[email-masked]>
...