[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Draft                                                J. Cuellar
Document: draft-cuellar-geopriv-reqs-02.txt                   Siemens AG

                                                     John B. Morris, Jr.
                                     Center for Democracy and Technology

                                                             D. Mulligan
                     Samuelson Law, Technology, and Public Policy Clinic

Expires: Nov. 2002                                              May 2002

                          Geopriv requirements


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   Location-based services, navigation applications, emergency services,
   management of equipment in the field, and other location-dependent
   services need geographic location information about a target (user,
   resource or other entity).  There is a need to securely gather and
   transfer location information for location services, protecting the
   privacy of the individuals involved.

   This document describes the requirements for the geopriv Location
   Object (used to transfer location data and perhaps some other

   Cuellar, Morris, Mulligan      Expires Nov 2002                  1

                         Geopriv Requirements                 May 2002

   information) and for further IETF protocols that use this Location
   Object as an embedded protocol. We focus on authorization, integrity
   and privacy requirements.


Table of Contents

       1. Overview.......................................................2

       2. Conventions used in this document..............................4

       3. Usage Model....................................................4
          3.1. Roles and attributes......................................4
          3.2. Data......................................................7
          3.3. Identification, Authentication, and Authorization.........8
          3.4. Data Flows................................................9
             3.4.1. Relationship framework..............................11
             3.4.2. Scenarios of Data Flow..............................11
          3.5. Further explanations.....................................13
             3.5.1. Location Data Types.................................13
             3.5.2. Public Global Identities............................14
             3.5.3. Authorization without Explicit Authentication.......14

       4. Requirements..................................................16
          4.1. Protocols................................................16
          4.2. Policy based Location Data transfer......................16
          4.3. Location Object, Location Data...........................17
          4.4. Policies.................................................17
          4.5. Identity Protection......................................18
          4.6. Authentication Requirements..............................18
          4.7. Actions to be secured....................................19

       5. Security Considerations.......................................19
       6. References....................................................19
       7. Author's Addresses............................................20
       8. Full Copyright Statement......................................20

1. Overview

   Location-based services (applications that require geographic
   location information as input) are becoming increasingly common.  The
   collection and transfer of location information about a particular
   device and/or target can have privacy implications.

   The ability to derive or compute a device's location, and access to
   the derived or computed location, are key elements of the location-
   based services privacy equation.  Central to a target's privacy are
   (a) the identity of entities that have access to raw location data,
   derive or compute location, and/or have access to derived or computed
   location information, and (b) whether those entities can be trusted
   to know and follow the target's (or better rule-maker's) policy.



   Cuellar, Morris, Mulligan      Expires Nov 2002                  2

                         Geopriv Requirements                 May 2002

   In this paper we assume that "location information" is a relatively
   specific way of describing where a device is located and that the
   location information is either (a) derived or computed from
   information generally not available to the general public, or (b)
   determined by a device that is not generally publicly addressable or
   accessible.  For example, location information could include
   information calculated by triangulating on a wireless signal with
   respect to cell phone towers, or longitude and latitude information
   determined by a device with GPS (global positioning satellite)
   capabilities.

   Excluded from the discussion below is the determination of location
   information wholly without the knowledge or consent of the target (or
   the target's network or access service provider), based on generally
   available information such as an IP or e-mail address.  It is
   important to note that information like IP address can enable someone
   to roughly or in some instances precisely estimate a location.
   Commercial services exist, for example, that offer to provide rough
   location information based on IP address.  Currently, this type of
   location information is typically less accurate and has a coarser
   granularity than the type of location information addressed in this
   document.  This less accurate type of location computation still
   raises significant potential privacy and public policy concerns, but
   such scenarios are generally outside the scope of this document.

   For the purposes of this document, "policies" or "privacy rules" are
   rules that regulate an entity's activities with respect to location
   information, including, but not limited to, the collection, use,
   disclosure, and retention of location information.  These rules must
   generally comply with fair information practices.  For example, see
   the OECD (Organization for Economic Co-operation and Development)
   Guidelines on the Protection of Privacy and Transporter Flows of
   Personal Data at
   http://www1.oecd.org/dsti/sti/it/secur/prod/PRIVEN.HTM.  The
   application of these rules is described briefly in the scenarios.
   However, they must be fully explored in a separate document prior to
   creating location privacy technologies.

   The main principles guiding the requirements exposed in this paper
   are:

   1) Security of the protocol is of utmost importance to guarantee the
      correctness (integrity) and the confidentiality of the location
      information.  This includes authenticating the main entities of
      the protocol and securing the exchanged messages.

   2) A most important role is played by user-controlled policies,
      which describe the permissions (or consent) given by the user.
      The policies specify the necessary conditions that allow a
      Location Server to forward (transformed or filtered) location
      information to a Location Recipient and the conditions under
      which and purposes for which location information can be used.
      That is, using policies, the user is able to specify which

   Cuellar, Morris, Mulligan      Expires Nov 2002                  3

                         Geopriv Requirements                 May 2002

      component or derived measure of the information is to be released
      to whom and in which granularity or accuracy.  The exact form or
      expressiveness of policies is not further discussed in this
      paper.

   3) Whenever possible, the location information should not be linked
      to the real identity of the user or a static identifier easily
      linked back to the real identity of the user (ie. phone number).
      Rather, the user is able to specify which local identifier,
      pseudonym, or private identifier is to be linked to the location
      information.

   4) The user may want to hide the real identities of himself and his
      partners not only to eavesdroppers but also to other entities
      participating in the protocol.

   Although complete anonymity may not be appropriate because of legal
   constraints or because some location services may in fact need
   explicit identifications, in most cases the location services only
   need some type of authorization information and/or perhaps anonymous
   identifiers of the entities in question.


