aggs1990的专栏

然而，本文件本身不得以任何方式进行修改，例如删除版权声明或提及互联网协会或其他互联网组织，除非是为了制定互联网标准而需要，在这种情况下，必须遵循互联网标准流程中定义的版权程序，或者根据需要将其翻译成英语以外的语言。本文件及其包含的信息是在“原样”的基础上提供的，互联网协会和互联网工程工作组不承担任何明示或暗示的保证，包括但不限于任何保证，即使用本文件中的信息不会侵犯任何权利或任何对适销性或特定用途适用性的暗示保证。上述授予的有限权限是永久性的，互联网协会或其继承人或受让人不会撤销。

​作者地址按照RFC 2543的编辑、作者和原始作者的字母顺序列出。所有列出的作者都积极为本文档贡献了大量文本。

Jean Mahoney提供了技术写作协助。Brian Rosen提供了汇编的BNF。​这项工作主要基于[41，42]。

responsesUDP only表4：计时器摘要。

30 参考性文献。

29 标准参考。

o添加了Content-Language, Content-Disposition和MIME-Version报头字段。o添加了Alert-Info, Error-Info和Call-Info报头字段，用于向用户显示可选内容。o增加了“眩光处理”机制，以处理双方同时向对方发送重新邀请的情况。oDate报头字段用于REGISTER响应，为用户代理中的日期自动配置提供了一种简单的方法。o添加了In-Reply-To和Reply-To报头字段，用于支持稍后返回未接来电或消息。o允许注册商拒绝期限太短的注册。

28.1 Major Functional Changes28.1 主要功能变化 o When a UAC wishes to terminate a call before it has been answered, it sends CANCEL. If the original INVITE still returns a 2xx, the UAC then sends BYE. BYE can only be sent on an existing call leg (now cal

​本RFC修订了RFC 2543。它主要与RFC 2543向后兼容。这里描述的更改修复了在RFC 2543中发现的许多错误，并提供了关于RFC 2543未详细说明的场景的信息。该协议在这里以一个更干净的分层模型呈现。​我们将差异分为功能行为和功能行为，前者是对RFC 2543的实质性更改，在某些情况下会影响互操作性或正确操作，后者不同于RFC 2543，但不是互操作性问题的潜在来源。也有无数的澄清，这里没有文档。28 ​对RFC 2543的更改​。

本文档还注册了四个新的内容处置报头“处置类型”：警报、图标、会话和呈现。作者要求将这些值记录在IANA的内容处置注册表中。​这些“处置类型”的描述，包括动机和例子，见第20.11节。alert the body是一种自定义铃声，用于提醒用户。​会话主体将通信会话描述为RFC 2327 SDP主体。27.6 新的内容处置参数注册。图标主体显示为用户的图标。呈现应该向用户显示的主体。

编码方案：SIP消息由一个8位报头组成，可选地后跟一个二进制MIME数据对象。因此，SIP消息必须被视为二进制消息。在正常情况下，SIP消息通过具有二进制能力的传输进行传输，不需要特殊编码。本文档注册了“message/sip”MIME媒体类型，以便允许sip消息作为sip中的主体进行隧道传输，主要用于端到端安全目的。version：所附消息的SIP版本号（例如“2.0”）。如果不存在，则版本默认为“2.0”。27.5 “message/sip”MIME类型。媒体子类型名称：sip。安全注意事项：见下文。

​响应代码表最初是从第21节填充的，这些部分标记为“信息”、“成功”、“重定向”、“客户端错误”、“服务器错误”和“全局故障”。​本规范在会话发起协议（SIP）参数下建立方法和响应代码子注册表，并按如下方式启动它们的填充。o响应代码的编号或正在注册的方法的名称；o该响应代码的默认原因短语（如适用）；o注册方法或响应代码的RFC编号；27.4 方法和响应代码。

​一些常用和广泛使用的报头字段可以指定为单字母紧凑形式（第7.3.3节）。紧凑型表单只能在SIP工作组审查后分配，然后发布RFC。​这就废弃了会话发起协议（SIP）参数下关于报头中子注册表的IANA指令。o该报头字段的紧凑形式版本（如果已定义）；o正在注册的报头字段的名称；o注册报头的RFC编号；27.3 报头字段名称。

警告300到329被保留用于指示会话描述中的关键词的问题，330到339是与会话描述中请求的基本网络服务相关的警告，370到379是与在会话描述中所请求的定量QoS参数相关的警告，以及390至399是不属于上述类别之一的杂项警告。​本规范在会话发起协议（SIP）参数下建立警告代码子注册表，并使用第20.43节中列出的警告代码启动其填充。RFC发布注册了其他警告代码。“警告代码”由三位数字组成。第一个数字“3”表示特定于SIP的警告。在未来的规范描述使用3xx以外的警告代码之前，只能注册3xx警告代码。

​选项标签用于报头字段，如Require, Supported, Proxy-Require,和Unsupported，以支持扩展的SIP兼容性机制（第19.2节）。选项标签本身是与特定SIP选项（即扩展）相关联的字符串。它标识SIP端点的选项。选项标记在标准跟踪RFC中发布时由IANA注册。RFC的IANA注意事项部分必须包括以下信息，这些信息与发布的RFC编号一起出现在IANA注册表中。​o选项标签的名称。​本规范在会话发起协议（SIP）参数下建立选项标签子注册表。o描述扩展的描述性文本。

​该规范指示IANA在http://www.iana.org/assignments/sip-parameters:选项标记、警告代码（警告代码）、方法和响应代码，添加到已经存在的报头字段的子注册表中。SIP应用程序中使用的所有方法名称、报头字段名称、状态代码和选项标记都通过RFC中的IANA注意事项部分中的说明向IANA注册。27 IANA的意见。

如果用户或服务选择在根据个人姓名和组织隶属关系（描述了大多数记录地址）可以猜测的地址进行访问，那么通过拥有未列出的“电话号码”来确保隐私的传统方法就会受到损害。因此，一个实现应该能够在每个用户的基础上限制向某些类别的呼叫者提供什么类型的位置和可用性信息。这不仅适用于表示请求发起者的From和相关报头，也适用于To-向最终目的地传递快速拨号昵称或一组目标的未扩展标识符可能不合适，当请求被路由时，这两个昵称中的任何一个都将从请求URI中删除，但如果两者最初相同，则在To报头字段中不改变。

为了解决这些问题，建议Request-URI包含SIP或SIPS URI的请求的接收方检查To报头字段值，看看它是否包含SIPS URI（但请注意，如果该URI具有相同的方案，但与To报头字段中的URI不等效，则不构成安全漏洞）。尽管客户端可以选择以不同的方式填充请求的Request-URI和To报头字段，但当使用SIPS时，这种差异可能被解释为可能的安全违规，因此请求可能被其接收方拒绝。然而，许多有效的体系结构使用TLS来保护请求路径的一部分，但依赖于其他一些机制来实现到UAS的最后一跳。

对于本地出站代理服务器或注册器来说，维护与许多UA的许多同时的长期TLS连接也可能是困难的。这引入了一些有效的可伸缩性问题，尤其是对于密集型密码套件。维护长期TLS连接的冗余，特别是当UA单独负责其建立时，也可能很麻烦。TLS仅允许SIP实体对与其相邻的服务器进行身份验证；TLS和本文档中指定的任何其他机制都不允许客户端对无法形成直接TCP连接的代理服务器进行身份验证。对TLS最常见的担忧是它不能在UDP上运行；TLS需要一个面向连接的底层传输协议，在本文档中，它的意思是TCP。

攻击者需要截获对话中双方之间的第一次密钥交换，从请求和响应中删除现有的CMS分离签名，并插入一个包含攻击者提供的证书（但似乎是正确记录地址的证书）的不同CMS分离签名。S/MIME机制允许UA在其密钥环上拥有记录目的地址的证书的情况下发送不带前导码的加密请求。然而，任何为记录地址注册的特定设备都可能不持有该设备当前用户以前使用的证书，因此，它将无法正确处理加密的请求，这可能导致一些可以避免的错误信号。需要注意的是，攻击者只能在双方首次交换密钥时利用此漏洞，在随后的情况下，密钥的更改对UA来说是显而易见的。

HTTP摘要的另一个限制是领域的范围。当用户想要将自己认证为与他们有预先存在的关联的资源时，例如用户是其客户的服务提供商时，摘要是有价值的（这是一种非常常见的情况，因此摘要提供了非常有用的功能）。相比之下，TLS的范围是域间或多域的，因为证书通常是全局可验证的，因此UA可以在没有预先存在的关联的情况下对服务器进行身份验证。在SIP中使用HTTP摘要的主要限制之一是摘要中的完整性机制对SIP的工作效果不太好。具体来说，它们提供对Request-URI和消息方法的保护，但不提供UA最希望保护的任何报头字段。

尽管这些安全机制在以明智的方式应用时可以挫败许多威胁，但实施者和网络运营商必须理解这些机制的范围存在局限性。

当SIP代理服务器运行的主机可从公共互联网路由时，应将其部署在具有防御操作策略的管理域中（阻止源路由流量，最好过滤ping流量）。这些堡垒主机还可以承受拒绝服务攻击的冲击，确保管理域内的SIP主机不会受到多余消息的干扰。UA和代理服务器应该只使用一个401（未授权）或407（需要代理身份验证）来质疑有问题的请求，放弃正常的响应重传算法，从而对未经身份验证的请求采取无状态的行为。重新发送401（未授权）或407（需要代理验证）状态响应会加剧攻击者使用伪造的报头字段值（如Via）将流量引导到第三方的问题。

Bob在一个不安全的接口上接收到这个INVITE，但他的UA检查并在这种情况下识别请求的From报头字段，然后将本地缓存的证书与INVITE主体签名中提供的证书进行匹配。他以类似的方式回答，向Carol证明了自己的身份，一场安全的对话开始了。biloxi代理有一个针对Bob的策略，所有未经身份验证的请求都应重定向到相应的注册联系人地址bob@biloxi.com'，即. Carol通过与biloxi代理建立的TLS连接接收重定向响应，因此她相信联系人地址的真实性。

有“alice@atlanta.com”一直试图联系，比如，”alex@atlanta.com“，本地代理将代理到Alex在注册时与注册商建立的TLS连接的请求。biloxi.com上的代理服务器应该依次检查atlanta.com上代理服务器的证书，并将证书断言的域与INVITE请求中From报头字段的“域名”部分进行比较。现在假设Alice的UA希望启动与远程管理域中的用户的会话，即“bob@biloxi.com”.我们还将说，本地管理域（atlanta.com）有一个本地出站代理。

注册商应向UA提供证书，证书所标识的站点必须与UA打算注册的域相对应；例如，如果UA打算注册记录的地址'alice@atlanta.com'，站点证书必须标识atlanta.com域（如sip.atlanta..com）中的主机。注册商接受注册后，UA应保持此TLS连接处于打开状态，前提是注册商还充当向其发送此管理域中用户请求的代理服务器。由于UA已经对TLS连接另一端的服务器进行了身份验证，因此已知通过该连接的所有请求都已通过代理服务器——攻击者无法创建看似通过该代理服务器发送的伪造请求。

这些安全机制的协同操作可以在一定程度上遵循现有的网络和电子邮件安全模型。在高层，UA使用摘要式用户名和密码向服务器（代理服务器、重定向服务器和注册器）进行身份验证；服务器使用TLS提供的站点证书向一跳之外的UA或一跳之外（反之亦然）的另一台服务器进行身份验证。​以下是一个示例，其中各种UA和服务器使用这些安全机制来防止第26.1节中描述的各种威胁。在对等级别上，UA通常信任网络来对彼此进行身份验证；然而，当网络不可信或网络本身不可信时，S/MIME也可以用于提供直接身份验证。6.3.2 安全解决方案。

这需要拥有由证书颁发机构颁发的一个或多个根证书（最好是与那些为web浏览器颁发根证书的站点证书类似的站点证书的知名分销商）。如果UA持有证书颁发机构的一个或多个根证书以验证TLS或IPSec的证书，则它应该能够根据需要重用这些证书来验证S/MIME证书。代理服务器、重定向服务器和注册器应至少配置一个摘要领域，并且给定服务器支持的至少一个“领域”字符串应与服务器的主机名或域名相对应。请注意，随着S/MIME实现的出现和对问题空间的更好理解，预计未来的安全扩展可能会升级与S/MIME相关的规范强度。

但是，S/MIME允许SIP UA对SIP中的MIME主体进行加密，从而端到端地保护这些主体而不影响消息头。S/MIME可以为消息体提供端到端的机密性和完整性，以及相互身份验证。还可以使用S/MIME通过SIP消息隧道为SIP报头字段提供一种完整性和机密性形式。如上所述，出于保密目的对整个SIP消息进行端到端加密是不合适的，因为网络中介机构（如代理服务器）需要查看某些报头字段才能正确路由消息，并且如果这些中介机构被排除在安全关联之外，则SIP消息基本上将是不可路由的。

SIP提供了基于HTTP认证的质询能力，该质询能力依赖于401和407响应代码以及用于携带质询和证书的报头字段。在没有重大修改的情况下，在SIP中重用HTTP摘要式身份验证方案可以实现重放保护和单向身份验证。​第22节详细介绍了摘要式身份验证在SIP中的使用。26.2.3 HTTP认证。

SIPS URI可以用作特定用户的记录地址，即用户在规范上已知的URI（在其名片上，在其请求的From报头字段中，在REGISTER请求的To报头字段中）。当用作请求的Request-URI时，SIPS方案表示，在请求到达负责请求URI的域部分的SIP实体之前，转发请求的每个跳都必须使用TLS进行保护；当被请求的发起者使用时（如果他们使用SIPS URI作为目标的记录地址，就会出现这种情况），SIPS规定到目标域的整个请求路径都是安全的。然而，SIPS的语义与SIP URI非常不同。

例如，Alice信任她的本地代理服务器，在证书交换后，该服务器决定信任Bob信任的本地代理服务器。IPSec通常在主机的操作系统级别实现，或者在安全网关上实现，该安全网关为其从特定接口接收的所有流量提供机密性和完整性（如在VPN体系结构中）。IPSec也可以在逐跳的基础上使用。​在SIP应用程序中使用TLS时，实现者必须至少支持TLS_RSA_WITH_AES_128_CBC_SHA密码套件[6]。请注意，传输机制是在SIP中逐跳指定的，因此通过TLS向代理服务器发送请求的UA无法保证端到端使用TLS。

为此，建议使用SIP的低层安全机制，该机制逐跳加密线路上的整个SIP请求或响应，并允许端点验证向其发送请求的代理服务器的身份。从上述威胁中，我们得出SIP协议所需的基本安全服务是：保持消息传递的机密性和完整性，防止重放攻击或消息欺骗，为会话中的参与者提供身份验证和隐私，以及防止拒绝服务攻击。SIP消息体的独立安全机制提供了一种端到端相互身份验证的替代方法，并对用户代理必须信任中介的程度进行了限制。SIP没有定义特定于SIP的新安全机制，而是尽可能重用从HTTP和SMTP空间派生的现有安全模型。

攻击者可以创建伪造的请求，其中包含伪造的源IP地址和相应的Via报头字段，该字段将目标主机标识为请求的发起者，然后将该请求发送到大量SIP网络元素，从而使用倒霉的SIP UA或代理生成针对目标的拒绝服务流量。SIP为分布式拒绝服务攻击创造了许多潜在的机会，这些攻击必须由SIP系统的实现者和运营商识别和解决。类似地，攻击者可能会在识别目标主机的请求中使用伪造的路由头字段值，然后将此类消息发送到分叉代理，分叉代理将增加发送到目标的消息。使用多播传输SIP请求会大大增加拒绝服务攻击的可能性。

在这种情况下，接收方只需要知道BYE来自与之建立相应对话的同一方（而不是确定发送方的绝对身份）。考虑这样一种情况：第三方攻击者在双方共享的对话中捕获一些初始消息，以了解会话的参数（To标记、From标记等），然后在会话中插入BYE请求。一旦通过初始消息传递建立了对话，就可以发送修改对话或会话状态的后续请求。至关重要的是，会话中的主体可以确定此类请求不是由攻击者伪造的。类似的会话中期威胁包括传输伪造的重新邀请，以改变会话（可能是为了降低会话安全性或作为窃听攻击的一部分重定向媒体流）。26.1.4 撕扯会话。

然而，由于在路由请求时，代理服务器会合法地检查或更改许多报头字段，因此并非所有报头字段都应该端到端保护。尽管它信任它所联系的域的代理服务器来正确地传递信号，但它可能不希望该域的管理员能够解密任何后续的媒体会话。更糟糕的是，如果代理服务器是主动恶意的，它可能会修改会话密钥，或者充当中间人，或者可能更改发起UA请求的安全特性。当然，SIP UA通过可信代理服务器路由请求。无论该信任是如何建立的（本节其他部分讨论了代理的身份验证），UA都可以信任代理服务器来路由请求，但不能检查或可能修改该请求中包含的主体。

例如，考虑一个域chicago.com的重定向服务端模拟另一个域biloxi.com的重定向服务器的情况。用户代理向biloxi.com.发送请求，但是chicago.com上的重定向服务端使用伪造的响应进行响应，该响应具有用于biloxi.com响应的适当SIP报头字段。与注册劫持威胁相反，考虑一下发送到biloxi.com的注册被chicago.com拦截的情况，chicago..com用伪造的301（永久移动）响应回复拦截的注册。然而，攻击者总是有可能冒充远程服务端，并且UA的请求可能被其他方拦截。

注册器评估REGISTER消息的From报头字段中断言的身份，以确定该请求是否可以修改与To报头字段中的记录地址相关联的联系人地址。例如，成功模拟有权更改与记录地址相关联的联系人的一方的攻击者可以取消注册URI的所有现有联系人，然后将其自己的设备注册为适当的联系人地址，从而将受影响用户的所有请求定向到攻击者的设备。这种威胁属于依赖于请求发起人缺乏加密保证的威胁家族。任何代表有价值服务的SIP UAS（例如，将SIP请求与传统电话呼叫交互的网关）都可能希望通过验证其接收到的请求来控制对其资源的访问。

这些攻击假设攻击者可以在一个环境中读取网络上的任何数据包——预计SIP将在公共互联网上频繁使用。网络上的攻击者可能能够修改数据包（可能在某个受损的中间层）。攻击者可能希望窃取服务、窃听通信或中断会话。以下示例决不能提供针对SIP的威胁的详尽列表；相反，这些是“经典”威胁，表明需要特定的安全服务，可以潜在地防止所有类别的威胁。本节详细介绍了大多数SIP部署中常见的一些威胁。选择这些威胁是为了说明SIP所需的每种安全服务。26.1 攻击和威胁模型。

接下来的注意事项首先考察了一组经典的威胁模型，这些模型广泛地确定了SIP的安全需求。SIP不是一个容易保护的协议。它对中介的使用、多方面的信任关系、完全不信任的元素之间的预期使用以及用户对用户的操作使安全性绝非微不足道。为了满足这些不同的需求，将需要适用于SIP的不同方面和用途的几种不同机制。请注意，SIP信令本身的安全性与SIP协同使用的协议（如RTP）的安全性无关，也与SIP可能携带的任何特定主体的安全含义无关（尽管MIME安全性在保护SIP方面发挥着重要作用）。媒体加密不在此文档的范围内。