Subject: Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 3 Jun 2009 17:47:01 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-geopriv-lbyr-requirements-07
Reviewer: Spencer Dawkins
Review Date: 2009-06-03
IETF LC End Date: 2009-06-09
IESG Telechat date: (not known)

Summary: This document is almost ready for publication as an Informational 
RFC.

Comments: Most of my notes below involve text clarity. I did question one 
2119 keyword use in Section 4.1, as well.

1.  Introduction

   Location determination, different than location configuration or

Spencer (clarity): Is this s/different than/as distinct from/ ? but this 
sentence didn't parse for me.

   dereferencing, often includes topics related to manual provisioning
   processes, automated location calculations based on a variety of
   measurement techniques, and/or location transformations, (e.g., geo-
   coding), and is beyond the scope of this document.

   The issues around location configuration protocols have been
   documented in a location configuration protocol problem statement and
   requirements document [I-D.ietf-geopriv-l7-lcp-ps].  There are
   currently several examples of a location configuration protocols
   currently proposed, including, DHCP
   [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD

Spencer (clarity): got a reference for LLDP-MED here?

   [I-D.ietf-geopriv-http-location-delivery] protocols.

2.  Terminology

   Location Configuration Protocol:  A protocol which is used by a
      client to acquire either location or a location URI from a

Spencer (clarity): I'm guessing here that you mean s/either location/either 
a location object/

      location configuration server, based on information unique to the
      client.

3.3.  Location URI Authorization

   Location URIs manifest themselves in a few different forms.  The
   different ways that a location URI can be represented is based on
   local policy, and are depicted in the following four scenarios.

   1. No specific information at all:  As is typical, a location URI is

Spencer (clarity): could this be something more like "No location 
information included in the URI:"?

      used to get location information.  However, in this case, the URI
      representation itself does not need to reveal any specific
      information at all.  Location information is acquired by the
      dereferencing operation a location URI.

   2. No user specific information:  By default, a location URI MUST NOT

Spencer (clarity): could this be "URI does not identify a user:"?

      reveal any information about the Target other than location
      information.  This is true for the URI itself, (or in the document
      acquired by dereferencing), unless policy explicitly permits
      otherwise.

3.4.  Location URI Construction

   Depending on local policy, a location URI may be constructed in such
   a way as to make it difficult to guess.  Accordingly, the form of the
   URI is then constrained by the degree of randomness and uniqueness
   applied to it.  In this case, it may be important to protect the
   actual location information from inspection by an intermediate node.

Spencer (clarity): is this section applicable to all of the scenarios in the 
previous section, or just to "possession authorization model"? If not 
applicable to all, you might point that out here.

   Construction of a location URI in such a way as to not reveal any
   domain, user, or device specific information, with the goal of making
   the location URI appear bland, uninteresting, and generic, may be
   helpful to some degree in order to keep location information more
   difficult to detect.  Thus, obfuscating the location URI in this way
   may provide some level of safeguard against the undetected stripping
   off of what would otherwise be evident location information, since it
   forces a dereference operation at the location dereference server, an
   important step for the purpose of providing statistics, audit trails,
   and general logging for many different kinds of location based
   services.

4.1.  Requirements for a Location Configuration Protocol

   C3. Location URI cancellation:  The location configuration protocol
      MUST support the ability to request a cancellation of a specific
      location URI.

      Motivation: If the client determines that in its best interest to
      destroy the ability for a location URI to effectively be used to
      dereference a location, then there should be a way to nullify the
      location URI.

Spencer (clarity): sorry, but can't parse this sentence. Something like "If 
the client determines that a location URI should no longer provide a 
location, then there should be a way to nullify the location URI"?

   C5. User Identity Protection:  The location URI MUST NOT contain
      information that identifies the user or device.  Examples include
      phone extensions, badge numbers, first or last names.

Spencer (minor): this is probably a good idea, but I'm not sure it's a 2119 
MUST (NOT). How would you recognize this on the wire (do you know what MY 
badge number is :-)?

      Motivation: It is important to protect caller identity or contact
      address from being included in the form of the location URI itself
      when it is generated.

   C7. Selective disclosure:  The location configuration protocol MUST
      provide a mechanism to control what information is being disclosed
      about the Target.

Spencer (clarity): not obvious who is controlling this disclosure until you 
get to the motivation sentence - perhaps "a mechanism allowing the Rule 
Maker to control ..."?

      Motivation: The Rule Maker has to be in control of how much
      information is revealed during the dereferencing step as part of
      the privacy features.

   C8. Location URI Not guessable:  As a default, the location
      configuration protocol MUST return location URIs that are random
      and unique throughout the indicated lifetime.  A location URI with
      128-bits of randomness is RECOMMENDED.

      Motivation: Location URIs should be constructed in such a way that
      an adversary cannot guess them and dereference them without having
      ever obtained them from the Target.

Spencer (clarity): s/ever/previously/ ?

4.2.  Requirements for a Location Dereference Protocol

   D1. Location URI support:  The location dereference protocol MUST
      support a location reference in URI form.

      Motivation: It is required that there be consistency of use
      between location URI formats used in an configuration protocol and

Spencer (nit): s/in an/in a/

      those used by a dereference protocol.

5.  Security Considerations

   The method of constructing the location URI to include randomized
   components helps to prevent adversaries from obtaining location
   information without ever retrieving a location URI.  In the
   possession model, a location URI, regardless of its construction, if
   made publically available, implies no safeguard against anyone being
   able to dereference and get the location.  Care has to be paid when
   distribution such a location URI to the trusted location recipients.

Spencer (clarity): s/distribution/distributing/ ?

   When this aspect is of concern then the authorization model has to be
   chosen.  Even in this model care has to be taken on how to construct
   the authorization policies to ensure that only those parties have
   access to location information that are considered trustworthy enough
   to enforce the basic rule set that is attached to location
   information in a PIDF-LO document.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 4 Jun 2009 08:24:45 -0600

Thanks for review ... just wanted to respond to one point in this.

On Jun 3, 2009, at 4:47 PM, Spencer Dawkins wrote:

> Spencer (minor): this is probably a good idea, but I'm not sure it's  
> a 2119 MUST (NOT). How would you recognize this on the wire (do you  
> know what MY badge number is :-)?

There is the age old discussion about what 2119 means in a requirement  
document, but I'm trying to ignore that and just go with how well this  
conveys the intent of the WG to future readers. I agree we could not  
really black box test this but I think it does get to the essence of  
what the requirement is. Even last names might be hard to tell they  
are a last name, I hear rumor that google thinks Tschofenig is a  
strong password though I note is is a very common word to find in  
internet drafts :-)

Anyways, I can't think of a better way to write this requirement so  
unless someone has a concrete proposal, I suspect I will just leave as  
is.

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Jun 2009 23:52:13 -0500

On Jun 4, 2009, at 9:24 AM, Cullen Jennings wrote:

>> Spencer (minor): this is probably a good idea, but I'm not sure  
>> it's a 2119 MUST (NOT). How would you recognize this on the wire  
>> (do you know what MY badge number is :-)?
>
> There is the age old discussion about what 2119 means in a  
> requirement document, but I'm trying to ignore that and just go with  
> how well this conveys the intent of the WG to future readers. I  
> agree we could not really black box test this but I think it does  
> get to the essence of what the requirement is. Even last names might  
> be hard to tell they are a last name, I hear rumor that google  
> thinks Tschofenig is a strong password though I note is is a very  
> common word to find in internet drafts :-)
>
> unless someone has a concrete proposal, I suspect I will just leave  
> as is.
>

Say WHY it MUST NOT.

All 2119 language needs explanation; you MUST NOT include identifying  
information because if you do, that information will be revealed to  
attackers, who may exercise it in attacks. Such attacks include but  
are not limited to social engineering, impersonation, stalking,  
extortion, and pretending to be an Area Director . . .

In other words, when you use 2119 language to explain a requirement,  
explain the rationale for that requirement; in particular explain what  
happens (or becomes possible) if the requirement is violated.

Unsubstantiated dogma is doggerel.

--
Dean