2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].

   Note that the requirements discussed here are requirements on privacy
   protocols for location services.  Thus the requirements sometimes
   refer only to the capabilities of these protocols.  For example,
   requiring that the protocol support integrity is not the same thing
   as requiring that all protocol traffic be authenticated.  In other
   cases, the requirement may be that the user always obtains a notice
   when his location data was not authenticated.  This is clearly not
   just a capability of the protocol.

3. Usage Model

   The following usage model will be discussed more extensively in
   another framework and scenarios document.  We present here a summary
   of the terminology of the usage model for convenience.

3.1. Roles and attributes

   The entities of a geopriv application or scenario may be given
   explicit roles:

      Target:
         The entity whose location is desired by the Location Seeker.
         In many cases the Target will be the human "user" of a Device


   Cuellar, Morris, Mulligan      Expires Nov 2002                  4

                         Geopriv Requirements                 May 2002

         or an object such as a vehicle or shipping container to which
         the device is attached. In some instances the target will be
         the device itself.

      Device:
         The technical device the location of which is tracked as a
         proxy for the location of a Target.  A Device might, for
         example, be a Global Positioning Satellite (GPS) receiver, a
         laptop equipped with a wireless access device, or a
         transmitter that emits a signal that can be tracked or
         located. In some situations there may be no Device, in the
         sense of this definition, but for instance a user is entering
         the location information manually.

      Rule-Maker:
         The individual or entity who has the authorization to set the
         applicable privacy rules, collectively known also as the
         policy.  In some cases this is the user who is in possession
         of the Device, but is some cases it is not.  For example,
         parents may control what happens to the location information
         derived from their children's cell phones.  The Rule-Maker is
         often, but not always, the "owner" of the Device used to track
         location.  For example, a company may own and provide a cell
         phone to an employee but permit him/her to set the privacy
         rules.  Other proposed names are "Owner (of the privacy
         rights)" or "policy maker"

      Unintended Target:
         A person or object tracked by proximity to the Target. This
         special case most frequently occurs if the target is not a
         person. For example, the Target may be a rental car equipped
         with a GPS device, used to track car inventory.  The rental
         company may not care about the driver's location, but the
         driver's privacy is implicitly affected.  Working group
         protocols may or may not protect or affect the privacy of
         Unintended Targets, but the impact on Unintended Targets
         should be acknowledged.


      Data Transporter (“DT”):
         An entity or networking that receives and forwards data
         without processing or altering it.  A Data Transporter could
         theoretically be involved in almost any transmission between a
         Device and a Location Processor, a Location Processor and a
         second Location Processor, or a Location Processor and a
         Location Seeker.  Some location tracking scenarios may not
         involve a Data Transporter.

      Location Seeker (“LS”)
         An individual or entity who seeks to receive location data
         about a Target.



   Cuellar, Morris, Mulligan      Expires Nov 2002                  5

                         Geopriv Requirements                 May 2002

      Computational Location Server (“CLServ”)
         A Device or entity that computes or processes raw data to
         compute or derive location data, or processes location data to
         transform or refine the data into new location data.
         <Why is this CLServ needed?>

      Location Storage (“LStor”)
         (. Location Server: Think of pure storage devices as disks.
         They matter for privacy purposes!)
         A Device or entity that stores raw or location data.

      Rule Repository (“RR”)
         A repository that contains private or public policies,
         identifiers, and perhaps also requests are stored.


   Attributes

   An entity that who seeks to access the location data is a Location
   Seeker and may act in one or more of the following roles: as the
   Location Sighter (Location Data Source), as a Location Server, or as
   an Ultimate Location Recipient.

      Location Sighter (LoSi), or Location Data Source
         The original source of the sighting of a target in a given
         transaction.

      Location Server (LS), or Intermediate Location Recipient:
         A Device or entity that provides access to raw data or
         location data after processing or altering it or not.  Some
         location tracking scenarios may not involve a Location Server.

      Ultimate Location Recipient (ULR):
         An individual or entity who receives location data about a
         Target and does not transmit the location information or
         information based on the Target's location (such as driving
         directions to or from the target) to another party distinct
         from the target or the Rule-Maker.

      A data transporter may be an

      Initial Access Provider (“IAP”):
         A data transporter that provides the initial network access or
         other data communications services essential for the operation
         of communications functions of the Device or computer
         equipment in which the Device operates.  Most commonly, an IAP
         will be a wireless carrier, an Internet Service Provider, or
         an internal corporate network, used by the Target and the
         Target's Device and over which location services are provided
         or utilized.  In many cases the IAP is the location sighter.
         In some instances the IAP’s infrastructure may be owned and



   Cuellar, Morris, Mulligan      Expires Nov 2002                  6

                         Geopriv Requirements                 May 2002

         controlled by another party who should be identified.  Some
         location tracking scenarios may not involve any IAP.


   The rules of the Target may be accessible to a Location Server in the
   form of Private or Public Rules Repositories:

      Public Policy Repository:
         A repository where signed policies, identifiers, and perhaps
         also requests are stored.

      Private Policy Repository:
         A repository of authenticated policies, identifiers, and
         perhaps also requests are stored, for the private use of one
         Location Server.


     +------------------+-----+------+--------+---------+----------+
     |                  | IAP | ULR  | Public | Private | Location |
     |                  |     |      |   RR   |   RR    |  Sighter |
     +------------------+-----+------+--------+---------+----------+
     |Target            |     |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Device            |     |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Rule Maker        |  x  |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Unintended Target |     |      |        |         |          |
     +------------------+-----+------+--------+---------+----------+
     |Data Transporter  |  x  |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Location Seeker   |  x  |  x   |        |         |          |
     +------------------+-----+------+--------+---------+----------+
     |Location Server   |  x  |      |        |         |    x     |
     +------------------+-----+------+--------+---------+----------+
     |Rule Repository   |     |      |    x   |    x    |          |
     +------------------+-----+------+--------+---------+----------+


3.2. Data

   The main data used by the protocol is the Location Object. It
   contains the "sighting" information (the pair identity and location)
   and some other information to be determined, e.g. time information,
   some types of policies, authenticators, etc.  (If no time information
   is included, this implicitly means "at the current time" or "at a
   very recent time".)

      Sighting: the location information for a target. This is the main
         private data accessed by Location Servers and/or Ultimate
         Location Recipients.  This sighting information is probably



   Cuellar, Morris, Mulligan      Expires Nov 2002                  7

                         Geopriv Requirements                 May 2002

         included in the Location Object.  Abstractly, it consists of
         two separate data fields:

              (Sighting-Identifier, Location)

         Sighting-Identifier is the identifier assigned to a device
         being sighted, and Location is the current position of a
         device being sighted.

         Not all entities have access to exactly the same piece of
         sighting information.  The sighting may be transformed to a
         new sighting pair:

              (Sighting-Identifier-1, Location-1)

         before it is provided by  the Location Data Source or the
         Location Server to another Location Recipient.

      Policy:
         A set of rules that regulate an entity's activities with
         respect to location information, including the collection,
         use, disclosure, and retention of location information.  In
         particular, the policy describes how location information may
         be used by an entity and which transformed location
         information may be released to which entities under which
         conditions.  Policies contain "rules" or "assertions".
         Policies must be obeyed; they are not of advisory character.
         To make this more explicit, the term "rules" is also used
         instead of "policy".

   Data attributes:
      Filtered:
         Location information that has been computationally modified.


3.3. Identification, Authentication, and Authorization

   This subsection introduces some terms to be used later in the
   Requirements Section.

      Entity-Identifier: The names used by the entities of the protocol
         to identify, authenticate or authorize themselves to other
         entities.  Policies also use entity-identifiers to express
         which Location Seekers may receive which transformed sighting
         information.

   The next type of identifier may not be used as an Entity-Identifier,
   since it can be shared by several, perhaps many, different entities:

      Role identifier
         ("administrator", "member-of-club-A", etc.) The meaning of the
         role may be context dependent.


   Cuellar, Morris, Mulligan      Expires Nov 2002                  8

                         Geopriv Requirements                 May 2002


   People use the word authentication with different meanings.  Some
   people insist that authentication associates an entity with a more or
   less well-known identity.  This basically means that if A
   authenticates another entity as being "B", then the label "B" has
   also a meaning for many entities different from A.  In this case, the
   label "B" is called a publicly known identifier, and the
   authentication is "explicit":

      Explicit Authentication
         The act of verifying a claimed static identity easily linked
         back to the real identity of the user, in the form of a pre-
         existing label from a predefined name space, as the sole
         originator of a message (message authentication) or as the
         end-point of a channel (entity authentication).

      Authorization
         The act of determining if a particular right, such as access
         to some resource, can be granted to the presenter of a
         particular credential.

         Depending on the type of credential, authorization may imply
         Explicit Authentication or not.

3.4. Data Flows

   Figure 1 presents the entities of a "typical" protocol setting, using
   the Location Object and the data flows between those entities.  Not
   all steps discussed here necessarily occur in every scenario.  The
   data flows may be one-step message exchanges, or multi-step sub-
   protocols and the actual transport of the Location Object may be done
   via some other transport entities not included in the diagram.  The
   data flows to be considered by the geopriv WG, in the sense that WG
   will assess their authentication, authorization and privacy
   requirements, are the following.  They are shown in Figure 1 by
   normal arrows ("--->")

      LI (Location Information):
         the location data source sends the "full", raw location
         information to the location server.

      FLI (Filtered Location Information):
         The location server sends filtered location information to the
         Location Recipient.  The information is filtered in the sense
         that in general not the original information is being
         delivered, but for instance a less precise version of the
         information.

   There is no technical reason for distinguishing Location Information
   from Filtered Location Information; it is just a way of insisting
   that the information sent by the location server is (or could be)
   different from the information he has received.


   Cuellar, Morris, Mulligan      Expires Nov 2002                  9

                         Geopriv Requirements                 May 2002


      Pol (Policy):
         The Rule-Maker(or in particular, the target itself) sends a
         Policy to the location server.

      PolInfo (Policy Information):
         the server informs the Location Seeker which data type(s) of
         filtered location information are available to him for a given
         target.  This mechanism must be able to be invoked by the
         Location Seeker before he sends an LRequest.


      LRequest (Location Information Request):
         the Location Seeker requests location information for a
         target, a given class of targets, or for targets with a
         particular set of attributes.  In this request, the Location
         Seeker may select which location information data type it
         prefers.  The Location Seeker can also specify the need for
         periodic location information updates.


  +---------+   Locate    +-----------+
  | Location|<************| Location  |         SPol +------------+
  |  Data   |     LI      | Server +  |<*************| Public     |
  | Source  |------------>| Private   |         *    | Policy     |
  |  + IAP  |             | Repository|<---\    *    | Repository |
  +---------+             +-----------+    |    *    +------------+
                           ^ |    |        |    *            ^
                   LRequest| |FLI |PolInfo |    *            * SPol
                           | V    V        |    *            *
  +----------+             +-----------+   |    *            *
  | Target   |             | Location  |<**+****/        +----------+
  |   or     |<***********>| Server +  |   |             |          |
  |Rule-Maker|   Service   | Private   |   | <-----------|Rule-Maker|
  +----------+             | Repository|<--/     Pol     |          |
       ^                   +-----------+                 +----------+
       *                   ^ |    |
       *           LRequest| |FLI |PolInfo
       *                   | V    V
       *                  +----------+
       *                  | Ultimate |
       ******************>| Location |
              Service     | Recipient|
                          +----------+

                   Figure 1: The Entities and Data Flows

   The following Data Flows MAY be outside of the scope of the geopriv
   WG, but should be mentioned for understandability.  They are shown in
   Figure 1 as while starred arrows ("***>").




   Cuellar, Morris, Mulligan      Expires Nov 2002                 10

                         Geopriv Requirements                 May 2002

      Service: (Service Information, Negotiation and Delivery):
         The target (or the Rule-Maker) and the client exchange
         information about the service and negotiate it.  The client
         provides service delivery to the target and accounting or
         billing date, as necessary.

      SPol (Signed Policy):
         As an alternative to Pol, the Rule-Maker may write a policy
         and place it in the Open Repository.  The entities access the
         repository via SPol.

      Locate:
         Request to locate the target.  When a Location Server receives
         an LRequest for a target for which has no current location
         information, the server may send this "Locate" request to the
         Location Data Source.

3.4.1. Relationship framework

   Location information can be used in very different environments. In
   some cases the participants will have longstanding relationships
   while in others participants may have discrete interactions.

   The different relationships raise different concerns for the
   implementation of privacy rules, including the need to communicate
   privacy instructions. It is important that the Geopriv specification
   acknowledge the varied relationships between parties to location
   exchanges and set out a privacy framework suitable for each. A public
   rule repository for example seems to be superfluous in a trusted
   environment where more efficient methods of addressing privacy issues
   likely exist. We propose the following attributes as modifiers to a
   given data flow:

      Trusted:
         The data flow is governed by a contract that protects location
         privacy.

      Non-trusted:
         The data flow is not governed by a contract that protects
         location privacy.

3.4.2. Scenarios of Data Flow

   In this subsection we introduce two short scenarios to illustrate how
   these terms and attributes describe location information
   transactions.

   SCENARIO 1: GPS Device with Internal Computing Power: Closed System

   In this example, the target wishes to know his/her location using
   Global Positioning System (GPS) and the device is capable of
   independently processing the raw data to determine its location.  The


   Cuellar, Morris, Mulligan      Expires Nov 2002                 11

                         Geopriv Requirements                 May 2002

   location is derived as follows: the device receives transmissions
   from the GPS satellites, internally computes and displays location.
   This is a closed system.  For the purpose of this and subsequent
   examples, it is assumed that the GPS satellite broadcasts
   information, and has no capacity to record the identity or
   whereabouts of devices using the signal.


        GPS Satellite
                |
                |
                |
                |
                V             GPS Device
         --------------------------------------------------
        /                                                  \
        |  Data         -----  Location  -----  Location   |
        |  Transporter          Server            Storage  |
        \                                           |      /
         -------------------------------------------|------
                                                    |
                                        ------------|------
                                       /            V      \
                                      / Target    Location  \
                                      |           Seeker     |
                                      |                      |
                                      \    Rule-Maker       /
                                       \                   /
                                        -------------------

   In this scenario the GPS device is both the IAP and the LoSi. The
   interaction occurs in a Trusted environment because it occurs in the
   rulemaker’s device.

   SCENARIO 2:  Cell Phone Roaming: Cell Phone Company Outsourced
   Billing and IT

   In this example, a cell phone is used outside its home service area
   (roaming). Also, the cell phone service provider (cell phone Corp 2)
   outsourced the billing of cell phone usage. The cell phone is not
   GPS-enabled.  Location is derived by the cell phone network in which
   the target and device are roaming.  When the target wishes to use the
   cell phone, cell phone Corp 1 (IAP) provides the roaming service for
   the target, which sends the raw data about usage (e.g. duration of
   call, location ­ roaming network, etc.) to cell phone Corp 2, the
   home service provider.  Cell phone Corp 2 submits the raw data to the
   billing company which processes the raw data for the billing
   statements.  Finally, the raw data is sent to a data warehouse where
   the raw data is stored in a location server (e.g. computer server).





   Cuellar, Morris, Mulligan      Expires Nov 2002                 12

                         Geopriv Requirements                 May 2002


              Cell Phone Corp 1                 Cell Phone Corp 2
              -----------------                -----------------
  Sighting   /                 \  Sighting    /                 \
Device ---  | Data Transporter| ---------  | Data Transporter |
             \                 /              \                 /
              -----------------               / -----------------
Target                                       /         |
                                            /  sighting|
                                           /           |
                                -----------            |
                               /                       V
             ------------     /                  ----------
            /            \   /                  /          \
           /   Location   \ /                  |  Location  |
           |   Storage     |   Location Info   |  Storage   |
           |               |<----------------- |            |
           |   Location    |                   |  Location  |
           |   Seeker      |                   |  Seeker    |
            \             /                     \          /
             -------------                       ----------


   Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1
   could be  Non-trusted (the rulemaker does not have a contract
   protecting location information with corp 1 and there is no
   contractual relationship with privacy provisions between corp 1 and
   corp 2) or Trusted (contract with privacy protections between cell
   phone corp 2 and corp 1).  Cell phone corp 2 is Trusted.



3.5. Further explanations

   <Note: This section is unnecessarily long! Most of text will be
   removed afterwards, but it may be useful in the discussions.  The
   contents of this subsection may be out of the scope of the work of
   the working group.  They are presented here to facilitate the
   understanding, present some possible examples, or suggest why some
   requirements are feasible.>

3.5.1. Location Data Types

   Two apparently different data types may contain the same information
   if it is possible to transform one data type into the other and vice-
   versa without information loss.

   One location data type DT1 may contain more location information than
   another DT2 in at least two different senses:

      - DT1 may have the same dimensions as DT2 has, plus some extra
         ones.  (For instance, DT1 contains velocity, while DT2 does
         not).

   Cuellar, Morris, Mulligan      Expires Nov 2002                 13

                         Geopriv Requirements                 May 2002


      - DT1 may be more accurate than DT2.

   In general, if DT1 has more information than DT2, then there is one a
   function that "translates correctly" from DT1 to DT2.  There are
   other types of transformations that introduce errors (obfuscation:
   intentionally make the location values less accurate by adding
   randomness).  During a transformation, information can be lost, but
   not gained.  Of course, a transformation that merges information from
   several sources clearly increases the information of each one.  Thus
   a transformation is a filtering of information.  For instance there
   are transformation functions from both data types "(latitude,
   longitude, altitude)" and "(country, state, province, city)" to the
   data types "(country, state)" and "time zone", but not vice-versa.

   Notice that if the space regions determined by different location
   values of DT2 do not overlap, then there is at most one
   transformation from DT1 to DT2.  If the space regions of DT2 overlap,
   then usually there is some choice, which can be given by a (pseudo-)
   random function.

   If DT1 does not have more information than DT2, then there is no
   function that "translates correctly" from DT1 to DT2.  In other
   words: there are many functions that translate from DT1 to DT2, but
   all introduce some degree of error.  We believe that this kind of
   functions should be avoided.

3.5.2. Public Global Identities

   If A has some information about a public global identifier "ID" and A
   discloses this information to B, then B may associate this
   information with the same entity as A did.  In this way, B may
   accumulate information about the entity labeled by "ID".

   A public identity is a well-known label that identifies an entity for
   a (rather large) group of entities.

   A public identity may be the subscription identity at the home domain
   (if applicable), a well-known identity (name, address or Tel Number),
   etc.

   An entity may regard the disclosure of his public identity (in
   connection with some activity of him, his location or other
   attribute) as a violation of his privacy right.

3.5.3. Authorization without Explicit Authentication

   In order to remain anonymous, an entity may use private identifiers.
   Private identifiers convey less information than public identities,
   because they are meaningful to a smaller number of entities and in
   use for a shorter duration.  Thus if A discloses a private identifier



   Cuellar, Morris, Mulligan      Expires Nov 2002                 14

                         Geopriv Requirements                 May 2002

   to B, B is less likely to associate this information with a known
   individual or entity than if a public identifier was disclosed.

      Short-lived identifier
         an identifier that is used only for one or a limited number of
         "sessions".

   Short-lived identifiers may be used to anonymously authenticate
   entities in some settings.

   In many situations, including pre-paid services, token-based or role-
   based authorizations, unauthenticated key agreement, and purpose-
   based identifiers, there is no need for explicit authentication.

   Using weaker forms of authentication, the communication partner may
   still want to make sure that he is communicating to the same entity
   during the whole session, or that he is communicating with an
   authorized entity.  Thus message authentication codes are used, based
   on "unauthenticated keys".

   Authorization credentials may be used in the same way as
   authentication credentials to secure a key agreement in the following
   sense: one party is assured that no other party aside from the owner
   of the authorization credentials (and possibly additional identified
   trusted parties) may gain access to the agreed secret key.  The
   resulting keys are called authorized keys.  Those keys may be used
   for message authentication, without implying an explicit
   authentication.

   In real life this corresponds for instance to the following
   situation: at a cloakroom a person deposits his coat and receives a
   credential that he may use later to obtain back the coat.

   One possible goal of the Rule-Maker is to hide the identity of the
   Location Recipient to the Location Server.  Nevertheless, the
   Location Server has to be sure that the Rule-Maker has authorized the
   Recipient to access the location.  This is a case of authorization
   without explicit authentication: the Location Server has to be sure
   that the Location Recipient is a particular (i.e., authorized)
   communication partner of the Rule-Maker.

   This may be done for instance as follows: consider a Location Seeker
   that obtains a set of "traveller's cheques" from the Rule-Maker.  The
   cheques will be used to "buy" location information from a Location
   Service.  Initially, the Location Seeker signs for a first time the
   cheques with any "signature" that he wants to use.  The Rule-Maker,
   through his own signature, authorizes the signature of the Location
   Seeker.  When presented to the Location Server, the cheques may be
   countersigned so that the server is sure that the signer is the same
   as the one who was authorized by the Rule-Maker.  This
   countersignature does not only authenticate the Location Seeker to
   the verifier, but also indirectly to the Rule-Maker, when the cheque


   Cuellar, Morris, Mulligan      Expires Nov 2002                 15

                         Geopriv Requirements                 May 2002

   is later presented to him.  Incidentally, the Rule-Maker may achieve
   full information about who has accessed to his location information.

   To hide the real identity of the Rule-Maker to the Location Server,
   the following dual solution can be used.  The Rule-Maker buys (say,
   using e-cash) a service from a Location Seeker (e.g. a navigation
   service).  During this transaction, the Location Seeker and the Rule-
   Maker agree on one or several pseudonyms and a set of "traveller's
   cheques" that the target may use later to authenticate himself to the
   server and thus indirectly also to the Location Seeker.
   Since e-cash protocols may be also anonymous, this may be used to
   hide simultaneously,

          o the identity of the target from the Location Server,
          o the identity of the Location Seeker from the Location
             Server,
          o the identity of the target from the Location Seeker.

   But notice that the Location Data Source is in general not able to
   localize the target based on some short-lived identifier.  In this
   scenario, the Location Data Source should be a Location Server, a
   different one from the one from whom the identity of the target is to
   be hidden.


4. Requirements

4.1. Protocols

      Req. 1.  The geopriv protocol MUST be an embedded protocol: it
            defines a Location Object, together with the security
            mechanisms used to secure it.  The security mechanisms are
            of two types: on one hand the Location Object as such is
            secured, using cryptographic checksums or encryption as
            part of the Location Object itself, and on the other hand
            security mechanisms may be provided by the embedding
            transport protocol that uses the Location Object.  If
            possible, security mechanisms on the Location Object itself
            are to be preferred.

   We refer to the embedded protocol also as the geopriv protocol and to
   the combination of both the embedded protocol and the transport
   protocol as the combined protocol.

4.2. Policy based Location Data transfer

      Req. 2.  The decision of a Location Server to provide a Location
            Seeker access to location information is based on user-
            defined privacy policies.

      Req. 3.  The Location Data Source may be unaware of the full
            policies defined by the Rule-Maker, but in that case it


   Cuellar, Morris, Mulligan      Expires Nov 2002                 16

                         Geopriv Requirements                 May 2002

            will have to obey another set of "generic" policies,
            consented to by the Rule-Maker, to transfer Location Data
            (raw or not) to another entity.

      Req. 4.  An Ultimate Location Recipient does not need to be aware
            of the full policies defined by the Rule-Maker, but it will
            obey a set of policies regarding the use and retention of
            the location information.

4.3. Location Object, Location Data

      Req. 5.  The embedded protocol MUST define one Location Object
            (both in syntax and semantics) that must be supported by
            all geopriv entities.  Some fields of the Location Object
            MAY be opaque to the embedded protocol.

      Req. 6.  The Location Object MAY define at least one Location
            Data Type (both syntax and semantics) that must be
            supported by all geopriv entities, or the Location Data
            field(s) of the Location Object MAY be opaque.  The
            Location Object MAY define at least one Location Data Type

   When transmitting location information, (LI and FLI in Figure 1), the
   sender and the receiver must agree on the data type of the location
   information.  The combined protocol may specify that the data type
   information is part of the Location Object or that sender and
   receiver have agreed on it before the actual data transfer.  Thus

      Req. 7.  The Location Object MAY contain a field for the data
            type of the Location Data.  This field MAY also be opaque.

4.4. Policies

      Req. 8.  The Location Object MAY contain a field for policies
            that may be passed to the location server or may be stored
            in a public (open) repository.

      Req. 9.  The Location Object MAY contain a field for identifiers
            that may be passed to the location server or may be stored
            in a public (open) repository.

      Req. 10.  The Location Object MAY contain a field for requests
            from the clients.

      Req. 11.  The combined protocol MAY specify a policy language.
            This policy language MAY be an existing one, an adaptation
            of an existing one or a new policy language.

            If specified, the policy language MUST be strong enough to
            express policies of the form: a group G of clients are
            allowed to know a certain transformation A of the location



   Cuellar, Morris, Mulligan      Expires Nov 2002                 17

                         Geopriv Requirements                 May 2002

            L of a target together with a given identifier I of the
            target for a given purpose, for a given period of time.

            If specified, the policy language MUST be strong enough to
            express conditions on G and A as follows:
            G, the group of clients SHOULD be characterized by the
            possession of (identifiers, credentials) with a certain
            syntactic property.
            A, the transformation function MAY be specified by data
            type of the expected filtered location information.

            Within those constraints, the policy language SHOULD be as
            simple as possible, or it SHOULD be an existing policy
            language.

