GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3693

Network Working Group J. Cuellar Request for Comments: 3693 Siemens AG Category: Informational J. Morris

                                     Center for Democracy & Technology
                                                           D. Mulligan
                      Samuelson Law, Technology & Public Policy Clinic
                                                           J. Peterson
                                                               NeuStar
                                                               J. Polk
                                                                 Cisco
                                                         February 2004
                        Geopriv Requirements

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2004).  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 (such as
 a user, resource or other entity).  There is a need to securely
 gather and transfer location information for location services, while
 at the same time protect the privacy of the individuals involved.
 This document focuses on the authorization, security and privacy
 requirements for such location-dependent services.  Specifically, it
 describes the requirements for the Geopriv Location Object (LO) and
 for the protocols that use this Location Object.  This LO is
 envisioned to be the primary data structure used in all Geopriv
 protocol exchanges to securely transfer location data.

Cuellar, et al. Informational [Page 1] RFC 3693 Geopriv Requirements February 2004

Table of Contents

 1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Conventions Used in this Document. . . . . . . . . . . . . . .  4
 3.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
 4.  Primary Geopriv Entities . . . . . . . . . . . . . . . . . . .  6
 5.  Further Geopriv Terminology. . . . . . . . . . . . . . . . . .  7
     5.1.  Location Information and Sighting. . . . . . . . . . . .  7
     5.2.  The Location Object and Using Protocol . . . . . . . . .  9
     5.3.  Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10
     5.4.  Further Geopriv Principals . . . . . . . . . . . . . . . 10
     5.5.  Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12
     5.6.  Identifiers, Authentication and Authorization. . . . . . 13
 6.  Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15
 7.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.1.  Location Object. . . . . . . . . . . . . . . . . . . . . 19
     7.2.  The Using Protocol . . . . . . . . . . . . . . . . . . . 21
     7.3.  Rule based Location Data Transfer. . . . . . . . . . . . 21
     7.4.  Location Object Privacy and Security . . . . . . . . . . 22
           7.4.1.  Identity Protection. . . . . . . . . . . . . . . 22
           7.4.2.  Authentication Requirements. . . . . . . . . . . 23
           7.4.3.  Actions to be secured. . . . . . . . . . . . . . 23
     7.5.  Non-Requirements . . . . . . . . . . . . . . . . . . . . 24
 8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 24
     8.1.  Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24
     8.2.  Securing the Privacy Rules . . . . . . . . . . . . . . . 24
     8.3.  Emergency Case . . . . . . . . . . . . . . . . . . . . . 24
     8.4.  Identities and Anonymity . . . . . . . . . . . . . . . . 25
     8.5.  Unintended Target. . . . . . . . . . . . . . . . . . . . 26
 9.  Protocol and LO Issues for later Consideration . . . . . . . . 26
     9.1.  Multiple Locations in one LO . . . . . . . . . . . . . . 26
     9.2.  Translation Fields . . . . . . . . . . . . . . . . . . . 26
     9.3.  Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27
     9.4.  Timing Information Format. . . . . . . . . . . . . . . . 27
     9.5.  The Name Space of Identifiers. . . . . . . . . . . . . . 27
 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     11.1. Normative Reference  . . . . . . . . . . . . . . . . . . 28
     11.2. Informative References . . . . . . . . . . . . . . . . . 28
 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30

Cuellar, et al. Informational [Page 2] RFC 3693 Geopriv Requirements February 2004

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
 Target can have important privacy implications.  A key goal of the
 protocol described in this document is to facilitate the protection
 of privacy pursuant to Privacy Rules set by the "user/owner of the
 Target" (or, more precisely in the terminology of this document given
 in Section 3 and 5.4 below, the "Rule Maker").
 The ability to gather and generate a Target'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 Privacy Rules of the user.
 The main principles guiding the requirements described in this
 document are:
 1) Security of the transmission of Location Object is essential to
    guarantee the integrity and confidentiality of the location
    information.  This includes authenticating the sender and receiver
    of the Location Object, and securing the Location Object itself.
 2) A critical role is played by user-controlled Privacy Rules, which
    describe the restrictions imposed or permissions given by the
    "user" (or, as defined below, the "Rule Maker").  The Privacy
    Rules specify the necessary conditions that allow a Location
    Server to forward Location Information to a Location Recipient,
    and the conditions and purposes for which the Location Information
    can be used.
 3) One type of Privacy Rules specify how location information should
    be filtered, depending on who the recipient is.  Filtering is the
    process of reducing the precision or resolution of the data.  A
    typical rule may be of the form: "my location can only be
    disclosed to the owner of such credentials in such precision or
    resolution" (e.g., "my co-workers can be told the city I am
    currently in").
 4) The Location Object should be able to carry a limited but core set
    of Privacy Rules.  The exact form or expressiveness of those Rules
    in the core set or in the full set is not further discussed in
    this document, but will be discussed more extensively in future
    documents produced by this working group.

Cuellar, et al. Informational [Page 3] RFC 3693 Geopriv Requirements February 2004

 5) Whenever appropriate, 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 (i.e.,
    Personally Identifiable Information such as a name, mailing
    address, phone number, social security number, or email address or
    username).  Rather, the user should be able to specify which local
    identifier, unlinked pseudonym, or private identifier is to be
    bound to the location information.
 6) 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 for some
 applications because of legal constraints or because some location
 services may in fact need explicit identifications, most often 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 [RFC2119].
 Note that the requirements discussed here are requirements on the
 generic Location Object and on using protocols for location services.
 Thus, for the most part, the requirements discussed in this document
 refer to capabilities that are mandatory-to-implement.  For example,
 requiring that implementations support integrity is not the same
 thing as requiring that all protocol traffic be authenticated.  In
 contrast, an example of a mandatory-to-use (not just mandatory-to-
 implement) requirement might be one that states that the user always
 receives a notice when his location data was not authenticated.  This
 practice is mandatory-to-use, not just to implement.

