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.