專(zhuān)利名稱(chēng)：對(duì)接收初始會(huì)話協(xié)議請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信網(wǎng)絡(luò)中的認(rèn)證技術(shù)，尤其一種對(duì)接收初始會(huì)話協(xié)議(SIP)請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的方法。
背景技術(shù)：
在RFC3261中規(guī)定了在初始會(huì)話協(xié)議(SIP協(xié)議)中采用摘要(Digest)認(rèn)證方法對(duì)SIP用戶(hù)身份進(jìn)行認(rèn)證鑒定。Digest認(rèn)證方法也是超文本傳輸協(xié)議(HTTP協(xié)議)中的認(rèn)證架構(gòu)所采用的認(rèn)證方法(由RFC2617所定義)。通過(guò)Digest認(rèn)證方法可驗(yàn)證發(fā)起請(qǐng)求的用戶(hù)的真實(shí)性，當(dāng)用戶(hù)的真實(shí)性得到確認(rèn)后，網(wǎng)絡(luò)決定是否為該用戶(hù)的請(qǐng)求提供相應(yīng)服務(wù)。但Digest認(rèn)證并不能解決所有安全問(wèn)題，例如，此方法并不能對(duì)傳送的消息內(nèi)容進(jìn)行加密。
參閱圖1所示，在SIP協(xié)議中對(duì)用戶(hù)注冊(cè)的認(rèn)證過(guò)程如下網(wǎng)絡(luò)設(shè)備有數(shù)字證書(shū)，終端開(kāi)機(jī)后先與網(wǎng)絡(luò)設(shè)備建立TLS連接，然后按下述步驟進(jìn)行注冊(cè)步驟1、終端向網(wǎng)絡(luò)設(shè)備發(fā)送REGISTER注冊(cè)請(qǐng)求消息。
步驟2、網(wǎng)絡(luò)設(shè)備生成“認(rèn)證挑戰(zhàn)”并在401響應(yīng)的WWW-Authenticate頭域中下發(fā)給終端。
步驟3、終端生成“認(rèn)證回應(yīng)”并在第二個(gè)REGISTER請(qǐng)求的Authorization頭域中攜帶給網(wǎng)絡(luò)設(shè)備。
步驟4、網(wǎng)絡(luò)設(shè)備依據(jù)“認(rèn)證回應(yīng)”的內(nèi)容，對(duì)終端的用戶(hù)身份認(rèn)證通過(guò)后，對(duì)REGISTER請(qǐng)求回送200響應(yīng)表明注冊(cè)成功。
至此，用戶(hù)的身份得到網(wǎng)絡(luò)設(shè)備的認(rèn)證，并且用戶(hù)終端與網(wǎng)絡(luò)設(shè)備間建立了用于保證后續(xù)兩者間通信安全的TLS安全通道(安全通道可在注冊(cè)前建立，也可在注冊(cè)過(guò)程中建立，例如3GPP IMS，在用戶(hù)注冊(cè)過(guò)程中，UE與P-CSCF間建立IPSec安全通道)。
步驟5-7，后續(xù)當(dāng)終端作為主叫發(fā)起呼叫請(qǐng)求時(shí)，網(wǎng)絡(luò)設(shè)備可不再認(rèn)證該終端，因?yàn)橐雅c該終端建立了TLS安全通道。
步驟8-10，后續(xù)當(dāng)終端作為被叫接收呼叫請(qǐng)求時(shí)，網(wǎng)絡(luò)設(shè)備也直接將相應(yīng)的INVITE請(qǐng)求通過(guò)與該終端已建立的TLS安全通道傳送給被叫終端。
實(shí)際的SIP應(yīng)用中，用戶(hù)終端有可能僅支持Digest認(rèn)證而不支持TLS等安全通道的建立。這種情況下，除了對(duì)用戶(hù)的注冊(cè)請(qǐng)求進(jìn)行Digest認(rèn)證外，也對(duì)后續(xù)的用戶(hù)會(huì)話建立請(qǐng)求，甚至是每一條用戶(hù)發(fā)起的請(qǐng)求消息，進(jìn)行Digest認(rèn)證，如圖2所示，其流程簡(jiǎn)述如下步驟1-4，對(duì)用戶(hù)的注冊(cè)請(qǐng)求，網(wǎng)絡(luò)通過(guò)401帶下對(duì)終端的“認(rèn)證挑戰(zhàn)”。終端在消息3REGISTIER帶回“認(rèn)證回應(yīng)”。網(wǎng)絡(luò)收到“認(rèn)證回應(yīng)”的內(nèi)容，經(jīng)Digest計(jì)算后驗(yàn)證了用戶(hù)的身份。用戶(hù)注冊(cè)成功。
步驟5-10，后續(xù)用戶(hù)發(fā)起呼叫請(qǐng)求INVITE時(shí)，由于沒(méi)有在網(wǎng)絡(luò)設(shè)備與終端間已建立安全通道，網(wǎng)絡(luò)設(shè)備再次對(duì)INVITE請(qǐng)求進(jìn)行認(rèn)證，在401響應(yīng)中下發(fā)“認(rèn)證挑戰(zhàn)”，用戶(hù)在步驟8中的INVITE請(qǐng)求中攜帶認(rèn)證回應(yīng)，網(wǎng)絡(luò)設(shè)備認(rèn)證通過(guò)后，處理該INVITE請(qǐng)求，提供相應(yīng)服務(wù)。
在RFC3261中，規(guī)定了相關(guān)認(rèn)證頭域只能在特定消息中攜帶。例如，攜帶認(rèn)證挑戰(zhàn)的WWW-Authenticate頭域僅能在響應(yīng)消息401/407中出現(xiàn)，而攜帶認(rèn)證回應(yīng)的Authorization頭域僅能在SIP請(qǐng)求消息中出現(xiàn)，這就限定了Digest認(rèn)證僅能應(yīng)用于對(duì)發(fā)送SIP請(qǐng)求的設(shè)備進(jìn)行身份認(rèn)證。因此，當(dāng)用戶(hù)終端僅支持Digest認(rèn)證而不支持TLS安全通道的建立時(shí)，現(xiàn)有技術(shù)方案僅針對(duì)發(fā)起請(qǐng)求的用戶(hù)進(jìn)行認(rèn)證，而不能對(duì)接收SIP請(qǐng)求的用戶(hù)進(jìn)行認(rèn)證。
由于當(dāng)前Digest認(rèn)證在SIP的應(yīng)用，不能針對(duì)接收SIP請(qǐng)求消息的設(shè)備進(jìn)行身份認(rèn)證，因此，就可能會(huì)存在安全漏洞。這是因?yàn)橛脩?hù)在網(wǎng)絡(luò)設(shè)備注冊(cè)成功后，該用戶(hù)標(biāo)識(shí)與相應(yīng)的用戶(hù)終端的聯(lián)系地址(IP地址)的對(duì)應(yīng)關(guān)系被保存在網(wǎng)絡(luò)設(shè)備。當(dāng)網(wǎng)絡(luò)設(shè)備接收到發(fā)往該用戶(hù)的SIP請(qǐng)求(例如該用戶(hù)作為被叫方)，若用戶(hù)終端與網(wǎng)絡(luò)設(shè)備間建有TLS安全通道時(shí)，網(wǎng)絡(luò)設(shè)備會(huì)基于已建立的TLS通道，向終端發(fā)送相應(yīng)SIP請(qǐng)求。若用戶(hù)終端與網(wǎng)絡(luò)設(shè)備間沒(méi)有建立安全通道，網(wǎng)絡(luò)設(shè)備僅依據(jù)先前注冊(cè)的用戶(hù)終端聯(lián)系地址，將相應(yīng)SIP請(qǐng)求發(fā)往對(duì)應(yīng)的IP地址，此時(shí)若被叫終端的IP地址被攻擊者仿冒，攻擊者則接收到相應(yīng)的SIP請(qǐng)求。

發(fā)明內(nèi)容
本發(fā)明提供一種對(duì)接收SIP請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的方法，以解決現(xiàn)有技術(shù)中存在不能針對(duì)接收SIP請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的問(wèn)題。
為解決上述問(wèn)題，本發(fā)明提供以下技術(shù)方案一種對(duì)接收SIP請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的方法，包括如下步驟發(fā)送SIP請(qǐng)求的設(shè)備針對(duì)接收SIP請(qǐng)求消息的目標(biāo)設(shè)備生成認(rèn)證挑戰(zhàn)，并向目標(biāo)設(shè)備下發(fā)攜帶該認(rèn)證挑戰(zhàn)的SIP請(qǐng)求消息；所述目標(biāo)設(shè)備根據(jù)用戶(hù)密鑰和所述認(rèn)證挑戰(zhàn)中的相關(guān)參數(shù)生成認(rèn)證回應(yīng)，并通過(guò)對(duì)請(qǐng)求的響應(yīng)消息傳送到所述發(fā)送SIP請(qǐng)求的設(shè)備；發(fā)送SIP請(qǐng)求的設(shè)備根據(jù)保存的用戶(hù)密鑰驗(yàn)證所述認(rèn)證回應(yīng)，以確定目標(biāo)設(shè)備身份的真實(shí)性。
其中若目標(biāo)設(shè)備身份真實(shí)性驗(yàn)證通過(guò)，則進(jìn)行后續(xù)業(yè)務(wù)流程；若目標(biāo)設(shè)備真實(shí)性驗(yàn)證失敗，則發(fā)送SIP請(qǐng)求的設(shè)備立即終止后續(xù)業(yè)務(wù)流程，或發(fā)起SIP請(qǐng)求的設(shè)備重新向目標(biāo)設(shè)備下發(fā)攜帶認(rèn)證挑戰(zhàn)的SIP請(qǐng)求消息對(duì)目標(biāo)設(shè)備身份進(jìn)行驗(yàn)證，直到驗(yàn)證失敗的次數(shù)超過(guò)設(shè)定的次數(shù)后終止后續(xù)業(yè)務(wù)流程。
所述接收SIP請(qǐng)求的目標(biāo)設(shè)備在回送認(rèn)證回應(yīng)時(shí)，可進(jìn)一步攜帶相關(guān)參數(shù)，以認(rèn)證發(fā)送SIP請(qǐng)求的設(shè)備的身份。
在目標(biāo)設(shè)備身份真實(shí)性驗(yàn)證通過(guò)后，發(fā)送SIP請(qǐng)求的設(shè)備根據(jù)認(rèn)證回應(yīng)中攜帶的所述相關(guān)參數(shù)，在后續(xù)發(fā)送給所述目標(biāo)設(shè)備的請(qǐng)求消息中攜帶相應(yīng)的認(rèn)證信息，由目標(biāo)設(shè)備對(duì)該認(rèn)證信息進(jìn)行驗(yàn)證。
目標(biāo)設(shè)備在所述認(rèn)證信息未通過(guò)驗(yàn)證時(shí)主動(dòng)終止后續(xù)業(yè)務(wù)流程。
在終止后續(xù)業(yè)務(wù)流程時(shí)，若認(rèn)證過(guò)程中已建立對(duì)話，則通過(guò)發(fā)送對(duì)話釋放消息以結(jié)束該對(duì)話。
目標(biāo)設(shè)備在針對(duì)SIP請(qǐng)求消息所返回的最終響應(yīng)消息中攜帶所述認(rèn)證回應(yīng)；或者，目標(biāo)設(shè)備在所返回的可靠傳送的臨時(shí)響應(yīng)消息中攜帶所述認(rèn)證回應(yīng)。
發(fā)送SIP請(qǐng)求的設(shè)備利用摘要(Digest)認(rèn)證算法生成所述認(rèn)證挑戰(zhàn)，所述目標(biāo)設(shè)備利用摘要(Digest)認(rèn)證算法生成認(rèn)證回應(yīng)；發(fā)送SIP請(qǐng)求的設(shè)備依據(jù)摘要(Digest)認(rèn)證算法對(duì)認(rèn)證回應(yīng)進(jìn)行驗(yàn)證。
本發(fā)明通過(guò)在發(fā)送給目標(biāo)設(shè)備的SIP請(qǐng)求消息中攜帶認(rèn)證挑戰(zhàn)和在相應(yīng)的SIP響應(yīng)消息攜帶認(rèn)證回應(yīng)實(shí)現(xiàn)對(duì)目標(biāo)設(shè)備的認(rèn)證。當(dāng)用戶(hù)注冊(cè)過(guò)程中終端沒(méi)有與網(wǎng)絡(luò)設(shè)備建立安全通道，網(wǎng)絡(luò)設(shè)備向終端發(fā)送SIP請(qǐng)求時(shí)，可采用本發(fā)明保證接收SIP請(qǐng)求的終端的身份的真實(shí)性。從而保證在未建立安全通道情況下的通信安全。此外，本發(fā)明作為一種通用的認(rèn)證消息接收方身份的方法，可應(yīng)用在很多SIP應(yīng)用場(chǎng)合，是對(duì)SIP協(xié)議應(yīng)用的一種擴(kuò)展。


圖1為現(xiàn)有的SIP協(xié)議中對(duì)用戶(hù)注冊(cè)的認(rèn)證流程；圖2為對(duì)每一條用戶(hù)發(fā)起的請(qǐng)求消息進(jìn)行Digest認(rèn)證的流程圖；圖3、圖4A、圖4B為本發(fā)明中對(duì)接收SIP請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的流程圖；圖5、圖6為發(fā)送SIP請(qǐng)求消息的設(shè)備與接收SIP請(qǐng)求消息的設(shè)備之間進(jìn)行雙向認(rèn)證的流程圖；圖7A、圖7B為本發(fā)明分別應(yīng)用于多播方式和網(wǎng)絡(luò)地址轉(zhuǎn)換方式的示意圖。
具體實(shí)施例方式
摘要(Digest)認(rèn)證以“challenge-response”的基本方式完成，本發(fā)明中相應(yīng)的稱(chēng)為“認(rèn)證挑戰(zhàn)-認(rèn)證回應(yīng)”。本發(fā)明中，發(fā)送SIP請(qǐng)求消息的設(shè)備通過(guò)WWW-Authenticate頭域攜帶“認(rèn)證挑戰(zhàn)”信息給接收SIP請(qǐng)求消息的設(shè)備，接收SIP請(qǐng)求消息的設(shè)備通過(guò)Authorization頭域攜帶“認(rèn)證回應(yīng)”信息給發(fā)送SIP請(qǐng)求消息的設(shè)備，發(fā)送SIP請(qǐng)求消息的設(shè)備據(jù)此認(rèn)證用戶(hù)身份的真實(shí)性。發(fā)送SIP請(qǐng)求消息的設(shè)備可以是用戶(hù)終端設(shè)備，也可以是網(wǎng)絡(luò)設(shè)備。在SIP應(yīng)用中，認(rèn)證方(在本發(fā)明中是發(fā)送SIP請(qǐng)求消息的設(shè)備)通常是網(wǎng)絡(luò)設(shè)備，被認(rèn)證方通常是用戶(hù)終端，下面的描述以此為例來(lái)說(shuō)明。
為了能夠清楚的描述本發(fā)明的具體實(shí)現(xiàn)，先分別介紹現(xiàn)有技術(shù)中“認(rèn)證挑戰(zhàn)”和“認(rèn)證回應(yīng)”中的主要參數(shù)WWW-AuthenticateDigestrealm＝″biloxi.com″，qop＝″auth，auth-int″，nonce＝″dcd98b7102dd2f0e8blld0f600bfb0c093″，opaque＝″5ccc069c403ebaf9f0171e9517f40e41″。
“realm”參數(shù)向用戶(hù)終端表明其當(dāng)前正接受來(lái)自哪個(gè)“域”的認(rèn)證，終端可向用戶(hù)顯示此信息，提示用戶(hù)應(yīng)該輸入的相應(yīng)帳號(hào)(包括用戶(hù)名和密碼]。用戶(hù)在不同的域可能有不同的用戶(hù)帳號(hào)。
“qop”，即quality of protection。此參數(shù)的值為“auth”，表明僅做用戶(hù)認(rèn)證。為“auth-int”，指示同時(shí)做用戶(hù)認(rèn)證和消息體完整性保護(hù)。當(dāng)進(jìn)行消息體的完整性保護(hù)時(shí)，生成“response”參數(shù)的算法加上消息體為輸入?yún)?shù)之一，與沒(méi)有完整性保護(hù)時(shí)算法不一樣。上例，qop＝″auth，auth-int″，表明網(wǎng)絡(luò)側(cè)同時(shí)支持這兩種方式。(由于RFC2069中沒(méi)有使用此參數(shù)，為了后向兼容RFC2069，“qop”參數(shù)是可選參數(shù)。
“nonce”，此參數(shù)由網(wǎng)絡(luò)側(cè)產(chǎn)生(與網(wǎng)絡(luò)側(cè)本地時(shí)間關(guān)聯(lián))。用戶(hù)終端在發(fā)回的Authorization認(rèn)證回應(yīng)頭域中，將nonce的內(nèi)容原封不動(dòng)的帶回，這樣網(wǎng)絡(luò)側(cè)可以根據(jù)此nonce中的內(nèi)容得知當(dāng)時(shí)生成此nonce參數(shù)的時(shí)間(即發(fā)送WWW-Authenticate認(rèn)證挑戰(zhàn)的時(shí)間)，與當(dāng)前收到Authorization的時(shí)間相比較，如果兩個(gè)時(shí)間相差過(guò)大，表明受到“重放”攻擊。
stale，若為T(mén)RUE，表示客戶(hù)端的前一個(gè)請(qǐng)求被拒絕的原因是因?yàn)榻?jīng)過(guò)網(wǎng)絡(luò)側(cè)的檢查，發(fā)現(xiàn)此請(qǐng)求中nonce中所帶的time-stamp信息比較老，這樣，客戶(hù)端在收到此WWW-Authenticate后，將會(huì)利用其中的新的nonce，自動(dòng)重新產(chǎn)生一個(gè)新的Authorization，而無(wú)需提示用戶(hù)輸入帳號(hào)。若為FALSE或其它值，則需要提示用戶(hù)輸入用戶(hù)帳號(hào)。
用戶(hù)終端根據(jù)用戶(hù)帳號(hào)及收到的WWW-Authenticate內(nèi)容產(chǎn)生Authorization頭域AuthorizationDigest usemame＝″bob″，realm＝″biloxi.com″，nonce＝″dcd98b7102dd2f0e8b11d0f600bfb0c093″，uri＝″sipbob@biloxi.com″，qop＝auth，nc＝00000001，cnonce＝″0a4fl13b″，response＝″6629fae49393a05397450978507c4efl″，opaque＝″5ccc069c403ebaf9f0171e9517f40e41″“uri”，攜帶request-uri中的內(nèi)容，之所以要以參數(shù)形式攜帶，是因?yàn)檎?qǐng)求消息中的request-uri內(nèi)容在傳送過(guò)程中可能被PROXY修改。此參數(shù)是生成“response”參數(shù)的輸入之一。
“qop”，上例中為“auth”，表明終端沒(méi)有使用消息體完整性保護(hù)的擴(kuò)展功能。
“nc”，表明這是第幾次使用同一個(gè)“nonce”生成認(rèn)證回應(yīng)。網(wǎng)絡(luò)側(cè)會(huì)維護(hù)一個(gè)nonce counter計(jì)數(shù)器，當(dāng)網(wǎng)絡(luò)收到同一個(gè)nc-value兩次或以上，表明受到了“replay”方式的攻擊。
“cnonce”，終端生成的nounce，在Authentication-Info頭域中被帶回，用于終端對(duì)網(wǎng)絡(luò)的認(rèn)證。
“response”，最重要的參數(shù)。終端根據(jù)用戶(hù)名、用戶(hù)密碼、realm-value、nonce、uri等值進(jìn)行計(jì)算得到的數(shù)據(jù)。網(wǎng)絡(luò)側(cè)也有這些輸入數(shù)據(jù)，因此采用相同的算法得到一串?dāng)?shù)據(jù)后，相比較，如相等，可證明用戶(hù)的密碼正確，以此證明用戶(hù)的身份。
生成response參數(shù)的算法如下，詳細(xì)內(nèi)容參見(jiàn)RFC2617第“3.2.2.1-3.2.2.3”節(jié)。
request-digest＝<″><KD(H(A1)，unq(nonce-value)″″nc-value″″unq(cnonce-value)″″unq(qop-value)″″H(A2))<″>
其中A1與A2的計(jì)算分別如下A1＝unq(username-value)″″unq(realm-value)″″passwdA2＝Method″″digest-uri-value除“WWW-Authenticate”和“Authorization”兩個(gè)基本頭域，RFC2617還新定義了Authentication-Info頭域，此頭域在終端認(rèn)證成功響應(yīng)中被攜帶給終端，傳達(dá)附加的認(rèn)證相關(guān)信息。此頭域在RFC2069中是不存在的，是RFC2617定義的一個(gè)擴(kuò)展。具體參數(shù)如下Authentication-Infoqop＝auth，rspauth＝″6629fae49393a05397450978507c4efl″，cnonce＝″0a4fl13b″，nc＝00000001
“qop”，表明認(rèn)證類(lèi)型(是否需要進(jìn)行消息體保護(hù))，同前描述。
“rspauth”，用于網(wǎng)絡(luò)向終端表明自己知道終端密碼。終端接收到此參數(shù)后，通過(guò)計(jì)算，如果計(jì)算結(jié)果與此參數(shù)的值相同，終端認(rèn)為網(wǎng)絡(luò)是可信的。此參數(shù)的計(jì)算與前面介紹“response”參數(shù)的計(jì)算方法基本相同。
“cnonce”，網(wǎng)絡(luò)將終端在Authorization頭域中攜帶的內(nèi)容通過(guò)此參數(shù)原樣返回給終端。
“nc”，nonce-count，表明這是第幾次使用同一個(gè)“nonce”生成認(rèn)證回應(yīng)。
除以上4個(gè)參數(shù)外，此頭域中可攜帶“nextnonce”參數(shù)，此參數(shù)包含的內(nèi)容是網(wǎng)絡(luò)希望終端在生成下一次認(rèn)證回應(yīng)中使用的nonce。網(wǎng)絡(luò)通過(guò)此參數(shù)，可實(shí)現(xiàn)一次性nonce或?qū)once值進(jìn)行改變。
參閱圖3所示，為了實(shí)現(xiàn)對(duì)接收SIP請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證，發(fā)起認(rèn)證的網(wǎng)絡(luò)設(shè)備在向目標(biāo)設(shè)備發(fā)送SIP請(qǐng)求消息中攜帶WWW-Authenticate頭域，發(fā)起認(rèn)證挑戰(zhàn)；目標(biāo)設(shè)備接收到攜帶WWW-Authenticate頭域的請(qǐng)求消息后，生成相應(yīng)的認(rèn)證回應(yīng)，通過(guò)SIP響應(yīng)消息在Authorization頭域中將認(rèn)證回應(yīng)攜帶給發(fā)起認(rèn)證的設(shè)備。發(fā)起認(rèn)證的設(shè)備依據(jù)收到的Authorization頭域，可對(duì)接收SIP請(qǐng)求消息的設(shè)備的身份進(jìn)行認(rèn)證，確切的知道該SIP請(qǐng)求消息的接收者的身份是否合法(接收者是否知道正確的用戶(hù)密碼)。
認(rèn)證挑戰(zhàn)和認(rèn)證回應(yīng)的生成采用現(xiàn)有Digest認(rèn)證中生成方法，只是計(jì)算A2有所不同。因?yàn)锳2的計(jì)算需要uti參數(shù)作為輸入，即A2＝Method ″″digest-uri-value?，F(xiàn)有Digest認(rèn)證方案，認(rèn)證回應(yīng)在請(qǐng)求消息攜帶，認(rèn)證回應(yīng)中uri參數(shù)對(duì)應(yīng)相應(yīng)請(qǐng)求消息的Request-URI，計(jì)算A2時(shí)，請(qǐng)求消息的Method以及Request-URI作為輸入?yún)?shù)，這樣可保護(hù)請(qǐng)求消息中的這兩個(gè)域不被第三方修改。而本發(fā)明中，認(rèn)證回應(yīng)在響應(yīng)消息中攜帶，終端計(jì)算Authorization頭域的response參數(shù)時(shí)，計(jì)算公式與現(xiàn)有的計(jì)算Authorization頭域的response參數(shù)的計(jì)算公式相同，但具體在計(jì)算A2時(shí)，由于響應(yīng)消息中沒(méi)有對(duì)應(yīng)的“Method”及“Request-URI”，因此本發(fā)明中約定，計(jì)算A2的公式為A2＝″″，其中，原先的digest-uri-value和Method在這里都是空字符串?；蛘?，A2＝Method″″，其中Method參數(shù)為終端接收到的SIP請(qǐng)求中的相應(yīng)Method。當(dāng)然計(jì)算A2參數(shù)時(shí)也可以采取其他方式。
在本發(fā)明，當(dāng)發(fā)起認(rèn)證的網(wǎng)絡(luò)設(shè)備接收到目標(biāo)設(shè)備在響應(yīng)消息中攜帶的認(rèn)證回應(yīng)后，如果對(duì)接收請(qǐng)求消息的設(shè)備認(rèn)證通過(guò)，則繼續(xù)業(yè)務(wù)流程。如對(duì)接收請(qǐng)求消息的設(shè)備認(rèn)證沒(méi)有通過(guò)，則發(fā)起認(rèn)證的網(wǎng)絡(luò)設(shè)備可終止后續(xù)業(yè)務(wù)流程，具體如何終止后續(xù)業(yè)務(wù)流程，與網(wǎng)絡(luò)設(shè)備發(fā)給用戶(hù)終端的請(qǐng)求消息相關(guān)。
如網(wǎng)絡(luò)設(shè)備發(fā)給用戶(hù)終端的SIP請(qǐng)求已相應(yīng)地建立對(duì)話(Dialog)，則網(wǎng)絡(luò)設(shè)備可以將Dialog釋放以終止后續(xù)的業(yè)務(wù)流程。建立Dialog的SIP請(qǐng)求有INVITE，或SUBSCRIBE等。
參閱圖4A所示，對(duì)接收SIP請(qǐng)求消息的設(shè)備認(rèn)證成功的流程如下步驟1-3，SIP服務(wù)器對(duì)主叫終端1發(fā)起的呼叫請(qǐng)求進(jìn)行Digest認(rèn)證，并在401響應(yīng)中下發(fā)認(rèn)證挑戰(zhàn)。
步驟4，主叫終端1將認(rèn)證回應(yīng)在INVITE中攜帶給SIP服務(wù)器，SIP服務(wù)器對(duì)主叫認(rèn)證成功。
步驟5-6，SIP服務(wù)器依據(jù)接收的INVITE尋找被叫，在發(fā)向被叫終端2的INVITE中，攜帶對(duì)被叫用戶(hù)的認(rèn)證挑戰(zhàn)頭域WWW-Authenticate。
當(dāng)用戶(hù)終端2接收消息INVITE后，可能向用戶(hù)提示輸入密碼，待用戶(hù)輸入密碼并確認(rèn)接收呼叫后，在200響應(yīng)中將認(rèn)證回應(yīng)傳給SIP服務(wù)器。或者用戶(hù)密碼已保存在用戶(hù)終端，而不需要向被叫用戶(hù)提示輸入密碼以接聽(tīng)入呼叫。
被叫用戶(hù)終端2除了可以在200響應(yīng)中攜帶認(rèn)證回應(yīng)外，也可在可靠傳送的臨時(shí)響應(yīng)中攜帶認(rèn)證回應(yīng)。
步驟7-9，SIP服務(wù)器接收被叫用戶(hù)的認(rèn)證回應(yīng)，認(rèn)證通過(guò)后，SIP服務(wù)器繼續(xù)后續(xù)的業(yè)務(wù)流程，將200響應(yīng)轉(zhuǎn)發(fā)給主叫終端1。主叫終端1回送ACK完成呼叫建立過(guò)程。
參閱圖4B所示，對(duì)接收請(qǐng)求消息的設(shè)備認(rèn)證失敗的流程如下
步驟1，主叫用戶(hù)終端l發(fā)起呼叫請(qǐng)求INVITE(這里省略了網(wǎng)絡(luò)設(shè)備可能對(duì)主叫的認(rèn)證過(guò)程)。
步驟2-4，SIP服務(wù)器依據(jù)接收的INVITE尋找被叫，在發(fā)向被叫終端2的INVITE中，攜帶對(duì)被叫用戶(hù)終端2的認(rèn)證挑戰(zhàn)頭域WWW-Authenticate，用戶(hù)終端2的認(rèn)證回應(yīng)頭域在200響應(yīng)中攜帶。SIP服務(wù)器依據(jù)終端2的認(rèn)證回應(yīng)判斷對(duì)被叫用戶(hù)終端2的認(rèn)證失敗。此時(shí)仍需要回送ACK以完成SIP的基本事務(wù)交互。
步驟5，由于對(duì)被叫終端2的認(rèn)證失敗，SIP服務(wù)器決定終止后續(xù)的業(yè)務(wù)流程，向被叫終端2發(fā)送BYE請(qǐng)求釋放呼叫。
步驟6，由于對(duì)被叫終端2的認(rèn)證失敗，SIP服務(wù)器決定終止后續(xù)的業(yè)務(wù)流程，向主叫終端1發(fā)送失敗響應(yīng)并攜帶相應(yīng)的頭域通知失敗原因。
當(dāng)被叫終端2采用在可靠臨時(shí)響應(yīng)中攜帶認(rèn)證回應(yīng)的方法時(shí)，SIP服務(wù)器終止同被叫終端2的業(yè)務(wù)流程的方法是發(fā)送CANCEL。
在認(rèn)證失敗的情況下，也可以不用立即終端后續(xù)流程，而是由發(fā)起認(rèn)證的網(wǎng)絡(luò)設(shè)備重新向目標(biāo)設(shè)備下發(fā)攜帶認(rèn)證挑戰(zhàn)的SIP請(qǐng)求消息進(jìn)行下一次驗(yàn)證，直到驗(yàn)證失敗的次數(shù)超過(guò)設(shè)定的次數(shù)后終止后續(xù)業(yè)務(wù)流程。這樣，可以避免用戶(hù)因偶然性的輸入錯(cuò)誤而終止后續(xù)業(yè)務(wù)流程的情況出現(xiàn)。
上述圖4A和圖4B的認(rèn)證流程應(yīng)用于IMS網(wǎng)絡(luò)時(shí)，由IMS網(wǎng)絡(luò)中的業(yè)務(wù)-呼叫會(huì)話控制功能(S-CSCF)實(shí)體代替SIP服務(wù)器，其實(shí)現(xiàn)過(guò)程與上述同理。
在對(duì)接收SIP請(qǐng)求的目標(biāo)設(shè)備進(jìn)行認(rèn)證的過(guò)程中，目標(biāo)設(shè)備在回送認(rèn)證回應(yīng)時(shí)可進(jìn)一步攜帶相關(guān)參數(shù)，以認(rèn)證發(fā)送SIP請(qǐng)求的設(shè)備的身份。在對(duì)接收SIP請(qǐng)求消息的設(shè)備認(rèn)證通過(guò)后，發(fā)送SIP請(qǐng)求的設(shè)備可以在后續(xù)發(fā)送給目標(biāo)設(shè)備的請(qǐng)求消息中攜帶認(rèn)證信息，由目標(biāo)設(shè)備對(duì)發(fā)送SIP請(qǐng)求的設(shè)備進(jìn)行認(rèn)證。
如圖5所示，當(dāng)發(fā)起認(rèn)證的網(wǎng)絡(luò)設(shè)備收到的SIP響應(yīng)消息中攜帶有“認(rèn)證回應(yīng)”Authorization頭域，其中有終端生成的參數(shù)“cnonce”，則網(wǎng)絡(luò)設(shè)備可以在后續(xù)發(fā)向終端的請(qǐng)求消息中攜帶Authentication-Info頭域，其中有“rspauth”參數(shù)，向終端表明網(wǎng)絡(luò)設(shè)備知道終端的密碼，終端接收到Authentication-Info后，依據(jù)自身計(jì)算的結(jié)果，檢查“rspauth”參數(shù)可判斷網(wǎng)絡(luò)設(shè)備是否知道自己的密碼，完成終端對(duì)網(wǎng)絡(luò)設(shè)備認(rèn)證的功能。
依據(jù)RFC2617的描述，“rspauth”參數(shù)的計(jì)算公式如下A2＝″″digest-uri-value在RFC2617中，Authentication-Info在響應(yīng)消息中攜帶，digest-uri-value為與該響應(yīng)消息對(duì)應(yīng)的請(qǐng)求消息中的Authorization頭域中的uri參數(shù)。本發(fā)明中Authentication-Info在請(qǐng)求消息中攜帶，因此本發(fā)明中，可在Authentication-Info中增加參數(shù)uri(與Authorization頭域中uri參數(shù)的含義相同)，在計(jì)算A2時(shí)，digest-uri-value即為參數(shù)uri的值。或者，在計(jì)算A2時(shí)，認(rèn)為digest-uri-value為空字符串。當(dāng)然，也可以采用他方法計(jì)算A2。
如圖6所示，在步驟1，網(wǎng)絡(luò)設(shè)備向終端發(fā)送攜帶認(rèn)證挑戰(zhàn)的NOTIFY請(qǐng)求消息；在步驟2，終端回應(yīng)401響應(yīng)消息并攜帶Authorization頭域，其中包含cnounce參數(shù)。網(wǎng)絡(luò)設(shè)備對(duì)終端的認(rèn)證成功，因響應(yīng)消息為401響應(yīng)消息，終端也要認(rèn)證網(wǎng)絡(luò)設(shè)備；在步驟3，網(wǎng)絡(luò)設(shè)備在NOTIFY消息中攜帶Authentication-Info頭域；在步驟4，終端對(duì)網(wǎng)絡(luò)進(jìn)行認(rèn)證，認(rèn)證成功后回送200響應(yīng)消息。
以上實(shí)施例為本發(fā)明的一種應(yīng)用情況，類(lèi)似的SIP應(yīng)用還有很多，如圖7A所示，一個(gè)IP網(wǎng)內(nèi)包括網(wǎng)絡(luò)設(shè)備和多個(gè)SIP終端，這些終端沒(méi)有注冊(cè)于網(wǎng)絡(luò)設(shè)備，當(dāng)網(wǎng)絡(luò)設(shè)備要向某個(gè)終端發(fā)送SIP請(qǐng)求時(shí)，采用IP多播的方式，并依據(jù)本發(fā)明在SIP請(qǐng)求消息中攜帶認(rèn)證挑戰(zhàn)，該IP網(wǎng)內(nèi)所有終端都將接收到該請(qǐng)求，但只有某個(gè)終端才能夠在相應(yīng)的響應(yīng)消息中攜帶正確的認(rèn)證回應(yīng)并得到網(wǎng)絡(luò)設(shè)備的后續(xù)服務(wù)。如圖7B所示，IP私網(wǎng)內(nèi)的多個(gè)終端通過(guò)NAT與SIP服務(wù)器通信，由于NAT的存在，SIP服務(wù)器不知道終端的私網(wǎng)地址，當(dāng)SIP服務(wù)器發(fā)送SIP請(qǐng)求給終端時(shí)，攜帶認(rèn)證挑戰(zhàn)，由NAT在私網(wǎng)內(nèi)進(jìn)行IP多播發(fā)送，所有終端接收到該SIP請(qǐng)求但僅有相應(yīng)的目標(biāo)設(shè)備能夠在響應(yīng)中攜帶正確的認(rèn)證回應(yīng)并得到后續(xù)SIP服務(wù)器的服務(wù)。
前面的描述，發(fā)送SIP請(qǐng)求的設(shè)備為網(wǎng)絡(luò)設(shè)備，接收SIP請(qǐng)求的設(shè)備為用戶(hù)終端，但本發(fā)明的應(yīng)用并不限于此，例如，通信是在兩個(gè)SIP終端間發(fā)生時(shí)(常見(jiàn)于Internet應(yīng)用)，發(fā)送SIP請(qǐng)求的終端同樣可以采用本發(fā)明認(rèn)證接收SIP請(qǐng)求的終端的身份的真實(shí)性，其認(rèn)證過(guò)程與上述同理，不再贅述。
顯然，本領(lǐng)域的技術(shù)人員可以對(duì)本發(fā)明進(jìn)行各種改動(dòng)和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若對(duì)本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動(dòng)和變型在內(nèi)。
權(quán)利要求
1.一種對(duì)接收初始會(huì)話協(xié)議(SIP)請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的方法，其特征在于，包括如下步驟發(fā)送SIP請(qǐng)求的設(shè)備針對(duì)接收SIP請(qǐng)求消息的目標(biāo)設(shè)備生成認(rèn)證挑戰(zhàn)，并向目標(biāo)設(shè)備下發(fā)攜帶該認(rèn)證挑戰(zhàn)的SIP請(qǐng)求消息；所述目標(biāo)設(shè)備根據(jù)用戶(hù)密鑰和所述認(rèn)證挑戰(zhàn)中的相關(guān)參數(shù)生成認(rèn)證回應(yīng)，并通過(guò)對(duì)請(qǐng)求的響應(yīng)消息傳送到所述發(fā)送SIP請(qǐng)求的設(shè)備；發(fā)送SIP請(qǐng)求的設(shè)備驗(yàn)證所述認(rèn)證回應(yīng)，以確定目標(biāo)設(shè)備身份的真實(shí)性。
2.如權(quán)利要求1所述的方法，其特征在于，若目標(biāo)設(shè)備身份真實(shí)性驗(yàn)證通過(guò)，則進(jìn)行后續(xù)業(yè)務(wù)流程；若目標(biāo)設(shè)備真實(shí)性驗(yàn)證失敗，則發(fā)送SIP請(qǐng)求的設(shè)備立即終止后續(xù)業(yè)務(wù)流程，或發(fā)起SIP請(qǐng)求的設(shè)備重新向目標(biāo)設(shè)備下發(fā)攜帶認(rèn)證挑戰(zhàn)的SIP請(qǐng)求消息對(duì)目標(biāo)設(shè)備身份進(jìn)行驗(yàn)證，直到驗(yàn)證失敗的次數(shù)超過(guò)設(shè)定的次數(shù)后終止后續(xù)業(yè)務(wù)流程。
3.如權(quán)利要求2所述的方法，其特征在于，所述接收SIP請(qǐng)求的目標(biāo)設(shè)備在回送認(rèn)證回應(yīng)時(shí)，可進(jìn)一步攜帶相關(guān)參數(shù)，以認(rèn)證發(fā)送SIP請(qǐng)求的設(shè)備的身份。
4.如權(quán)利要求3所述的方法，其特征在于，在目標(biāo)設(shè)備身份真實(shí)性驗(yàn)證通過(guò)后，發(fā)送SIP請(qǐng)求的設(shè)備根據(jù)認(rèn)證回應(yīng)中攜帶的所述相關(guān)參數(shù)，在后續(xù)發(fā)送給所述目標(biāo)設(shè)備的請(qǐng)求消息中攜帶相應(yīng)的認(rèn)證信息，由目標(biāo)設(shè)備對(duì)該認(rèn)證信息進(jìn)行驗(yàn)證，由此確認(rèn)發(fā)送SIP請(qǐng)求的設(shè)備的身份真實(shí)性。
5.如權(quán)利要求4所述的方法，其特征在于，目標(biāo)設(shè)備在所述認(rèn)證信息未通過(guò)驗(yàn)證時(shí)主動(dòng)終止后續(xù)業(yè)務(wù)流程。
6.如權(quán)利要求2或5所述的方法，其特征在于，在終止后續(xù)業(yè)務(wù)流程時(shí)，若認(rèn)證過(guò)程中已建立對(duì)話，則通過(guò)發(fā)送對(duì)話釋放消息以結(jié)束該對(duì)話。
7.如權(quán)利要求1所述的方法，其特征在于，目標(biāo)設(shè)備在針對(duì)SIP請(qǐng)求消息所返回的最終響應(yīng)消息中攜帶所述認(rèn)證回應(yīng)；或者，目標(biāo)設(shè)備在所返回的可靠傳送的臨時(shí)響應(yīng)消息中攜帶所述認(rèn)證回應(yīng)。
8.如權(quán)利要求1所述的方法，其特征在于，發(fā)送SIP請(qǐng)求的設(shè)備利用摘要(Digest)認(rèn)證算法生成所述認(rèn)證挑戰(zhàn)，所述目標(biāo)設(shè)備利用摘要(Digest)認(rèn)證算法生成認(rèn)證回應(yīng)；發(fā)送SIP請(qǐng)求的設(shè)備依據(jù)摘要(Digest)認(rèn)證算法對(duì)認(rèn)證回應(yīng)進(jìn)行驗(yàn)證。
9.如權(quán)利要求8所述的方法，其特征在于，通過(guò)SIP請(qǐng)求消息中的WWW-Authenticate頭域攜帶認(rèn)證挑戰(zhàn)，通過(guò)SIP響應(yīng)消息中的Authorization頭域攜帶認(rèn)證回應(yīng)。
10.如權(quán)利要求8所述的方法，其特征在于，利用Digest認(rèn)證算法生成A2時(shí)，以參數(shù)digest-uri-value和參數(shù)Method為空字符串作為輸入，或以參數(shù)digest-uri-value為空字符串和以SIP請(qǐng)求消息中相應(yīng)的參數(shù)Method作為輸入計(jì)算參數(shù)A2。
11.如權(quán)利要求4所述的方法，其特征在于，發(fā)送SIP請(qǐng)求的設(shè)備根據(jù)認(rèn)證回應(yīng)中的相關(guān)參數(shù)，利用Digest認(rèn)證算法生成認(rèn)證信息，并通過(guò)后續(xù)發(fā)送給所述目標(biāo)設(shè)備的請(qǐng)求消息中的Authentication-Info頭域攜帶該認(rèn)證信息，目標(biāo)設(shè)備利用Digest認(rèn)證算法對(duì)認(rèn)證信息進(jìn)行驗(yàn)證。
12.如權(quán)利要求1所述的方法，其特征在于，發(fā)送SIP請(qǐng)求的設(shè)備可為網(wǎng)絡(luò)設(shè)備，也可為用戶(hù)終端設(shè)備。
全文摘要
本發(fā)明公開(kāi)了一種對(duì)接收初始會(huì)話協(xié)議請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證的方法，以解決現(xiàn)有技術(shù)中不能針對(duì)接收SIP請(qǐng)求消息的設(shè)備進(jìn)行認(rèn)證而存在安全性差的問(wèn)題；其中，發(fā)送SIP請(qǐng)求的設(shè)備針對(duì)接收SIP請(qǐng)求消息的設(shè)備生成認(rèn)證挑戰(zhàn)，并向目標(biāo)設(shè)備下發(fā)攜帶該認(rèn)證挑戰(zhàn)的SIP請(qǐng)求消息；所述目標(biāo)設(shè)備根據(jù)用戶(hù)密鑰和所述認(rèn)證挑戰(zhàn)中的相關(guān)參數(shù)生成認(rèn)證回應(yīng)，并通過(guò)響應(yīng)消息傳送到所述發(fā)送SIP請(qǐng)求的設(shè)備；發(fā)送SIP請(qǐng)求的設(shè)備根據(jù)保存的用戶(hù)密鑰驗(yàn)證所述認(rèn)證回應(yīng)，以確定目標(biāo)設(shè)備身份的真實(shí)性。
文檔編號(hào)H04L9/32GK1889562SQ20051008006
公開(kāi)日2007年1月3日 申請(qǐng)日期2005年6月28日 優(yōu)先權(quán)日2005年6月28日
發(fā)明者文楷 申請(qǐng)人:華為技術(shù)有限公司