互联网协议的隐私注意事项

RFC6973：Privacy Considerations for Internet Protocols，July 2013

摘要

本文档为制定协议规范中包含的隐私注意事项提供了指导。它旨在让互联网协议的设计者、实施者和用户意识到与隐私相关的设计选择。它表明，任何单独的RFC是否保证特定的隐私考虑部分将取决于文档的内容。

关于本备忘录

本文件不是互联网标准轨道规范；它是为了提供信息而发布的。

本文件是互联网架构委员会（IAB）的产品，代表了IAB认为有价值的信息，以供永久记录。它代表了互联网架构委员会（IAB）的共识。IAB批准出版的文件不适用于任何级别的互联网标准；参见RFC 5741的第2节。

有关本文件的当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6973.

版权声明

版权所有（c）2013 IETF Trust和文件作者。保留所有权利。本文件受BCP 78和IETF信托与IETF文件相关的法律规定的约束(http://trustee.ietf.org/license-info)自本文件发布之日起生效。请仔细查看这些文件，因为它们描述了您对本文件的权利和限制。

1、 简介

[RFC3552]为协议设计者提供了关于如何将安全性作为协议设计的一部分以及如何将安全问题告知协议规范的读者的详细指导。本文件旨在提供一套类似的指南，用于在协议设计中考虑隐私。

隐私是一个复杂的概念，有着丰富的历史，涵盖了许多学科。关于数据，这通常是一个适用于“个人数据”的概念，通常定义为与已识别或可识别个人有关的信息。多年来，在不同的论坛上开发了许多隐私原则和隐私设计框架。其中包括公平信息实践（Fair Information Practices，FIPs），这是一套与收集和使用个人数据有关的隐私保护基线（例如，通常基于经合组织制定的原则），以及为系统设计提供高级隐私指导的“设计隐私”概念（例如，见[PbD]）。本文件中提供的指导受到了先前工作的启发，但其目的是更具体，将协议设计者引向可能影响使用互联网协议的个人隐私的特定工程选择。

不同的人对隐私意味着什么有着截然不同的概念，无论是从总体上还是与他们个人有关的概念[Westin]。此外，隐私作为一个法律概念在不同的司法管辖区有不同的理解。本文件中提供的指导是通用的，可用于为世界任何地方使用的任何协议的设计提供信息，而无需参考具体的法律框架。

任何单独的文档是否有特定的隐私考虑部分将取决于文档的内容。完全以隐私为重点的文档可能不值得单独一节（例如，“可信网络内断言身份的会话发起协议（Session Initiation Protocol，SIP）的私有扩展”[RFC3325]）。对于某些规范，隐私考虑是安全考虑的一个子集，可以在安全考虑部分中明确讨论。有些文件不需要讨论隐私问题（例如，“Opus音频编解码器的定义”[RFC6716]）。此处提供的指导可以而且应该用于评估协议、体系结构和操作规范的隐私考虑因素，并决定这些考虑因素是在单独的部分、安全考虑因素部分还是在整个文档中进行记录。这里提供的指导旨在帮助隐私分析的思维过程；它没有提供如何编写隐私考虑部分的具体说明。

本文件的组织结构如下：第2节描述了这里提供的指导在IETF和更大的互联网社区中的适用范围；第3节解释了本文件中使用的术语；第4节回顾了典型的通信体系结构，以了解在哪些方面可能存在隐私威胁；第5节讨论了应用于互联网协议时对隐私的威胁；第6节概述了这些威胁的缓解措施；第7节提供了在IETF规范中分析和记录隐私注意事项的指南；第8节研究了IETF协议的隐私特性，以演示指导框架的使用。

2、 互联网协议的隐私影响范围

互联网协议通常是灵活构建的，这使得它们在各种体系结构、上下文和部署场景中都很有用，而不需要在不同设计的组件之间有显著的相互依赖性。尽管协议设计者在设计时通常会考虑到一个特定的目标体系结构或一组体系结构，但在实现存在并与其他协议或组件组合部署以形成完整的系统之后，体系结构框架在以后开发并不罕见。

因此，协议设计者在设计时能够预见特定协议的所有隐私影响的程度是有限的。单个协议本身可能是相对良性的，并且它可以利用协议栈的较低层（互联网协议安全性、传输层安全性等）的隐私和安全特性来降低攻击风险。但是，当部署在更大的系统中或以设计时未设想的方式使用时，其使用可能会产生新的隐私风险。协议通常在设计时间后很长一段时间由不同于协议设计人员的人员来实现和部署。第7节中的指导方针要求协议设计者考虑他们的协议如何与存在于协议边界之外的系统和信息交互，但不要想象每一种可能的部署场景。

此外，在许多情况下，系统的隐私属性取决于完整的系统设计，其中各种协议被组合在一起以形成产品解决方案；实现，包括用户界面设计；以及操作部署实践，包括进行部署的公司的默认隐私设置和安全流程。这些细节特定于特定的实例化，并且通常在IETF中进行的工作范围之外。这里提供的指导可能有助于选择这些细节，但其主要目的是帮助设计、实施和操作协议。

数据收集和使用的透明度（通常通过用户界面设计来实现）通常被视为决定系统隐私影响的关键因素（无论是正确的还是错误的）。尽管大多数IETF活动不涉及标准化用户界面或面向用户的通信，但在某些情况下，理解预期的用户交互对协议设计可能很重要。意外的用户行为可能会对安全性和/或隐私产生不利影响。

总之，隐私问题，甚至是与协议开发相关的问题，都超出了本文讨论的技术指导范围。例如，考虑HTTP[RFC2616]，它被设计为允许交换任意数据。对使用HTTP的隐私考虑因素的完整分析可能包括交换什么类型的数据、如何存储这些数据以及如何处理这些数据。因此，对个人静态个人网页的分析将不同于使用HTTP交换健康记录。从事HTTP扩展（如Web分布式创作和版本控制（Web Distributed Authoring and Versioning，WebDAV）[RFC4918]）的协议设计者不应描述所有可能的使用场景中产生的隐私风险，而应描述扩展特定的隐私属性以及设计时预期和预见的扩展的任何特定用途。

3、 术语

本节定义了本文件中使用的基本术语，并酌情引用了预先存在的定义。与[RFC4949]中一样，每个条目前面都有一个美元符号（$）和一个用于自动搜索的空格。请注意，本文档并没有试图用简短的定义来定义“隐私”一词。相反，隐私是本文档所包含内容的总和。因此，我们遵循[RFC3552]所采取的方法。[RFC4949]中提供了几种不同简要定义的示例。

3.1、 实体

其中几个术语在第4节中作了进一步的阐述。

$Attacker：一个反对一个或多个隐私保护目标的实体。与观察者不同，攻击者的行为是未经授权的。

$Eavesdropper：一种在启动器不知情或未经授权的情况下被动观察启动器通信的攻击者。参见[RFC4949]。

$Enabler：一种协议实体，用于促进发起方和接收方之间的通信，而无需直接位于通信路径中。

$Individual：一个人。

$Initiator：一个协议实体，用于启动与接收方的通信。

$Intermediate：位于发起方和接收方之间的协议实体，是发起方和接收者进行通信所必需的。与窃听者不同，中介是通信体系结构的一部分，因此至少是默认授权的实体。例如，SIP[RFC3261]代理是SIP体系结构中的中介。

$Observer：一个能够观察和收集通信信息的实体，根据具体情况可能会对隐私构成威胁。正如本文档中所定义的，发起方、接收方、中介方和启用方都可以是观察者。观察员与窃听者的区别在于，他们至少得到了默许。

$Recipient：从发起方接收通信的协议实体。

3.2、 数据与分析

$Attack：一个实体试图侵犯个人隐私的故意行为。参见[RFC4949]。

$Correlation：与个人相关的各种信息的组合，或者在组合时获得该特征的信息。

$Fingerprint：标识设备或应用程序实例的一组信息元素。

$Fingerprinting：观察者或攻击者根据与观察者或攻击者通信的多个信息元素（以足够高的概率）唯一识别设备或应用程序实例的过程。参见[EF]。

$Item of Interest（IOI）：观察者或攻击者可能感兴趣的任何数据项。这包括属性、标识符、身份、通信内容以及发生通信交互的事实。

$Personal Data：与可以直接或间接识别的个人有关的任何信息。

$(Protocol) Interaction：特定协议中的通信单元。单个交互可以由发起方和接收方之间的单个消息或多个消息组成，具体取决于协议。

$Traffic Analysis：通过观察流量（存在、不存在、数量、方向、定时、数据包大小、数据包组成和/或频率）推断信息，即使流量是加密的。参见[RFC4949]。

$Undetectability：观察者或攻击者无法充分区分感兴趣的项目是否存在。

$Unlinkability：在一组特定的信息中，观察者或攻击者无法区分两个感兴趣的项目是否相关（具有足够高的概率，对观察者或攻击者有用）。

3.3、 可识别性

$Anonymity：匿名的状态。

$Anonymity Set：一组具有相同属性的个人，从特定攻击者或观察者的角度来看，使他们无法区分。

$Anonymous：一个个体的状态，在这种状态下，观察者或攻击者无法在一组其他个体（匿名集）中识别该个体。

$Attribute：个人的属性。

$Identifiability：个人可识别的程度。

$Identifiable：观察者或攻击者能够知道个人身份的属性。

$Identification：将信息链接到特定的个人，以推断个人的身份，或允许在某些情况下推断个人的身分。

$Identified：个人身份已知的状态。

$Identifier：在某些上下文中唯一引用协议实体或个人的特定标识的数据对象。参见[RFC4949]。标识符可以基于自然名称——官方名称、个人名称和/或昵称——也可以是人工的（例如x9z32vb）。然而，根据定义，标识符在其使用上下文中是唯一的，而自然名称通常不是唯一的。

$Identity：个人属性的任何子集，包括在给定上下文中标识个人的名称。个人通常有多种身份，可以在不同的环境中使用。

$Identity Confidentiality：个人的属性，只有接收者才能在一组其他个人中充分识别该个人。这可能是身份验证协议的一个理想特性。

$Identity Provider：负责建立、维护、保护和担保与个人相关的身份的实体（通常是一个组织）。

$Official Name：在某些官方背景下注册的个人姓名（例如，个人出生证明上的姓名）。官方名称往往不是唯一的。

$Personal Name：个人的自然名称。个人名字往往不是唯一的，通常包括与姓氏组合的名字。一个人在一生中的任何时候都可能有多个个人名字，包括官方名字。从技术角度来看，不能总是确定对个人的特定提及是否是或基于个人的个人姓名（见假名）。

$Pseudonym：个人在某些情况下使用的名字，与该情况下其他人已知的个人姓名无关，目的是不透露与他或她的其他姓名相关的个人身份。假名往往不是唯一的。

$Pseudomanity：使用假名的状态。

$Pseudonymous：个人的属性，其中个人由假名识别。

$Real Name：请参阅个人姓名和正式姓名。

$Relying Party：依靠身份提供者对个人身份的断言为个人提供服务的实体。实际上，依赖方将身份管理的各个方面委托给身份提供者。这种委托需要协议交换、信任以及对依赖方和身份提供者之间交换的信息语义的共同理解。

4、 沟通模式

为了理解隐私危害意义上的攻击，考虑整体通信架构和不同参与者在其中的角色是有帮助的。考虑一个协议实体，即“发起人”，它发起与某些接收方的通信。隐私分析与协议最相关，在这些协议中，发起人代表个人（或不同时间的不同个人）行事。正是这个人的隐私受到了潜在的威胁（尽管在某些情况下，发起人会传达另一个人的信息，在这种情况下，他们的隐私利益都会受到牵连）。

通信可以是发起方和接收方之间的直接通信，也可以涉及双方通信所必需的应用层中介（如代理、缓存或中继）。在某些情况下，该中介在通信的整个持续时间内保持在通信路径中；有时它只用于通信建立，用于入站或出站通信。在某些情况下，可能会遍历一系列中介。在较低层，参与分组转发的附加实体也可能干扰隐私保护目标。

一些通信任务需要与不同实体进行多协议交互。例如，在向HTTP服务器发出请求之前，发起方和用于网络访问的认证、授权和计费（Authentication，Authorization，and Accounting，AAA）服务器之间以及向用于名称解析的域名系统（Domain Name System，DNS）服务器之间可以进行交互。在这种情况下，HTTP服务器是接收方，而其他实体是发起方到接收方通信的推动者。类似地，与接收方的单个通信可能会在发起方或接收方与其他实体之间产生进一步的协议交互，并且实体的角色可能会随着每次交互而改变。例如，HTTP请求可能会触发与身份验证服务器或其他资源服务器的交互，其中接收方将成为这些稍后交互的发起方。

因此，当对涉及多个通信阶段的架构进行隐私分析时，从隐私考虑的角度来看，所涉及的实体可能在每个阶段扮演不同的或相反的角色。了解整个体系结构的隐私含义可能需要对每个阶段进行单独的分析。

协议设计通常基于这样一种概念，即接收方、中介机构和启用方被认为有权接收和处理来自发起方的数据。正如[RFC3552]所解释的，“我们假设参与协议交换的终端系统本身没有受到损害”。然而，隐私分析需要质疑这一假设，因为系统经常为了获取个人数据而受到损害。

尽管接收者、中间人和启用者通常不被视为攻击者，但他们都可能构成隐私威胁（取决于上下文），因为他们能够观察、收集、处理和传输与隐私相关的数据。以下将这些实体统称为“观察者”，以区别于传统攻击者。从隐私的角度来看，一种重要类型的攻击者是窃听者：一种在发起者不知情或未经授权的情况下被动观察发起者通信的实体。

下一节中的威胁描述解释了观察者和攻击者可能如何伤害个人隐私。不同种类的攻击在通信路径中的不同点可能是可行的。例如，观察者可以在启动器和中介之间发起监视或识别攻击，或者可以监视使能器（例如，通过观察启动器的DNS查询）。

5、 隐私威胁

隐私危害有多种形式，包括对财务状况、声誉、孤独、自主和安全的危害。例如，身份盗窃或勒索的受害者可能因此遭受经济损失。当披露有关个人的信息，无论是真是假，都会使该个人遭受耻辱、尴尬或个人尊严的丧失时，就会发生声誉损害。侵犯或中断个人的生活或活动可能会损害个人独处的能力。当个人或其活动受到监测、暴露或面临暴露风险时，这些人可能会被扼杀，无法表达自己，无法与他人交往，也无法自由地生活。他们可能也会感到普遍的不安，因为被监控或收集有关他们的数据是“令人毛骨悚然的”。如果这种监控是为了跟踪或暴力（例如，监控进出家庭虐待庇护所的通信），可能会使个人处于人身危险之中。

本节列出了常见的隐私威胁（大量引用[Solove]和[CoE]），显示了每一种威胁都可能导致个人遭受隐私伤害，并提供了这些威胁如何在互联网上存在的例子。这种威胁建模的灵感来源于安全威胁分析。尽管它并不完全适合评估互联网协议和系统中的隐私风险，但迄今为止还没有开发出更好的方法。

一些隐私威胁已经在互联网协议中被视为常规安全分析的一个问题。其他则是更纯粹的隐私威胁，现有的安全考虑通常不会解决这些威胁。这里描述的威胁分为也可能被视为安全威胁的威胁和主要是隐私威胁的威胁。

请注意，个人对下述做法的认识和同意可能会改变个人对其威胁隐私程度的看法和担忧。例如，如果个人授权监督自己的活动，该个人可能能够采取行动减轻与之相关的伤害，或者可能认为伤害的风险是可以容忍的。

5.1、 组合安全隐私威胁

5.1.1、 监督

监视是对个人通信或活动的观察或监控。监视对个人的影响可能从焦虑和不适到行为变化，如抑制和自我审查，甚至对个人实施暴力。个人不需要意识到监视会影响他或她的隐私：监视的可能性可能足以损害个人的自主权。

即使被监视的个人无法识别，或者他们的通信被加密，监视也会影响隐私。例如，进行流量分析的观察者或窃听者可能能够确定存在什么类型的流量（例如，实时通信或批量文件传输）或正在使用哪些协议，即使观察到的通信是加密的或通信者是不可识别的。这种监视可能会对相关人员产生不利影响，使他们成为进一步调查或执法活动的目标。它还可能启用特定于协议的攻击，例如重定向到专门的拦截点或特定于协议拒绝服务。使用可预测的分组大小或定时或在分组内的可预测偏移处包括固定令牌的协议可以促进这种监视。

监视可以由观察者或窃听者在通信路径上的任何点进行。保密保护（如[RFC3552]第3节所述）对于防止对通信内容的监控是必要的。为了防止对通信模式进行流量分析或其他监控，可能需要采取其他措施，如[Tor]。

5.1.2、 存储数据泄露

未采取适当措施保护存储数据不受未经授权或不适当访问的终端系统会使个人面临潜在的财务、声誉或身体伤害。

防止存储数据泄露通常不在IETF协议的范围内。然而，许多常见的协议功能（例如，密钥管理、访问控制或操作日志记录）需要存储有关通信启动器的数据。当要求或建议由终端系统存储或记录有关启动器或其通信的信息时（例如，参见RFC 6302[RFC6302]），重要的是要认识到该信息被泄露的可能性，并将该可能性与数据存储的好处进行权衡。任何存储数据的接收方、中间方或启用方都可能容易受到损害。（请注意，存储数据泄露不同于有目的的披露，第5.2.4节对此进行了讨论。）

5.1.3、 入侵

入侵包括扰乱或中断一个人的生活或活动的入侵行为。入侵可以挫败个人独处的欲望，消耗他们的时间或注意力，或中断他们的活动。这种威胁集中在对一个人生活的入侵上，而不是直接入侵一个人的通信。后者见第5.1.1节。

未经请求的消息和拒绝服务攻击是互联网上最常见的入侵类型。任何能够向启动器发送不需要的流量的攻击者都可以实施入侵。

5.1.4、 错误归因

当与一个人有关的数据或通信被归因于另一个人时，就会发生错误归因。误认可能会给被误认的个人带来不利的声誉、财务或其他后果。

协议上下文中的错误归因是由于使用了不充分或不安全的身份或身份验证形式造成的，有时与欺骗有关。例如，正如[RFC6269]所指出的，滥用缓解通常是在源IP地址的基础上进行的，这样，如果确定滥用活动来源于各个IP地址，则可以阻止或暂时将其列入黑名单。然而，在多个个人共享一个IP地址的情况下，共享该地址的所有个人都可能受到这些处罚，即使他们没有参与滥用。这种威胁可以通过使用具有适当身份验证形式的身份管理机制（理想情况下具有加密属性）来缓解，这样可以将行动唯一地归因于个人，从而为问责制提供基础，而不会产生误报。

5.2、 隐私特定威胁

5.2.1、 相关性

相关性是与个人相关的或在组合时获得该特征的各种信息的组合。相关性可以挑战人们对他人所知的极限的期望。它可以增加相关者对个人的权力，以及相关者做出判断的能力，威胁个人的自主权和声誉。

相关性与识别密切相关。互联网协议可以通过允许随着时间的推移跟踪和组合个人的活动来促进相关性。在堆栈的任何层使用持久的或不常被替换的标识符可以促进相关性。例如，发起方在多次交互中持续使用相同的设备ID、证书或电子邮件地址，可以允许接收方（和观察者）随着时间的推移关联发起方的所有通信。

例如，考虑传输层安全性（Transport Layer Security，TLS）会话恢复[RFC5246]或没有服务器端状态的TLS会话恢复[RFC 5077]。在RFC 5246[RFC5246]中，服务器在ServerHello消息中为客户端提供session_id，并缓存master_secret以供以后交换。当客户端启动与服务器的新连接时，它会在其ClientHello消息中重新使用以前获得的session_id。服务器同意通过使用相同的session_id和先前存储的master_secret来恢复会话，以生成TLS记录层安全联盟。RFC5077[RFC5077]借鉴了会话恢复的设计思想，但服务器将所有状态信息封装到票证中，而不是缓存它。能够观察TLS客户端和TLS服务器之间的协议交换的攻击者能够在会话id和票证以明文形式交换时（初始握手消息中交换的数据就是这样）将初始交换链接到随后恢复的TLS会话。

理论上，任何接收到发起方通信的观察者或攻击者都可以参与关联。潜在相关性的程度将取决于实体从启动器接收到什么数据，以及是否可以访问其他数据。通常，中介只需要少量的信息来进行消息路由和/或安全性。理论上，协议机制可以确保这些实体无法访问端到端信息，但在实践中，部署端到端安全程序的困难、额外的消息传递或计算开销以及其他业务或法律要求往往会减缓或阻止端到端安全机制的部署，从技术角度来看，让中介机构更多地接触发起人的数据，而不是绝对必要的。

5.2.2、 标识

身份识别是将信息与特定个人联系起来，以推断个人身份或允许推断个人身份。在某些情况下，识别个人是完全合法的，而在另一些情况下，身份识别可能会抑制个人的匿名或假名能力，从而扼杀他们的活动或表达。身份识别也使个人更容易受到他人（如政府）的明确控制，并与其他个人相比受到区别对待。

许多协议提供了一些功能来传达这样一种想法，即已经提供了一些方法来验证实体是他们声称的实体。通常，这是通过加密身份验证来实现的。此外，许多协议标识符，例如在SIP或可扩展消息传递和存在协议（Extensible Messaging and Presence Protocol，XMPP）中使用的协议标识符，可以允许直接识别个人。协议标识符也可以通过相关性间接地对识别做出贡献。例如，一个不直接对用户进行身份验证的网站可以将其HTTP头日志与另一个对用户进行验证的网站的日志相匹配，从而使第一个网站上的用户可以识别。

与关联一样，任何观察者或攻击者都可以参与识别，这取决于通过协议机制或其他渠道可获得的关于启动器的信息。

5.2.3、 二次使用

二次使用是指未经个人同意，将收集到的个人信息用于与收集信息不同的目的。二次使用可能会违背人们的期望或欲望。二次使用的可能性可能会产生未来如何使用信息的不确定性，这可能会从一开始就阻碍信息交流。二次使用包括对数据的任何使用，包括披露。

二次使用的一个示例是身份验证服务器，该服务器使用网络访问服务器的访问请求来跟踪启动器的位置。任何观察者或攻击者都可能对启动器的数据进行不必要的二次使用，防止二次使用通常不在IETF协议的范围内。

5.2.4、 披露

披露是对个人信息的披露，影响他人对个人的判断。披露可能会违反个人对其共享数据保密性的期望。披露的威胁可能会阻止人们参与某些活动，因为他们担心声誉受到损害，或者仅仅因为他们不希望被观察到。

任何接收到关于启动器的数据的观察者或攻击者都可能参与披露。有时披露是无意的，因为系统设计者没有意识到所交换的信息与个人有关。协议限制公开的最常见方式是提供访问控制机制（在第5.2.5节中讨论）。IETF地理位置隐私体系结构[RFC6280]提供了另一个例子，它支持用户表达一种方式，即他们的位置信息不被公开到预期接收者之外。

5.2.5、 排除

排除是指未能让个人了解他人掌握的关于他们的数据，并参与其处理和使用。排除减少了维护人员信息的实体的责任，并在个人控制信息收集和使用方式的能力方面造成了一种脆弱感。

互联网协议参与强制排除的最常见方式是通过访问控制机制。IETF中开发的存在体系结构是一个很好的例子，其中个人被包括在关于他们的信息的控制中。使用规则表达语言（例如，呈现授权规则[RFC5025]），呈现客户端可以授权其呈现信息可以被共享的特定条件。

当接收方未能让发起方参与有关数据收集、处理和使用的决策时，排除主要被认为是有问题的。窃听者本质上是在进行排除，因为他们的数据收集和处理做法是隐蔽的。

6、 威胁缓解

众所周知，隐私难以衡量和量化。特定协议、系统或体系结构“保护”或“增强”隐私的程度取决于与其设计、使用和潜在滥用有关的大量因素。然而，针对第5节中讨论的威胁，有一些公认的缓解措施。本节描述了三类相关缓解措施：（1）数据最小化、（2）用户参与和（3）安全。本节中描述的隐私缓解措施可以松散地映射到现有的隐私原则，如公平信息实践，但它们已经进行了调整，以适应本文件的目标受众。

6.1、 数据最小化

数据最小化是指收集、使用、披露和存储执行任务所需的最小数据。减少交换的数据量可以减少可能被滥用或泄露的数据量。

数据最小化可以通过多种不同的方式实现，包括限制个人数据的收集、使用、披露、保留、可识别性、敏感性和访问。将协议元素收集的数据仅限于必要的数据（收集限制）是帮助减少与协议使用相关的隐私风险的最直接的方法。在某些情况下，协议设计者也可以建议限制数据的使用或保留，尽管协议本身通常不能控制这些属性。

然而，数据最小化在协议设计中最直接的应用是限制可识别性。通过使用假名或根本不使用标识符来减少数据的可识别性，有助于削弱个人与其通信之间的联系。允许周期性地创建新的或随机化的标识符降低了多个协议交互或通信可以关联回同一个体的可能性。以下部分探讨了协议设计者可能寻求实现的与可识别性相关的许多不同属性。

数据最小化可以缓解以下威胁：监视、存储数据泄露、关联、识别、二次使用和披露。

6.1.1、 匿名

为了实现个人的匿名性，必须存在一组看起来与该个人具有相同属性的个人。对于攻击者或观察者来说，这些人必须看起来彼此无法区分。所有这些个体的集合被称为匿名集合，并且这个集合的成员身份可能随着时间的推移而变化。

匿名集的组成取决于观察者或攻击者的知识。因此，匿名性相对于观察者或攻击者而言是相对的。发起人可能仅在一组潜在发起人中是匿名的（其发起人匿名集），其本身可能是所有可能发起通信的个人的子集。相反，收件人可能仅在一组潜在收件人中是匿名的，即其收件人匿名集。两个匿名集合可能是不相交的，可能重叠的，或者可能是相同的。

例如，考虑RFC 3325（P-Asserted-Identity（PAI））[RFC3325]，这是会话发起协议（SIP）的扩展，允许个人，例如IP语音（Voice over IP，VoIP）呼叫者，指示他或她信任的中介不要用个人的已验证和验证的身份填充SIP From报头字段。因此，呼叫的接收方以及个人信任域之外的任何其他实体只会知道SIP消息（通常是SIP INVITE）是用标题字段“From:“Anonymous”SIP:anonymous@anonymous.invalid”，而不是个人的记录地址，后者通常被认为是用户的“公共地址”。当使用PAI时，该个人在启动器匿名集合中变为匿名，该集合由每个使用该特定中介的个人填充。

注意，该示例忽略了接收方可以从其他SIP有效载荷（例如，SIP Via和Contact报头、会话描述协议（Session Description Protocol，SDP））推断或获得个人数据的事实。这意味着PAI只试图解决特定的威胁，即披露接收方的身份（在From报文头中）。这个警告使特定协议扩展的分析更容易，但在进行整个体系结构的分析时不能假设。

6.1.2、 假名

在互联网协议的背景下，几乎所有的标识符都可以是昵称或假名，因为通常不需要在协议中使用个人名称。然而，在某些情况下，可以合理地假设将使用个人姓名（例如，vCard[RFC6350]）。

当较少的个人数据可以与假名联系在一起时，假名性就会得到加强；当同一个假名被使用的频率较低并且在较少的上下文中使用时；以及当独立选择的假名更频繁地用于新的动作时（从观察者或攻击者的角度来看，这使得它们不可链接）。

对于互联网协议，以下是重要的考虑因素：协议是否允许在没有人类互动的情况下更改假名，默认的假名寿命长度，假名暴露给谁，个人如何能够控制披露，更改假名的频率，以及更改假名的后果。

6.1.3、 身份保密

当接收方以外的任何一方无法在匿名集中充分识别发起方时，发起方具有身份机密性。匿名集的大小对身份机密性有直接影响，因为匿名集越小，就越容易识别发起人。身份保密旨在提供针对窃听者和中介的保护，而不是针对预期的通信端点的保护。

例如，考虑使用可扩展身份验证协议（Extensible Authentication Protocol，EAP）[RFC3748]的网络访问身份验证过程。EAP包括身份交换，其中身份响应主要用于路由目的和选择要使用的EAP方法。由于EAP身份请求和身份响应是以明文形式发送的，因此沿着EAP对等体和EAP服务器之间的通信路径的窃听者和中介可以窥探身份，该身份以RFC 4282[RFC4282]中定义的网络接入标识符（Network Access Identifier，NAI）的形式编码。为了解决这种威胁，如RFC 4282[RFC4282]中所讨论的，NAI的用户名部分（但不是领域部分）可以通过EAP方法提供的加密支持对这些窃听者和中介机构隐藏。身份保密性已成为EAP的推荐设计标准（参见[RFC4017]）。例如，用于第三代认证和密钥协商的EAP方法（Authentication and Key Agreement，EAP-AKA）[RFC4187]通过利用临时身份来保护EAP对等方的身份不受被动对手的攻击。EAP互联网密钥交换协议版本2（EAP-Internet Key Exchange Protocol version 2，EAP-IKEv2）方法[RFC5106]是EAP方法的一个示例，该方法提供针对个人身份的主动攻击者的保护。

6.1.4、 身份管理中的数据最小化

现代系统越来越多地依赖多方交易来验证个人身份。这些系统中的许多系统使用身份提供者，该身份提供者负责向提供一些受保护资源的依赖方提供AAA功能。为了方便这些功能，身份提供者通常会经过验证个人身份并向个人颁发证书的过程。当个人试图使用依赖方提供的服务时，依赖方依赖其身份提供者提供的身份验证断言。请注意，在更复杂的场景中，身份验证断言是展示个人能力和角色的特征。授权责任也可以在身份提供者和依赖方之间分担，并且不一定只需要与身份提供者共存。

这样的系统能够支持以不同方式最小化数据收集的许多属性：

在某些用例中，依赖方不需要知道个人的真实姓名或出生日期（例如，当个人的年龄是唯一需要验证的属性时）。

可以防止串通的依赖方使用个人的证件来跟踪个人。也就是说，可以防止两个不同的依赖方确定同一个人已经向他们两个进行了身份验证。这通常需要身份管理协议的支持以及依赖方和身份提供者的支持。

可以防止身份提供者知道个人与哪些依赖方进行了互动。这至少需要在发起方访问资源时避免身份提供者和依赖方之间的直接通信。

6.2、 用户参与

如第5.2.5节所述，在个人不知情的情况下“秘密”收集和使用数据，容易侵犯个人的隐私期望，并可能导致数据滥用。因此，隐私制度往往包括一些规定，要求向个人通报数据收集和使用情况，并让他们参与有关数据处理的决定。在工程环境中，支持用户参与的目标通常意味着为用户提供控制共享数据的方法。这也可能意味着为用户提供方式，以表明他们希望如何使用和共享自己的数据。不同的协议和架构设计可以使支持用户参与（例如，支持用于用户交互的对话框的能力）变得更容易或更困难；例如，基于OAuth的服务可能比AAA服务具有更自然的用户输入挂钩。

用户参与可以缓解以下威胁：监视、二次使用、披露和排除。

6.3、 安全

保持数据在静止和传输过程中的安全是隐私保护的另一个重要组成部分。正如[RFC3552]第2节所述，许多安全目标也有助于增强隐私：

*保密性：对无意中的侦听器保密数据。

*对等实体身份验证：确保通信的端点是预期的端点（支持维护机密性）。

*未经授权的使用：仅将数据访问权限限制为那些获得授权的用户。（请注意，这个目标也属于数据最小化范围。）

*使用不当：限制授权用户使用数据的方式。（请注意，这个目标也属于数据最小化范围。）

请注意，即使实现了这些目标，感兴趣的项目的存在——属性、标识符、身份、通信、动作（例如通信的发送或接收），或者攻击者或观察者可能感兴趣的任何其他项目——仍然可能是可检测的，即使它们不可读。因此，不可检测性，即观察者或攻击者无法充分区分感兴趣的项目是否存在，可以被视为进一步的安全目标（尽管这可能极难实现）。

通过流量分析检测正在使用的协议或应用程序可能特别难以防范。与个人的匿名性一样，实现“协议匿名性”需要存在多个似乎具有相同属性的协议或应用程序——例如，数据包大小、内容、令牌位置或数据包间定时。如果多个协议或应用程序无法区分，攻击者或观察者将无法使用流量分析来识别正在使用的协议或应用软件。

对于不同的协议，在不同程度上防范流量分析的威胁是可能的，可能取决于实现或使用特定的细节，也可能取决于哪些其他协议已经存在，以及它们是否共享类似的流量特性。防御措施也将因协议的设计目的而异；例如，在某些情况下，随机化数据包大小、定时或令牌位置将减少流量分析的威胁，而在其他情况下（例如实时通信），将这些因素中的一些或全部保持不变是更合适的防御措施。请参阅“安全RTP可变比特率音频使用指南”[RFC6562]，以了解如何评估这些权衡的示例。

通过提供适当的安全保护，可以减轻以下威胁：监视、存储数据泄露、错误归因、二次使用、泄露和入侵。

7、 指导方针

本节以关于正在设计的方案的问卷形式为文件作者提供指导。调查问卷在设计过程中的任何时候都可能有用，特别是在文档作者开发了[RFC4101]中描述的高级协议模型之后。

请注意，本节中提供的指导并不建议具体做法。IETF中开发的协议范围太广，无法就数据的特定用途或如何平衡隐私与其他设计目标提出建议。然而，通过仔细考虑每个问题的答案，文档作者应该能够进行全面的分析，作为讨论协议是否充分保护隐私免受威胁的基础。本指南旨在帮助隐私分析的思维过程；它没有提供如何编写隐私考虑部分的具体说明。

该框架分为四个部分：三个部分涉及第6节中的每个缓解类别，外加一个通用部分。由于[RFC3552]中已经存在实质性指导，因此安全性尚未得到充分阐述。

7.1、 数据最小化

a.标识符。协议使用哪些标识符来区分通信的发起者？协议是否使用允许不同协议交互相互关联的标识符？在实现协议目标的同时，哪些标识符可以省略或减少识别？

b.数据。协议暴露了哪些关于个人、他们的设备和/或他们的设备使用的信息（除了（a）中讨论的标识符）？这些信息在多大程度上与个人身份有关？协议如何将个人数据与（a）中讨论的标识符相结合？

c.观察员。（a）和（b）中讨论的哪些信息暴露给每个其他协议实体（即接收方、中介方和启用方）？协议实现者是否有办法选择限制与每个实体共享的信息？是否有可用的操作控制措施来限制与每个实体共享的信息？

d.指纹。在许多情况下，协议中信息元素的特定顺序和/或出现允许使用该协议的用户、设备或软件被指纹识别。该协议易受指纹识别攻击吗？如果是，怎么做？它的设计可以减少或消除漏洞吗？如果没有，为什么不呢？

e.标识符的持久性。协议设计中对（a）中讨论的标识符的使用寿命做出了哪些假设？协议是否允许实现者或用户删除或替换标识符？规范建议在默认情况下多久删除或替换一次标识符？标识符以及其他状态信息是否可以设置为自动过期？

f.相关性。协议是否允许标识符的关联？是否有预期的方式将协议暴露的信息与协议外获得的信息相结合或关联？这种组合或关联将如何促进用户、设备或应用程序的指纹识别？是否存在预期的与外部数据的组合或相关性，从而使协议的用户更容易识别？

g.保留。协议或其预期用途是否要求接收方、中介机构或启用方保留（a）或（b）中讨论的信息？如果是，为什么？保留是持久的还是暂时的？

7.2、 用户参与

a.用户控制。在通过协议共享或暴露个人数据或标识符之前，协议定义或要求什么控制或同意机制？如果没有规定此类机制或控制，是否预期控制和同意将在协议之外处理？

b.控制与个别收件人的共享。协议是否为发起人提供了与不同收件人共享不同信息的方式？如果没有，协议之外是否存在为启动器提供此类控制的机制？

c.对与中介机构共享的控制。协议是否为启动器提供了限制与中介共享哪些信息的方法？如果没有，协议之外是否存在为用户提供此类控制的机制？是否期望用户与运营这些中介机构的人建立管理信息使用的关系（合同关系或其他关系）？

d.偏好表达。该协议是否为发起人提供了向接收者或中介人表达个人在收集、使用或披露其个人数据方面的偏好的方式？

7.3、 安全

a.监督。协议的安全考虑如何防止监视，包括窃听和流量分析？协议是否泄露了可以通过流量分析观察到的信息，例如通过使用固定偏移量的固定令牌，或者允许观察者确定流量特性的数据包大小或定时（例如，正在使用哪个协议，或者流量是否是实时流的一部分）？

b.存储数据泄露。协议的安全考虑如何防止或减轻存储数据泄露？

c.入侵。协议的安全考虑如何防止或减轻入侵，包括拒绝服务攻击和未经请求的通信？

d.错误归因。协议识别和/或认证个人的机制如何防止错误归因？

7.4、 通用

a.权衡。该协议是否在隐私与可用性、隐私与效率、隐私与可实施性或隐私与其他设计目标之间进行了权衡？描述所选设计的权衡和基本原理。

b.默认值。如果协议可以在多个模式或多个可配置选项下运行，那么默认模式或选项是否会使协议暴露的数据和标识符的数量、可识别性和持久性最小化？默认模式或选项是否最大限度地增加了用户参与的机会？它是否提供了所有模式/选项中最严格的安全功能？如果这些问题中的任何一个答案都是否定的，请解释为什么选择了保护性较低的默认值。

8、 示例

以下部分给出了本文件建议的威胁分析和威胁缓解措施的示例。它涵盖了一个特别困难的应用程序协议presence，试图在易受上述许多威胁影响的体系结构上演示这些原则。本文并非作为IETF规范中可能出现的隐私考虑部分的示例，而是作为在将隐私作为第一原则时应纳入协议设计的思想示例。

在[RFC2778]的摘要中定义的呈现服务允许通信服务的用户监视彼此的可用性和配置，以便做出关于通信的决定。存在信息是高度动态的，并且通常表征用户是在线还是离线、繁忙还是空闲、远离通信设备还是在附近等等。必要的是，这些信息具有一定的隐私影响，从一开始，IETF就致力于为用户提供控制，以确定如何共享他们的存在信息。用于呈现的公共简档（Common Profile for Presence，CPP）[RFC3859]定义了用于呈现信息的传递的一组逻辑操作。该抽象模型适用于多个呈现系统。用于即时消息和存在利用扩展的SIP存在系统（SIP for Instant Messaging and Presence Leveraging Extensions，SIMPLE）[RFC3856]使用CPP作为其基线架构，并且可扩展消息和存在协议（XMPP）中的存在操作也已映射到CPP[RFC3922]。

RFC 2778和RFC 3859中定义的基本体系结构是一个中介体系结构。客户端（RFC 2778术语中的呈现实体）将其呈现信息发布到呈现服务器，呈现服务器又将信息分发给授权的观察者。因此，呈现服务器将呈现信息保留一段时间，直到其更改或过期，以便在请求时向授权的观察者透露。此体系结构反映了现有的预标准部署模型。将显式授权机制集成到存在体系结构中，在共享信息之前让最终用户参与决策过程方面取得了广泛成功。如今部署的几乎所有呈现系统都提供了这样的机制，通常是通过对等授权系统，通过该系统，一对用户在同意成为“好友”时，同意将其呈现信息泄露给彼此。好友列表由服务器管理，但由最终用户控制。用户也可以通过类似的接口显式地相互阻止，在某些部署中，希望提供各种类型的“礼貌阻止”。

然而，从隐私设计的角度来看，经典的存在体系结构几乎代表了最坏的情况。在数据最小化方面，存在实体与存在服务共享其敏感信息，并且虽然服务仅与用户授权的观察者共享该存在信息，但没有任何技术机制限制这些观察者将存在中继到其他第三方。这些实体中的任何一个都可以无限期地记录或保留存在信息。这种敏感性不能通过让用户匿名来减轻，因为系统的目的确实是促进相互认识的用户之间的通信。用户使用的标识符是长期存在的，并且通常包含个人信息，包括个人姓名和服务提供商的域。虽然用户确实参与了好友列表和黑名单的构建，但他们这样做几乎没有问责的希望：用户有效地将他们的存在信息扔到了一个存在服务器上，而该服务器又将信息分发给观察者。用户通常无法验证是否只将存在分发给授权的观察者，尤其是因为是服务器对观察者进行身份验证，而不是最终用户。此外，服务器与呈现数据的所有发布者和消费者之间的连接是窃听者的一个有吸引力的目标，并且需要强大的保密机制，尽管最终用户无法再次验证呈现服务器与观察者之间存在什么机制。

此外，存在信息的灵敏度不限于通信的配置和能力。例如，功能可以揭示用户使用的设备类型，由于多个设备可以发布同一用户的存在，因此存在允许攻击者关联用户设备的重大风险。开发了一个重要的存在扩展，以支持位置共享。GEOPRIV工作组开始努力使共享地理位置的系统协议标准化。在租用工作组的过程中，在最初的要求和隐私威胁分析期间，很明显，该系统将需要一个支持用户同意共享位置信息的基本通信机制。这些需求与存在框架的相似性很快得到了认可，该设计决策记录在[RFC4079]中。因此，位置信息与通过该系统可用于中介机构和授权观察者的其他存在信息混合。

关于存在信息的隐私问题很大程度上是由于存在体系结构的内置中介而产生的。对存在服务器的需求源于存在的两个主要设计要求：首先，当用户不在线时，服务器可以用“离线”指示进行响应；其次，服务器可以在用户的控制下合成由不同设备发布的呈现信息。此外，为了便于将URI用作实体的标识符，一些服务必须使用呈现URI中出现的域名来操作主机，并且在实际情况下，任何商业呈现架构都不会迫使最终用户拥有和操作自己的域名。许多像presence这样的应用程序的最终用户都在NAT或防火墙后面，实际上无法从互联网接收直接连接——这些客户端通过presence服务器打开并维护的持久双向通道对协议的运行至关重要。

人们必须首先问，以调解换取在场是否值得。服务器需要位于所有发布状态信息的中间吗？存在信息的端到端加密似乎可以解决其中的许多问题。存在实体可以用观察者的公钥加密存在信息，然后才通过服务器发送存在信息。IETF为存在信息定义了一种对象格式，称为存在信息数据格式（Presence Information Data Format，PIDF），为了传递位置信息，该格式被扩展到PIDF位置对象（PIDF Location Object，PIDF-LO）——这些XML对象被设计用于容纳加密的包装器。对这些数据进行加密还有一个额外的好处，即可以防止存储的明文呈现信息被试图破坏呈现服务器的攻击者获取。然而，这个提议很快就遇到了可用性问题。发现观察者的公钥是第一个困难，很少有互联网协议能成功解决这个问题。然后，该解决方案将要求在线实体向在线服务发布每个授权观察者的其在线信息的一个加密副本，而不管观察者是否正在积极寻求在线信息——对于具有许多观察者的在线实体来说，这可能会给在线服务器带来不可接受的负担，特别是考虑到在线信息的动态性。最后，它防止服务器在同一用户的控制下合成多个设备报告的呈现信息。总的来说，这些困难使得存在信息的对象加密前景堪忧。

一些支持存在信息的协议，例如SIP，可以以重定向模式而不是发布或代理模式来操作中介。换言之，这些协议可以仅仅将观察者重定向到存在实体，而不是通过服务器发送存在信息，然后存在信息可以直接且安全地从存在实体传递到观察者。值得注意的是，这将向观察者披露存在实体的IP地址，这有其自身的一系列风险。在这种情况下，存在实体可以准确地决定它想与有问题的观察者共享什么信息，它可以用它选择的任何强度的凭证来验证观察者本身，并且通过端到端加密，它可以降低任何窃听的可能性。在重定向架构中，呈现服务器仍然可以提供必要的“离线”指示，而不需要呈现服务器自己观察和转发所有信息。这种机制比加密更有前景，但也存在很大的困难。它也不提供来自多个设备的存在信息的组合；事实上，它迫使观察者自己执行这种组合。然而，这种方法的最大障碍是在存在实体的设备和观察者之间创建端到端连接的困难，因为这些端点中的一些或全部可能位于阻止对等连接的NAT或防火墙之后。虽然有解决这个问题的潜在方案，如NAT的会话遍历实用程序（Session Traversal Utilities for NAT，STUN）和NAT周围使用中继的遍历（Traversal Using Relays around NAT，TURN），但它们增加了整个系统的复杂性。

因此，中介是存在体系结构中一个很难去除的特性。很难最大限度地减少与中介机构共享的数据，特别是由于对组成的要求。因此，对与中介共享的控制必须来自体系结构的某些其他显式组件。因此，IETF中的呈现工作侧重于提高用户对呈现服务器活动的参与度。这项工作始于GEOPRIV工作组，负责控制位置隐私，因为用户的位置被认为具有特别敏感的属性。为了满足[RFC2779]中定义的隐私要求，一组使用指示，例如是否允许重传或保留期何时到期，已经被添加到PIDF-LO，使得它们总是与位置信息本身一起传播。这些隐私偏好不仅适用于存储和转发存在信息的中介机构，也适用于消费该信息的观察者。

这种方法在很大程度上遵循了知识共享[CC]的精神，即使用有限数量的条件（如“共享”[CC-SA]）。然而，与知识共享不同，GEOPRIV工作组没有启动制作法律语言或设计图形图标的工作，因为这不属于IETF的范围。特别地，GEOPRIV规则规定了对位置信息的保留和重传的偏好；虽然GEOPRIV不能强制任何接收PIDF-LO对象的实体遵守这些偏好，但如果用户根本缺乏表达这些偏好的能力，我们可以保证他们的偏好不会得到尊重。GEOPRIV规则可以提供一种建立问责制的手段。

保留和重传元素被认为是共享存在中偏好表达的最重要的例子。PIDF对象是为可扩展性而设计的，为PIDF-LO创建的规则集也可以进行扩展，以提供用户偏好的新表达式。然而，并不是所有的用户偏好信息都应该绑定到一个特定的PIDF对象中；存在体系结构所采用的许多形式的访问控制策略需要通过与用户的某种接口在存在服务器中提供。这一要求最终引发了通用访问控制策略语言的标准化，称为通用策略框架（定义于[RFC4745]）。这种语言允许将控制信息分布的方法表示为以XML格式表示的简单条件、操作和转换规则。Common Policy本身是一种需要实例化的抽象格式：可以找到存在授权规则[RFC5025]和地理位置策略[RFC6772]的两个示例。前者为基于存在的系统提供了额外的表达能力，而后者为基于位置的条件和转换定义了语法和语义。

最终，关于存在的隐私工作代表了隐私原则与架构和市场需求之间的妥协。虽然从体系结构中完全删除中介或阻止他们访问呈现信息是不可行的，但IETF确实为用户提供了一种表达他们的偏好并在呈现服务中提供他们的控制的方式。到目前为止，我们在隐私机制的实现领域还没有取得很大成功，但通过记录和承认这些机制的局限性，设计者能够为实现者和最终用户提供关于IETF存在协议的隐私属性的知情视角。

9、 安全注意事项

本文档描述了协议设计者除了定期安全分析之外还应考虑的隐私方面。

10、 鸣谢

我们要感谢Christine Runnegar提供的大量有益的评论意见。

我们要感谢Scott Brim、Kasey Chappelle、Marc Linsner、Bryan McLaughlin、Nick Mathewson、Eric Rescorla、Scott Bradner、Nat Sakimura、Bjoern Hoehrmann、David Singer、Dean Willis、Lucy Lynch、Trent Adams、Mark Lizar、Martin Thomson、Josh Howlett、Mischa Tuffield、S.Moonesamy、Zhou Sujing、Claudia Diaz、Leif Johansson、Jeff Hodges、Stephen Farrell、Steven Johnston、Cullen Jennings，Ted Hardie、Dave Thaler、Klaas Wierenga、Adrian Farrel、Stephane Bortzmeyer、Dave Crocker和Hector Santos对本文件的有用反馈。

最后，我们要感谢参与者在2010年12月由麻省理工学院、ISOC、W3C和IAB共同组织的互联网隐私研讨会上提供的反馈。

尽管John Morris目前受雇于美国政府，但他以个人身份参与了本文件的制定，文件中表达的观点可能无法反映其雇主的观点。

12、 参考资料

[CC-SA] Creative Commons, "Share Alike", 2012, <http://wiki.creativecommons.org/Share_Alike>.[CC] Creative Commons, "Creative Commons", 2012, <http://creativecommons.org/>.[CoE] Council of Europe, "Recommendation CM/Rec(2010)13 of the Committee of Ministers to member states on the protection of individuals with regard to automatic processing of personal data in the context of profiling", November 2010, <https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913>.[EFF] Electronic Frontier Foundation, "Panopticlick", 2013, <http://panopticlick.eff.org>.[FIPs] Gellman, B., "Fair Information Practices: A Basic History", 2012, <http://bobgellman.com/rg-docs/rg-FIPShistory.pdf>.[OECD] Organisation for Economic Co-operation and Development, "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data", (adopted 1980), September 2010, <http://www.oecd.org/>.[PbD] Office of the Information and Privacy Commissioner, Ontario, Canada, "Privacy by Design", 2013, <http://privacybydesign.ca/>.[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.[RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004.[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.[RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, September 2012.[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.[Solove] Solove, D., "Understanding Privacy", March 2010.[Tor] The Tor Project, Inc., "Tor", 2013, <https://www.torproject.org/>.[Westin] Kumaraguru, P. and L. Cranor, "Privacy Indexes: A Survey of Westin's Studies", Dece