3. Glossary

 For easy reference and readability, below are basic terms that will
 be defined more formally and fully later in this document.
    Location Generator (LG): The entity that initially determines or
       gathers the location of the Target and creates Location Objects
       describing the location of the Target.

Cuellar, et al. Informational [Page 4] RFC 3693 Geopriv Requirements February 2004

    Location Object (LO): An object conveying location information
       (and possibly privacy rules) to which Geopriv security
       mechanisms and privacy rules are to be applied.
    Location Recipient (LR): The entity that receives location
       information.  It may have asked for this location explicitly
       (by sending a query to a location server), or it may receive
       this location asynchronously.
    Location Server (LS): The entity to which a LG publishes location
       objects, the recipient of queries from location receivers, and
       the entity that applies rules designed by the rule maker.
    Precision: The number of significant digits to which a value has
       been reliably measured.
    Principal: The holder/subject of the credentials, e.g., a
       workstation user or a network server.
    Resolution: The fineness of detail that can be distinguished in a
       measured area.  Applied to Geopriv this means the finite area
       within provided and closed borders (ex. Latitude and Longitude
       boundaries).
    Rule Holder: The entity that provides the rules associated with a
       particular target for the distribution of location information.
       It may either 'push' rules to a location server, or a location
       server may 'pull' rules from the Rule Holder.
    Rule Maker: The authority that creates rules governing access to
       location information for a target (typically, this it the
       target themselves).
    Rule, or Privacy Rule: A directive that regulates an entity's
       activities with respect to location information, including the
       collection, use, disclosure, and retention of location
       information.
    Target: A person or other entity whose location is communicated by
       a Geopriv Location Object.
    Using Protocol: A protocol that carries a Location Object.
    Viewer: A Principal that consumes location information that is
       communicated by a Geopriv Location Object, but does not pass
       this information further.

Cuellar, et al. Informational [Page 5] RFC 3693 Geopriv Requirements February 2004

 Resolution and Precision are very close terms.  Either quality can be
 'reduced' to coarsen location information: 'resolution' by defining a
 off-center perimeter around a user's location or otherwise enlarging
 the area in consideration (from state to country, say) and
 'precision' by discarding significant digits of positioning
 information (rounding off longitude and latitude from seconds to
 minutes, say).  Another WG document discusses this topic in much more
 detail.

4. Primary Geopriv Entities

 The following picture shows the primary Geopriv entities in a simple
 and basic architecture, without claim of completeness or any
 suggestion that the entities identified must in all cases be
 physically separate entities.
                            +----------+
                            |  Rule    |
                            | Holder   |
                            |          |
                            +----+-----+
                                 |
                             rule|interface
                                 V
 +----------+               +----------+               +----------+
 |Location  |  publication  | Location |  notification |Location  |
 |Generator +-------------->| Server   +-------------->|Recipient |
 |          |  interface    |          |  interface    |          |
 +----------+               +----------+               +----------+
 The four primary Entities are described as follows:
    Location Generator (LG):  The entity that initially determines or
       gathers the location of the Target and creates Location Objects
       describing that location.  LGs publish Location Objects to
       Location Servers.  The manner in which the Location Generator
       learns of Location Information is outside the scope of the
       Geopriv Protocol.
    Location Server (LS): The LS is an element that receives
       publications of Location Objects from Location Generators and
       may receive subscriptions from Location Recipients.  The LS
       applies the rules (which it learns from the Rule Holder) to LOs
       it receives from LGs, and then notifies LRs of resulting LOs as
       necessary.

Cuellar, et al. Informational [Page 6] RFC 3693 Geopriv Requirements February 2004

    Location Recipient (LR): The LR is an element that receives
       notifications of Location Objects from Location Servers.  The
       LR may render these LOs to a user or automaton in some fashion.
    Rule Holder (RH): The RH is an element that houses Privacy Rules
       for receiving, filtering and distributing Location Objects for
       specific Targets.  An LS may query an RH for a set of rules, or
       rules may be pushed from the RH to an LS.  The rules in the
       Rule Holder are populated by the Rule Maker.
 Thus Location Generation is the process of gathering Location
 Information, perhaps from multiple sources, at an IP-based Geopriv
 Entity, the LG, which communicates with other Geopriv Entities.
 Rules MUST be authenticated and protected.  How this is done and in
 particular how to distribute the keys to the RM and other authorities
 is outside of the scope of this document.  See also Section 8.2,
 "Securing the Privacy Rules".
 The interfaces between the Geopriv entities are not necessarily
 protocol interfaces; they could be internal interfaces within a
 single composed device.  In some architectures, the Location
 Generator, Rule Holder, and Location Server might all be implemented
 in the same device.  There may be several Rule Holders that enforce
 the Privacy Rules at a particular Location Server.

5. Further Geopriv Terminology

 The terminology and definitions detailed below include both terms
 that, besides the primary Geopriv entities, (1) are used in the
 requirements section of this document, and (2) provide additional
 detail about the usage model envisioned for the Geopriv Location
 Object.  These latter terms will be utilized in a separate scenarios
 document and elsewhere.

5.1. Location Information and Sighting

 The focus of the Geopriv working group is on information about a
 Target's location that is NOT based on generally or publicly
 available sources, but instead on private information provided or
 created by a Target, a Target's Device, or a Target's network or
 service provider.  Notwithstanding this focus on private location
 information, the Geopriv Location Object could certainly be used to
 convey location information from publicly available sources.
    Location Information: A relatively specific way of describing
       where a Device is located.

Cuellar, et al. Informational [Page 7] RFC 3693 Geopriv Requirements February 2004

 This Location Information may have been determined in many different
 ways, including:
 (a) derived or computed from information generally not available to
 the general public (such as information mainly available to a network
 or service provider), (b) determined by a Device that may not be
 generally publicly addressable or accessible, or (c) input or
 otherwise provided by a Target.
 As examples, the Location Information could include (a) information
 calculated by triangulating on a wireless signal with respect to cell
 phone towers, (b) longitude and latitude information determined by a
 Device with GPS (global positioning satellite) capabilities, (c)
 information manually entered into a cell phone or laptop by a Target
 in response to a query, or (d) automatically delivered by some other
 IP protocol, such as at device configuration via DHCP.
 Excluded from this definition 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.  In some
 cases, information like IP address can enable someone to estimate (at
 least roughly) a location.  Commercial services exist that provide
 rough location information based on IP addresses.  Currently, this
 type of location information is typically less precise than the type
 of location information addressed in this document.  Although this
 type of location computation still raises significant potential
 privacy and public privacy concerns, such scenarios are generally
 outside the scope of this document.
 Within any given location-based transaction, the INITIAL
 determination of location (and thus the initial creation of Location
 Information) is termed a Sighting:
    Sighting:
       The initial determination of location based on non-public
       information (as discussed in the definition of Location
       Information), and the initial creation of Location Information.
 Some variant of the sighting information is included in the Location
 Object.  Abstractly, it consists of two separate data fields:
          (Identifier, Location)

Cuellar, et al. Informational [Page 8] RFC 3693 Geopriv Requirements February 2004

 where Identifier is the identifier assigned to a Target being
 sighted, and Location is the current position of that Target being
 sighted.  Not all entities may have access to exactly the same piece
 of sighting information.  A sighting may be transformed to a new
 sighting pair:
          (Identifier-1, Location-1)
 before it is provided by a Location Generator or Location Server to
 Location Recipient.  In this case, Identifier-1 may be a Pseudonym,
 and Location-1 may have less precision or resolution than the
 original value.

5.2. The Location Object and Using Protocol

 A main goal of the Geopriv working group is to define a Location
 Object (LO), to be used to convey both Location Information and basic
 privacy-protecting instructions:
    Location Object (LO): This data contains the Location Information
       of the Target, and other fields including an identity or
       pseudonym of the Target, time information, core Privacy Rules,
       authenticators, etc.  Most of the fields are optional,
       including the Location Information itself.
 Nothing is said about the semantics of a missing field.  For
 instance, a partially filled object MAY be understood implicitly as a
 request to complete it.  Or, if no time information is included, this
 MAY implicitly mean "at the current time" or "at a very recent time",
 but it could be interpreted in a different way, depending on the
 context.
 The "using protocol" is the protocol that uses (reads or modifies)
 the Location Object.  A protocol that just transports the LO as a
 string of bits, without looking at them (like an IP storage protocol
 could do), is not a using protocol, but only a transport protocol.
 Nevertheless, the entity or protocol that caused the transport
 protocol to move the LO is responsible for the appropriate
 distribution, protection, usage, retention, and storage of the LO
 based on the rules that apply to that LO.
 The security and privacy enhancing mechanisms used to protect the LO
 are of two types: First, the Location Object definition MUST include
 the fields or mechanisms used to secure the LO as such.  The LO MAY
 be secured, for example, using cryptographic checksums or encryption
 as part of the LO itself.  Second, the using protocol may also
 provide security mechanisms to securely transport the Location
 Object.

Cuellar, et al. Informational [Page 9] RFC 3693 Geopriv Requirements February 2004

 When defining the LO, the design should observe that the security
 mechanisms of the Location Object itself are to be preferred.  Thus
 the definition of the LO MUST include some minimal crypto
 functionality (Req. 14 and 15).  Moreover, if the RM specifies the
 use of a particular LO security mechanism, it MUST be used (Req. 4).

5.3. Trusted vs. Non-trusted Data Flows

 Location information can be used in very different environments.  In
 some cases, the participants will have longstanding relationships,
 while in others the participants may have discrete interactions with
 no prior contractual or other contact.
 The different relationships raise different concerns for the
 implementation of privacy rules, including the need to communicate
 Privacy Rules.  A public Rule Holder, for example, may be unnecessary
 in a trusted environment where more efficient methods of addressing
 privacy issues exist.  The following terms distinguish between the
 two basic types of data flows:
    Trusted Data Flow:
       A data flow that is governed by a pre-existing contractual
       relationship that addresses location privacy.
    Non-trusted Data Flow:
       The data flow is not governed by a pre-existing contractual
       relationship that addresses location privacy.

5.4. Further Geopriv Principals

    Target:
       The entity whose location is desired by the Location Recipient.
       In many cases the Target will be the human "user" of a Device
       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 whereby the location is tracked as a proxy
       for the location of a Target.
 A Device might, for example, be a cell phone, 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, such as when a Target manually inputs
 location information (perhaps with a web browser), the Target is
 effectively performing the function of a Device.

Cuellar, et al. Informational [Page 10] RFC 3693 Geopriv Requirements February 2004

    Rule Maker (RM):
       The individual or entity that has the authorization to set the
       applicable Privacy Rules for a potential Geopriv Target.  In
       many cases this will be the owner of the Device, and in other
       cases this may be the user who is in possession of the Device.
       For example, parents may control what happens to the location
       information derived from a child's cell phone.  A company, in
       contrast, may own and provide a cell phone to an employee but
       permit the employee to set the privacy rules.
       There are four scenarios in which some form of constraint or
       override might be placed on the Privacy Rules of the Rule
       Maker:
       1. In the case of emergency services (such as E911 within the
          United States), local or national laws may require that
          accurate location information be transmitted in certain
          defined emergency call situations.  The Geopriv Working
          Group MUST facilitate this situation.
       2. In the case of legal interception, the RM may not be aware
          of an override directive imposed by a legal authority.  It
          is not the expectation of the Working Group that a
          particular accommodation will be made to facilitate this
          situation.
       3. In the context of an employment relationship or other
          contractual relationship, the owner of a particular location
          (such as a corporate campus) may impose constraints on the
          use of Privacy Rules by a Rule Maker.  It is not the
          expectation of the Working Group that a particular
          accommodation will be made to facilitate this situation.
       4. It is conceivable that a governmental authority may seek to
          impose constraints on the use of Privacy Rules by a Rule
          Maker in non-emergency situations.  It is not the
          expectation of the Working Group that a particular
          accommodation will be made to facilitate this situation.
    Viewer:
       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 any party OTHER than the
       Target or the Rule Maker.

Cuellar, et al. Informational [Page 11] RFC 3693 Geopriv Requirements February 2004

    Data Transporter:
       An entity or network 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 Server, a Location Server and a second
       Location Server, or a Location Server and a Viewer.  Some
       location tracking scenarios may not involve a Data Transporter.
    Access Provider (AP):
       The domain 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.  Often, the AP -- which will be a
       wireless carrier, an Internet Service Provider, or an internal
       corporate network -- contains the LG.  Sometimes the AP has a
       "dumb" LG, one that transmits Geopriv LOs but does not use any
       part of the Geopriv Location Object.  Other cases may not
       involve any AP, or the AP may only act as a Data Transporter.
    Location Storage:
       A Device or entity that stores raw or processed Location
       Information, such as a database, for any period of time longer
       than the duration necessary to complete an immediate
       transaction regarding the Location Information.
 The existence and data storage practices of Location Storage is
 crucial to privacy considerations, because this may influence what
 Location Information could eventually be revealed (through later
 distribution, technical breach, or legal processes).

5.5. Privacy Rules

 Privacy Rules are rules that regulate an entity's activities with
 respect to location and other information, including, but not limited
 to, the collection, use, disclosure, and retention of location
 information.  Such rules are generally based on fair information
 practices, as detailed in (for example) the OECD Guidelines on the
 Protection of Privacy and Transporter Flows of Personal Data [OECD].
    Privacy Rule:
       A rule or 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 Rule describes how location information may be
       used by an entity and which transformed location information
       may be released to which entities under which conditions.
       Rules must be obeyed; they are not advisory.

Cuellar, et al. Informational [Page 12] RFC 3693 Geopriv Requirements February 2004

 A full set of Privacy Rules will likely include both rules that have
 only one possible technical meaning, and rules that will be affected
 by a locality's prevailing laws and customs.  For example, a
 distribution rule of the form "my location can only be disclosed to
 the owner of such credentials and in such precision or resolution"
 has clear-cut implications for the protocol that uses the LO.  But
 other rules, like retention or usage Rules, may have unclear
 technical consequences for the protocol or for the involved entities.
 For example, the precise scope of a retention rule stating "you may
 not store my location for more than 2 days" may in part turn on local
 laws or customs.

5.6. Identifiers, Authentication and Authorization

 Anonymity is the property of being not identifiable (within a set of
 subjects).  Anonymity serves as the base case for privacy: without
 the ability to remain anonymous, individuals may be unable to control
 their own privacy.  Unlinkability ensures that a user may make
 multiple uses of resources or services without others being able to
 link these uses to each other.  Unlinkability requires that entities
 be unable to determine whether the same user caused certain specific
 operations in the system. [ISO99]  A pseudonym is simply a bit string
 which is unique as an ID and is suitable to be used for end-point
 authentication.
    Unlinked Pseudonym:
       A pseudonym where the linking between the pseudonym and its
       holder is, at least initially, not known to anybody with the
       possible exception of the holder himself or a trusted server of
       the user.  See [Pfi01] (there the term is called Initially
       Unlinked Pseudonym).
 The word authentication is used in different manners.  Some require
 that authentication associates an entity with a more or less well-
 known identity.  This basically means that if A authenticates another
 entity B as being "id-B", then the label "id-B" is a well-known, or
 at least a linkable identity of the entity.  In this case, the label
 "id-B" is called a publicly known identifier, and the authentication
 is "explicit":
    Explicit Authentication:
       The act of verifying a claimed identity as the sole originator
       of a message (message authentication) or as the end-point of a
       channel (entity authentication).  Moreover, this identity is
       easily linked back to the real identity of the entity in
       question, for instance being a pre-existing static label from a
       predefined name space (telephone number, name, etc.)

Cuellar, et al. Informational [Page 13] RFC 3693 Geopriv Requirements February 2004

    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 or may not
 imply Explicit Authentication.

Cuellar, et al. Informational [Page 14] RFC 3693 Geopriv Requirements February 2004

6. Scenarios and Explanatory Discussion

 In this subsection we introduce short scenarios to illustrate how
 these terms and attributes describe location information
 transactions.  Additional illustrative scenarios are discussed in a
 separate document.
 SCENARIO 1: GPS Device with Internal Computing Power: Closed System
 In this example, the Target wishes to know his/her location using the
 Global Positioning System (GPS) and the Device is capable of
 independently processing the raw data to determine its location.  The
 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 some
 signal, and has no information about the identity or whereabouts of
 Devices using the signal.
       GPS Satellite
               |
               | Sighting (not a Geopriv Interface)
               |
               |
               |
               V             GPS Device
        --------------------------------------------------
       /                                                  \
       |  Location     -----  Location  -----  Location   |
       |  Generator            Server            Storage  |
       \                                           |      /
        -------------------------------------------|------
                                                   |
                                                   | Notification
                                                   | Interface
                                                   |
                                       ------------|------
                                      /            V      \
                                     / Target    Location  \
                                     |          Recipient   |
                                     |                      |
                                     \    Rule Maker       /
                                      \                   /
                                       -------------------
 In this scenario the GPS Device is both the AP and the LG.  The
 interaction occurs in a Trusted environment because it occurs in the
 Rule Maker's Device.

Cuellar, et al. Informational [Page 15] RFC 3693 Geopriv Requirements February 2004

 SCENARIO 2:  Cell Phone Roaming
 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 accounting 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 (AP) provides the roaming service for
 the Target, which sends the raw data about usage (e.g., duration of
 call, location in the roaming network, etc.) to cell phone Corp 2,
 the home service provider.  Cell phone Corp 2 submits the raw data to
 the accounting company, which processes the raw data for the
 accounting 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).
                Cell Phone Corp 1                Cell Phone Corp 2
                -----------------               -----------------
      Sighting /                 \  Publish    /                 \
 Device ----- | Data Transporter | ---------  | Data Transporter |
 Target        \                 / Interface   \                 /
                -----------------              / -----------------
                                              /       |
                                             /        | Notification
                                            /         | Interface
                                 -----------          |
                                /                     V
              ------------     /                  ----------
             /            \   /                  /          \
            /   Location   \ /                  |  Location  |
            |   Storage     |   Location Info   |  Storage   |
            |               |<----------------- |            |
            |   Location    |                   |  Location  |
            |  Recipient    |                   | Recipient  |
             \             /                     \          /
              -------------                       ----------
 Here, cell phone Corp 1 is the AP and the LG.  In this scenario, Cell
 phone Corp 2 is likely to be a Trusted entity, but cell phone Corp 1
 may be Non-trusted.

Cuellar, et al. Informational [Page 16] RFC 3693 Geopriv Requirements February 2004

 SCENARIO 3:  Mobile Communities and Location-Based Services
 The figure below shows a common scenario, where a user wants to find
 his friends or colleagues or wants to share his position with them or
 with a Location-Based Service Provider.  Some of the messages use a
 Location Object to carry, for instance, identities or pseudonyms,
 credentials and proof-of-possession of them, Rules and Location Data
 Information, including Data Types and Precision or Resolution.
 Messages that do not use the Location Object and are outside of the
 scope of the Geopriv WG, but should be mentioned for
 understandability, are shown in the figure as starred arrows
 ("***>").
       +---------+                      +------------+
       |         |                      |            |
       | Location|<**                   |   Public   |
       |Generator|    *                 | Rule Holder|
       |         |      *               |            |
       +---------+\       *             +------------+
                    \        *3     1a*        *
                      \        *    *          *
                        \        **            *
                          \    *  *            *1a
                            \*      *          *
                           *  \       *        *
                         *      \       *      *
                       *          \4      *    *
                     *              \       *  V
                   *                  \->+-----------+
       +----------+           1          | Location  |
       |   Rule   |--------------------->| Server +  |
       |   Maker  |                      | Private   |
       +----------+                      |Rule Holder|
                                         +-----------+
                                              ^  |
                                             3|  |5
                                              |  V
                                          +----------+
                                          | Location |
                                          | Recipient|
                                          +----------+
 Assume that the Rule Maker and the Target are registered with the
 Location Server.  The RM has somehow proven to the LS that he indeed
 is the owner of the privacy rights of the Target (the Target is
 usually a Device owned by the Rule Maker).  The Rule Maker and the
 Location Server have agreed on the set of keys or credentials and
 cryptographic material that they will use to authenticate each other,

Cuellar, et al. Informational [Page 17] RFC 3693 Geopriv Requirements February 2004

 and in particular, to authenticate or sign the Rules.  How this has
 been done is outside of the scope of the document.
    1: Rule Transfer:
       The Rule Maker sends a Rule to the Location Server.  This Rule
       may or may not be a field in a Location Object.
    1a:Signed Rule:
       As an alternative, the Rule Maker may write a Rule and place it
       in a Public Rule Holder.  The entities access the repository to
       read the signed Rules.
    2: Location Information Request:
       The Location Recipient requests location information for a
       Target.  In this request, the Location Recipient may select
       which location information data type it prefers.  One way of
       requesting Location Information MAY be sending a partially
       filled Location Object, including only the identities of the
       Target and Location Recipient and the desired Data Type and
       precision or resolution, and providing proof of possession of
       the required credentials.  But whether or not the using
       protocol understands this partially filled object as a request
       MAY depend on the using protocol or on the context.  The
       Location Recipient could also specify the need for periodic
       location information updates, but this is probably out of the
       scope of Geopriv.
    3: Locate:
       When a Location Server receives a Location Information Request
       for a Target which has no current location information, the
       server may ask the Location Generator to locate the Target.
    4: Location Information:
       The Location Generator sends the "full" location information to
       the Location Server.  This Location Information may or may not
       be embedded in a Location Object.
    5: Filtered Location Information:
       The Location Server sends the location information to the
       Location Recipient.  The information may be filtered in the
       sense that in general a less precise or a computed version of
       the information is being delivered.

Cuellar, et al. Informational [Page 18] RFC 3693 Geopriv Requirements February 2004

7. Requirements

7.1. Location Object

 Remember that this document is primarily specifying requirements on
 the definition of the LO.  Some Requirements read like this:  "The LO
 definition MUST contain Field 'A' as an optional field."  This
 requirement states that
 o  the document that defines the LO MUST define the LO field 'A',
 o  the field 'A' MUST be defined as optional to use (an instance of a
    LO MAY or may not contain the field 'A').
 Some Requirements read like this: "The LO definition MUST contain
 Field 'A', which MAY be an optional field."  This requirement states
 that
 o  the document that defines the LO MUST define the LO field 'A',
 o  the field 'A' MAY be defined as optional or not to use.  If it is
    defined as optional to use, any instance of an LO MAY or may not
    contain the field 'A'; if it is not optional, all instances of LOs
    MUST contain the field 'A'.
 Req. 1.  (Location Object generalities)
    1.1) Geopriv MUST define one Location Object (LO) -- both in
    syntax and semantics -- that must be supported by all Geopriv
    entities.
    1.2) Some fields of the Location Object MAY be optional.  This
    means that an instance of a Location Object MAY or may not contain
    the fields.
    1.3) Some fields of the Location Object MAY be defined as
    "extensions".  This means that the syntax or semantics of these
    fields is not fully defined in the basic Location Object
    definition, but their use may be private to one or more of the
    using protocols.
    1.4) The Location Object MUST be extensible, allowing the
    definition of new attributes or fields.
    1.5) The object MUST be suitable for requesting and receiving a
    location.

