[Geopriv] not-so Quick review of barnes-geopriv-lo-sec-03

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Mon Nov 10 2008 - 18:27:52 EST

My first thorough read through of this version of the draft. I didn't intend for it to turn into a review, but that's how it goes. There's a lot of useful material here. In general, it makes sense, but I feel that the draft takes a little too long to get to the point in the earlier sections and is a little light on some of the later in-depth areas. I'll call out specific sections and make suggestions where I have them.

Section 3.1 is one of the sections that is too long. I think that less focus on what an LS might do and more on what the context means would help. The context is about a Target, it has identity (and an identifier), an authorization policy and some means to acquire location information.

Section 3.1 needs to be very clear that authorization policy applies before any of the operations requested by the LR are applied.

Section 3.1.1 uses public and private identifiers. However, the private identifier is NOT analogous to an unlinked pseudonym as suggested. If a private identifier may be derived from public information, then it is linked. Similarly, an unlinked pseudonym might be public (usually only by it explicitly being made public). My view is that these are orthogonal. A statement to that effect would be better.

  Public and private identifiers are orthogonal to the concept of unlinked pseudonyms used in [RFC3693].

In many respects, this is why Section 3.1.1 is valuable - it covers the problem from a different angle.

Section 3.1.1 talks at great length about what these identifiers are, but doesn't get to "why" all this discussion exists.

Section 3.1.1 Where are the discussions about the security/privacy properties of each class of identifier?

Section 3.1.2 is interesting for its categorization of rules. We need to have some discussion on context rules and their relationship with RFC 4745 some time... However, I don't think that this categorization is always clear. For instance, time constraints could fit into any of the categories: The request that is made at a particular time; the location that is not available at a particular time; or the context that cannot be used at a particular time. It seems to be a little subjective.

Section 3.1.2 implies that "sticky" rules are observed by the LS. Given that these are intended for the LR, I was always of the opinion that these rules could be different, and that the LS cannot rely upon them. Of course, this breaks with the concept that the LS is an LR (and based on that model, only the LG is exempt from the sticky rules). However, I believe that there needs to be something here that deals with the issue that each LR (including the LS) might need to have different "sticky" rules. My personal view is that where a separate channel to the rule maker exists, that is the only channel rules need to come from. That addresses the ugly problem that has the sticky rules translated at each step in the chain of location servers. "Sticky" rules need more consideration.

Section 3.1.3 a location context could also include a source for location information - a location URI, a location generator, an identifier and a location determination engine. The LG point links into the discussion in 3.2.1...

Section 3.2 I'd prefer to see 3.2.4 moved to 3.2.1

Section 3.2.1 The subject of this section, the "Location dereference server", and its treatment is disingenuous. All that is really necessary here is to note that location by reference uses a URI as an identifier and the server that serves this is a location server. That would be an informative note only, to make it clear that when we talk location by reference, we aren't really talking about anything particularly special.

Section 3.2.2 By the above, this is not different except that perhaps presence uses public identifiers by default. Even then, they don't have to.

Section 3.2.3 Naming problem here. The identity extensions draft has a better discussion on this now.

Section 3.2.4 There is an (unstated) assumption that is most obvious here:
  "the target (the primary rule-maker)"
On the principle that all assumptions must be stated, this needs to be much clearer.

I'd like to see a more thorough treatment of the two location by reference scenarios.

Check for typos here, there are a couple.

Section 4 Is there anything new to add on top of what is in regransmission [sic]? If not, then I'd suggest that this section doesn't need to exist.

Section 5 Figure 3 The LG here is shown as separate, as if the example of "publishing to an LS" is canon. I'm of the opinion that the LG can (and should) be an LS as well. (That's just removal of the first arrow.)

Section 5.1.1 s/his location/this location/

Section 5.1.1 no mention of unlinked pseudonyms in this context (these are useful from the perspective of "location only" as in req C8 of lbyr-requirements). There's a trade-off that isn't really given enough thought. This spills over into 5.1.2 as well.

Section 5.2 This section could be differently organized. For each requirement, there is a responsibility. The requirement that rules are followed: the rule maker requires it, the location server must fulfil it.
Then there is a requirements that the rules correspond to the right target. A requirement that the rules are not modified (responsibility for rule makers and holders both). A requirement that rules are private, or at least that rules are only disseminated based on other rules. And so on and so forth. Listing the requirements might help here.

(I wouldn't characterise the rule maker as having a responsibility for rule distribution. Particularly in light of the existence of the rule holder role. Certainly, the rest of the text here is correct - but it's only the rule maker's stake, or interest, not responsibility. The rule maker's interest is in ensuring that the rules it makes are used. To that end, they must reach the LS unmodified.)

I take it that Section 5.3 is obliquely referring to SIP conveyance.

Section 5.4 needs references for S/MIME and XMLSIG. I'll have to come back to this as well, I'm not sure if this is all that helpful as it stands.

Cheers,
Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Mon, 10 Nov 2008 17:27:52 -0600

This archive was generated by hypermail 2.1.8 : Mon Nov 10 2008 - 18:28:04 EST