Subject: Re: [Geopriv] Changes in -policy-uri-06

From: Robert Sparks <[email-masked]>
Date: Mon, 01 Oct 2012 16:23:38 -0500

On 9/26/12 7:59 AM, Richard Barnes wrote:
> Dear GEOPRIV,
>
> The latest version of -policy-uri seems to have addressed all of the 
> DISCUSS comments, but it contains several changes that I would like to 
> run by the working group.  Going in order of the diff [1]:
>
> -- Section 1: Clarified that LbyR only provides privacy protections if 
> appropriate access control policies are configured
>
> -- Section 3.1: Added requirement that clients SHOULD support HTTP 
> client auth and MAY support TLS client certs.
>
> -- Added Section 3.3, providing some example policies (e.g., a 
> deny-all policy)
>
> -- Section 7.1: Clarified that the general requirements for TLS 
> support/usage are the same as for -deref-protocol.
>
> -- Section 7.2: Clarified requirements for entropy in policy URIs, and 
> provided an example algorithm for generating policy URIs
There's one change in this section that goes beyond clarification. I 
have no problem with it, but I wanted to make sure people knew
it was there - you changed the recommended entropy going into the policy 
URI from 32 to 128 bits.
>
> -- Added Section 7.4, recommending that policy URIs be protected to 
> the same level as other shared secrets (e.g., passwords)
>
> The only normative changes are (1) SHOULD support HTTP client auth, 
> and (2) SHOULD protect policy URIs as shared secrets.
>
> Hope this helps,
> --Richard
>
>
> [1] 
> <http://tools.ietf.org/rfcdiff?url1=draft-ietf-geopriv-policy-uri-04.txt&url2=draft-ietf-geopriv-policy-uri-06.txt>
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 3 Oct 2012 04:33:26 -0600

I have two questions about the text in 3.3:

> The same reasoning could also be applied to servers, with the caveat
>   that servers do not know whether a given HELD client supports the use
>   of policy URIs.  A client that does not understand policy URIs will
>   not be able to set its own policy, and so the server must choose a
>   default that is open enough that clients will find it useful.  

I feel like between this statement and the text in 3.2 and 7.4 about authorization by possession ("Without policy URIs, location URIs are subject to the "authorization by possession model", and location URIs must be conveyed to another entity in order to be useful."), the suggestions to servers about how they should set the default policy are muddy. A default option that is open enough for clients to find it useful could be a whole set of things that are still more restrictive than authorization by possession. I realize that there is no normative requirement for the default to be anything in particular, but I think every time the subject of the default is raised, the suggestion should be consistent.

> On the
>   other hand, once a client indicates that it understands policy URIs
>   (e.g., by sending an HTTP request to a policy URI), the server may
>   change its default policy to something more restrictive -- even the
>   empty, default-deny policy -- since the client can specify something
>   more permissive if desired.