Cuellar, et al. Informational [Page 19] RFC 3693 Geopriv Requirements February 2004

    1.6) The object MUST permit (but not require) the Privacy Rules to
    be enforced by a third party.
    1.7) The object MUST be usable in a variety of protocols, such as
    HTTP and SIP, as well as local APIs.
    1.8) The object MUST be usable in a secure manner even by
    applications on constrained devices.
 Req. 2.  (Location Object fields) The Location Object definition MUST
    contain the following Fields, which MAY be optional to use:
    2.1) Target Identifier
    2.2) Location Recipient Identity
    This identity may be a multicast or group identity, used to
    include the Location Object in multicast-based using protocols.
    2.3) Location Recipient Credential
    2.4) Location Recipient Proof-of-Possession of the Credential
    2.5) Location Field
    2.5.1) Motion and direction vectors.  This field MUST be optional.
    2.6) Location Data Type
    When transmitting the Location Object, the sender and the receiver
    must agree on the data type of the location information.  The
    using protocol may specify that the data type information is part
    of the Location Object or that the sender and receiver have agreed
    on it before the actual data transfer.
    2.7) Timing information:
    (a) When was the Location Information accurate? (sighting time)
    (b) Until when considered current?  TTL (Time-to-live) (This is
    different than a privacy rule setting a limit on data retention)
    2.8) Rule Field: this field MAY be a referral to an applicable
    Rule (for instance, a URI to a full Rule), or it MAY contain a
    Limited Rule (see Req. 11), or both.
    2.9) Security-headers and -trailers (for instance encryption
    information, hashes, or signatures) (see Req. 14 and 15).
    2.10) Version number

Cuellar, et al. Informational [Page 20] RFC 3693 Geopriv Requirements February 2004

 Req. 3.  (Location Data Types)
    3.1) The Location Object MUST define at least one Location Data
    Type to be supported by all Geopriv receivers (entities that
    receive LOs).
    3.2) The Location Object SHOULD define two Location Data Types:
    one for latitude / longitude / altitude coordinates and one for
    civil locations (City, Street, Number) supported by all Geopriv
    receivers (entities that receive LOs).
    3.3) The latitude / longitude / altitude Data Type SHOULD also
    support a delta format in addition to an absolute one, used for
    the purpose of reducing the size of the packages or the security
    and confidentiality needs.
    3.4) The Location Object definition SHOULD agree on further
    Location Data Types supported by some Geopriv entities and defined
    by other organizations.

7.2. The Using Protocol

 Req. 4.  The using protocol has to obey the privacy and security
    instructions coded in the Location Object and in the corresponding
    Rules regarding the transmission and storage of the LO.
 Req. 5.  The using protocol will typically facilitate that the keys
    associated with the credentials are transported to the respective
    parties, that is, key establishment is the responsibility of the
    using protocol.
 Req. 6.  (Single Message Transfer)  In particular, for tracking of
    small target devices, the design should allow a single
    message/packet transmission of location as a complete transaction.
 Other requirements on the using protocol are out of the scope of this
 document, but might be the subject of future efforts from this
 working group.  See also Section 9 (Protocol and LO Issues for later
 Consideration).

7.3. Rule based Location Data Transfer

 Req. 7.  (LS Rules) The decision of a Location Server to provide a
    Location Recipient access to Location Information MUST be based on
    Rule Maker-defined Privacy Rules.

Cuellar, et al. Informational [Page 21] RFC 3693 Geopriv Requirements February 2004

 It is outside of our scope how Privacy Rules are managed and how a
 Location Server has access to the Privacy Rules.  Note that it might
 be that some rules contain private information not intended for
 untrusted parties.
 Req. 8.  (LG Rules) Even if a Location Generator is unaware of and
    lacks access to the full Privacy Rules defined by the Rule Maker,
    the Location Generator MUST transmit Location Information in
    compliance with instructions set by the Rule Maker.  Such
    compliance MAY be accomplished by the Location Generator
    transmitting the LO only to a URI designated by the Rule Maker.
 Req. 9.  (Viewer Rules) A Viewer does not need to be aware of the
    full Rules defined by the Rule Maker (because a Viewer SHOULD NOT
    retransmit Location Information), and thus a Viewer SHOULD receive
    only the subset of Privacy Rules necessary for the Viewer to
    handle the LO in compliance with the full Privacy Rules (such as,
    instruction on the time period for which the LO can be retained).
 Req. 10.  (Full Rule language) Geopriv MAY specify a Rule language
    capable of expressing a wide range of privacy rules concerning
    location information.  This Rule language MAY be an existing one,
    an adaptation of an existing one or a new Rule language, and it
    SHOULD be as simple as possible.
 Req. 11.  (Limited Rule language) Geopriv MUST specify a limited Rule
    language capable of expressing a limited set of privacy rules
    concerning location information.  This Rule language MAY be an
    existing one, an adaptation of an existing one or a new Rule
    language.  The Location Object MUST include sufficient fields and
    data to express the limited set of privacy rules.

7.4. Location Object Privacy and Security

7.4.1. Identity Protection

 Req. 12.  (Identity Protection) The Location Object MUST support use
    of Unlinked Pseudonyms in the corresponding identification fields
    of Rule Maker, Target, Device, and Location Recipient.  Since
    Unlinked Pseudonyms are simply bit strings that are not linked
    initially to a well-known identity, this requirement boils down to
    saying that the name space for Identifiers used in the LO has to
    be large enough to contain many unused strings.

Cuellar, et al. Informational [Page 22] RFC 3693 Geopriv Requirements February 2004

7.4.2. Authentication Requirements

 Req. 13.  (Credential Requirements) The using protocol and the
    Location Object SHOULD allow the use of different credential
    types, including privacy-enhancing credentials (for instance those
    described in [Bra00] or [Cha85]).

7.4.3. Actions to be secured

 Req. 14.  (Security Features) The Location Object MUST support fields
    suitable for protecting the Object to provide the following
    security features:
    14.1)     Mutual end-point authentication: the using protocol is
    able to authenticate both parties in a Location Object
    transmission,
    14.2)     Data object integrity: the LO is secured from
    modification by unauthorized entities during transmission and
    storage,
    14.3)     Data object confidentiality: the LO is secured from
    eavesdropping (unauthorized reading) during transmission and
    storage, and
    14.4)     Replay protection: an old LO may not be replayed by an
    adversary or by the same entity that used the LO itself (except
    perhaps during a small window of time that is configurable or
    accepted by the Rule Maker).
 Req. 15.  (Minimal Crypto)
    15.1)     Geopriv MUST specify a minimum mandatory to implement
    Location Object security, including mandatory to implement crypto
    algorithms for digital signature algorithms and encryption
    algorithms.
    15.2)     It MAY also define further mandatory to implement
    Location Object security mechanisms for message authentication
    codes (MACs) or other purposes.
    15.3)     The protocol SHOULD allow a bypass if authentication
    fails in an emergency call.
 The issue addressed in the last point is that an emergency call in
 some unfavorable situations may not be completed if the minimal
 authentication fails.  This is probably not what the user would like
 to happen.  The user may prefer an unauthenticated call to an

Cuellar, et al. Informational [Page 23] RFC 3693 Geopriv Requirements February 2004

 unauthenticated emergency server over no call completion at all, even
 at the risk that he is talking to an attacker or that his information
 is not secured.

7.5. Non-Requirements

 Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification
    SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).

8. Security Considerations

 The purpose of the Geopriv Location Object and the requirements on
 the using protocol are to allow a Privacy Rule-controlled disclosure
 of location information for location services.

8.1. Traffic Analysis

 The information carried within the Location Object is secured in a
 way compliant with the privacy and security Rules of the Rule Maker,
 but other information, carried in other objects or headers are in
 general not secured in the same way.  This means that Geopriv may not
 as a general matter, secure the Target against general traffic
 analysis attacks or other forms of privacy violations.

8.2. Securing the Privacy Rules

 The Privacy Rules of the Rule Maker regarding the location of the
 Target may be accessible to a Location Server in a public or non-
 public Rule Holder, or they may be carried by the Location Object, or
 they may be presented by the Location Recipient as capabilities or
 tokens.  Each type of Rule has to be secured its own particular way.
 The rules in a non-public Rule Holder are typically authenticated
 using a MAC (Message Authentication Code) or a signature, depending
 on the type of keys used.  The rules in a public Rule Holder (one
 that in principle may be accessed directly by several entities, for
 instance several Location Servers) are typically digitally signed.
 Rule Fields in an LO are secured as part of the LO itself.  A Geopriv
 Token (a token or ticket issued by the Rule Maker to a Location
 Recipient, expressing the explicit consent of the Rule Maker to
 access his location information) is authenticated or signed.

8.3. Emergency Case

 Let us consider the situation where the authentication fails in an
 emergency call because the authentication center fails to
 authenticate itself.  In this case, one way of implementing the

Cuellar, et al. Informational [Page 24] RFC 3693 Geopriv Requirements February 2004

 authentication bypass for emergency calls (mentioned in Req 15.3) is
 to let the user have the choice of writing a Rule that says:
  1. "If the emergency server does not authenticate itself, send the

location information anyway", or

  1. "If the emergency server does not authenticate itself, let the

call fail".

 Second, in the case where the authentication of the emergency call
 fails because the user may not authenticate itself, the question
 arises: whose Rule to use?  It is reasonable to use a default one:
 this location information can only be sent to an emergency center.
 The third situation, which should be studied in more detail, is:
 what to do if not only the user fails to authenticate itself, but
 also the emergency center is not authenticable?  It is reasonable to
 send the Location Information anyway, but are there any security
 threats that must be considered?

8.4. Identities and Anonymity

 The use of Unlinked Pseudonyms is necessary to obtain anonymity.
 The purpose of the use of Unlinked Pseudonyms is the following: the
 using protocol should be able to hide the real identity of the Rule
 Maker, the Target, and the Device, from Location Servers or Location
 Recipients, if required by the RM.  Also, the using protocol SHOULD
 be able to hide the real identity of the Location Recipient from the
 Location Server.
 In this last case, the Target is not concerned about the Server
 identifying him and knowing his location, but identifying his
 business partners, and therefore his habits, etc.  Reasons for hiding
 the real identities of the Location Recipients include (a) that this
 knowledge may be used to infer the identity of the Target, (b) that
 knowledge of the identity of the Location Recipient may embarrass the
 Target or breach confidential information, and (c) that the dossier
 telling who has obtained a Target's location information over a long
 period of time can give information on habits, movements, etc.  Even
 if the location service providers agree to respect the privacy of the
 user, are compelled by laws or regulations to protect the privacy of
 the user, and misbehavior or negligence of the Location Server can be
 ruled out, there is still risk that personal data may become
 available to unauthorized persons through attacks from outsiders,
 unauthorized access from insiders, technical or human errors, or
 legal processes.

Cuellar, et al. Informational [Page 25] RFC 3693 Geopriv Requirements February 2004

 On some occasions, a Location Server has to know who is supplying the
 Privacy Rules for a particular Target, while in other situations it
 could be enough to know that the supplier of the Rules is authorized
 to do so.

8.5. Unintended Target

 An Unintended Target is 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.
 Geopriv may or may not protect or affect the privacy of Unintended
 Targets, but the impact on Unintended Targets should be acknowledged.

9. Protocol and LO Issues for later Consideration

 This section briefly discusses issues relating to the Location Object
 or the protocol that have emerged during the discussion of earlier
 versions of this document.

9.1. Multiple Locations in one LO

 A location Field is intended to represent one point or one region in
 space (either 1, 2, or 3 dimensionally).  The possibility of
 inclusion of multiple locations is discussed in another document.
 The current rough consensus is the following: the LO definition MAY
 allow the Location Field to be optional, to appear exactly one time
 or to occur several times.  Each Location Field may contain one or
 more "Location Representations", each of which is intended to
 represent a different measurement or a different formatting of the
 same position.  But there are other possibilities for using multiple
 Location Fields and multiple representations: maybe several Location
 Fields would be used to report the same sighting in different
 formats, or multiple sightings at different times, or multiple sensor
 locations for the same device, or other purposes, which could also
 depend on the using protocol.  This is all for further discussion.

9.2. Translation Fields

 It is possible to include fields to indicate that one of the
 locations is a translation of another.  If this is done, it is also
 possible to have a field to identify the translator, as identity and
 method.

Cuellar, et al. Informational [Page 26] RFC 3693 Geopriv Requirements February 2004

9.3. Truth Flag

 Geopriv MUST be silent on the truth or lack-of-truth of the location
 information contained in the LO.  Thus, the LO MUST NOT provide an
 attribute in object saying "I am (or am not) telling you the whole
 truth."

9.4. Timing Information Format

 The format of timing information is out of the scope of this
 document.

9.5. The Name Space of Identifiers

 Who defines the Identities: can the using protocol define the
 Identifiers or must the using protocol use and authenticate
 Pseudonyms proposed by the Rules, chosen independently of the using
 protocol?  Of course, if the using protocol has an appropriate
 namespace, containing many unused names that may be used as
 pseudonyms and may be replaced by new ones regularly, then the
 Location Object may be able to use the name space.  For this purpose,
 the user would probably have to write his Rules using this name
 space.  Note that it is necessary to change the used pseudonyms
 regularly, because identifying the user behind an unlinked pseudonym
 can be very simple.
 There are several advantages in letting the using protocol define the
 name space:
 o  the embedded authentication would be easier, as the using protocol
    often already has the credentials for the authentication identity
    in place and the "embedded" authentication would be independent on
    the form of Identifiers,
 o  the size of the names would be fixed.
 On the other hand, the benefits of the Rule choosing the identifiers
 are:
 o  the user has a control of his anonymity, and
 o  the interworking of multiple systems with Location object across
    protocol boundaries is facilitated.

Cuellar, et al. Informational [Page 27] RFC 3693 Geopriv Requirements February 2004

10. Acknowledgements

 We wish to thank the members of the IETF Geopriv WG for their
 comments and suggestions.  Aaron Burstein, Mehmet Ersue, Allison
 Mankin, Randall Gellens, and the participants of the Geopriv meetings
 in San Diego and Yokohama provided detailed comments or text.

11. References

11.1. Normative Reference

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

11.2. Informative References

 [Bra00]   Stefan A.: Rethinking Public Key Infrastructures and
           Digital Certificates : Building in Privacy, MIT Press;
           ISBN:  0262024918; 1st edition, August, 2000
 [Cha85]   Chaum, David: Security without Identification, Card
           Computers to make Big Brother Obsolete.  Original Version
           appeared in: Communications of the ACM, vol. 28 no. 10,
           October 1985 pp. 1030-1044. Revised version available at
           http://www.chaum.com/articles/
 [ISO99]   ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
 [OECD]    OECD Guidelines on the Protection of Privacy and
           Transborder Flows of Personal Data, http://www.oecd.org.
 [Pfi01]   Pfitzmann, Andreas; Koehntopp, Marit: Anonymity,
           Unobservability, and Pseudonymity - A Proposal for
           Terminology; in: H Federrath (Ed.): Designing Privacy
           Enhancing Technologies; Proc.  Workshop on Design Issues in
           Anonymity and Unobservability; LNCS 2009; 2001; 1-9.  Newer
           versions available at
           http://www.koehntopp.de/marit/pub/anon

Cuellar, et al. Informational [Page 28] RFC 3693 Geopriv Requirements February 2004

12. Authors' Addresses

 Jorge R Cuellar
 Siemens AG
 Corporate Technology
 CT IC 3
 81730 Munich, Germany
 EMail: Jorge.Cuellar@siemens.com
 John B. Morris, Jr.
 Director, Internet Standards, Technology & Privacy Project
 Center for Democracy & Technology
 1634 I Street NW, Suite 1100
 Washington, D.C. 20006 USA
 EMail: jmorris@cdt.org
 URI: http://www.cdt.org
 Deirdre K. Mulligan
 Samuelson Law, Technology & Public Policy Clinic
 Boalt Hall School of Law
 University of California
 Berkeley, CA 94720 USA
 EMail: dmulligan@law.berkeley.edu
 URI: http://www.law.berkeley.edu/cenpro/samuelson/
 Jon Peterson
 NeuStar, Inc.
 1800 Sutter St
 Suite 5707
 Concord, CA 94520 USA
 EMail: jon.peterson@neustar.biz
 URI: http://www.neustar.biz/
 James M. Polk
 Cisco Systems
 2200 East President George Bush Turnpike
 Richardson, Texas 75082 USA
 EMail: jmpolk@cisco.com

Cuellar, et al. Informational [Page 29] RFC 3693 Geopriv Requirements February 2004

13. Full Copyright Statement

 Copyright (C) The Internet Society (2004).  This document is subject
 to the rights, licenses and restrictions contained in BCP 78 and
 except as set forth therein, the authors retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed
 to pertain to the implementation or use of the technology
 described in this document or the extent to which any license
 under such rights might or might not be available; nor does it
 represent that it has made any independent effort to identify any
 such rights.  Information on the procedures with respect to
 rights in RFC documents can be found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use
 of such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository
 at http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention
 any copyrights, patents or patent applications, or other
 proprietary rights that may cover technology that may be required
 to implement this standard.  Please address the information to the
 IETF at ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Cuellar, et al. Informational [Page 30]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3693.txt · Last modified: 2004/02/17 20:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki