IP多媒体子系统接入域安全机制的选择方法

摘要

本发明公开了一种统一的IP多媒体子系统(IMS)接入域安全实现方法，该方法在IMS网络的网络设备上针对接入网络或/和用户标识配置一种或多种接入域安全机制；所述网络设备依据用户终端的请求消息从配置的接入域安全机制中选择一种接入域安全机制，并由网络中执行安全机制的设备利用选择的接入域安全机制处理所述请求消息。

说明书

技术领域

本发明涉及通信领域中的安全技术，尤其涉及IP多媒体子系统(IMS)接入域安全机制的选择方法。

背景技术

IP多媒体子系统(IMS)作为固定和移动网络的核心会话控制层，已成为目前业界讨论的重点，在第三代移动通信系统(3G)以及TISPAN标准中定义了很多IMS相关的规范，包括网络架构、接口、协议等各个方面，其中安全是3G及TISPAN考虑的一个重要方面。目前规范中从安全的角度将IMS网络划分为接入域和网络域，并分别定义了接入域和网络域的安全规范，IMS网络的安全模型如图1所示。

IMS网络中定义的呼叫会话控制功能(CSCF)实体用于完成呼叫和会话时的控制和路由等功能，P/S/I-CSCF是为了实现不同的功能而区分的，代理-呼叫会话控制功能(P-CSCF)是完成用户UE的接入，所有UE通过P-CSCF接入网络；业务-呼叫会话控制功能(S-CSCF)提供会话控制和路由等核心功能；查询-呼叫会话控制功能(I-CSCF，Interrogating-CSCF)用于S-CSCF的选择及不同运营商或不同区域网络之间的互通，实现网络屏蔽等功能，如可能作为不同运营商之间的唯一出入口；用户归属服务器(HSS)，用于保存用户签约数据和配置数据等。

从图1中可以看出，接入域安全机制包括与用户终端(UE)相关的两个接口：接口1和接口2。接口1为UE与IMS网络间的双向认证接口，完成用户认证功能；接口2用于保证UE与P-CSCF间的通信安全。

3GPP对接口1和接口2的实现，是通过在用户终端注册流程中应用DigestAKA(摘要认证与密钥协商)机制来完成。用户终端注册过程中涉及的主要网络实体为：用户终端UE、P-CSCF、S-CSCF、用户归属服务器(HSS)，关于“IMS接入域安全”的更进一步信息，可参考3GPP技术标准TS33.203对IMS网络接入域安全性的详细描述。Digest AKA机制可参考TS33.203第6.1节内容，以及IETF的RFC3310。

由于无线领域现有大量用户终端不符合3GPP协议规范，不支持3GPP TS33.203要求的接入域安全机制，例如使用SIM卡的用户终端或者使用USIM/ISIM卡的2G用户终端。为了能够向这类终端用户提供IMS业务，TR33.978定义了称为“Early IMS”的接入域安全机制。Early IMS接入域安全的基本原理，是将应用层安全建立在接入层安全之上。接入层对终端接入进行认证后，将经过认证的信息传送给应用层，应用层依据这些信息对用户请求进行应用层安全认证。如图3所示，Early IMS接入域安全机制的原理如下：

1、PDP激活过程。用户终端通过GGSN接入GPRS网络，GGSN认证用户标识IMSI和MSISDN，为用户终端分配网络传输层标识(IP地址)；GGSN通过“Accounting Request Start”将(用户标识、终端IP地址)对应关系传送到HSS，HSS保存该对应关系。

2、认证注册请求。用户终端发起注册请求REGISTER；P-CSCF转发请求到S-CSCF时，在REGISTER携带用户终端源IP地址；S-CSCF依据REGISTER请求中的公有用户标识，查询是否已注册，如未注册，通过MAR/MAA由HSS获取公有用户标识对应的终端IP地址(HSS静态配置公有用户标识与MSISDN的对应关系，此时可通过公有用户标识获得对应的终端IP地址)。S-CSCF检查收到的REGISTER的终端源IP地址，如果与从HSS获得的相同，则通过认证。

3、认证非注册请求。由于P-CSCF与UE间没有建立安全通道，对终端发起的所有请求消息，S-CSCF都需要进行认证，以确保用户名与源IP地址是对应的。用户注册后，S-CSCF保存有用户标识与IP地址的对应关系。收到任何非注册请求消息，比较发起请求的用户终端的源IP地址与S-CSCF保存的该用户IP地址是否相同，如果不相同，拒绝该请求。

TR33.978，第6.2.6节，定义了IMS网络与终端间关于Early IMS与IMS AKA两种认证方式间的互通。

按TS33.203的要求，终端在注册请求中需要携带安全头域“Authorization”及“Security-Client”，而Early IMS认证不需要终端在注册请求中携带这些安全头域，因此当IMS网络同时支持两种认证方式时，对没有包含这些安全头域的注册(REGISTER)请求将采用Early IMS认证。

采用此方式确定对终端采用的认证方式，一方面无法扩展支持更多的认证方式，例如：如果同时支持Digest认证，终端的注册请求也不携带安全头域，这时就无法区分Digest认证和Early IMS，因此，在支持更多的认证方式时其扩展性差。另一方面，这种安全机制采用哪种认证是由终端决定而非网络决定，当两种认证的安全级别相同时没有问题，但如果同时支持多种不同安全级别的认证方式时，则不宜由终端来决定认证方式，因此，这种安全机制在适应网络的灵活性差。

发明内容

本发明提供一种IP多媒体子系统(IMS)接入域安全机制的选择方法，以解决现有技术只能支持两种IMS接入域安全机制，在增加安全机制时存在扩展性和灵活差的问题。

为解决上述问题，本发明提供以下技术方案：

一种IP多媒体子系统(IMS)接入域安全机制的选择方法，该方法包括步骤：

在IMS网络的网络设备上针对接入网络或/和用户标识配置一种或多种接入域安全机制；

依据用户终端的请求消息从配置的接入域安全机制中选择一种接入域安全机制，并由网络中执行安全机制的设备利用选择的接入域安全机制进行相应处理。

所述接入域安全机制包括对用户采用的认证方式。

在用户归属服务器(HSS)上针对用户标识配置对用户采用的认证方式，该HSS接收到网络中的业务-呼叫会话控制功能(S-CSCF)实体的多媒体认证请求后，根据该请求中的用户标识选择一种认证方式，并将对应的认证数据返回给S-CSCF实体，由S-CSCF实体与用户终端进行交互完成认证。

在IMS网络中的代理-呼叫业务控制功能(P-CSCF)实体上还针对接入网络配置采用的认证方式。

P-CSCF实体在接收到用户终端未指明认证方式的请求消息后在转发的请求消息中指明采用的认证方式；或者，P-CSCF实体在接收到用户终端指明认证方式的请求消息时，若发现该认证方式与本实体上针对接入网配置的认证方式不同，则在转发的请求消息中指明采用本实体上配置的认证方式。

在用户归属服务器(HSS)上针对用户标识配置对用户终端可采用的多种认证方式，该HSS接收到网络中的业务-呼叫会话控制功能(S-CSCF)实体的多媒体认证请求后，根据该请求中的用户标识获得相应的多种认证方式，并将对应的认证数据通过S-CSCF实体传送到用户终端，由用户终端选择一种认证方式来完成认证。

在P-CSCF实体上针对接入网络配置对用户终端采用的认证方式，P-CSCF实体在向S-CSCF实体转发用户终端的注册请求消息时，根据用户终端所在接入网络在该注册请求消息中指明对用户的认证方式。

所述接入域安全机制包括用户终端与代理-呼叫业务控制功能(P-CSCF)实体间需要建立的安全通道类型。

在HSS上针对用户标识配置用户终端与P-CSCF间需要建立的安全通道类型；该HSS接收到网络中的业务-呼叫会话控制功能(S-CSCF)实体的多媒体认证请求后，将选择的需要建立的安全通道类型返回给S-CSCF实体，由S-CSCF实体通知P-CSCF实体，P-CSCF实体据此与终端协商确定最终建立的安全通道类型。

在P-CSCF实体还针对接入网络配置用户终端与P-CSCF实体间需要建立的安全通道类型；若P-CSCF实体发现本实体上配置的安全通道类型与HSS选择的安全通道类型不同，则按HSS选择的安全通道类型在本实体与用户终端之间建立安全通道。

在P-CSCF上针对不同的接入网络配置用户终端与P-CSCF间需要建立的安全通道类型；在认证过程中，P-CSCF实体根据用户终端所在接入网络对应的安全通道类型，与用户终端协商建立该类型的安全通道。

本发明通过在网络设备上配置一种或多种安全机制，由HSS或用户终端选择其中一种安全机制来保证用户的接入安全，不仅其扩展性强，能够满足各种类型终端安全接入IMS网络，而且可灵活满足各种安全需求。

附图说明

图1为现有技术的IMS网络安全模型；

图2为现有技术中Early IMS的接入域安全机制的流程示意图；

图3A为网络设备同时支持多种接入域安全机制的示意图；

图3B为本发明中Digest MD5认证的流程图；

图4为本发明中由HSS决定认证机制的认证流程图；

图5为本发明中由用户终端决定认证机制的认证流程图；

图6为本发明由P-CSCF实体确定接入域安全机制的流程图。

具体实施方式

为了提高IMS接入域安全机制上的可扩展性和灵活性，满足不同的安全需求，本发明在IMS网络的网络设备上配置一种或多种接入域安全机制，依据用户的请求消息，选择确定使用的接入域安全机制。

IMS网络中的网络设备同时支持多种接入域安全机制的实现如图3A所示。接入域安全机制包括对用户采用的认证方式(如图3A中Digest AKA，DigestMD5等)和用户终端与IMS网络中的代理-呼叫会话控制功能(P-CSCF)实体之间需要建立的安全通道类型(如图3A中的IPSec，TLS等)。可以在HSS上针对用户标识配置一种或多种认证方式、一种或多种安全通道类型；也可以在P-CSCF上针对接入网络配置一种或多种认证方式，在P-CSCF上针对接入网络配置一种或多种对应的安全通道类型。在HSS针对用户标识配置安全机制的方法，与在P-CSCF上针对接入网络配置安全机制的方法，可以分别单独使用，也可以结合在一起使用。

用户认证方式包括：Digest AKA、Early IMS和Digest MD5；也可包括其他类似的可用于IMS网络的认证方式。Digest MD5与Early IMS，都是为了将不支持3GPP要求的Digest AKA的SIP终端接入IMS网络的认证机制。

在HSS上针对用户标识配置安全机制时，用户标识可以是私有用户标识，这通常针对有用户卡(ISIM卡等)的用户接入情况；当用户终端没有类似的用户卡，实际是针对公有用户标识配置相应的安全机制。

如果在HSS上针对用户标识配置有多种认证方式，需最终选择确定一种认证方式，具体包括如下两种选择方法：

(1)用户终端声明自己支持的认证机制，由HSS决定采用哪种认证机制。

用户终端在第一个REGISTER消息中携带Authorization头域，向网络表明自己支持的认证机制。例如，如下头域表明用户终端支持Digest AKA。

Authorization：Digest username＝userl_private@homel.net，realm＝″registrar.服务homel.net″，nonce＝″″，uri＝″sip：registrar.homel.net″，response＝″″，algorithm＝AKAy1-MD5。

第一个REGISTER请求携带Authorization头域表明用户终端支持的认证算法，S-CSCF向HSS发送的MAR请求中“Authentication Scheme”信息单元的内容为收到的REGISTER请求中的Authorization头域所表明的认证算法。此时，HSS检查MAR请求中“Authentication Scheme”信息单元的认证算法是否包含在HSS配置数据中此用户标识对应的认证算法中，检查通过后，采用此认证算法生成认证数据。

当在P-CSCF针对接入网络配置了一种或多种认证方法，P-CSCF收到用户注册请求后，将确定一种认证方法并在注册请求Authorization头域携带给S-CSCF(详见后续描述)。S-CSCF并不区分Authorization头域中的认证方法是由终端填写的还是在经过P-CSCF时被决定的，都将此认证方法在MAR中指示给HSS，HSS的处理与前述相同。

如果S-CSCF收到的注册请求没有携带Authorization头域指示认证方法，HSS可按配置缺省选择一种认证方法(例如选择优先级别高的认证方法)，采用这种认证方法来生成认证数据返回给S-CSCF以认证用户。

(2)HSS提供可能的认证方法，由用户终端选择。

当S-CSCF收到的注册请求没有携带Authorization头域指示认证方法，HSS没有足够依据从针对用户标识配置的多种认证方法中选择一种认证方法时，HSS向S-CSCF返回的MAA响应中，携带配置的各种认证方式所对应的认证数据，S-CSCF可在下发认证请求Challenge时指示自己支持的多种认证方法，由终端自行选择。例如：S-CSCF向用户终端下发的401响应消息中一次可携带多个Challenge，即多个WWW-Authenticate头域，每个WWW-Authenticate头域分别对应不同的认证方法。用户终端收到后，选择自己支持的最强的认证方法，在下一个注册请求消息中，通过Authorization头域指示上来。

当HSS针对用户标识仅配置了一种认证方法，则无论接收的MAR所指示的认证方法是什么，HSS总选择配置的认证方法。

参阅图3B所示，在IMS接入域内，由S-CSCF实体对用户终端注册请求实施Digest MD5认证的具体步骤如下：

步骤1：用户终端UE向P-CSCF实体发起注册请求消息REGISTER。

步骤2：P-CSCF实体将注册请求REGISTER转发到S-CSCF实体。

步骤3：S-CSCF实体向HSS发起携带有用户标识的多媒体认证请求消息(MAR消息)，该用户标识从注册请求消息REGISTER中获得。

步骤4：HSS接收到MAR消息，根据用户标识对应的用户配置数据判断对该用户进行Digest MD5认证，根据用户配置数据中的用户名username-value、所对应的域名realm-value以及用户密码passwd，按RFC2617所描述公式H(A1)＝H(unq(username-value)″：″unq(realm-value)″：″passwd)计算出H(A1)，向S-CSCF返回携带H(A1)的MAA消息。

步骤5：S-CSCF保存HA1，同时生成认证挑战中的各项参数，如nonce，参数“realm”即用户所在域的域名，可直接从用户标识中获取。并根据各项参数生成WWW-Authenticate头域，并通过401响应将该头域下发到P-CSCF实体。

步骤6：P-CSCF接收来自S-CSCF的401响应，检查消息内容知认证算法为Diges认证，此时P-CSCF不修改401响应，透传该401响应到用户终端UE。

步骤7：用户终端从401响应中获取WWW-Authenticate(认证挑战)后，结合自身密钥计算“request-digest”，携带在认证回应Authorization的response参数中，并通过重新发起的注册请求消息REGISTER将认证回应携带到P-CSCF实体。

步骤8：P-CSCF实体将注册请求REGISTER传送到S-CSCF实体。

步骤9：S-CSCF实体收到认证回应后，再结合HA1计算出“request-digest”，与认证回应Authorization中response参数的内容相比较，若两者相同，则认证通过并向用户侧返回200响应，否则认证失败。

步骤10：P-CSCF实体向用户终端转发200响应消息。

参阅图4所示，用户终端声明自己支持的认证机制，由HSS决定认证机制的实现过程如下：

步骤20：用户终端UE通过P-CSCF向S-CSCF实体发起注册请求REGISTER，该注册请求REGISTER中声明用户终端支持的认证机制，如DigestMD5。

步骤21：S-CSCF实体通过Cx接口向HSS发送MAR请求认证数据，其中，声明用户终端支持的认证机制，如Digest MD5。在MAR消息请求中携带有“Authentication Scheme”信息单元。

步骤22：HSS从MAR中获得用户标识ID1，查询预先配置的用户标识与认证方式之间的关系，得到该用户标识ID1所对应的多个认证方式。如：EarlyIMS和Digest MD5。由于MAR中声明终端支持Digest MD5，因此，HSS优先选择Digest MD5认证方式；HSS通过MAA消息将认证方式和认证数据返回给S-CSCF实体。

HSS作为用户认证方式的决策点，当收到的MAR请求中的“AuthenticationScheme”指示的认证方式不在其配置的该用户的认证方式列表中，则选择某一缺省认证方式。

步骤23-25：S-CSCF实体收到MAA响应后，依据获得的认证数据生成认证挑战，在401响应中携带给用户终端，用户终端与S-CSCF交互完成认证(详细流程参阅图3B的步骤5-10)。

参阅图5所示，以为用户标识ID2配置Early IMS和Digest MD5认证方式为例，HSS提供可能的认证方法，由用户终端决定认证机制的实现过程如下：

步骤30：用户终端UE通过P-CSCF向S-CSCF实体发起注册请求REGISTER。

步骤31：S-CSCF实体通过Cx接口向HSS发送MAR消息请求认证数据，在MAR消息请求中未携带“Authentication Scheme”信息单元。

步骤32：HSS从MAR中获得用户标识ID2，查询预先配置的用户标识与认证方式之间的关系，得到该用户标识ID2所对应的Early IMS和Digest MD5认证方式；HSS通过MAA消息将Early IMS和Digest MD5认证方式，以及相应的认证数据返回给S-CSCF实体。

步骤33：S-CSCF实体收到MAA响应后，依据获得的认证数据分别生成两个认证挑战WWW-Authenticate头域，在401响应中携带给用户终端。S-CSCF向用户终端下发的401响应消息中一次可携带多个Challenge，即多个WWW-Authenticate头域，每个Challenge分别对应不同的认证机制。

步骤34：用户终端从401响应中获取两个WWW-Authenticate头域后了解网络侧支持Early IMS和Digest MD5认证方式，根据自身支持的最强的认证方式，如Digest MD5认证方式，结合自身密钥计算“request-digest”，携带在认证回应Authorization的response参数中，并通过重新发起的注册请求消息REGISTER来完成认证(其后处理流程参阅图3B的步骤8-10，不再赘述)。

IMS接入域安全机制由两部分组成，包括对用户的认证和保证信令传输安全。为保证信令传输安全，可在用户终端与P-CSCF间建立安全通道。具体要求建立的安全通道类型可以由运营商在网络设备上配置。对用户认证方法的配置，和对安全通道类型的配置，相应的实现流程是相互独立的，运营商可以在P-CSCF或HSS已配置认证方式的基础上或在没有配置认证方式的情况下在P-CSCF实体上或在HSS上配置安全通道类型。

安全通道包括但不限于IPSec，TLS等。例如，作为安全通道的一个特例，对某些接入环境，运营商通过底层IP组网保证接入终端与P-CSCF间的通信安全。运营商确定接入网络已有相应安全保证的情况下，如VPN，P-CSCF与该接入网络内的用户终端间不要求再建立安全通道。

安全通道的另一个特例，用户终端与P-CSCF间没有任何安全通道，底层IP组网也没有保证两者间的通信安全。运营商选择接入这类用户时，UE与P-CSCF间安全通信没有保证。为防止用户欺骗，可在注册和会话建立过程中对用户进行认证。在会话建立过程对用户终端的认证可采用如下方式：收到用户发起会话请求时，S-CSCF实体首先对终端进行Digest MD5认证，认证通过后，再继续进行呼叫建立过程，否则拒绝会话请求。更进一步，除了对会话建立请求进行认证，S-CSCF实体也可对每条用户终端发起的所有请求消息进行DigestMD5认证。

当对用户终端采用Digest AKA认证方法，在认证过程中P-CSCF和UE都可获得IK/CK，IK/CK就是建立安全通道的密钥，即可将IK/CK用于IPSEC，也可将IK/CK用于TLS通道建立。如果对用户终端采用Digest MD5认证，此认证过程中不产生用于建立安全通道的密钥，此时可采用其他方式，例如终端配置P-CSCF的数字证书，终端与P-CSCF间建立TLS连接。

实际应用中存在各种各样的安全通道类型，运营商可以在HSS上针对用户标识配置用户终端UE与P-CSCF间要建立的安全通道类型。类似于在HSS针对用户标识配置相应的用户认证机制，在上述图4和图5的流程中，S-CSCF实体与HSS之间进行MAR/MAA的交互过程中，S-CSCF获得HSS配置的UE与P-CSCF实体间安全通道类型，并将此类型信息通过401响应携带给P-CSCF实体，P-CSCF实体依据此信息与终端协商安全通道类型并等待安全通道的建立。例如，S-CSCF实体可以通过在401响应中增加一个私有扩展头域“security-channel”向P-CSCF实体表明要建立的安全通道类型。P-CSCF实体作为安全通道的建立点，当收到来自S-CSCF实体的401响应中携带的安全通道类型指示参数，就以此与用户终端协商确定要建立的安全通道。

用户终端可通过各种不同的接入网络，经P-CSCF接入到IMS。P-CSCF对外可提供多个网络接口，每个网络接口对应一个接入网络，例如移动接入UMTS/GPRS，固定接入，或接入类型ADSL/LAN/HFC/WiFi。运营商针对一个接入网络可实施一种接入域安全机制，即针对P-CSCF的某个网络接口，运营商可配置相对应的接入域安全机制，包括对用户的认证方式和UE与P-CSCF间需建立的安全通道类型。

运营商可在P-CSCF实体上针对接入网络配置接入域安全机制，包括对用户认证机制及UE和P-CSCF实体间的安全通道类型。参阅图6所示：

步骤50：P-CSCF实体接收到用户终端的注册请求REGISTER，识别出接收该请求的网络接口，依据配置数据，确定该网络接口对应的接入域安全机制类型。其中，UE与P-CSCF实体间的安全通道类型，由P-CSCF实体保存供安全通道的建立使用，对用户采用的认证机制，P-CSCF实体在REGISTER请求中传送给S-CSCF实体。

若UE发出的REGISTER请求未携带Authorization头域，P-CSCF实体在REGISTER新增加Authorization头域，并在该头域携带参数“algorithm”，向S-CSCF实体表明对该用户采用的认证机制类型。

若UE发送的REGISTER请求中已经携带了Authorization头域，P-CSCF实体检查其中的“algorithm”参数内容，如不符合本地配置的与该网络接口相对应的用户认证机制，则修改为本地配置的用户认证机制并向S-CSCF实体转发REGISTER请求。

步骤51：S-CSCF实体收到REGISTER请求后，向HSS发MAR请求，携带信息单元“Authentication Scheme”向HSS表明对用户采用的认证机制。

步骤52：HSS没有针对用户标识配置接入域安全机制，仅依据MAR请求中指示的认证机制，在MAA中回送相应的认证数据。S-CSCF实体据此生成WWW-Authenticate头域并携带在401响应中(其余步骤参阅前述流程中的相关步骤)。

若HSS不支持MAR请求的信息单元“Authentication Scheme”指示的认证机制，S-CSCF实体通过MAA可获知，S-CSCF实体向用户终端返回4XX响应(如420 Bad Extension)。

步骤53：P-CSCF实体通过401响应的Security-Server头域，将先前保存的要建立的安全通道类型同终端协商。

步骤54：用户终端与P-CSCF实体建立指定类型的安全通道。

P-CSCF实体向用户终端发送401响应后，P-CSCF实体进入安全通道建立阶段。等待一段时间，如终端没有发起安全通道建立，认为与终端间安全通道建立失败，拒绝后续用户请求。如安全通道建立成功，则将在已建立的安全通道上接收并处理后续用户请求。

以上步骤包括了既在P-CSCF针对接入网络配置用户认证方法，也对接入网络配置安全通道类型，但并不限定这两种配置必须同时使用。

仅在P-CSCF针对接入网络配置安全通道类型，流程简述如下：

(1)P-CSCF实体收到用户终端的第一个REGISTER请求，依据网络接口确定用户终端所在接入网络，并根据配置确定与用户终端间需建立的安全通道类型。

(2)P-CSCF实体通过401响应的Security-Server头域，将要建立的安全通道类型与终端协商。

(3)用户终端与P-CSCF实体建立指定类型的安全通道。

(4)P-CSCF实体向用户终端发送401响应后，P-CSCF实体进入安全通道建立阶段。等待一段时间，如终端没有发起安全通道建立，认为与终端间安全通道建立失败，拒绝后续用户请求。如安全通道建立成功，则将在已建立的安全通道上接收并处理后续用户请求。

以上分别描述了在HSS针对用户标识配置接入域安全机制的方法，以及在P-CSCF针对接入网络配置接入域安全机制的方法。这两种方法可分别单独使用，也可以结合成使用。如，运营商既在HSS配置了接入域安全机制，也同时在P-CSCF配置接入域安全机制，这种方式的处理流程如下：

(1)P-CSCF依据接收的注册请求相应的接入网络，确定用户认证方法以及安全通道类型，P-CSCF保存安全通道类型供后续建立安全通道使用，P-CSCF将用户认证方法在注册请求的Authorization头域中携带到S-CSCF。

(2)S-CSCF将Authorization头域中的用户认证方法在MAR中传递到HSS。

(3)HSS依据用户标识，依据本地配置信息，获得用户认证算法和安全通道类型，HSS确定要使用的用户认证方法并在MAA中指示S-CSCF，HSS将配置的安全通道类型在MAA中传递到S-CSCF。

(4)S-CSCF依据用户认证数据，构造WWW-Authenticate头域。S-CSCF将安全通道类型通过私有扩展头域Security-Channel传递到P-CSCF。

(5)P-CSCF收到S-CSCF的401响应，检查其中携带了Security-Channel头域，则依据此头域内容与终端协商要建立的安全通道。(如未携带Security-Channel头域，则按P-CSCF自己保存的安全通道机制与终端进行协商确定)

此外还存在其他各种可能的应用情况，例如：运营商在HSS针对用户标识仅配置用户认证方式，在P-CSCF针对接入网络仅配置安全通道类型。这种情况下具体的实现流程可以从前面所描述的相关实现流程中获知。

在UE与P-CSCF间建立安全通道后，P-CSCF通过注册请求(图6中步骤55)中携带SIP消息头域(例如，可以是Security-Channel私有扩展头域)向S-CSCF表明与UE间最终建立的安全通道类型。S-CSCF可以在后续的处理过程中使用此信息。例如，对没有建立安全通道的用户进行基于每会话请求或每请求消息的Digest MD5认证，或者对没有建立安全通道的用户提供受限的业务。S-CSCF利用此安全通道类型信息所做的具体处理可以属于用户签约信息，在HSS针对用户配置，或者属于S-CSCF的本地全局配置信息，统一处理而不针对某个具体的用户。

通过本发明的方案，使得IMS网络设备对IMS接入域安全机制的支持更加灵活。一方面是可兼容目前存在的各种接入域安全机制，例如，为了实现TS33.203定义的安全机制需求，可以在HSS配置用户对应的认证机制为“DigestAKA”，同时在P-CSCF配置相应的接入域为“与UE间建立IPSec安全通道”。又例如，对采用Early IMS方式接入的用户，在HSS配置该用户对应的认证机制为“Early IMS”(即终端源IP地址与用户标识相对应的认证方式)，同时在P-CSCF配置相应的接入域为“不需要建立特定的安全通道”(通信安全已由底层IP组网保证)，通过此配置，即可实现Early IMS的安全需求。另一方面更为灵活的是，本方案还可支持各种可能的接入域安全机制，例如，运营商可以配置用户的认证机制为“Digest MD5”，安全通道为“不需要建立特定的安全通道”(通信安全已由底层IP组网保证)，这样就实现了另外一种与单纯的Early IMS有所区别的接入域安全机制。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。