4.5. Identity Protection

      Req. 12.  When a location server accepts a policy that uses a
            role identifier, the Rule-Maker MUST prove the ownership of
            the claimed role identifier.  This is a property of the
            combined protocol.

      Req. 13.  The combined protocol MUST be able to hide the real
            identity and static identifiers association with the real
            identity of the Rule-Maker, the target, and the device from
            the Ultimate Location Recipient.

   This may be easily done using short-lived or role identifiers.

      Req. 14.  The combined protocol MUST be able to hide the real
            identity of the Location Recipient to the Location Server.

   <Give an example where hiding the identity of the Location Recipient
   is what should be required: The target is not concerned about the
   Server identifying him and knowing his location, but identifying his
   business partners, and therefore habits, etc.>

      Req. 15.  The combined protocol MUST be able to hide the real
            identity of the Rule-Maker to a Location Seeker, including
            a Location Server.

4.6. Authentication Requirements

      Req. 16.  The combined protocol MUST allow different
            authentication schemes. The combined protocol MUST
            guarantee that appropriate keys (shared or asymmetric) are
            generated and available to secure the Location Object
            within the embedded protocol.

      Req. 17.  The combined protocol MUST allow authorization without
            explicit authentication.



   Cuellar, Morris, Mulligan      Expires Nov 2002                 18

                         Geopriv Requirements                 May 2002

4.7. Actions to be secured

      Req. 18.  The embedded protocol MUST be able to secure the
            Location Object for the following message flows (mutual
            end-point authentication, data object integrity, data
            object confidentiality, replay protection, in the absence
            of a time parameter): LI, Pol, LIF, LRequest, and PolInfo.

      Req. 19.  The embedded protocol MUST specify a minimum mandatory
            to implement Location Object security including mandatory
            to implement crypto transforms.

      Req. 20.  The embedding protocol MAY provide extra security for
            these flows (hop-by-hop or end-to-end).

   In full details, these requirements have many consequences: the
   communicating parties MUST have security relationships between them,
   allowing them to construct secure channels between them.  This may
   imply that some scenarios should not be permitted in general.  The
   Rule-Maker MAY choose to use the security provided by the embedded or
   by the embedding protocol, or none.

      Req. 21.  When a Location Server accepts a policy from the Rule-
            Maker, the target MUST prove to the combined protocol that
            he owns the claimed group or role identifier that should be
            passed to the Location Recipient.

   (For instance, if a Target wants the role identifier "medical doctor"
   to be passed to a Location Recipient, the Target must prove the
   claims to be a medical doctor.)

      Req. 22.  The "generic" policies (as opposed to the policies
            created by the Rule-Maker) used by the Location Data
            Source, by the Ultimate Location Recipients and by the
            Location Server of some special scenarios to be discussed
            yet MUST be made explicit.


5. Security Considerations

   The purpose of the geopriv protocol is to allow a policy-controlled
   disclosure of location information for location services.  Only the
   information carried within the Location Object is secured in a way
   compliant with the privacy and security policies of the target.  This
   does not mean that geopriv secures the target against general traffic
   analysis attacks or other forms of privacy violations.

   The Location Server is assumed to be trustworthy.

6. References




   Cuellar, Morris, Mulligan      Expires Nov 2002                 19

                         Geopriv Requirements                 May 2002

   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
          Levels", BCP 14, RFC 2119, March 1997.


7. Author's Addresses

   Jorge R Cuellar
   Siemens AG
   Corporate Technology
   CT IC 3
   81730 Munich                   Email:  Jorge.Cuellar@mchp.siemens.de
   Germany

   John B. Morris, Jr.
   Director, Internet Standards, Technology & Policy Project
   Center for Democracy and Technology
   1634 I Street NW, Suite 1100
   Washington, DC 20006                         Email:  jmorris@cdt.org
   USA                                               http://www.cdt.org

   Deirdre K. Mulligan
   Samuelson Law, Technology and Public Policy Clinic
   Boalt Hall School of Law
   University of California
   Berkeley, CA 94720-7              Email:  dmulligan@law.berkeley.edu

8. Full Copyright Statement

   Copyright (C) The Internet Society (date).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Cuellar, Morris, Mulligan      Expires Nov 2002                 20

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/