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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf