CN1889562A - 对接收初始会话协议请求消息的设备进行认证的方法 - Google Patents

Abstract

本发明公开了一种对接收初始会话协议请求消息的设备进行认证的方法，以解决现有技术中不能针对接收SIP请求消息的设备进行认证而存在安全性差的问题；其中，发送SIP请求的设备针对接收SIP请求消息的设备生成认证挑战，并向目标设备下发携带该认证挑战的SIP请求消息；所述目标设备根据用户密钥和所述认证挑战中的相关参数生成认证回应，并通过响应消息传送到所述发送SIP请求的设备；发送SIP请求的设备根据保存的用户密钥验证所述认证回应，以确定目标设备身份的真实性。

Description

对接收初始会话协议请求消息的设备进行认证的方法

技术领域

本发明涉及通信网络中的认证技术，尤其一种对接收初始会话协议(SIP)请求消息的设备进行认证的方法。

背景技术

在RFC3261中规定了在初始会话协议(SIP协议)中采用摘要(Digest)认证方法对SIP用户身份进行认证鉴定。Digest认证方法也是超文本传输协议(HTTP协议)中的认证架构所采用的认证方法(由RFC2617所定义)。通过Digest认证方法可验证发起请求的用户的真实性，当用户的真实性得到确认后，网络决定是否为该用户的请求提供相应服务。但Digest认证并不能解决所有安全问题，例如，此方法并不能对传送的消息内容进行加密。

参阅图1所示，在SIP协议中对用户注册的认证过程如下：

网络设备有数字证书，终端开机后先与网络设备建立TLS连接，然后按下述步骤进行注册：

步骤1、终端向网络设备发送REGISTER注册请求消息。

步骤2、网络设备生成“认证挑战”并在401响应的WWW-Authenticate头域中下发给终端。

步骤3、终端生成“认证回应”并在第二个REGISTER请求的Authorization头域中携带给网络设备。

步骤4、网络设备依据“认证回应”的内容，对终端的用户身份认证通过后，对REGISTER请求回送200响应表明注册成功。

至此，用户的身份得到网络设备的认证，并且用户终端与网络设备间建立了用于保证后续两者间通信安全的TLS安全通道(安全通道可在注册前建立，也可在注册过程中建立，例如3GPP IMS，在用户注册过程中，UE与P-CSCF间建立IPSec安全通道)。

步骤5-7，后续当终端作为主叫发起呼叫请求时，网络设备可不再认证该终端，因为已与该终端建立了TLS安全通道。

步骤8-10，后续当终端作为被叫接收呼叫请求时，网络设备也直接将相应的INVITE请求通过与该终端已建立的TLS安全通道传送给被叫终端。

实际的SIP应用中，用户终端有可能仅支持Digest认证而不支持TLS等安全通道的建立。这种情况下，除了对用户的注册请求进行Digest认证外，也对后续的用户会话建立请求，甚至是每一条用户发起的请求消息，进行Digest认证，如图2所示，其流程简述如下：

步骤1-4，对用户的注册请求，网络通过401带下对终端的“认证挑战”。终端在消息3REGISTIER带回“认证回应”。网络收到“认证回应”的内容，经Digest计算后验证了用户的身份。用户注册成功。

步骤5-10，后续用户发起呼叫请求INVITE时，由于没有在网络设备与终端间已建立安全通道，网络设备再次对INVITE请求进行认证，在401响应中下发“认证挑战”，用户在步骤8中的INVITE请求中携带认证回应，网络设备认证通过后，处理该INVITE请求，提供相应服务。

在RFC3261中，规定了相关认证头域只能在特定消息中携带。例如，携带认证挑战的WWW-Authenticate头域仅能在响应消息401/407中出现，而携带认证回应的Authorization头域仅能在SIP请求消息中出现，这就限定了Digest认证仅能应用于对发送SIP请求的设备进行身份认证。因此，当用户终端仅支持Digest认证而不支持TLS安全通道的建立时，现有技术方案仅针对发起请求的用户进行认证，而不能对接收SIP请求的用户进行认证。

由于当前Digest认证在SIP的应用，不能针对接收SIP请求消息的设备进行身份认证，因此，就可能会存在安全漏洞。这是因为：用户在网络设备注册成功后，该用户标识与相应的用户终端的联系地址(IP地址)的对应关系被保存在网络设备。当网络设备接收到发往该用户的SIP请求(例如该用户作为被叫方)，若用户终端与网络设备间建有TLS安全通道时，网络设备会基于已建立的TLS通道，向终端发送相应SIP请求。若用户终端与网络设备间没有建立安全通道，网络设备仅依据先前注册的用户终端联系地址，将相应SIP请求发往对应的IP地址，此时若被叫终端的IP地址被攻击者仿冒，攻击者则接收到相应的SIP请求。

发明内容

本发明提供一种对接收SIP请求消息的设备进行认证的方法，以解决现有技术中存在不能针对接收SIP请求消息的设备进行认证的问题。

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

一种对接收SIP请求消息的设备进行认证的方法，包括如下步骤：

发送SIP请求的设备针对接收SIP请求消息的目标设备生成认证挑战，并向目标设备下发携带该认证挑战的SIP请求消息；

所述目标设备根据用户密钥和所述认证挑战中的相关参数生成认证回应，并通过对请求的响应消息传送到所述发送SIP请求的设备；

发送SIP请求的设备根据保存的用户密钥验证所述认证回应，以确定目标设备身份的真实性。

其中：

若目标设备身份真实性验证通过，则进行后续业务流程；若目标设备真实性验证失败，则发送SIP请求的设备立即终止后续业务流程，或发起SIP请求的设备重新向目标设备下发携带认证挑战的SIP请求消息对目标设备身份进行验证，直到验证失败的次数超过设定的次数后终止后续业务流程。

所述接收SIP请求的目标设备在回送认证回应时，可进一步携带相关参数，以认证发送SIP请求的设备的身份。

在目标设备身份真实性验证通过后，发送SIP请求的设备根据认证回应中携带的所述相关参数，在后续发送给所述目标设备的请求消息中携带相应的认证信息，由目标设备对该认证信息进行验证。

目标设备在所述认证信息未通过验证时主动终止后续业务流程。

在终止后续业务流程时，若认证过程中已建立对话，则通过发送对话释放消息以结束该对话。

目标设备在针对SIP请求消息所返回的最终响应消息中携带所述认证回应；或者，目标设备在所返回的可靠传送的临时响应消息中携带所述认证回应。

发送SIP请求的设备利用摘要(Digest)认证算法生成所述认证挑战，所述目标设备利用摘要(Digest)认证算法生成认证回应；发送SIP请求的设备依据摘要(Digest)认证算法对认证回应进行验证。

本发明通过在发送给目标设备的SIP请求消息中携带认证挑战和在相应的SIP响应消息携带认证回应实现对目标设备的认证。当用户注册过程中终端没有与网络设备建立安全通道，网络设备向终端发送SIP请求时，可采用本发明保证接收SIP请求的终端的身份的真实性。从而保证在未建立安全通道情况下的通信安全。此外，本发明作为一种通用的认证消息接收方身份的方法，可应用在很多SIP应用场合，是对SIP协议应用的一种扩展。

附图说明

图1为现有的SIP协议中对用户注册的认证流程；

图2为对每一条用户发起的请求消息进行Digest认证的流程图；

图3、图4A、图4B为本发明中对接收SIP请求消息的设备进行认证的流程图；

图5、图6为发送SIP请求消息的设备与接收SIP请求消息的设备之间进行双向认证的流程图；

图7A、图7B为本发明分别应用于多播方式和网络地址转换方式的示意图。

具体实施方式

摘要(Digest)认证以“challenge-response”的基本方式完成，本发明中相应的称为“认证挑战-认证回应”。本发明中，发送SIP请求消息的设备通过WWW-Authenticate头域携带“认证挑战”信息给接收SIP请求消息的设备，接收SIP请求消息的设备通过Authorization头域携带“认证回应”信息给发送SIP请求消息的设备，发送SIP请求消息的设备据此认证用户身份的真实性。发送SIP请求消息的设备可以是用户终端设备，也可以是网络设备。在SIP应用中，认证方(在本发明中是发送SIP请求消息的设备)通常是网络设备，被认证方通常是用户终端，下面的描述以此为例来说明。

为了能够清楚的描述本发明的具体实现，先分别介绍现有技术中“认证挑战”和“认证回应”中的主要参数：

WWW-Authenticate：Digest

realm＝″biloxi.com″，

qop＝″auth，auth-int″，

nonce＝″dcd98b7102dd2f0e8blld0f600bfb0c093″，

opaque＝″5ccc069c403ebaf9f0171e9517f40e41″。

“realm”参数向用户终端表明其当前正接受来自哪个“域”的认证，终端可向用户显示此信息，提示用户应该输入的相应帐号(包括用户名和密码]。用户在不同的域可能有不同的用户帐号。

“qop”，即quality of protection。此参数的值为“auth”，表明仅做用户认证。为“auth-int”，指示同时做用户认证和消息体完整性保护。当进行消息体的完整性保护时，生成“response”参数的算法加上消息体为输入参数之一，与没有完整性保护时算法不一样。上例，qop＝″auth，auth-int″，表明网络侧同时支持这两种方式。(由于RFC2069中没有使用此参数，为了后向兼容RFC2069，“qop”参数是可选参数。

“nonce”，此参数由网络侧产生(与网络侧本地时间关联)。用户终端在发回的Authorization认证回应头域中，将nonce的内容原封不动的带回，这样网络侧可以根据此nonce中的内容得知当时生成此nonce参数的时间(即发送WWW-Authenticate认证挑战的时间)，与当前收到Authorization的时间相比较，如果两个时间相差过大，表明受到“重放”攻击。

stale，若为TRUE，表示客户端的前一个请求被拒绝的原因是因为经过网络侧的检查，发现此请求中nonce中所带的time-stamp信息比较老，这样，客户端在收到此WWW-Authenticate后，将会利用其中的新的nonce，自动重新产生一个新的Authorization，而无需提示用户输入帐号。若为FALSE或其它值，则需要提示用户输入用户帐号。

用户终端根据用户帐号及收到的WWW-Authenticate内容产生Authorization头域：

Authorization：Digest usemame＝″bob″，

realm＝″biloxi.com″，

nonce＝″dcd98b7102dd2f0e8b11d0f600bfb0c093″，

uri＝″sip：bob@biloxi.com″，

qop＝auth，

nc＝00000001，

cnonce＝″0a4fl13b″，

response＝″6629fae49393a05397450978507c4efl″，

opaque＝″5ccc069c403ebaf9f0171e9517f40e41″

“uri”，携带request-uri中的内容，之所以要以参数形式携带，是因为请求消息中的request-uri内容在传送过程中可能被PROXY修改。此参数是生成“response”参数的输入之一。

“qop”，上例中为“auth”，表明终端没有使用消息体完整性保护的扩展功能。

“nc”，表明这是第几次使用同一个“nonce”生成认证回应。网络侧会维护一个nonce counter计数器，当网络收到同一个nc-value两次或以上，表明受到了“replay”方式的攻击。

“cnonce”，终端生成的nounce，在Authentication-Info头域中被带回，用于终端对网络的认证。

“response”，最重要的参数。终端根据用户名、用户密码、realm-value、nonce、uri等值进行计算得到的数据。网络侧也有这些输入数据，因此采用相同的算法得到一串数据后，相比较，如相等，可证明用户的密码正确，以此证明用户的身份。

生成response参数的算法如下，详细内容参见RFC2617第“3.2.2.1-3.2.2.3”节。

request-digest＝<″><KD(H(A1)，unq(nonce-value)

                               ″：″nc-value

                               ″：″unq(cnonce-value)

                               ″：″unq(qop-value)

                               ″：″H(A2)

                          )<″>

其中A1与A2的计算分别如下：

A1＝unq(username-value)″：″unq(realm-value)″：″passwd

A2＝Method″：″digest-uri-value

除“WWW-Authenticate”和“Authorization”两个基本头域，RFC2617还新定义了Authentication-Info头域，此头域在终端认证成功响应中被携带给终端，传达附加的认证相关信息。此头域在RFC2069中是不存在的，是RFC2617定义的一个扩展。具体参数如下：

Authentication-Info：

qop＝auth，

rspauth＝″6629fae49393a05397450978507c4efl″，

cnonce＝″0a4fl13b″，

nc＝00000001

“qop”，表明认证类型(是否需要进行消息体保护)，同前描述。

“rspauth”，用于网络向终端表明自己知道终端密码。终端接收到此参数后，通过计算，如果计算结果与此参数的值相同，终端认为网络是可信的。此参数的计算与前面介绍“response”参数的计算方法基本相同。

“cnonce”，网络将终端在Authorization头域中携带的内容通过此参数原样返回给终端。

“nc”，nonce-count，表明这是第几次使用同一个“nonce”生成认证回应。

除以上4个参数外，此头域中可携带“nextnonce”参数，此参数包含的内容是网络希望终端在生成下一次认证回应中使用的nonce。网络通过此参数，可实现一次性nonce或对nonce值进行改变。

参阅图3所示，为了实现对接收SIP请求消息的设备进行认证，发起认证的网络设备在向目标设备发送SIP请求消息中携带WWW-Authenticate头域，发起认证挑战；目标设备接收到携带WWW-Authenticate头域的请求消息后，生成相应的认证回应，通过SIP响应消息在Authorization头域中将认证回应携带给发起认证的设备。发起认证的设备依据收到的Authorization头域，可对接收SIP请求消息的设备的身份进行认证，确切的知道该SIP请求消息的接收者的身份是否合法(接收者是否知道正确的用户密码)。

认证挑战和认证回应的生成采用现有Digest认证中生成方法，只是计算A2有所不同。因为A2的计算需要uti参数作为输入，即A2＝Method ″：″digest-uri-value。现有Digest认证方案，认证回应在请求消息携带，认证回应中uri参数对应相应请求消息的Request-URI，计算A2时，请求消息的Method以及Request-URI作为输入参数，这样可保护请求消息中的这两个域不被第三方修改。而本发明中，认证回应在响应消息中携带，终端计算Authorization头域的response参数时，计算公式与现有的计算Authorization头域的response参数的计算公式相同，但具体在计算A2时，由于响应消息中没有对应的“Method”及“Request-URI”，因此本发明中约定，计算A2的公式为：A2＝″：″，其中，原先的digest-uri-value和Method在这里都是空字符串。或者，A2＝Method″：″，其中Method参数为终端接收到的SIP请求中的相应Method。当然计算A2参数时也可以采取其他方式。

在本发明，当发起认证的网络设备接收到目标设备在响应消息中携带的认证回应后，如果对接收请求消息的设备认证通过，则继续业务流程。如对接收请求消息的设备认证没有通过，则发起认证的网络设备可终止后续业务流程，具体如何终止后续业务流程，与网络设备发给用户终端的请求消息相关。

如网络设备发给用户终端的SIP请求已相应地建立对话(Dialog)，则网络设备可以将Dialog释放以终止后续的业务流程。建立Dialog的SIP请求有INVITE，或SUBSCRIBE等。

参阅图4A所示，对接收SIP请求消息的设备认证成功的流程如下：

步骤1-3，SIP服务器对主叫终端1发起的呼叫请求进行Digest认证，并在401响应中下发认证挑战。

步骤4，主叫终端1将认证回应在INVITE中携带给SIP服务器，SIP服务器对主叫认证成功。

步骤5-6，SIP服务器依据接收的INVITE寻找被叫，在发向被叫终端2的INVITE中，携带对被叫用户的认证挑战头域WWW-Authenticate。

当用户终端2接收消息INVITE后，可能向用户提示输入密码，待用户输入密码并确认接收呼叫后，在200响应中将认证回应传给SIP服务器。或者用户密码已保存在用户终端，而不需要向被叫用户提示输入密码以接听入呼叫。

被叫用户终端2除了可以在200响应中携带认证回应外，也可在可靠传送的临时响应中携带认证回应。

步骤7-9，SIP服务器接收被叫用户的认证回应，认证通过后，SIP服务器继续后续的业务流程，将200响应转发给主叫终端1。主叫终端1回送ACK完成呼叫建立过程。

参阅图4B所示，对接收请求消息的设备认证失败的流程如下：

步骤1，主叫用户终端l发起呼叫请求INVITE(这里省略了网络设备可能对主叫的认证过程)。

步骤2-4，SIP服务器依据接收的INVITE寻找被叫，在发向被叫终端2的INVITE中，携带对被叫用户终端2的认证挑战头域WWW-Authenticate，用户终端2的认证回应头域在200响应中携带。SIP服务器依据终端2的认证回应判断对被叫用户终端2的认证失败。此时仍需要回送ACK以完成SIP的基本事务交互。

步骤5，由于对被叫终端2的认证失败，SIP服务器决定终止后续的业务流程，向被叫终端2发送BYE请求释放呼叫。

步骤6，由于对被叫终端2的认证失败，SIP服务器决定终止后续的业务流程，向主叫终端1发送失败响应并携带相应的头域通知失败原因。

当被叫终端2采用在可靠临时响应中携带认证回应的方法时，SIP服务器终止同被叫终端2的业务流程的方法是发送CANCEL。

在认证失败的情况下，也可以不用立即终端后续流程，而是由发起认证的网络设备重新向目标设备下发携带认证挑战的SIP请求消息进行下一次验证，直到验证失败的次数超过设定的次数后终止后续业务流程。这样，可以避免用户因偶然性的输入错误而终止后续业务流程的情况出现。

上述图4A和图4B的认证流程应用于IMS网络时，由IMS网络中的业务-呼叫会话控制功能(S-CSCF)实体代替SIP服务器，其实现过程与上述同理。

在对接收SIP请求的目标设备进行认证的过程中，目标设备在回送认证回应时可进一步携带相关参数，以认证发送SIP请求的设备的身份。在对接收SIP请求消息的设备认证通过后，发送SIP请求的设备可以在后续发送给目标设备的请求消息中携带认证信息，由目标设备对发送SIP请求的设备进行认证。

如图5所示，当发起认证的网络设备收到的SIP响应消息中携带有“认证回应”Authorization头域，其中有终端生成的参数“cnonce”，则网络设备可以在后续发向终端的请求消息中携带Authentication-Info头域，其中有“rspauth”参数，向终端表明网络设备知道终端的密码，终端接收到Authentication-Info后，依据自身计算的结果，检查“rspauth”参数可判断网络设备是否知道自己的密码，完成终端对网络设备认证的功能。

依据RFC2617的描述，“rspauth”参数的计算公式如下：

A2＝″：″digest-uri-value

在RFC2617中，Authentication-Info在响应消息中携带，digest-uri-value为与该响应消息对应的请求消息中的Authorization头域中的uri参数。本发明中Authentication-Info在请求消息中携带，因此本发明中，可在Authentication-Info中增加参数uri(与Authorization头域中uri参数的含义相同)，在计算A2时，digest-uri-value即为参数uri的值。或者，在计算A2时，认为digest-uri-value为空字符串。当然，也可以采用他方法计算A2。

如图6所示，在步骤1，网络设备向终端发送携带认证挑战的NOTIFY请求消息；在步骤2，终端回应401响应消息并携带Authorization头域，其中包含cnounce参数。网络设备对终端的认证成功，因响应消息为401响应消息，终端也要认证网络设备；在步骤3，网络设备在NOTIFY消息中携带Authentication-Info头域；在步骤4，终端对网络进行认证，认证成功后回送200响应消息。

以上实施例为本发明的一种应用情况，类似的SIP应用还有很多，如图7A所示，一个IP网内包括网络设备和多个SIP终端，这些终端没有注册于网络设备，当网络设备要向某个终端发送SIP请求时，采用IP多播的方式，并依据本发明在SIP请求消息中携带认证挑战，该IP网内所有终端都将接收到该请求，但只有某个终端才能够在相应的响应消息中携带正确的认证回应并得到网络设备的后续服务。如图7B所示，IP私网内的多个终端通过NAT与SIP服务器通信，由于NAT的存在，SIP服务器不知道终端的私网地址，当SIP服务器发送SIP请求给终端时，携带认证挑战，由NAT在私网内进行IP多播发送，所有终端接收到该SIP请求但仅有相应的目标设备能够在响应中携带正确的认证回应并得到后续SIP服务器的服务。

前面的描述，发送SIP请求的设备为网络设备，接收SIP请求的设备为用户终端，但本发明的应用并不限于此，例如，通信是在两个SIP终端间发生时(常见于Internet应用)，发送SIP请求的终端同样可以采用本发明认证接收SIP请求的终端的身份的真实性，其认证过程与上述同理，不再赘述。

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

Claims (12)

1、一种对接收初始会话协议(SIP)请求消息的设备进行认证的方法，其特征在于，包括如下步骤：

发送SIP请求的设备针对接收SIP请求消息的目标设备生成认证挑战，并向目标设备下发携带该认证挑战的SIP请求消息；

所述目标设备根据用户密钥和所述认证挑战中的相关参数生成认证回应，并通过对请求的响应消息传送到所述发送SIP请求的设备；

发送SIP请求的设备验证所述认证回应，以确定目标设备身份的真实性。

2、如权利要求1所述的方法，其特征在于，若目标设备身份真实性验证通过，则进行后续业务流程；若目标设备真实性验证失败，则发送SIP请求的设备立即终止后续业务流程，或发起SIP请求的设备重新向目标设备下发携带认证挑战的SIP请求消息对目标设备身份进行验证，直到验证失败的次数超过设定的次数后终止后续业务流程。

3、如权利要求2所述的方法，其特征在于，所述接收SIP请求的目标设备在回送认证回应时，可进一步携带相关参数，以认证发送SIP请求的设备的身份。

4、如权利要求3所述的方法，其特征在于，在目标设备身份真实性验证通过后，发送SIP请求的设备根据认证回应中携带的所述相关参数，在后续发送给所述目标设备的请求消息中携带相应的认证信息，由目标设备对该认证信息进行验证，由此确认发送SIP请求的设备的身份真实性。

5、如权利要求4所述的方法，其特征在于，目标设备在所述认证信息未通过验证时主动终止后续业务流程。

6、如权利要求2或5所述的方法，其特征在于，在终止后续业务流程时，若认证过程中已建立对话，则通过发送对话释放消息以结束该对话。

7、如权利要求1所述的方法，其特征在于，目标设备在针对SIP请求消息所返回的最终响应消息中携带所述认证回应；或者，目标设备在所返回的可靠传送的临时响应消息中携带所述认证回应。

8、如权利要求1所述的方法，其特征在于，发送SIP请求的设备利用摘要(Digest)认证算法生成所述认证挑战，所述目标设备利用摘要(Digest)认证算法生成认证回应；发送SIP请求的设备依据摘要(Digest)认证算法对认证回应进行验证。

9、如权利要求8所述的方法，其特征在于，通过SIP请求消息中的WWW-Authenticate头域携带认证挑战，通过SIP响应消息中的Authorization头域携带认证回应。

10、如权利要求8所述的方法，其特征在于，利用Digest认证算法生成A2时，以参数digest-uri-value和参数Method为空字符串作为输入，或以参数digest-uri-value为空字符串和以SIP请求消息中相应的参数Method作为输入计算参数A2。

11、如权利要求4所述的方法，其特征在于，发送SIP请求的设备根据认证回应中的相关参数，利用Digest认证算法生成认证信息，并通过后续发送给所述目标设备的请求消息中的Authentication-Info头域携带该认证信息，目标设备利用Digest认证算法对认证信息进行验证。

12、如权利要求1所述的方法，其特征在于，发送SIP请求的设备可为网络设备，也可为用户终端设备。

Images