Re: [Geopriv] WGLC: draft-ietf-geopriv-policy-uri-00

Hi Alissa, 

here are a few review comments. 

In the document we do not use Target but instead host. Is this intentional? 
We also use the term LS rather than LIS. Is this intentional? 

A few minor comments inline:

FROM:

"
   From a privacy perspective, however, current LCPs are limited in
   their flexibility, in that they do not provide the Device (the client
   in an LCP) with a way to inform the Location Server with policy for
   how his location information should be handled.  This document
   addresses this gap by defining a simple mechanism for referring to
   and manipulating policy, and by extending current LCPs to carry
   policy references.  Using the mechanisms defined in this document, an
   LCP server (acting for the Location Server) can inform a client as to
   which policy document controls a given location resource, and the LCP
   client (in its Rule Maker role) can inspect this document and modify
   it as necessary.
"
TO:
"
   From a privacy perspective, however, current LCPs are limited in
   their flexibility, in that they do not provide hosts (the clients
   in an LCP) with a way to inform the Location Server with 
   policy for how his location information should be handled.  This document
   addresses this gap by defining a simple mechanism for referring to
   and manipulating policy, and by extending current LCPs to carry these
   policy references.  Using the mechanisms defined in this document, an
   LCP server (acting for the LIS) can inform a host as to
   which policy document controls a given location resource, and the LCP
   client (in its Rule Maker role) can inspect this document and modify
   it as necessary.
"

The following figure, which is based on Figure 1 of RFC 5808, illustrates the interactions:

    +---------+---------+   Location    +-----------+
    |         |         |  Dereference  | Location  |
    |      LIS/LS       +---------------+ Recipient |
    |         |         |   Protocol    |           |
    +----+----+----+----+      (d)      +-----+-----+
         |         |                          |
         |         |                          |
   Policy|         |Location                  |Location
 Exchange|         |Configuration             |Conveyance
      (b)|         |Protocol                  |Protocol
         |         |(a)                       |(c)
         |         |                          |
  +------+----+----+----+                     |
  |  Rule     | Target/ |                     |
  |  Maker    | Host    +---------------------+
  |           |         |
  +-----------+---------+

In Section 3 I noticed that we only talk about HTTP URIs. We may want to use HTTP/HTTPS instead. 

The text in Section 3.2 says: 

"
   A Location Server creates a policy URI for a specific location
   resource at the time that the location resource is created; that is,
   a policy URI is created at the same time as the location URI that it
   controls.  The URI of the policy resource MUST be different to the
   location URI.
"

The current text gives the impression that the policy URI is bound to location itself. Location, however, is an always changing element in the architecture. Instead, the policy URI follows the lifecycle of it the location URI: when all the location URI are destroyed the policy URI becomes invalid as well. 
As the text later says each location URI is associated with zero or one policy URIs. This is not correct given the example in Section 5.1 where a single policy URI is associated with two location URIs.

So, I suggest to add a picture to illustrate the case. Here is a proposal:

                     +----------+
                     | Actual   |
                     | Location |
                     +----+-----+
                          |
                     +----+-----+
                     | Device   |
                     | Identity |          +-----------+
                     +----+-----+          | Policy    |
                          |                | Reference |
                          |                +-----+-----+
                          |                      |
                     +----+-----+          +-----+-------+
                     | Context  |          | Policy      |
                     | Handler  |----------+ Information |
                     +----=+----+          +-------------+
                       ,-'  '-.
                    ,-'        `-.
                _.-'              `..
             ,,'                     `._
     +------'---------+      +---------+------+
     | Location URI-1 | ...  | Location URI-n |
     +----------------+      +----------------+

A few words about the picture: 

- There is some progressing engine in the location server that maps the input identifiers to some location. This figure is about the location URIs being provided as input to the entire process. 

- There is an implementation internal data structure that glues everything together - the context handler. The policy information is bound to this handler since it is not bound to a specific identifier per se (at least not in the way how the document is written).

Now, the only question is how the lifetime of each of these objects relate to each other. 
For example, a policy may contain a validity element. For example, do you expert the location URI to be invalid when the validity time expires? 

In particular, the following statement needs to be strong: 

FROM:
"
   A DELETE request to a policy URI is a request to delete the
   referenced policy document and terminate access to the protected
   resource. 
"

TO:
"
   A DELETE request to a policy URI is a request to delete the
   referenced policy document. The LS MUST also terminate access to 
   location information referenced by any of the location URIs 
   previously distributed. 
"

We have to describe the followingI believe it should instead say:

"
   A Location Server creates a policy URI at the same time as the location URI 
   that it controls. Internally to the Location Server the policy URI refers to 
   the location URIs. The URI of the policy resource MUST be different to the
   location URI since they refer to different information elements. 
"

There is a small typo in the following sentence:

A policy URI MUST NOT be provided to an entity that is not
   authorized to view or set policy.  This document does not describe
   how policy might be provided to entities other than for location
   configuration. in responses to dereferencing requests
                ˆˆˆˆ
   [I-D.ietf-geopriv-deref-protocol] or requests from third parties
   [I-D.ietf-geopriv-held-identity-extensions].

FROM:

"
   A policy URI is a shared secret between Location Server and its
   clients.  Knowledge of a policy URI is all that is required to
   perform any operations allowed on the policy.  Thus, a policy URI is
   constructed so that it is hard to predict (see Section 8).
"

TO:

"
   From a security point of view a policy URI has to be treated like a 
   secret shared between Location Server and each of its
   clients.  Knowledge of a policy URI is all that is required to
   perform any operations allowed on the policy.  Thus, a policy URI is
   constructed so that it is hard to predict (see Section 8) and
   confidentiality protected while in transit. 
"

s/5.3.  Basic access control policy/5.3.  Basic Access Control Policy

Section 5.3 says:

"
   Consider a user that gets the policy URI
   <https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
   above LCP example.  The first thing this allows the user to do is
   inspect the default policy that the LS has assigned to this URI:
"

I would suggest not to talk about the user but instead talk about the LCP client software since otherwise one might get the impression that a human would do any of this. 

From:

"
   Finally, after using the URI for a period, the user wishes to
   permanently invalidate the URI.
"

Section 7.1: 

The text says "URI: urn:ietf:params:xml:ns:grip" but it has to be "urn:ietf:params:xml:ns:geopriv:held:policy". 

Security considerations: Wouldn't it be more useful to always require HTTPS to be used? Are there really cases where it wouldn't be used? Do we feel OK with the requirement that every LCP has to confidentiality protect the transmission of the policy URI to the host given that DHCP does not meet this confidentiality requirement? 

Regarding the policy capabilities: In HELD context we had the functionality for limited use URIs and Snapshot URIs. A limited use URI can only be accessed a fixed number of times to yield the location of the Target.  A snapshot URI points to the location of the Target at a specific point in time, and no matter how many times the URI is accessed it will always yield the same location.

Did we loose this functionality? 

Ciao
Hannes

On Mar 29, 2011, at 10:20 AM, Alissa Cooper wrote:

> This is a GEOPRIV Working Group Last Call for comments on
> draft-ietf-geopriv-policy-uri-00
> 
> Please send your comments to the list by 12 April 2011.  As always, please remember to send a note in if you've read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem."
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv