SIP安全机制协议-科能调度指挥系统

10.8.1为何需要SIP安全机制协议

3GPP版本5和版本6的IMS采用IPsec作为P-CSCF和UE之间的安全机制，IPsec仅是几种可能的安全机制之一。IMS的设计还允许Gm接口使用其他的安全机制。提供这种开放性往往会导致后向兼容性问题，例如，兼容版本6的UE可能无法理解任何其他的安全机制，但是它应该可以附着到一个更高版本的、已经支持IPsec以外的其他安全机制的P-CSCF上。

因此，设计了SIP安全机制协议(Sip-Sec-Agree）以使UE和P-CSCF间可以协商和采用共同的安全机制。对于目前的版本，惟一的安全机制是IPseco。然而，一些实体可能已经支持其他机制作为其私有特性。

10.8.2 概述

为了使例子不过于简单和单调，我们假设UE支持IPsec和HTTP摘要，而P-CSCF支持IPsec和传输层安全(TLS）,并优先选择TLS。本章的读者不需要对这些机制本身有任何的了解。

我们已经知道，UE发往P-CSCF的初始REGISTER请求是没有安全保护的。为了建立一个共同的安全机制,Tobias的UE通过初始REGISTER的Security-Client消息头公布那些它已经支持的机制，该消息头中包含对所支持的机制的列表。

P-CSCF在401(未授权）响应中返回Security-Server消息头，包含P-CSCF侧所支持的机制的列表。而且，P-CSCF对每个机制添加一个优先级(q值）。

基于这些信息，UE和P-CSCF现在都可以得知双方所共同支持的安全机制。如果有超过一个的安全机制，将选择和采用被P-CSCF赋予最高优先级的机制。为了保证这个机制可以立刻建立起来，P-CSCF还会在401(未授权）响应中发送进一步的信息，使UE可以建立起该机制。例如，在一个非IMS环境下，如果所选择的机制是HTTP摘要，可以发送一个Proxy-Authenticate消息头。

如我们在10.7节中见到的，UE和P-CSCF随后就会建立起安全机制，在本例中是基于IPsecSAo之后两个实体间的所有消息都通过这些SA受保护地进行传递。

然而，初始的REGISTER请求及其响应仍然是得不到保护的，因此该消息就有可能被恶意用户篡改或者在易误码的空中接口上发生错误。

像前面章节中介绍的那样，UE发出的第二个REGISTER请求会重复所有为认证和注册过程所必需的信息，认证和注册都是在UE与S-CSCF之间进行的。为了确保与SIP安全机制协议有关的信息也没有被改变，UE会：

• 在第二个REGISTER中重复初始REGISTER中的Security-Client消息头；

• 将来自P-CSCF的401(未授权）响应中Security-Server消息头中的内容复制到Security-Verify消息头中，并在第二个REGISTER中发送出去。

只要建立的安全联盟在使用中，UE就会在每个发往P-CSCF的请求中重复Security-Verify消息头。

通过交换Security-Client(来自UE）和Security-Server(来自P-CSCF）消息头，双方还可以对IPsecSA的一些参数达成一致，也就是说，它们会相互告知受保护的客户端和服务器端口(port-c和port-s）以及安全参数索引(SPI：spi-c和spi-s）。

10.8.3 初始REGISTER请求中与SIP安全机制协议有关的消息头

为了激活安全机制协定，UE在初始REGISTER请求中包含如下信息：

REGISTERsip:homel.frSIP/2.0

Require:sec-agree

Proxy-Require:sec-agree

Security-Client:digest,IPsec-3gpp;alg=hmac-sha-1-96

;spi-c=23456789;spi-s=12345678

;port-c=2468;port-s=1357

Proxy-Require消息头中包含了选项标签"sec-agree”,它指示下一跳代理(这里就是P-CSCF）必须支持SIP安全机制协议的过程，以便进一步处理本请求。如果下一跳代理不支持SIP安全机制协议的过程，它会根据［RFC3261］定义的对Proxy-Require消息头的处理规定，发回一个420(无效扩展）响应，其中包含一个Unsupported消息头，其内容是选项标签"sec-agree”。由于本例中的P-CSCF完全兼容IMS版本5和版本6,它当然会支持SIP SA过程而不会向UE发送这样的响应。

此外，还包括一个Require消息头，指示了“sec-agree”选项标签。［RFC3329］定义了SIP安全机制协议，强制要求包括该字段。Require消息头与Proxy-Require的用法相同，但它是被远端UE所用(而非代理）。它的存在仅仅是为了防止如下情况：如果请求(本例中是REGISTER请求）直接从源UE发往最终目的地(S-CSCF）,而后者根本不看Proxy-Require消息头，这就意味着不会发生安全机制的协商。Require消息头则可以强制接收方执行sec-agree过程。

由于P-CSCF可以执行SIP安全机制协议过程，它将Require和Proxy-Require中的sec-agree选项标签删除，然后将请求送往Tobias的归属运营商网络。

Tobias UE在Security-Client消息头中将所支持的安全机制列表发送给P-CSCFo根据该消息头中的信息，P-CSCF了解到TobiasUE支持两种安全机制：一个是HTTP摘要(“degist”），另一个是3GPP所使用的IPsec("IPsec-3gpp”）。这两种机制在消息头中使用逗号隔开。后者的参数列表(用“：”隔开）包括：

• 算法(alg参数）——用于IPsec加密和保护，在本例中是HMACSHA1-96算法，在［RFC2404］中定义；

• 受保护的客户端端口(port-c）和受保护的服务器端口(port-s）——用于UE侧的IPsec SA；

• SPI——IPsecSA中与受保护的客户端端口相关的spi-c,以及IPsecSA中与受保护的服务器端口相关的spi-s。

P-CSCF也会删除Security-Client消息头，然后再进一步转发REGISTER请求。请注意在IMS中，只有IPsec-3gpp安全机制是可用的。此处的例子使用了摘要和TLS,作为SIP-Sec-Agree有关的消息头中可能使用的额外的安全机制。这仅仅是为了解释协商过程隐含的原理。

10.8.4 401(未授权）响应中的Security-Server消息头

当接到来自S-CSCF的对于REGISTER请求的401(未授权）响应时，P-CSCF在响应的Secutity-Server消息头中包含了一个所支持的安全机制的列表。

SIP/2.0401Unauthorized

Security-Server:tls;q=0.2,IPsec-3gpp;q=0.1;alg=hmac-sha-1-96

;spi-c=98765432;spi-s=87654321

;port-c=8642;port-s=7531

在这个例子中，P-CSCF支持两个安全机制：3GPP特定的IPsec和TLS。它还给予TLS较高的优先级:只要UE也支持TLS,就应该选择它作为UE和P-CSCF之间消息的安全保护。

此外，P-CSCF使用与UE相同的方式，发送关于SPI、受保护的客户端和服务器端口等与IPsec有关的信息。

当向UE发送401(未授权）响应时，P-CSCF已经知道将使用IPsec作为安全机制，因为它了解到这是UE和它自己都能支持的惟一的机制。

10.8.5 第二个REGISTER消息中的SIP安全机制协议消息头

在接到401(未授权）响应后，UE就可以建立IPsecSA了。当这完成之后，它可以使用已经建立起来的SA来发送第二个REGISTER请求。在这个REGISTER请求中包含以下有关信息：

REGISTERsip:homel.frSIP/2.0

Require:sec-agree

Proxy-Require:sec-agree

Security-Verify:tls;q=0.2,IPsec-3gpp;q=0.l

;alg=hmac-sha-1-96

;spi-c=98765432;spi-s=87654321

;port-c=8642;port-s=7531

Security-Client:digest,IPsec-3gpp;alg=hmac-sha-1-96

;spi-c=23456789;spi-s=12345678

;port-c=2468;port-s=1357

这里Require和Proxy-Require消息头又一次包含了选项标签"sec-agree”。它们的作用与初始REGISTER请求一样(见10.8.3节），并且会重复出现在UE发出的每一个REGISTER请求中。P-CSCF总会先将它们删掉再继续转发该请求，与初始REGISTER请求的处理方式一样。如果在删除sec-agree之后发现Proxy-Require或Require消息头之一(或全部）变成空，则P-CSCF也会将其删除。

Security-Verity消息头复制了所收到的Security-Server消息头。Security-Client的内容就是对初始REGISTER请求的简单重复。

P-CSCF将会比较初始和第二个REGISTER请求中的两个Security-Client消息头，看它们是否匹配。它还会比较两个消息头的内容：一是它所发送的401(未授权）响应中的Security-Server消息头，一是它所收到的第二个REGISTER请求中的Security-Verify消息头。

在进一步发送这个REGISTER请求之前，P-CSCF将从中删除Security-Client和Security-Server消息头。

10.8.6SIP安全机制协议与重注册

在每次重注册过程中，S-CSCF都可以决定对UE进行重新认证；通过重新认证，它强制UE和P-CSCF之间建立一组新的IPsecSA,因为IPsecSA所依赖的IK在每次重认证过程中都要改变(见10.13.2节）。建立一组新的SA也就意味着：要协商一组新的SPI新的受保护的客户端和服务器端口。

当UE发送新的REGISTER请求来重注册时，它还不能确定S-CSCF是否会要求重认证。因而它需要在每个新的REGISTER请求中加入新的Security-Client消息头，其中包含新的SPI值、受保护的客户端和服务器端口。

REGISTERsip:homel.frSIP/2.0

Require:sec-agree

Proxy-Require:sec-agree

Security-Verify:tls;q=0.2,IPsec-3gpp;q=0.1;alg=hmac-sha-l-96

;spi-c=98765432;spi-s=87654321

;port-c=8642;port-s=7531

Security-Client:digest,IPsec-3gpp;alg=hmac-sha-1-96

;spi-c=23456790;spi-s=l2345679

;port-c=2470;port-s=1357

请注意Security-Client消息头中SPI的值和受保护的客户端端口号巳经发生了改变，在S-CSCF要求重认证UE时，这样才能建立一组新的SAoUE的受保护的服务器端口没有变化，在用户的注册状态下始终保持不变(见10.7.3节）。

Security-Verify消息头的内容没有改变，因为它是最后一次收到的Security-Server消息头的复制品。

在收到S-CSCF发来的对该REGISTER请求的响应时，P-CSCF和UE就能知道是否需要建立新的IPsecSA：也就是说，是接到了一个401(未授权）响应还是接到了一个2oo(OK）响应。

当从S-CSCF收到一个401(未授权）响应时，P-CSCF将会在这个响应中添加一个新的Security-Server消息头，提供新的受保护端口值和新的SPI。

SIP/2.0401Unauthorized

Security-Server:tls;q=0.2,IPsec-3gpp;q=0.1;alg=hmac-sha-1-96

;spi・c=98765434;spi-s=87654322

;port-c=8644;port-s=7531

此外，P-CSCF不会改变受保护的服务器端口(7531）。于是，UE和P-CSCF之间就建立了一组新的临时SA(见10.7.3节）。作为对重认证挑战的响应(见10.6节），REGISTER请求将通过这组新的临时SA发送出去，并包含以下消息头：

REGISTERsip:homel.frSIP/2.0

Require:sec-agree

Proxy-Require:sec-agree

Security-Verify:tls;q=0.2,IPsec-3gpp;q=0.1;alg=hmac-sha-1-96

;spi・c=98765434;spi・s=87654322

;port-c=8644;port-s=7531

Security-Client:digest,IPsec-3gpp;alg=hmac-sha-1-96

;spi・c=23456790;spi-s=l2345679

;port-c=2470;port-s=1357

与初始注册过程一样(见图10-10）,第二个REGISTER请求仍然重复了上一个REGISTER请求的Security-Client消息头(但采用新值），并将刚才收到的401(未授权）响应的Security-Server消息头的值复制到Security-Verify消息头中。重注册过程的第二个REGISTER请求将不再承载与以前建立的SA组有关的任何信息。