RFC 3694
Threat Analysis of the Geopriv Protocol
Threat Analysis of the Geopriv Protocol 🦋
Okay bestie, this is RFC 3694 🎀, published in February 2004 in the Network Working Group. It's written by M. Danley and D. Mulligan (from the Samuelson Law, Technology & Public Policy Clinic), J. Morris (from the Center for Democracy & Technology), and J. Peterson (from NeuStar). Its category is Informational 📚, so it gives information to the Internet community and doesn't specify an Internet standard. The header doesn't list anything it obsoletes or updates. ✨
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
This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. 🔥
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Habitat of the Geopriv Protocol . . . . . . . . . . . . . . . 3
3. Motivations of Attackers of Geopriv . . . . . . . . . . . . . 4
4. Representative Attacks on Geopriv . . . . . . . . . . . . . . 5
4.1. Protocol Attacks . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Eavesdropping and/or Interception . . . . . . . 5
4.1.2. Identity Spoofing . . . . . . . . . . . . . . . 6
4.1.3. Information Gathering . . . . . . . . . . . . . 7
4.1.4. Denial of Service . . . . . . . . . . . . . . . 8
4.2. Host Attacks . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Data Stored at Servers . . . . . . . . . . . . . 9
4.2.2. Data Stored in Devices . . . . . . . . . . . . . 9
4.2.3. Data Stored with the Viewer . . . . . . . . . . 10
4.2.4. Information Contained in Rules . . . . . . . . . 10
4.3. Usage Attacks . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Threats Posed by Overcollection . . . . . . . . 11
5. Countermeasures for Usage Violations . . . . . . . . . . . . . 12
5.1. Fair Information Practices . . . . . . . . . . . . . . . 12
6. Security Properties of the Geopriv Protocol . . . . . . . . . 13
6.1. Rules as Countermeasures . . . . . . . . . . . . . . . . 13
6.1.1. Rule Maker Should Define Rules . . . . . . . . . 13
6.1.2. Geopriv Should Have Default Rules . . . . . . . 14
6.1.3. Location Recipient Should Not Be Aware of All
Rules. . . . . . . . . . . . . . . . . . . . . . 14
6.1.4. Certain Rules Should Travel With the LO . . . . 14
6.2. Protection of Identities . . . . . . . . . . . . . . . . 14
6.2.1. Short-Lived Identifiers May Protect Target's
Identity . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Unlinked Pseudonyms May Protect the Location
Recipients' Identity . . . . . . . . . . . . . . 15
6.3. Security During Transmission of Data . . . . . . . . . . 15
6.3.1. Rules May Disallow a Certain Frequency of
Requests . . . . . . . . . . . . . . . . . . . . 15
6.3.2. Mutual End-Point Authentication . . . . . . . . 16
6.3.3. Data Object Integrity & Confidentiality . . . . 16
6.3.4. Replay Protection . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . . 16
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 181. Introduction ✨
The rise of location-based services that mix tracking and navigation brings some seriously big privacy and security concerns 😭. These services let users figure out their own location and also find out where other people are. In certain peer-to-peer exchanges, device identification happens automatically inside a defined location perimeter, which tells peer devices a given user's identity and availability. On top of that, records of location exchanges can reveal a lot about people's habits, whereabouts, and associations 👀.
The Geopriv requirements let the Location Object (LO) support a wide variety of uses of Location Information (LI). The Geopriv object itself is meant to be technology-neutral 🧚, so lots of different devices can provide LI in the form of an LO. Geopriv also requires that many classes of Viewers be able to request LI from a Location Server. The requirements cover situations where the Target has a contractual relationship with the entities that transmit and receive LI, and situations where no contract exists. Requiring the Geopriv object to support any technology, Target-Viewer relationship, or underlying legal framework governing LI makes it harder to protect privacy and the security of LI 💅.
This document analyzes threats to LI in transmission and storage. How likely it is that LI gets compromised by these threats depends on the circumstances. A server selling location information to potential marketers poses a distinctly lower risk than an outside individual intercepting a Target's present location to commit a physical attack 🚨. It's important that we consider these threats as we work toward defining the LO 🫶.
Some of the threats discussed in this document may be outside the scope of the Geopriv charter, e.g., threats arising from failure to meet contractual obligations. Still, a comprehensive discussion of threats is necessary to identify desirable security properties and counter-measures that will improve the security of the LO, and thereby better protect LI 🌈.
2. Habitat of the Geopriv Protocol 🏡
The Geopriv architecture will be deployed on the open Internet, which is a pretty rough neighbourhood 💀. Potential attackers can inspect packets on the wire, spoof Internet addresses, and launch large-scale denial-of-service attacks. In some architectures, portions of Geopriv traffic (especially traffic between the Location Generator and an initial Location Server) may occur over managed networks that do not interface with the public Internet 🌸.
The protocol itself assumes interaction between a number of logical roles, and many of them will commonly be implemented in distributed network devices (for a full list of Geopriv roles and entities with definitions, see [1]) 🍓. The endpoints of the common Geopriv transactions are the Location Generator (the source of location information from the perspective of the network) and the Location Recipient. Both a Location Generator and a Location Recipient may have a relationship with a Location Server. The Location Generator publishes data to a Location Server (which may provide a grooming/filtration function for location information), and the Location Recipient requests and/or receives information from the Location Server. This gives two points where Geopriv information could require protection across the wire 🔐. Rules can also be passed over the network from a Rule Holder to a Location Server, which is another point where the architecture requires security 🛡️.
It's important to note that Location Generators and Location Recipients may be implemented on low-cost devices, for which strong cryptographic security is currently prohibitively expensive computationally 🥺.
3. Motivations of Attackers of Geopriv 😈
The most obvious motivation for an attacker of Geopriv is to learn the location of a subject who wishes to keep their position private. Another is for authorized Viewers to ascertain location information with a greater degree of precision than the Rule Maker desires 👁️. But there are several other potential motivations that cause concern too 😬. Attackers might want to stop a Target's location from being distributed, or to modify or corrupt location information in order to misrepresent the Target's location, or to redirect the Target's location information to a third party that isn't authorized to know it. Attackers may want to identify the associates of a Target, or learn a Target's habits or routines. Attackers might want to learn the identity of all the parties in a certain location. Finally, some attackers may simply want to halt an entire Geopriv system through denial-of-service attacks 🙅♀️.
There's also a class of attackers who may be authorized as legitimate participants in a Geopriv protocol exchange but who abuse location information. This includes distributing or accumulating location information outside the parameters of agreements between the principals, possibly for commercial purposes or as an act of unlawful surveillance 🚫.
4. Representative Attacks on Geopriv ⚔️
4.1. Protocol Attacks 🎯
4.1.1. Eavesdropping and/or Interception
Okay bestie, picture a location-based game 🧚 that's basically hide-and-seek but make it tech. A centralized server gives hints about where the 'hider' is to a bunch of 'seekers' 👀. The seekers only get very coarse location data, but a single referee gets unfiltered, precise location info about the hider. Each seeker has a wireless device (a Location Recipient in Geopriv terms) that gets coarse positioning data from the Location Server. The hider carries a device (a Location Generator using GPS) that sends location info to the Location Server 📍.
Ngl, the cheating drama starts when a seeker wants to attack the Geopriv protocol to find the hider's exact spot. There are a bunch of ways to do it. They could eavesdrop on either of two network connections: the one between the Location Generator and the Location Server, or the one between the Location Server and the referee's Location Recipient (the one that gets precise info). They could also impersonate the referee to the Location Server to get unfiltered Location Information. Or they could impersonate the Location Server to the hider's Location Generator, which would also give them precise location info 😈. Finally, the cheater could try to act as the Rule Maker. If they provide Rules to the Location Server, their own Location Recipient gets access to uncoarsened location information. Villain arc, no cap 💀.
From these threats, we can derive a need for several security properties of the architecture.
- Confidentiality is required on both the connection between the Location Generator and the Location Server, as well as the connection between the Location Server and any given Location Recipient. 🔐
- Location Servers must be capable of authenticating and authorizing Location Recipients to prevent impersonation.
- Similarly, Location Generators must be capable of authenticating and authorizing Location Servers in order to prevent impersonation.
- Finally, the Location Server must be able to authenticate Rule Makers, to make sure that unauthorized parties cannot change rules. 🙅♀️
4.1.2. Identity Spoofing
Okay, this one is giving office drama 🍿. Imagine a boss who employs two rivals. One of them goes on a business trip to Cleveland. Both rivals carry devices that a Location Generator tracks (like cell phones the carrier can triangulate), and both rivals let their boss see their (coarse) location info. The rival who stayed home wants to hack the Geopriv protocol so it looks like the traveling rival is actually goofing off in South Beach instead of sitting through a dull technology conference in Cleveland 🙄. How would someone even pull that off?
The attacker might try to spoof network traffic from the Location Generator to the Location Server. This is especially possible if, through some other means like a denial-of-service attack, the Location Generator can't issue its own reports anymore 🤯. The attacker's goal could be to provide falsified location info that fits someone in Miami, or even to replay a genuine location object from the rival's earlier visit to Miami 🌴. The attacker might also try to spoof traffic from the Location Server to the boss' Location Recipient.
From these threats, we can derive a need for several security properties of the architecture.
- There is a need for the Location Server to authenticate Location Generators. 🪪
- Location Recipients must be capable of authenticating Location Servers.
- Location information must be protected from replay attacks.
Identity spoofing can create even more threats once the protocol is under attack 🚨. In many situations, the identity of the Viewer decides whether LI gets revealed and, if it does, how that LI gets filtered. If that identity is compromised, privacy is in danger. Anyone inside or outside the transaction who can impersonate an authorized entity can access confidential information or start false transmissions in that entity's name. For example, being able to spoof the identity of the Location Recipient would let an unauthorized entity access both the identity and the location of the Target at the moment the LO was sent. Scary stuff, bestie 😭.
4.1.3. Information Gathering
Eavesdropping and interception can also create traffic analysis threats, and these get worse the longer the interceptor keeps collecting data 🕵️♀️. Traffic analysis is when an eavesdropper figures out how the entities are related just from the fact that a network transmission happened. Say an employer sends an employee's location to a customer. An eavesdropper could tell that these three entities are somehow interacting with one another. If the eavesdropping keeps going, the collection of interactions would cover the employer, the employees, and all of their customers. That log would show that the employer and employee are frequently associated, and it would reveal which clients dealt with the pair most often. So the traffic analysis threat creates the risk of eavesdroppers finding out the Target's associates 👯.
Traffic analysis might also let an eavesdropper figure out the identity or characteristics of targets in a particular location 📡. By watching transmissions between Location Generators in a specific location and Location Servers (maybe by eavesdropping on a wireless or wireline LAN scoped to that location), and then possibly following the data to various Location Recipients, an attacker could learn the associates of the targets there, including their employer. They might even extrapolate further identity info from that 🫣.
If the eavesdropper can intercept not only an encrypted LO but also the plaintext LI itself, even more threats show up 🙈. Let's go back to the employer requesting an employee's location info. In this case, intercepting just one of those past transactions could reveal the identities and/or locations of all three parties, plus the fact that they're connected. If there's a log of this data, analysis could reveal a regular route the employee travels to visit customers, a general area where the employee works, the identities and locations of the employee's entire customer base, and info about how all the entities relate. Iconic for the wrong reasons 💀.
Threats based on traffic analysis are hard to handle with protocol security measures, but they're important to note 📝.
From these threats, we can derive a need for several security properties of the architecture.
- The Rule Maker must be able to define Rules regarding the use of their LI. 📜
- The connection between the Location Generator and Location Server, as well as the connection between the Location Server and Location Recipient, must remain confidential.
- Location Servers must be capable of authenticating Location Recipients to prevent impersonation.
- Location Servers must be able to authenticate Rule Makers to ensure that unauthorized entities cannot change rules.
4.1.4. Denial of Service
Parties who want to take down Geopriv service for entire networks, instead of just targeting particular users, would probably go after the Location Server 🎯. In many scenarios, the Location Server runs the show by managing access to location info for many devices, so in these architectures it's a natural single point of failure. Main character target, unfortunately 😩.
The Geopriv protocol seems to have some openings for amplification attacks ⚡. When a Location Generator publishes location info, the Location Server acts as an exploder, potentially delivering that info to lots of targets. Now imagine the Location Generator sends really rapid position updates (as many as the link speed can handle, especially in high-bandwidth wireless environments). If the Location Server then proxies that info to Seekers at a similar rate, things could get messy 🌊 fast when a large number of Seekers are tracking the same user.
Also, most operations associated with the Location Server probably need cryptographic authentication 🔑. Cryptographic operations cost computing resources on the Location Server's side. That makes it a tempting way for attackers to flood the Location Server with dummy Geopriv info spoofed to look like it came from a Location Generator, Location Recipient, or the Rule Maker. Since the Location Server has to spend resources verifying the credentials in these Geopriv messages, floods of Geopriv info could hit harder than denial-of-service attacks based on generic packet flooding 😵.
From these threats, we can derive a need for several security properties of the architecture.
- Location Servers must use stateless authentication challenges and similar measures to ensure that authentication attempts will not unnecessarily consume system resources. 🧱
- The Rule Maker must be able to provision policies that limit the rate at which Location Information is sent to prevent amplification attacks.
4.2. Host Attacks
4.2.1. Data Stored at Servers
LI kept on a server is exposed to lots of potential risks 🗂️. First, there may be accidental misuse of LI by the server. Whether it's negligence, carelessness, or just a lack of knowledge, the server might accidentally release LI to the wrong Location Recipients, or fail to filter the LI it sends out properly. Second, the server may intentionally misuse LI. A server could decide to sell a "profile" it has compiled on a Target or Location Recipient, even though the Rule Maker's Rule says otherwise. Or someone working for the server could misuse their access to get LI for personal gain 💸. Third, even with the most secure and trusted server, someone outside the system could still hack in to retrieve LI 🏴☠️. Last, someone could use the legal system to subpoena an individual's records from a Server. That process would likely reveal the Target's location info without notice to the Target or the Target's consent ⚖️.
Data stored at the server may reveal the Target's present location if the data is used or intercepted at or near the moment of transmission ⏱️. Say a Target requests a map from their current location to a nearby store, and the Location Server sends that info to the wrong Location Recipient. The Viewer could then know the identity of the Target, the Target's current location, and where the Target might be headed 🗺️.
Data stored at the Location Server can also create many of the traffic analysis threats discussed in Section 4.1 above 🔍. If someone gains access not only to the fact of the LO transmission but also to the LI transmitted, they can put together a history of where that Target has been, for how long, and with whom 🧾.
4.2.2. Data Stored in Devices 📱✨
Okay so bestie, Geopriv has to work with literally any type of technology or Device, which makes it super hard to figure out how risky a specific device actually is 🫠. Like, any device that keeps a log of the location requests it sent or the LOs it received poses a similar threat to the info sitting at a Location Server, which we already covered 🔥. And a court subpoena or warrant for someone's device could pull up that same kind of log 👀.
Depending on the device, data can also get compromised in some way, and that's always a possibility 💀. If a Device has a screen, there's always a chance another person gets to look at the display without the user knowing 🙈. A Device that gives verbal feedback (like giving directions to the blind) adds more ways for LI to leak 🗣️. Say the Target/Viewer is sitting in a public place and asks for directions from the Target's home to another location. Anyone who can hear the Device output might figure out the Target's identity, their residence, and maybe where they're headed 😭.
And if the device kept location information and then got lost or stolen, someone other than the Rule Maker could potentially access info about who LI was sent to and when, plus maybe where the Target was during each transaction 😱. That's so much private info, like who the owner has been hanging out with and every place the Target has been and for how long 💅.
4.2.3. Data Stored with the Viewer 🧚
The threats here are pretty much the same as the ones we just talked about for Location Servers and Devices 🫶. The whole point of giving this its own section is to show that, depending on how complicated the transaction is and who else is involved, data stored at different points can bring up the same kinds of privacy risks 🦋.
4.2.4. Information Contained in Rules 📜👀
Honestly, the Rules a Rule Maker creates can reveal info about either the Rule Maker or the Target, and that's a lot 😳. A rule that degrades all information sent out by approximately 25 miles might tell an interceptor how to figure out the Target's true location 🙃. Or take this rule: "Tell my boss what room I'm in when I'm in the building, but when I'm outside the building between 9 a.m. and 5 p.m. tell him I'm in the building," which reveals way more than most employees would ever want 💀. Any boss who was the Location Recipient and got LI that said "in the building" would instantly realize the employee was somewhere else 🚩.
If an entity could get into a log of data at the Location Server or at a Device, knowing the Rules would let them "decode" the device's location info into something way more accurate 🔍. So my boss could not only tell where I am at this minute, but could also tell how many times over the last year I had been outside the building between 9 a.m. and 5 p.m. 😭🫠.
The Rules themselves can also say stuff about the Target 🎀. A rule like the one above would clearly show the employment relationship between the two people, plus the fact that the employee was hiding something from the employer 👀. And when you put it together with other info, the location information might let someone identify the Target 🕵️♀️.
4.3. Usage Attacks 🌸
4.3.1. Threats Posed by Overcollection 🍓
Weak or missing default privacy rules would also put LI at risk 💔. Without default Rules for LOs, a ton of Devices would probably reveal LI by default 😬. Privacy rules should control the collection, use, disclosure, and retention of Location Information 📋. These rules must comply with fair information practices, which we'll dig into in Section 5.1 ✨.
Tech-savvy Device users can totally write their own privacy rules to protect their LI 🧠. But plenty of people won't have the skill or the motivation to do it 😴. So if everyone was left to their own devices, a lot of users would end up with no privacy rules for their LI at all 😱. That leaves their LI completely open to all kinds of attacks 💀. Default rules are the fix for this problem 🫶.
Without default rules, a device might just broadcast to anyone nearby at regular intervals, respond to anyone nearby who asked it something, or send signals out to unknown entities 📡🙈.
Also, without a default rule of "Do not re-distribute," the Location Server could pass the Target's location info along to other people 😤. And without a default rule limiting how long LI gets kept, the risk from inappropriate use and access to stored data goes way up 📈.
Defining default privacy rules is out of scope for this doc, but default rules are still necessary to limit the privacy risks of using services and devices that use LI 💜.
5. Countermeasures for Usage Violations 🛡️💖
5.1. Fair Information Practices 🧾✨
Okay, so the principles of fair information practices say that entities handling personal info have to meet certain obligations for its collection, use, maintenance, and security 📚. They also give the people whose info gets collected some due process-like rights over how it's handled ⚖️. These practices are designed to prevent specific threats that come from collecting personal info about individuals 🎯. That's why they're "countermeasures" that should be reflected in technical systems that handle personal info, along with the Rules that govern how it's used 🔐. A quick rundown of these practices might be super helpful when you're writing the requirements for the LO 📝.
There are seven main principles of fair information practices 👑:
- Openness: The existence of a record-keeping system for personal information must be known, along with a description of the main purpose and uses of the data. So any entity that collects LI should tell individuals that it's being collected and what it's being used for 📢. Openness is designed to stop secret systems from popping up 🕵️.
- Individual Participation: Individuals should have a right to view all information collected about them, and to correct or remove data that isn't timely, accurate, relevant, or complete 🙋♀️. This principle is there because sometimes the info that gets collected can be inaccurate or inappropriate 🙃.
- Collection Limitation: Data should be collected by lawful and fair means, and where appropriate, with the knowledge or consent of the subject. Data collection should be minimized to what's necessary to support the transaction 🤏. Setting limits on collection helps protect people from overcollection, whether that means grabbing too much info or holding onto it for too long 🗓️.
- Data Quality: Personal data should be relevant to the purposes it's collected and used for, and personal information should be accurate, complete, and timely 💯. This requirement is designed to prevent particular kinds of harm that can come from using personal info, whether that use is appropriate or not 🚫.
- Finality: There should be limits on the use and disclosure of personal data. Data should only be used for the purposes specified when it was collected, and shouldn't be otherwise used or disclosed without the consent of the data subject or other legal authority 🔒. Like, a consumer who gives LI to a business to get directions isn't giving it for any other reason 🗺️. So the business should only use that LI to provide directions, and nothing else 🚗.
- Security: Personal Data should be protected by reasonable security safeguards against risks like loss, unauthorized access, destruction, use, modification, or disclosure 🛡️. Some security measures can happen outside of the LO (like limiting which employees can access Location Servers), while others can be done through the LO or LO applications 🧑💻.
- Accountability: Record keepers should be accountable for following fair information practices 📒. It's usually easier for an individual to enforce these practices when they're explicitly written down, either in the Rules the Rule Maker writes or in contracts between the individual and a trusted entity 🤝✍️.
6. Security Properties of the Geopriv Protocol 🔐💫
The countermeasures suggested below reflect the threats discussed in this document 🎀. So there's some overlap between the proposed security properties listed below and the requirements in [1] 🔁.
6.1. Rules as Countermeasures 👑📏
The sections below are meant to show that in lots of cases, threats to LI can be limited through clear, unavoidable rules set by Rule Makers 🦋.
6.1.1. Rule Maker Should Define Rules 🧑⚖️
The Rule Maker for a given Device will usually be either the user or the owner of the Device 🙌. In some situations, the Rule Maker might be both of those people 😌. Depending on the device, the Rule Maker may or may not be the person most closely aligned with the Target 🤔. For example, a kid carrying a cell phone might be the Target, but the kid's parent would probably be the Rule Maker for the Device 👪. Giving the Rule Maker control is a chance to strengthen the consent part of the collection limitation and finality principles we just covered 💪.
6.1.2. Geopriv Should Have Default Rules 🌈
Some Rule Makers might not know how much Rules affect the disclosure of their LI, so Geopriv should include default Rules 🧠. The Rule Maker is always free to change their Rules to get more or less protection 🔄. To protect privacy and physical safety, default Rules should, at a minimum, limit the disclosure and retention of LI 🛡️.
Default Rules are also needed for so-called "dumb" Location Generators (LG) 🤖. If a LG can't figure out the Rules the Rule Maker set before it publishes the LO to a Location Server, it's important that some default Rules protect that LO in transit and make sure the LO only ends up with authorized Location Recipients 🚚. These default LG Rules would help prevent many of the threats discussed in this document 🙌. And the Rule Maker should be able to find out what these default Rules say at any time 🔍.
6.1.3. Location Recipient Should Not Be Aware of All Rules 🙈🤫
A Viewer should not be aware of all the Rules the Rule Maker defined 👀. The Viewer only needs to know the Rules it has to follow, like the ones about how it uses and keeps the LI 📝. Other Rules, like ones about the accuracy or filtering of the LI, or rules that don't cover the interaction at hand, should not be revealed to the Viewer 🙊. This countermeasure fits the minimization part of the collection limitation principle and makes sure the Rule Maker only reveals what they actually mean to reveal 💖✨.
6.1.4. Certain Rules Should Travel With the LO 🧳
Okay so LI security at the device level is kinda messy bestie 🙈 The Rule Maker has no real control over what happens to the LI once it lands at the Location Recipient 😭 BUT if certain Rules travel with the LO, the Rule Maker can encourage Viewer compliance with its Rules 💅 Like, a Rule could ride along with the LO and say when it's time to purge the data, which stops anyone from building a "log" of the Target's LI on any Device involved in sending the LO 🫶 Letting Rules travel with the LO can also limit the opportunity for traffic analysis attacks 🔥
6.2. Protection of Identities 🎀
Identities are literally the MVP of the LO 👑 In lots of cases, some form of identification of the Target, Rule Maker, and Viewer is needed for authentication, but there are different ways to separate those authentication "credentials" from the true identity of these devices ✨ These countermeasures are super useful because if a log of LI gets compromised, no matter where it came from, it's way less threatening to privacy when the Target's identity has been stripped 💖
6.2.1. Short-Lived Identifiers May Protect Target's Identity 🦋
Short-lived identifiers would let the using protocol hide the true identity of the Rule Maker and the Target from Location Servers or Location Recipients 🧚 They'd still allow authentication, so only appropriate Location Recipients get the LO 🙌 At the same time, making these identifiers short-lived helps stop any association between a Target's true identity and particular habits and associates 💜
6.2.2. Unlinked Pseudonyms May Protect the Location Recipients' Identity 🌸
Unlinked pseudonyms protect the Location Recipients' identity in much the same way short-lived identifiers protect the Target's 💅 When you use both, any record a Location Server keeps of a transaction would have two "credentials" tied to an LI transmission: one linked to the Target and one linked to the Location Recipient 🫶 Those credentials let the Location Server authenticate the transmission without ever learning the true identities of the people on each side 🔥
6.3. Security During Transmission of Data 🌈
The attacks described in this document motivate the following security properties for the connections between the Location Generator and Location Server, the Location Server and Rule Maker, and the Location Server and Location Recipient 👑
6.3.1. Rules May Disallow a Certain Frequency of Requests 🍓
The Rule Maker might be able to set a Rule that disallows a certain number of requests made within a specific period of time 🕰️ This kind of arrangement would let the Rule Maker somewhat stop attackers from spotting patterns in randomly coarsened data 🕵️♀️ Say an "untrusted" Location Recipient is only supposed to get LI coarsened to the level of a city. Only one request might be honored every 2 hours 😤 That way, Location Recipients can't keep sending repeated requests to squeeze out more accurate presence information 🙅♀️
Similarly, thresholds on notifications of location information can help to combat amplification attacks 📣
6.3.2. Mutual End-Point Authentication 🔐
Authentication is crucial to the security of LI during transmission 🥹 The Location Server must be capable of authenticating Location Recipients to prevent impersonation 🎭 Location Generators must be capable of authenticating Location Servers so raw location information isn't sent to improper entities 🚫 And Location Servers must be able to authenticate Rule Makers so unauthorized entities can't change Rules 🙅♀️
6.3.3. Data Object Integrity & Confidentiality 🧁
The LO must maintain integrity at all points of communication between Location Servers and Location Recipients 🛡️ Confidentiality is required on both the connection between the Location Generator and the Location Server, and on the connection between the Location Server and any given Location Recipient 🔒 Confidentiality of Rules sent over the network to the Location Server is of comparable importance 💜
6.3.4. Replay Protection 🔁
Replay protection stops an attacker from capturing a piece of location information and replaying it later to convince Viewers of an erroneous location for the Target 😱 Both Location Recipients and Location Servers may need replay protection, depending on their capabilities 🧠
7. Security Considerations 🚨
This informational document characterizes potential security threats targeting the Geopriv architecture 💀 Honestly, the whole document is about threats, so this section is giving "read the entire thing" energy 🙈
8. IANA Considerations 📋
This document introduces no additional considerations for IANA ✅
9. Informative References 📚
[1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, "Geopriv Requirements", RFC 3693, January 2004.
10. Authors' Addresses 💌
Michelle Engelhardt Danley
Samuelson Law, Technology & Public Policy Clinic
Boalt Hall School of Law
University of California
Berkeley, CA 94720
USA
EMail: mre213@nyu.edu
URI: http://www.law.berkeley.edu/cenpro/samuelson/
Deirdre 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/
John B. Morris, Jr.
Center for Democracy & Technology
1634 I Street NW
Suite 1100
Washington, DC 20006
USA
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/11. 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 on 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 on whether any license under such rights might or might not be available 🤷♀️ It also doesn't claim to have made any independent effort to identify any such rights 🙈 Information about the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for implementers or users of this specification to use such proprietary rights, 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 required to implement this standard 💌 Please send that information to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society 💜
📦 where this page comes from
- ietf: rfc3694 2004-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms