WO2007000115A1 - Procede d'authentification de dispositif recevant un message de demande sip - Google Patents

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带下对终端的 "认证挑战"。 终端在消息 3REGISTER带回 "认证回应"。 网络收到 "认证回应" 的内容， 经 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请求。 若用户终端与网络设备 间没有建立安全通道， 网络设备仅依据先前注册的用户终端联系地址， 将相 006 001479 应 SIP请求发往对庶的 IP地址，此时若被叫终端的 IP地址被攻击者仿冒，攻 击者则接收到相应的 SIP请求。 发明内容

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

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

一种对接收 SIP请求消息的设备进行认证的方法， 包括如下步骤： 发送 SIP请求的设备针对接收 SIP请求消息的目标设备生成认证挑战，并 向目标设备下发携带该认证挑战的 SIP请求消息；

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

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

其中-.

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

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

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

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

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

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

发送 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="dcd98b7102dd2f0e8b 11 d0f600bfb0c093

opaque=^M5ccc069c403 ebaf9f0171 e9517f40e41 "。

"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 username="bob",

realm="biloxi.com",

nonce="dcd98b7102dd2f0e8blld0f600bfb0c093",

uri="sip:bob@biloxi.com",

qop=auth₅

nc=00000001,

cnonce="0a4fll3b",

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 ( Al ), unq ( nonce-value )

"：" nc-value

":" unq ( cnonce-value )

":" unq ( qop-value )

":" H ( A2 )

) <">

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

Al= unq ( username-value ) ":" unq ( realm-value ) "：" passwd

A2= Method "：" digest-uri-value

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

Authentication-Info：

qop=auth,

rspauth="6629fae49393a05397450978507c4efl " ,

cnonce="0a4fll3b",

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的计算需要 uri参数作为输入， 即 A2 = Method "：" digest-uri-value。 现有 Digest认证方案， 认证回应在请求消息携带， 认证回应 中 uri参数对应相应请求消息的 Request-URI,计算 A2时，请求消息的 Method 以及 Request-URI作为输入参数，这样可保护请求消息中的这两个域不被第三 方修改。 而本发明中， 认证回应在响应消息中携带， 终端计算 Authorization 头 i或的 response参数时，计算公式与现有的计算 Authorization头； I或的 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 , 主叫用户终端 1发起呼叫请求 INVITE (这里省略了网络设备可 能对主叫的认证过程

步珮 2 - 4, SIP服务器依据接收的 INVITE寻找被叫， 在发向被叫终端 2 用户终端 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头域， 其中 包含 enounce参数。网络设备对终端的认证成功，因响应消息为 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

权利要求

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 )认证算法生成所述认证挑战， 所述 P)标设备利用摘要（ 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请求的设备可为 网络设备， 也可为用户终端设备。