J. Cuellar
Internet Draft                                                 M. Ersue
Document: draft-cuellar-geopriv-reqs-01.txt                  Siemens AG
Expires: 2002                                                  Feb 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 such a geopriv protocol
   used to transfer location data, focusing on authorization, integrity
   and privacy.





   Cuellar, Ersue       Expires September 2002                       1

                         Geopriv Requirements               March 2002

Table of Contents

    1. Overview.......................................................2
    2. Conventions used in this document..............................3
    3. Usage Model....................................................3
       3.1. Entities..................................................3
       3.2. Data......................................................4
       3.3. Identification, Authentication, and Authorization.........5
       3.4. Data Flows................................................5
       3.5. Further explanations......................................7
          3.5.1. Location Data Types..................................8
          3.5.2. Public Global Identities.............................8
          3.5.3. Authorization without Explicit Authentication........9
    4. Requirements..................................................10
       4.1. Location information formats.............................10
       4.2. Policies.................................................11
       4.3. Identity Protection......................................11
       4.4. Authentication Requirements..............................12
       4.5. Actions to be secured....................................12
       4.6. Transport Requirements...................................12
    5. Security Considerations.......................................12
    6. References....................................................13
    7. Author's Addresses............................................13
    8. Full Copyright Statement......................................13

1. Overview

   The main principles 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. That is, using policies, the
      user is able to specify which 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. 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.



   Cuellar, Ersue       Expires September 2002                       2

                         Geopriv Requirements               March 2002

   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

3.1. Entities

   The draft [2] introduces the following 5 functional elements (or
   "entities" of the protocol). Please refer to that draft for a
   discussion of the functionality of the entities and for a
   description of scenarios.

      Target: The entity whose location is desired by the Location
         Recipient.

      Owner of the privacy rights of the target, or, for abbreviation,
         the owner, or Rule maker, or policy maker: An entity that has
         the authorization to detemine and write the privacy policies
         that apply to the location information of the target. Other
         probably better names are "policy maker" or "rule maker"

      Location Server (or "Intermediate Location Receiver"): Entity
         offering Location Service capabilities based on user-defined
         privacy policies.

      Ultimate Location Recipient: A Location Recipient that is the
         ultimate recipient of the location information (he may not
         pass this information, or derived one, to others, except to
         the target or the owner). This entity does not need to be
         aware of the policies defined by the owner, but it will obey a
         set of "generic" policies.

      Location Data Source: The original source of the sighting. For
         technical reasons, mentioned in [2], the Location Data Source

   Cuellar, Ersue       Expires September 2002                       3

                         Geopriv Requirements               March 2002

         may be also unaware of the policies defined by the owner, but
         it will also then obey another set of "generic" policies.

   Further, we also consider here the following entities:

      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.

3.2. Data

   The main data used by the protocol is the "sighting" (the pair
   identity and location) and the policies.

      Sighting: the private data accessed by the Location Data Source
         and Location Recipients. Abstractly, it is seen as a pair:

              (Sighting-Identifier, Location)

         expressing the assertion that the target identified by "
         Sighting-Identifier" is currently at position "Location". (In
         practice, this pair may include also a time component. For
         shortness, we assume no time information, implicitly meaning
         "at the current time" or "at a very recent time".)

         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 being forwarded by the Location Data Source or by the
         Location Server to another Location Recipient.

      Sighting-Identifier: The first component of the sighting, used to
         identify the target.

      Location: The second component of the sighting, used to describe
         the current position of the target.

      Policy: An assertion that a certain transformed sighting
         information may be released to a certain entity (or group of
         entities) under a certain set of conditions. Policies are said
         to contain "rules" or "assertions".
         Policies in this sense (as in many other uses at the IETF)
         must be obeyed, they are not of advisory charachter. To make
         this more explicit, the term: "rule" has been also proposed to

   Cuellar, Ersue       Expires September 2002                       4

                         Geopriv Requirements               March 2002

         replace "policy", then being a "rule" composed of different
         "assertions".

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 Recipients may receive which transformed
         sighting information.

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

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

   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 identity, in the form of a pre-
         existing label from a publicly known 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 the protocol and the data flows
   between them. (The data flows MAY be one-step message exchanges, or
   multi-step sub-protocols). The data flows to be considered by the
   geopriv WG, in the sense that WG will assess their authentication,
   authorization and privacy requirements, are:

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

   Cuellar, Ersue       Expires September 2002                       5

                         Geopriv Requirements               March 2002


      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
         full information is being delivered, but only 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.

      Pol (Policy): An owner of the target (or in particular, the
         target itself) sends a Policy to the location server.

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


      LRequest (Location Information Request): the Location Recipient
         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 Recipient may select which
         location information data type it prefers. The Location
         Recipient can also specify the need for periodic location
         information updates.

























   Cuellar, Ersue       Expires September 2002                       6

                         Geopriv Requirements               March 2002


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

                   Figure 1: The Entities and Data Flows
      Normal arrows ("--->") are part of the scope of the geopriv WG,
                 starred arrows ("***>") are probably not.

   The following Data Flows MAY be outside of the scope of the geopriv
   WG, but should be mentioned for understandability:

      Service: (Service Information, Negotiation and Delivery): The
         target (or the owner of the target) 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 owner of the
         target 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"
         command to the Location Data Source.

3.5. Further explanations

   Note: The contents of this subsection may be out of the scope of the
   work of the working group. They are presented here only to
   facilitate the understanding, present some possible examples, or
   suggest why some requirements are feasible.

   Cuellar, Ersue       Expires September 2002                       7

                         Geopriv Requirements               March 2002


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).

      - 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. 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.


   Cuellar, Ersue       Expires September 2002                       8

                         Geopriv Requirements               March 2002

   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.
   The idea is that private identifiers convey less information than
   public identities, are meaningful to a smaller amount of entities,
   or are meaningful only for a quite short period of time. Thus if A
   has some information about a private identifier "ID" and A discloses
   this information to B, then it is quite probable that B may not
   associate this information with any identifier that he currently
   knows.

      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 identify entities
   at least for a small period of time or by a small group of entities.

   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 Owner is to hide the identity of the
   Location Recipient to the Location Server. Nevertheless, the Location
   Server has to be sure that the Owner 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 Owner.

   Cuellar, Ersue       Expires September 2002                       9

                         Geopriv Requirements               March 2002


   This may be done for instance as follows: consider a Location
   Recipient that obtains a set of "traveller's cheques" from an owner
   of the privacy rights of a target. The cheques will be used to "buy"
   location information from a Location Service. Initially, the Location
   Recipient signs for a first time the cheques with any "signature"
   that he wants to use. The owner, through his own signature,
   authorizes the signature of the Location Recipient. 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 owner. This countersignature does not only
   authenticate the Location Recipient to the verifier, but also
   indirectly to the owner, when the cheque is later presented to him.
   Incidentally, the owner may achieve full information about who has
   accessed to his location information.

   To hide the real identity of the owner to the Location Server, the
   following dual solution can be used. An owner buys (say, using e-
   cash) a service from a Location Recipient (e.g. a navigation
   service). During this transaction, the Location Recipient and the
   owner 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 Recipient.
   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 Recipient from the Location
             Server,
          o the identity of the target from the Location Recipient.

   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. Location information formats

      Req. 1.  The protocol MAY define at least one location data type
            (both syntax and semantics) that must be supported by all
            geopriv entities.

      Req. 2.  When transmitting location information, (LI and LIF in
            Figure 1), the sender and the receiver MUST agree on the
            data type of the location information. The protocol MAY
            specify that the data type information is part of the same
            message as the location information object or that sender


   Cuellar, Ersue       Expires September 2002                      10

                         Geopriv Requirements               March 2002

            and receiver have agreed on it before the actual data
            transfer.

4.2. Policies

      Req. 3.  The protocol MAY specify the format of signed policies
            and identifiers that may be passed to the location server
            by other means besides the data flow Pol. For instance,
            such signed policies may be stored in a public (open)
            repository.

            This repository could also be used for location information
            requests from the clients. In that case, the protocol MAY
            specify the format of signed requests.

            The protocol MAY specify the data flow SPol, used to access
            the Public repository. In that case it MAY also specify the
            access control rules to the repository.

      Req. 4.  The 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
            L of a target together with a given identifier I of the
            target.

            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.3. Identity Protection

      Req. 5.  When a location server accepts a policy that uses a role
            identifier, the owner MUST prove the ownership of the
            claimed role identifier.

      Req. 6.  The protocol MUST be able to hide the real identity of
            the owner or target to the Ultimate Location Recipient.

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



   Cuellar, Ersue       Expires September 2002                      11

                         Geopriv Requirements               March 2002

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

      Req. 8.  The protocol MUST be able to hide the real identity of
            the owner to a Location Recipient, including a Location
            Server.

4.4. Authentication Requirements

      Req. 9.  The protocol MUST allow different authentication schemes

      Req. 10.  The protocol MUST allow authorization without explicit
            authentication.

4.5. Actions to be secured

      Req. 11.  The following message flows should be secured (mutual
            end-point authentication, data object integrity, data
            object confidentiality, replay protection): LI, Pol, LIF,
            LRequest, and PolInfo. In full details an with all its
            consequences, this requirement is not trivial to achieve:
            the communicating parties MUST have security relationships
            between them, allowing them to dynamically construct secure
            channels between them. This may imply that some scenarios
            should not be permitted in general.

      Req. 12.  When a Location Server accepts a policy from an owner,
            the target MUST prove the ownership of the claimed group or
            role identifier that should be passed to the Location
            Recipient.

      Req. 13.  The "generic" policies (as opposed to the policies
            created by the owner of the privacy) used by the Location
            Data Source, by the Ultimate Location Data Recipients and
            by the Location Server of Scenario 3 of [2] MUST be made
            explicit.

4.6. Transport Requirements

   There are many possible requirements that one could foresee. For
   instance, as in [3]: The protocol SHALL support UDP transport with
   retry timers for reliability. The protocol SHOULD support TCP as an
   optional transport and it MAY support RTP and/or SCTP as optional
   transports. Another possibility would be that:

      Req. 14.  The protocol is transport "agnostic", that is, the
            protocol MUST allow use of different transports.

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 by this protocol is secured in a way compliant

   Cuellar, Ersue       Expires September 2002                      12

                         Geopriv Requirements               March 2002

   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

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

   [2] Cuellar, Ersue, and Takahashi.: Geopriv Scenarios, draft-
          cuellar-geopriv-scenarios-00.txt, work in progress.

   [3] Rosen, et. al.: Geolocation/Privacy Object Requirements, draft-
          rosen-geopriv-requirements-00.txt, work in progress.

7. Author's Addresses

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

   Mehmet Ersue
   Siemens AG
   Information and Communication Mobile
   ICM N PG SP ST SA 1
   81359 Munich                     Email:  Mehmet.Ersue@icn.siemens.de
   Germany

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.

   Cuellar, Ersue       Expires September 2002                      13

                         Geopriv Requirements               March 2002


   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, Ersue       Expires September 2002                      14