认证

10.6.1概述

3.8节中已经介绍，IMS中有几组安全关系。其中两个会影响SIP信令(见图10-4）：用户与网络间的认证，UE与P-CSCF间的SA安全联盟。IMS中的认证和SA建立过程都与SIP注册过程直接结合在一起。

图10-4   IMS注册过程中的认证信息流

IMS认证基于一个共享密钥和一个序列号(SQN）,它们仅在HSS和Tobias手机UICC(统一集成芯片）的ISIM应用处可见。由于HSS从不直接和UE通信,因此由S-CSCF执行认证过程以及认证S-CSCF需要的所有与安全性相关的参数。在注册过程中，S-CSCF从HSS处下载所谓的认证向量(AV）。

为了进行认证,Tobias在初始的REGISTER请求中发送他的私有用户标识(在我们的例子中是tobias_private@homel.fr）。该私有用户标识保存在ISIM应用中，只用于认证和注册过程。

当收到REGISTER请求时，S-CSCF从HSS中下载AV。该AV本身并不包含共享密钥和SQN,而是包括(此外还有其他参数）：

• 一个随机挑战(RAND）；

• 所期望的结果(XRES）；

• 网络认证令牌(AUTN）；

• 完整性密钥(IK）；

• 加密密钥(CK）。

这些参数使得S-CSCF不需要知道共享密钥和SQN就可以执行认证过程。

为了进行认证，S-CSCF用一个401(未授权）响应来拒绝用户发出的初始REGISTER请求，响应中包括RAND、AUTN、IK和CK(此外还有其他参数）。

当接收到401(未授权）响应后，P-CSCF去掉其中的IK和CK,然后才发往UE。IK是随后在P-CSCF和UE之间建立的SA的基础(见10.7节）。

在接收到响应后，UE将收到的参数传给ISIM应用，后者：

• 基于共享密钥和SQN来校验AUTN„若AUTN校验成功，网络就通过认证了(即UE可以确认认证数据是从归属运营商网络中发来的）。

• 基于共享密钥和收到的RAND来计算结果(RES）。

• 计算IK,P-CSCF和UE将共享该IK,作为SA的基础。

然后,UE在第二个REGISTER请求中把认证挑战响应(RES）反馈给S-CSCF,S-CSCF将其与来自HSS的AV中的XRES相比较。如果校验成功，S-CSCF就认为用户通过了认证，并继续执行SIP注册过程(见10.5.6节）。

任何时候当UE再发出另一个REGISTER请求时(即由于重注册或注册解除）,它总是包含与第二个REGISTER请求相同的认证参数,直到S-CSCF重新认证UE。

10.6.2  HTTP摘要和3GPP AKA

［RFC2617］定义了超文本传输协议(HTTP）摘要，［RFC3261］中介绍了如何在SIP中使用它。另一方面,IMS是第三代伙伴计划/通用移动通信系统(3GPP/UMTS）体系的一部分，它使用3GPP认证和密钥协商(AKA）机制来进行认证。

为了在IMS中实现基于3GPP AKA的认证，［RFC3310］定义了3GPP AKA参数(如上文所述）如何映射到HTTP摘要认证中。因此，用于承载3GPP AKA信息的信令元素(SIP消息头和参数）与用于承载HTTP摘要所使用的信令元素是完全一样的。但是，它们的含义(即它们在UE、P-CSCF和S-CSCF处的解释）却不同。

为了将3GPPAKA认证机制与其他的HTTP摘要机制(例如MD5）区别出来，它被授予了一个新的算法值：“AKAvl-MD5”。

10.6.3 初始REGISTER请求中的认证信息

在初始REGISTER请求中，Tobias的UE使用HTTP摘要的Authorization消息头来传输Tobias的私有用户标识。为了满足HTTP摘要的要求，UE在Authorization消息头中包含以下字段：

• 认证模式一一由于3GPP AKA被映射到HTTP摘要机制，因此该值设置为“Digest”。

• 用户名字段——其值设置为Tobias的私有用户标识，它将被S-CSCF和HSS用于识别用户并找到相应的AV。

• 域和URI字段——其值设置为Tobias的归属域。

• 响应和nonce域——其值设为空。该字段在HTTP摘要中是必需的，但不用于初始REGISTER请求中。

REGISTER如下所示：

REGISTERsip:homel.fr SIP/2.0

Authorization:Digestusemame="tobias_private@home1.fr",

realm="homel.fr",

nonce="",

uri="sip:homel.fr",

response=""

由于在UE和P-CSCF之间没有建立任何类型的SIP信令级相互安全机制，P-CSCF不能保证REGISTER请求真的是Tobias发出的。例如，一个恶意用户可能伪造这个请求并把它发给P-CSCF,而P-CSCF并不了解真相。因此，P-CSCF在Authorization消息头中增加integrity-protected字段并将值设为"no",然后再将请求发往Tobias的归属网络：

REGISTER sip:homel.fr SIP/2.0

Authorization:Digestusemame="tobias_private@homel.fr", 

realm="homel.fr",

nonce="",

uri="sip:homel.fr", 

response=”",

integrity-protected=*'no"

10.6.4   S-CSCF挑战UE

收到REGISTER请求后，S-CSCF通过用户名字段中的私有用户标识识别出用户，并从HSS中下载AV。基于AV中的数据，它通过401(未授权）响应返回WWW-Authenticate消息头并将其字段填写如下：

•  在nonce字段填入RAND和AUTN参数，都是32B长度并采用Base64编码(nonce字段还可能包含其他的服务器专用数据）。

•  在算法字段填入“AKAvl-MD5”，表示3GPPAKA机制。

•  在IK和CK扩展字段中填入完整性和加密密钥。注意［RFC3261］对WWW-Authenticate消息头的原始定义中并不包含这两个字段。这两个字段在［3GPP TS 24.229］中定义。

WWW-Authenticate消息头如下所示：

SIP/2.0401Unauthorized

WWW-Authenticate:  Digestrealm="homel.fr",

                                   nonce=A34Cm+Fva37UYWpGNB34JP,

                                   algorithm=AKAvl-MD5,

                                   ik="0123456789abcdeedcba9876543210",

                                   ck="987654321OabcdeedcbaO123456789"

在接收到401(未授权）响应后，P-CSCF必须从WWW-Authenticate消息头中去除IK和CK并将其存储起来，然后再将响应发往UE：

SIP/2.0  401  Unauthorized

WWW-Authenticate:  Digestrealm="homel.fr",

                                   nonce=A34Cm+Fva37UYWpGNB34JP,algorithm=

                                   AKAvl-MD5

10.6.5UE对挑战的响应

根据收到的AUTN参数，TobiasUE的ISIM应用确定该401(未授权）响应确实是Tobias的归属运营商网络所发送的。它还可以从AUTN参数中推导出:HSS和ISIM之间的SQN(序列号）仍处于同步状态。

根据所收到的参数和共享密钥，ISIM能够生成响应消息所需要的数值，并将其交给UE。UE在第二个REGISTER请求中加上Authorization消息头，包含以下字段(之外还有其他参数）：

•  用户名字段一一该字段中包含Tobias的私有用户标识。

•  nonce字段一一该字段原样返回401(未授权）响应中WWW-Authentication

消息头中的同名字段的值。

•  响应字段——该字段包含认证挑战结果RES,它是ISIM根据接收到的RAND和共享密钥计算生成的。

ISIM还会计算IK,P-CSCF也知道该值。根据这个密钥(以及其他信息，见10.7节），UE和P-CSCF建立IPsecSA安全联盟，在此基础上UE发送第二个REGISTER请求：

REGISTER sip:homel.fr SIP.2.0

Authorization:Digestusemame="userl_private@homel.fr",

                       Realm="homel.fr"

                       nonce=A34Cm+Fva37UYWpGNB34JP,algorithm=AKAv1-MD5,

                       uri='sip:homel.fr",

                       response=“6629fae49393a05397450978507c4efl”

10.6.6  完整性保护和成功认证

现在P-CSCF能够检验出所收到的REGISTER请求在从UE到P-CSCF的路上是否被篡改过，因为它现在能够检查其完整性。如果检验成功，P-CSCF在Authentication消息头的“integrity-protected”字段内写入“yes”,并将REGISTER请求发往Tobias的归属网络：

REGISTERsip:hotnel.frSIP/2.0

Authorization:Digestusemame="userl_private@homel.fr",

                       Realm="homel.fr"

                       nonce=A34Cm+Fva37UYWpGNB34JP,algorithm=AKAvl-MD5,

                       uri="sip:homel.fr",

                       response="6629fae49393a05397450978507c4efl"

                       integrity-protected=“yes“

S-CSCF将比较所接收到的RES和AV中的XRES。如果两个参数是完全相同的，则S-CSCF就成功地认证了用户。只有完成这一步之后，它才会继续进行正常的SIP注册过程。

10.6.7相关标准

与10.6节有关的规范包括：

• 3GPPTS33.102    Securityarchitecture.

• 3GPPTS33.203    AccesssecurityfbrIP-basedservices.

• RFC2401       SecurityArchitecturefbrtheInternetProtocol.

• RFC2403            TheUseofHMAC-MD10-96withinESPandAH.

• RFC2404       TheUseofHMAC-SHA-1-96withinESPandAH.

• RFC2617       HTTPAuthentication:BasicandDigestAccessAuthentication.

• RFC3310       HypertextTransferProtocol(HTTP)DigestAuthetication

              UsingAuthenticationandKeyAgreement(AKA).

10.7  接入安全性一IPsecSA

10.7.1概述

3.8.4节介绍了接入安全的原理。Gm接口的安全性是基于IPsec  SA实现的，它要求在SIP信令级完成特定的处理。本节描述UE和P-CSCF如何协商安全性机制，如何交换IPsec有关的参数，以及SA如何建立和处理。

由于IPsec SA的建立是基于用户认证的基础上，因此每次重认证过程中都要建立新的SA。所以在UE和P-CSCF之间就必须建立新的IPsec SA对。

10.7.2  初始注册过程中建立SA

初始REGISTER请求以及401(未授权）响应在UE和P-CSCF之间传递时，没有受到任何保护措施。这两个消息传递了必要的信息，使得UE和P-CSCF之间可以协商安全机制，并对SA要使用的参数和端口达成一致。

在注册过程中，UE和P-CSCF之间建立了两对IPsec SA。如不特别说明，将这两对SA安全联盟称为“一组SA”，而将这四个中的单个的或特定的IPsecSA安全联盟称为一个“SA”。

这四个IPsecSA并不是静态的连接(例如TCP连接），它们可以看作UE和P-CSCF之间的逻辑联合，使SIP消息得以安全地交换。

一组SA使用四个端口：

• 受保护的UE客户端端口(ucl）；

• 受保护的UE服务器端口(usl）；

• 受保护的P-CSCF客户端端口(pcl）；

• 受保护的P-CSCF服务器端口(psl）。

在首次注册(见图10-5）中，UE和P-CSCF使用SIP安全机制协议(见10.8节）的Security-Client>Security-Server和Security-Verify等消息头，来协商这些端口。

图10-5  首次注册过程中建立SA

这组SA的建立需要使用共享的密钥。然而，P-CSCF对Tobias  ISIM应用与归属网络HSS之间共享的安全参数一无所知。因此，S-CSCF在401(未授权）响应中使用WWW-Authenticate消息头将IK和CK发给P-CSCF。P-CSCF必须将这两个密钥从消息头中去掉并保存在本地，然后才能将401(未授权）响应发给UE；之后P-CSCF就使用IK作为这组SA的共享密钥。Gm接口另一侧的UE就从收到的401(未授权）响应中的挑战来计算IK,并将其作为共享密钥(见10.6.6节）。

通过IK,P-CSCF和UE可以在四个端口之间建立起一组SA,关于这四个端口的信息巳经事先在初始REGISTER请求及其响应中进行了交换：

•  在ucl和psi之间用于UE向P-CSCF发送SIP请求；

•  在usl和pci之间用于P-CSCF向UE发送SIP响应；

•  在usl和pci之间用于P-CSCF向UE发送SIP请求；

•  在ucl和psi之间用于UE向P-CSCF发送SIP响应。

一组SA在建立之后被分配一个临时的生命周期。虽然UE将要通过这组临时SA来发送所有后续的请求和响应，但是必须等到UE和S-CSCF之间的认证过程完成之后，这组SA才能投入使用。这样做是为了确保UE和P-CSCF之间的安全机制是建立在对用户成功认证的基础上。

在向UE发送200(OK）响应时，P-CSCF将更新这组SA的生命周期，变为注册时的生命周期(即Contact消息头中的超时时间）再加上30soUE在接收到200(OK）响应后也进行同样的操作。

如果是首次注册(即现在所描述的情况），P-CSCF和UE双方随后都将立刻开始使用这组SA。这意味着P-CSCF将通过所建立的这组SA来发送所有去往UE的SIP消息。UE也将同样通过所建立的这组SA发出所有SIP消息。

10.7.3 重认证情况下对多组SA的处理

我们已经见到第一组SA是如何在首次注册过程中建立的。由于一组SA的建立是基于S-CSCF发出的401(未授权）响应中的认证数据，因此每次重认证都会在UE和P-CSCF之间建立一组新的SA。重认证过程在10.13节中介绍。在重认证成功后，UE和P-CSCF之间会维护两组SA(见图10-6）：

•  在重注册发生之前已经建立并投入使用的那组SA,现在称为“旧SA组”;

•  基于重认证而建立一组新的SA,现在称为“新SA组”。

这种情况的复杂之处在于，P-CSCF无法确认Tobias的UE是否已经收到对第二个REGISTER请求的200(OK）响应，因为SIP没有定义对收到响应的确认机制，只有对INVITE请求的响应除外。如果UE没有接收到对第二个REGISTER的200(0K）响应，它就无法使用新SA组。所以，P-CSCF必须等待UE使用新SA组发来新请求，它自己才能开始使用新SA组。这意味着，只要P-CSCF还没有在新SA组上收到UE发来的请求，它就:

图10-6  重认证过程中的两组SA

•  在向UE发送请求时使用旧SA组，即从它的受保护的客户端端口pcl到UE的受保护的服务器端口usl；

•  保持两组SA,直到其中之一或两者全部超时，或者接收到一个来自UE的新请求。

在我们的例子中，我们假设UE已经接到对第二个REGISTER的200(OK）响应，因而得知认证过程已经成功并且可以启用新的SA组。但是，P-CSCF对此并不知情，它仍然得使用旧SA组向UE发送呼入请求。因此，UE也需要维护两组SA。

当UE需要发送新请求时，它会使用新SA组，P-CSCF就能确认新SA组已经完全可以投入使用(见图10-7）o此外，此时还不能立刻放弃旧SA组，因为有可能UE已经通过它收到或发出了一个请求，而对端还没有响应。因此，旧SA组还需要再保存64*T1秒(IMS环境下一般是128s）后才可以丢弃。

图10-7   启用一组新SA并放弃旧SA组

还要注意UE不能用新SA组对来自旧SA组的请求(例如一个MESSAGE请求）发送响应(例如200(OK）响应）。由于P-CSCF的Via消息头或者TCP连接的约束，UE必须使用与请求相同的端口和相同的SA组发送该请求的响应。

任何时候一旦一个临时的SA建立起来，UE就要丢弃所有其他的SA,惟独发送最后一个REGISTER请求所使用的那个SA除外。因此，UE永远不需要同时处理多于两组的SA。

10.7.4SA的生命周期

在一个正在进行的认证过程中，临时SA组的生命周期被限制为4min,这保证可以完成认证过程。在认证成功后，新SA组的生命周期被设置为以下两者之—：

•  刚结束的注册过程的超时时间加上30s,该注册过程超时时间如对REGISTER的200(OK）响应中Contact消息头expire参数所示，或者

•  如果己经存在另一组SA,只要这组SA的生命周期超过刚结束的注册过程的超时时间加30s,则设为该组SA的生命周期。

任何时候一旦重注册成功完成，P-CSCF和UE就要把所有现存SA的生命周期更新为刚结束的注册过程的超时时间再加30s,只要这个值超过现存SA组已分配的生命周期。因此，UE和P-CSCF间的SA的生命周期总是比Tobias向IMS网络注册的生命周期长30s。

当P-CSCF得知Tobias不再是注册状态时(例如，收到了包含Tobias注册状态信息的NOTIFY消息，指示网络发起了注册解除，见10.14.3节），P-CSCF将在64*T1秒之后丢弃所有到达该UE的SA。

10.7.5 端口设置和路由

使用SA端口需要特别注意，因为这会严重影响P-CSCF和UE间的路由。如图10-6所示，Tobias的UE：

• 将从受保护的客户端端口(2468）发出所有请求；

• 期望从受保护的服务器端口(1357）收到所有的响应；

• 期望从受保护的服务器端口(1357）收到所有的请求；

• 将从受保护的客户端端口(2468）发出对所收到请求的所有响应。

另一方面，P-CSCF：

• 将从受保护的客户端端口(8642）发送所有发往UE的请求；

• 期望从受保护的服务器端口(7531）收到所有来自UE的响应；

• 期望从受保护的服务器端口(7531）收到所有来自UE的请求；

• 将从受保护的客户端端口(8642）发送所有发往UE的响应。

为了确保所有请求都是通过IPsecSA发出的：

• UE将其受保护的服务器端口设置为其地址的一部分：

■在每个请求的Contact消息头中(包括所有的REGISTER请求）；

■在每个请求的Via消息头中，不止是首个REGISTER请求。

• UE在它发出的每个初始请求的Route消息头中，将P-CSCF的受保护的服务器端口设为出站代理(即P-CSCF）地址的一部分。

• P-CSCF将其受保护的服务器端口设为其地址的一部分：

■ 在每个发往UE的初始请求的Record-Route消息头中；

■ 在每个响应的Record-Route消息头中，这些响应是发往UE,并携带P-CSCF的Record-Route条目(在Record-Route消息头中设置端口号的细节参见11.3节）。

10.7.5.1注册过程中的端口设置

例如，Tobias的UE使用如下信息来进行初始注册：

REGISTER sip:homel.frSIP/2.0

Via:sip:[5555::l:2:3:4];branch=0uetb

Route:<sip:[5555::a:b:c:d];lr>

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

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

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

Contact:sip:[5555::l:2:3:4]:1357

这意味着：

•UE将按照以下端口建立IPsecSA：

■将端口2468作为受保护的客户端端口(Security-Client消息头中的port-c参数）；

■将端口1357作为受保护的服务器端口(Security-Client消息头中的port-s参数）。

•UE期望所有呼入请求都被传送到它的受保护的服务器端口(Contact消息头中的port值）。

•UE将这个初始REGISTER请求发往P-CSCF未受保护的端口5060,因为Route消息头中没有指定端口号。

•UE将在未受保护的端口5060上等候对该初始REGISTER的所有响应，因为Via消息头中没有指定端口号。

随后UE收到的401(未授权）响应将如下所示：

SIP/2.0401Unauthorized

Via:sip:[5555::I:2:3:4];branch=0uetb

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将使用以下端口建立IPsecSA：

•  将端口8642作为受保护的客户端端口(Secutity-Server消息头中的port-c参数）；

•  将端口7531作为受保护的服务器端口(Secutity-Server消息头中的port-s参数）。

在上述交换之后，UE和P-CSCF之间就建立起临时的SA组，UE将按保护方式发出第二个REGISTER请求，如下所示：

REGISTERsip:homel.fr SIP/2.0

Via:sip:[5555::l:2:3:4];1357;branch=luetb

Route:<sip:[5555::a:b:c:d];7531;lr>

Contact:sip:[5555::l:2:3:4]:1357

注意这个请求仍然包含Security-Client和Secutity-Verify消息头(见10.8节）,但由于它们对于SA的建立和传送已经不再有什么影响了，因此就没有显示在这个例子中。上述REGISTER请求意味着UE会：

•  希望所有呼入初始请求都被传送到它的受保护的服务器端口(Contact消息头中的端口号）；

•  已经通过临时IPsecSA发送该REGISTER请求(即发往P-CSCF受保护的服务器端口——Route消息头中的端口号）；

•  希望对于该REGISTER请求的所有响应都通过临时IPsec SA发送过来(即它的受保护的服务器端口1357—Via消息头中的端口号）。

10.7.5.2重认证过程的端口设置

如前所述，每次重认证都会生成一对新的IPsec SA。当根据SIP安全机制协议为新建SA交换安全参数索引和受保护的端口号时，P-CSCF和UE仅仅改变它们的受保护的客户端端口：

• 对于两组SA,UE都是通过它受保护的服务器端口(usl）接收请求和响应；

• 对于两组SA,P-CSCF都是通过它受保护的服务器端口(psi）接收请求和响应；

• 对于新SA组，UE使用一个新的受保护客户端端口(uc2）向P-CSCF发送请求和响应；

• 对于新SA组，P-CSCF使用一个新的受保护客户端端口(pc2）向UE发送请求和响应。

这是由于两组SA不能使用完全相同的端口参数。而且，如果受保护的服务器端口发生改变，将产生重大问题，意味着：

• UE将需要进行重认证，因为它已注册的联系方式中包含受保护的服务器端口；

• UE将需要对所有已建立的会话发送re-INVITE,因为它发送给对端的联系方式信息中包含受保护的服务器端口；

• P-CSCF将在旧的受保护的服务器端口上接收UE对每个已建立对话的所有后续请求(包含UE的所有订阅信息），因为SIP不可能对已建立的对话变更其路由信息。

以上所列举的还并不完整，但已经可以说明改变受保护的服务器端口将导致SIP路由产生很多问题。因此非常重要的就是，只要用户保持注册状态，就不能对该值进行修改。

10.7.5.3 除REGISTER外其他SIP请求的端口设置

11.3节描述了在非REGISTER请求中设置受保护的服务器端口的详细情况。

10.7.5.4UDP和TCP两种情况下的端口使用

前面几节介绍了如何通过一个或多个SA组对请求和响应进行传送。在所选的例子中，只使用了UDP作为传输协议。然而对于TCP,这些过程稍有不同。

若通过UDP发送请求时(见图10-8）,所有相关的响应都要传送到Via消息头所指示的IP地址和端口号。当通过TCP发送请求时(见图10-9）,Via消息头中的信息被覆盖掉，响应被传送回发送该请求的IP地址和端口号。这里需要注意TCP本质上是面向连接的传输协议。通过使用这个规则，可以确保不需要建立额外的TCP连接，来发送对TCP接收的请求的响应。这使得P-CSCF和UE之间SIP消息的路由行为会根据协议的不同而有所不同。不论使用UDP还是TCP,UE将在其发出的每个请求的Via消息头中设置其受保护的服务器端口(usl）。所有的请求都是从UE的受保护的客户端端口(ucl）发出。

图10-8   使用UDP时UE和P-CSCF之间请求和响应的路由

当使用UDP时，对于该请求的响应将发往Via消息头中所指示的UE受保护的服务器端口(usl）。当使用TCP时，对于该请求的响应将发往UE受保护客户端端口(ucl），请求就是从该端口发出的。对于另一个方向也是同样的(即由P-CSCF发往UE的请求及其响应）。

图10-9  使用TCP时UE和P-CSCF之间请求和相应的路由

10.7.6 相关标准

与10.7节有关的规范有：