When you say "default policy" above, are you talking about the policy that exists between the time that the client issues a GET for the policy and the time that the client issues a PUT or DELETE on the policy? (Not exactly what I would think of as a "default," but that's my best guess as to what this means). 

If the above interpretation is correct, this still seems a little weird to me to suggest that servers would change from auth-by-possession to deny-everything just because a client supports policy URIs. E.g., if the client fires the GET when the user opens up a permissions interface, but then the user cancels without setting his policy, the policy will have changed completely without the user taking any affirmative step. I realize that this scenario is possible, but I don't see why we need to point it out explicitly.

Alissa

On Sep 26, 2012, at 6:59 AM, Richard Barnes wrote:

> Dear GEOPRIV,
> 
> The latest version of -policy-uri seems to have addressed all of the DISCUSS comments, but it contains several changes that I would like to run by the working group.  Going in order of the diff [1]:
> 
> -- Section 1: Clarified that LbyR only provides privacy protections if appropriate access control policies are configured
> 
> -- Section 3.1: Added requirement that clients SHOULD support HTTP client auth and MAY support TLS client certs.
> 
> -- Added Section 3.3, providing some example policies (e.g., a deny-all policy)
> 
> -- Section 7.1: Clarified that the general requirements for TLS support/usage are the same as for -deref-protocol.
> 
> -- Section 7.2: Clarified requirements for entropy in policy URIs, and provided an example algorithm for generating policy URIs
> 
> -- Added Section 7.4, recommending that policy URIs be protected to the same level as other shared secrets (e.g., passwords)
> 
> The only normative changes are (1) SHOULD support HTTP client auth, and (2) SHOULD protect policy URIs as shared secrets.
> 
> Hope this helps,
> --Richard
> 
> 
> [1] <http://tools.ietf.org/rfcdiff?url1=draft-ietf-geopriv-policy-uri-04.txt&url2=draft-ietf-geopriv-policy-uri-06.txt>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 3 Oct 2012 14:39:34 -0400

Hey Alissa,

Thanks for pointing these out.  There is some legitimate ambiguity.  Proposed text inline below.

> I feel like between this statement and the text in 3.2 and 7.4 about authorization by possession ("Without policy URIs, location URIs are subject to the "authorization by possession model", and loc…

OLD: "Without policy URIs, location URIs are subject to the "authorization by possession model", and"
NEW: "Without policy URIs, location URIs are subject to a default policy set unilaterally by the server, and"

> If the above interpretation is correct, this still seems a little weird to me to suggest that servers would change from auth-by-possession to deny-everything just because a client supports policy U…

I was thinking that the server would change before it responds to the GET, in which case the user would see the policy as default-deny.  But I see your point.

OLD: "the server may change its default policy to something more restrictive"
NEW: "the server may change the policy for the relevant policy URI from its default policy to something more restrictive"

NEW(at end of paragraph):
"
Obviously, if such a change is made, it should be visible to the client.  For example, if the server uses a GET request to a policy URI as an indication that the client supports policy URIs, then it should change the policy before replying to the GET.  That way, the results of the GET will accurately reflect the more restrictive policy.
"

Do those clarifications help?

--Richard

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Oct 2012 19:45:31 +0100

> Obviously, if such a change is made, it should be visible to the client.  For example, if the server uses a GET request to a policy URI as an indication that the client supports policy URIs, then i…

This bothers me.  It bugged me before, but I couldn't pin it down to
something specific.  Thanks for the extra text to help clarify things.

A GET is supposed to be safe.  This violates that basic contract.  If
I make a GET request to a policy URI, there could be consequences that
I am not aware of.

The problem is that it is possible, prior to the GET, to observe the
policy that the server has applied.  Having that policy change as a
result of a request that is defined as having no repercussions on the
requester is not good.

A better way of signaling support for this sort of feature would be at
the time that the resources were created.

--Martin

---

From: Richard Barnes <[email-masked]>
Date: Wed, 3 Oct 2012 15:08:10 -0400

> the time that the resources were created.

How silly of me.  I forgot the <requestPolicyURI> element that we defined, which is exactly what you're asking for.

OLD: "once a client indicates that it understands policy URIs (e.g., by sending an HTTP request to a policy URI)"
NEW: "if a client indicates that it understands policy URIs (e.g., by including a <requestPolicyURI> element in its HELD request)"

That leaves DHCP out in the cold, but I think it's much better than changing on GET.

--Richard

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Oct 2012 21:47:44 +0100

> That leaves DHCP out in the cold, but I think it's much better than changing on GET.

DHCP servers will have to operate on the assumption that the client
doesn't understand policies.  That's simply maintains status quo.  The
HELD side improves upon it.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Oct 2012 11:41:28 -0400

> NEW: "Without policy URIs, location URIs are subject to a default policy set unilaterally by the server, and"

Better, thanks.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Oct 2012 11:43:27 -0400

> NEW: "if a client indicates that it understands policy URIs (e.g., by including a <requestPolicyURI> element in its HELD request)"

I would say drop the "e.g.," and it's good to go.
Alissa