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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Apr 2011 18:43:42 +0300

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 27 Apr 2011 14:18:02 +0800

Hi Hannes,

I think that most of your comments are good feedback, I'll pick out a few that I think need response.

>    their flexibility, in that they do not provide hosts (the clients
[...]
>    LCP server (acting for the LIS) can inform a host as to

I think that the original "(active for the Location Server)" was correct in this context.  Policy is enforced by the Location Server and so policy is created for the benefit of the LS.  I consider LIS and LCP server to be synonymous.  

The other edits are good.

>    which policy document controls a given location resource, and the 
[...]
> to use HTTP/HTTPS instead.

I tend to use "HTTP URI" as the general and "http: or https: URI" as the specific.  HTTPS isn't a protocol, though the contemporary etymologists might disagree given its widespread use.

On the other hand, that degree of pedantry doesn't help a casual or lazy reader.  The goal is to make it clear that a secured resource is important.  Without making Section 3 any less succinct.

> 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.

There might need to be a clarification, but there is an important distinction between _resource_ and _URI_.  A better way to describe it might be:

	There is exactly one policy resource for each location resource.  For a given resource, there are zero or more URIs that can be used to identify that resource.

Section 3.2 might need to be updated with text to this effect.

Based on this model, Section 5.1 shows an example where location URIs = 2 and policy URIs = 1. 

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

That's a good picture - though I'd not use the term "Context Handler" without better context [sic].  I'm inclined not to include the picture.  If we did include such a picture, I'd include two things:  policy resource/URI separation, and location resource/location snapshot distinction - that is, noting that the location resource is tied to a particular device and that the value/representation of the resource changes as the location of the device changes.
 
> 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?

Policy and location resources are irrevocably tied.  Their lifetimes are the same.

Any policy needs to be enforced against the location URI until the location URI expires.  If the policy includes validity statements, then those need to be respected.  

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

[[Missed something here?]]
>    location URI since they refer to different information elements.

I'd prefer not to include this.  See above discussion on URIs and resources in respect to the first two sentences.

For the last sentence, the reason you give is only the smallest part.   There's actually more reason than the fact that they are different resources.  The security considerations section explains why you shouldn't be able to go from location URI to policy URI in any way: the policy URI is primarily protected by the fact that it isn't known.

> TO:
> 
> "
>    [1: From a security point of view a policy URI has to be treated like a
>    clients.]  Knowledge of a policy URI is all that is required to
>    constructed so that it is hard to predict (see Section 8) [2: and
>    confidentiality protected while in transit.]
> "

I'm not sure what the first edit adds.  The addition to the end of the paragraph is a good pickup.

> 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?

DHCP weasels around that by relying on layer 1 or layer 2 measures - they assume that the wire is secured somehow.  That gives DHCP the ability to claim confidentiality.  It's fairly clear that open WiFi wrecks that, but you could say that RFC 3825^H^H^H^H 3825bis and RFC 4676^H^H^H^H 4776 do have the proper "caveat lector" sections.
 
> 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.
> 

If you want to think about it in those terms, yes.  Conceptually, those are still possible, though I've been convinced that limited use is hard enough to implement that adding it would be a waste of effort.  Snapshot might still be addressed through a HELD extension.
 
> Hannes

--Martin

---

From: Richard L. Barnes <[email-masked]>
Date: Thu, 28 Apr 2011 13:21:46 -0400

Hey Hannes,

Always nice when co-authors submit comments :)

> In the document we do not use Target but instead host. Is this intentional? 

The host in this case is being both a Target and a Rule Maker.  I don't see a need to replace all the terms, but we could insert some text to clarify.

> We also use the term LS rather than LIS. Is this intentional? 

This makes sense, since the location server in question really is acting as a Location Server in the sense of RFC 3693 and geopriv-arch.

>    ...

Agree to change Device / client to "host".  Think that Location Server is better than LIS here.

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

Added the figure to the Introduction, but changed the letters to numbers to correspond to 5808.

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

Done, in first sentence.

> 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 U…

You've got the constraint backwards: Each location URI has at most one policy URI, but each policy URI can control multiple location URIs.  As Martin notes, in light of that, the example in Section 5.1 is fine.

I agree with Martin that the diagram is unnecessary.

> 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? 

Yes, by definition.  But not necessarily permanently; the RM can send a new policy that re-opens the validity period.  The validity ends permanently when the HELD validity time is reached or the RM sends a DELETE request.  Added a note:
"
A location URI can thus become valid 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.
" 

>    location information referenced by any of the location URIs 

How is this different from the current text?
"
the Location Server deletes the policy referenced by the URI and disallows any further access to the location resources it governs.
"
I've added a MUST here, if that helps.

>    [I-D.ietf-geopriv-held-identity-extensions].

Fixed.

>    confidentiality protected while in transit. 

Agree with Martin.  Made the latter change, but not the former.

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

Fixed.

> 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. 

Done. s/user/client/g

>    permanently invalidate the URI.

Leaving this as "user", since clients don't make authorization decisions.

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

Fixed.

> 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 co…

I agree with Martin's comments here.

> Did we loose this functionality? 

I agree with Martin's comments here, with one revision: These should be common-policy extensions rather than HELD extensions.  For example:
<transformations>
  <provide-at-time>2011-04-29T12:34</provide-at-time>
</transformations>

But in any case, not in this document.

--Richard