diff options
Diffstat (limited to 'doc/rfc/rfc3693.txt')
| -rw-r--r-- | doc/rfc/rfc3693.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc3693.txt b/doc/rfc/rfc3693.txt new file mode 100644 index 0000000..a9c2887 --- /dev/null +++ b/doc/rfc/rfc3693.txt @@ -0,0 +1,1683 @@ + + + + + + +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: + + - "If the emergency server does not authenticate itself, send the + location information anyway", or + + - "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] + |