專利名稱：會話初始協(xié)議認(rèn)證的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)安全技術(shù)領(lǐng)域，具體涉及一種會話初始協(xié)議認(rèn)證的方法。
背景技術(shù)：
隨著互聯(lián)網(wǎng)及下一代網(wǎng)絡(luò)的發(fā)展，其方便的接入、逐步提高的接入速度、易于擴展的特性、以及豐富的業(yè)務(wù)功能，受到了運營商及用戶的歡迎，但與此同時其安全性方面也逐步受到人們的關(guān)注。SIP(會話初始協(xié)議)協(xié)議作為下一代網(wǎng)絡(luò)的核心協(xié)議在安全性方面也面臨著同樣的問題，接入認(rèn)證是解決這一問題的方式之一，已有的SIP協(xié)議(RFC3261)提供了基本的接入認(rèn)證方式，即所謂的degist(摘要)認(rèn)證。
SIP協(xié)議具有簡單、擴展性好及與Internet應(yīng)用緊密結(jié)合的特點，僅用3條消息(INVITE、BYE和ACK)和4個頭域(To、From、Call-ID和Cseq)就能實現(xiàn)簡單的Internet電話。SIP中有客戶機和服務(wù)器之分?？蛻魴C是指為了向服務(wù)器發(fā)送請求而與服務(wù)器建立連接的應(yīng)用程序。B2B用戶代理(Back to Back User Agent)和代理(Proxy)中含有客戶機。服務(wù)器是用于向客戶機發(fā)出的請求提供服務(wù)并回送應(yīng)答的應(yīng)用程序。共有四類基本服務(wù)器1.B2B用戶代理服務(wù)器當(dāng)接到SIP請求時它聯(lián)系用戶，并代表用戶返回響應(yīng)。
2.代理服務(wù)器代表其它客戶機發(fā)起請求，既充當(dāng)服務(wù)器又充當(dāng)客戶機的媒介程序。在轉(zhuǎn)發(fā)請求之前，它可以改寫原請求消息中的內(nèi)容。
3.重定向服務(wù)器它接收SIP請求，并把請求中的原地址映射成零個或多個新地址，返回給客戶機。
4.注冊服務(wù)器它接收客戶機的注冊請求，完成用戶地址的注冊。用戶終端程序往往需要包括用戶代理客戶機和用戶代理服務(wù)器。
SIP的認(rèn)證過程是一個類似于HTTP(HyperText Transfer Protocol)的無狀態(tài)的基于Challenge(問詢)的機制(RFC2617)，基本思路是認(rèn)證的雙方共享用戶名和初始密碼。在認(rèn)證的過程中，認(rèn)證方向被認(rèn)證方發(fā)送Challenge，被認(rèn)證方在收到Challenge后，將用戶名和初始密碼經(jīng)過加密，形成一個字符串，傳遞給認(rèn)證方；認(rèn)證方將自己知道的用戶名和密碼通過同樣的方式進行加密，得到一個字符串，通過比較該字符串和被認(rèn)證方傳遞的字符串是否一致來判斷用戶的密碼是否正確。
在SIP中采用Digest Scheme(摘要機制)的認(rèn)證方式，具體流程如圖1所示。
對于UAS(服務(wù)器端)，如果需要認(rèn)證UAC(客戶端)，則必須發(fā)送401 Unauthorized響應(yīng)，401 Unauthorized響應(yīng)表示客戶試圖未經(jīng)授權(quán)訪問受密碼保護的資源或者客戶。401響應(yīng)中必須攜帶WWW-Authenticate頭域，UAC據(jù)此顯示用戶名字/密碼對話框，然后在填寫合適的Authorization頭后再次發(fā)出請求，在Authorization頭域中攜帶認(rèn)證信息。注冊服務(wù)器和重定向服務(wù)器也可以使用401響應(yīng)來進行認(rèn)證UAC。
對于Proxy(代理服務(wù)器)而言，如果要認(rèn)證UAC，則必須采用407Proxy Authentication Required響應(yīng)，407 Proxy Authentication Required類似于401，表示客戶必須先經(jīng)過代理服務(wù)器的授權(quán)，并必須在其中攜帶Proxy-Authenticate頭域。UAC可以再次發(fā)起請求，在Proxy-Authorization頭域中攜帶認(rèn)證信息。
當(dāng)UAC因為收到401或者407響應(yīng)而重新發(fā)起請求時，一般應(yīng)該使用和上一個請示求相同的Call-ID，F(xiàn)rom頭域和To頭域，但是Cseq頭域中的序數(shù)必須加一，即有相同Call-ID的請求必須擁有遞增的Cseq號。
該認(rèn)證方式只提供最基本的接入認(rèn)證功能，在網(wǎng)絡(luò)安全方面存在以下缺陷1、RFC3261中的基本Digest認(rèn)證機制只能對UAC的Request消息發(fā)起認(rèn)證，對401或者407響應(yīng)則沒有相應(yīng)的認(rèn)證機制，所以很容易導(dǎo)致對UAC發(fā)起Plain Text(明文)攻擊。
2、由于在RFC3261 Digest所有的認(rèn)證(只有對UAC的Request消息發(fā)起的認(rèn)證)過程中都使用了初始密鑰，所以容易被監(jiān)聽，分析(Authorization和Proxy-Authorization)頭域，而得出初始密鑰，容易導(dǎo)致字典攻擊。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一種會話初始協(xié)議認(rèn)證的方法，以提高網(wǎng)絡(luò)接入的安全性。
本發(fā)明的目的是通過以下技術(shù)方案實現(xiàn)的一種會話初始協(xié)議認(rèn)證的方法，包括A、客戶端發(fā)送不帶認(rèn)證信息的請求消息到服務(wù)器端，請求接入；B、所述服務(wù)器端收到所述請求消息后回送帶有服務(wù)器端的認(rèn)證交換信息及服務(wù)器端DH認(rèn)證響應(yīng)信息的響應(yīng)消息；C、所述客戶端對收到的響應(yīng)消息進行認(rèn)證，認(rèn)證通過后，發(fā)送帶有客戶端認(rèn)證信息的請求消息到服務(wù)器端；D、所述服務(wù)器端根據(jù)收到的請求消息對所述用戶進行認(rèn)證，并回送包含服務(wù)器端認(rèn)證信息的響應(yīng)消息；E、所述用戶根據(jù)收到的所述包含服務(wù)器端認(rèn)證信息的響應(yīng)消息驗證所述服務(wù)器端的合法性。
所述步驟B包括服務(wù)器端根據(jù)用戶名和初始密碼生成所述服務(wù)器端DH認(rèn)證響應(yīng)信息。
所述帶有客戶端認(rèn)證信息的請求消息包括可選的客戶端的認(rèn)證交換信息、客戶端DH認(rèn)證響應(yīng)信息。
所述步驟C包括C1、所述客戶端根據(jù)所述服務(wù)器端的認(rèn)證交換信息及本端的認(rèn)證交換信息獲取共享密鑰；C2、根據(jù)所述共享密鑰生成所述客戶端DH認(rèn)證響應(yīng)信息。
所述步驟D包括當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中不包括所述用戶的認(rèn)證交換信息時，所述服務(wù)器端使用用戶名和初始密碼對收到的請求消息進行認(rèn)證；當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中包括所述用戶的認(rèn)證交換信息時，所述服務(wù)器端根據(jù)所述用戶的認(rèn)證交換信息以及本端的認(rèn)證交換信息獲取共享密鑰，根據(jù)所述共享密鑰對收到的請求消息進行認(rèn)證。
所述步驟D還包括當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中不包括所述用戶的認(rèn)證交換信息時，根據(jù)所述用戶名和初始密碼生成所述服務(wù)器端DH認(rèn)證響應(yīng)信息；當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中包括所述用戶的認(rèn)證交換信息時，所述服務(wù)器端根據(jù)所述用戶的認(rèn)證交換信息以及本端的認(rèn)證交換信息獲取共享密鑰，根據(jù)所述共享密鑰生成服務(wù)器端DH認(rèn)證響應(yīng)信息。
所述包含服務(wù)器端認(rèn)證信息的響應(yīng)消息包括可選的DH認(rèn)證信息頭域。
所述DH認(rèn)證信息頭域包括服務(wù)器端的驗證信息。
所述方法還包括在所述客戶端和所述服務(wù)器端都獲取共享密鑰后，進行消息交互時，只使用所述共享密鑰對所述消息進行加密。
所述服務(wù)器端包括代理服務(wù)器、背靠背服務(wù)器、重定向服務(wù)器和注冊服務(wù)器。
由以上本發(fā)明提供的技術(shù)方案可以看出，本發(fā)明在現(xiàn)有SIP基本認(rèn)證基礎(chǔ)上，引入DH(Diffie-Hellman)算法，并對SIP頭域及字段進行擴展，使初始密鑰只在第一次交互中使用，在其他的認(rèn)證過程中使用共享密鑰，使初始密鑰得到了充分的保護，可以有效地防止字典攻擊；同時，當(dāng)任何一方重啟后或者希望更換共享密碼時，也可以重新啟用校驗初始密碼的方式，通過使用認(rèn)證次數(shù)計數(shù)器，有效地防止向UAS或者Proxy的replay(重發(fā))攻擊。利用本發(fā)明，可以大大提高網(wǎng)絡(luò)的安全性。


圖1是現(xiàn)有技術(shù)中SIP的認(rèn)證流程；圖2是本發(fā)明會話初始協(xié)議認(rèn)證的方法的流程圖；圖3是本發(fā)明方法中用戶接入時的消息流程圖。
具體實施例方式
本發(fā)明的核心在于在現(xiàn)有SIP基本認(rèn)證基礎(chǔ)上，引入DH算法，并對SIP頭域及字段進行擴展，不僅對用戶的請求消息發(fā)起認(rèn)證，而且對服務(wù)器端的響應(yīng)消息也提供相應(yīng)的認(rèn)證機制，以便有效地防止對用戶發(fā)起的Plain Text；同時，在本發(fā)明方法中，初始密碼只在第一次交互中使用，后續(xù)的認(rèn)證過程都通過共享密碼來加密，以便有效地防止字典攻擊，而且，當(dāng)任何一方重啟后或者希望更換共享密碼時，也可以重新啟用校驗密碼的方式，以便有效地防止replay攻擊和兼容異常情況。
為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明，下面結(jié)合附圖和實施方式對本發(fā)明作進一步的詳細(xì)說明。
參照圖2，圖2是本發(fā)明方法的詳細(xì)流程，包括以下步驟步驟201客戶端發(fā)送不帶認(rèn)證信息的請求消息到服務(wù)器端，請求接入。所述服務(wù)器端包括代理服務(wù)器、背靠背服務(wù)器、重定向服務(wù)器和注冊服務(wù)器。
步驟202服務(wù)器端收到所述請求消息后根據(jù)用戶名和初始密碼生成服務(wù)器端DH認(rèn)證響應(yīng)信息。
步驟203向客戶端回送帶有服務(wù)器端的認(rèn)證交換信息及服務(wù)器端DH認(rèn)證響應(yīng)信息的響應(yīng)消息。
步驟204客戶端根據(jù)服務(wù)器端的認(rèn)證交換信息及本端的認(rèn)證交換信息獲取共享密鑰。
步驟205根據(jù)所述共享密鑰生成客戶端DH認(rèn)證響應(yīng)信息。
步驟206客戶端對收到的響應(yīng)消息進行認(rèn)證，認(rèn)證通過后，發(fā)送帶有客戶端認(rèn)證信息的請求消息到服務(wù)器端。所述帶有客戶端認(rèn)證信息的請求消息包括可選的客戶端的認(rèn)證交換信息、客戶端DH認(rèn)證響應(yīng)信息。
步驟207服務(wù)器端根據(jù)收到的請求消息對用戶進行認(rèn)證，并回送包含服務(wù)器端認(rèn)證信息的響應(yīng)消息。所述包含服務(wù)器端認(rèn)證信息的響應(yīng)消息包括可選的DH認(rèn)證信息頭域。所述DH認(rèn)證信息頭域包括服務(wù)器端的認(rèn)證信息。
服務(wù)器端收到的請求消息有兩種情況該消息的頭域中不包括客戶端的認(rèn)證交換信息；該消息的頭域中包括客戶端的認(rèn)證交換信息。
當(dāng)該消息的頭域中不包括客戶端的認(rèn)證交換信息時，服務(wù)器端使用用戶名和初始密碼對收到的請求消息進行認(rèn)證并根據(jù)所述用戶名和初始密碼生成所述服務(wù)器端DH認(rèn)證響應(yīng)信息。
當(dāng)該消息的頭域中不包括客戶端的認(rèn)證交換信息時，服務(wù)器端根據(jù)用戶的認(rèn)證交換信息以及本端的認(rèn)證交換信息獲取共享密鑰，根據(jù)所述共享密鑰對收到的請求消息進行認(rèn)證，并根據(jù)所述共享密鑰生成服務(wù)器端DH認(rèn)證響應(yīng)信息。
步驟208用戶根據(jù)收到的包含服務(wù)器端認(rèn)證信息的響應(yīng)消息驗證所述服務(wù)器端的合法性。
上述過程結(jié)束后，也就是說在客戶端和服務(wù)器端都獲取共享密鑰后，進行消息交互時，只使用所述共享密鑰對所述消息進行加密。
參照圖3，圖3示出了本發(fā)明方法中用戶接入時的消息流程對于UAS(服務(wù)器端)，如果需要認(rèn)證UAC(客戶端)，則必須發(fā)送401響應(yīng)，并必須在其中攜帶WWW-Authenticate頭域，在該頭域中包含UAS的認(rèn)證，以防止Middle-In-Man攻擊。UAC可以再次發(fā)起請求，在Authorization頭域中攜帶認(rèn)證信息。Registrars(注冊服務(wù)器)和Redirectserver(重定向服務(wù)器)也可以使用401響應(yīng)來進行認(rèn)證UAC。
對于Proxy(代理服務(wù)器)，如果需要認(rèn)證UAC，則必須發(fā)送407響應(yīng)，并必須在其中攜帶Proxy-Authenticate頭域，在該頭域中包含Proxy的認(rèn)證，以防止Middle-In-Man攻擊。UAC可以再次發(fā)起請求，在Proxy-Authorization頭域中攜帶認(rèn)證信息。
當(dāng)UAC因為收到401或者407響應(yīng)而重新發(fā)起請求時，一般應(yīng)該使用相同的Call-ID，F(xiàn)rom頭域和To頭域，但是CSeq頭域中的序數(shù)必須加一。
但是一個Server(UAS或者Proxy)不能向ACK(確認(rèn)客戶端已經(jīng)接收到對INVITE的最終響應(yīng))請求和CANCEL請求發(fā)起認(rèn)證。對于UAC而言，比較好的方式是在ACK消息中包含一個通過認(rèn)證的認(rèn)證信息，該認(rèn)證信息包括Authorization和Proxy-Authorization頭域，它是在和ACK對應(yīng)的INVITE消息中攜帶的并已經(jīng)通過UAS或Proxy認(rèn)證。
為了防止Plain Text攻擊，UAS或者Proxy應(yīng)在認(rèn)證的成功響應(yīng)(200)中包含新增頭域DH-Authentication-Info，在該新增頭域中包含UAS或者Proxy的驗證信息，UAC通過該信息驗證UAS或者Proxy的合法性。
這可以是一個可選的特性，如果UAC和UAS或者Proxy間配置了必須包含DH-Authentication-Info，則可以實現(xiàn)UAC驗證其接入的服務(wù)器的合法性。如果在200響應(yīng)中沒有包含DH-Authentication-Info或者驗證失敗，且在UAC和UAS或者Proxy間配置了必須要包含DH-Authentication-Info，則UAC可以認(rèn)為這是某個惡意的服務(wù)器接收了消息，可以選擇拒絕服務(wù)器。
在上述認(rèn)證過程中，只在初始的認(rèn)證過程中使用初始密鑰Ki，而在以后的認(rèn)證過程中都使用共享密鑰Ks，對于圖2中的消息而言，F(xiàn)2-F4所使用的密鑰是Ki，而F6-F8使用的密鑰是Ks。由于Ki只出現(xiàn)一次，所以可以有效地防止Plain Text和字典攻擊。
下面詳細(xì)說明本發(fā)明中的SIP頭域中的擴展參數(shù)及新增的SIP頭域本技術(shù)領(lǐng)域人員知道，在RFC3261中定義了四個頭域，分別為WWW-Authenticate，Proxy-Authenticate，Authorization，Proxy-Authorization，本發(fā)明即是在此基礎(chǔ)上，通過對這四個頭域中參數(shù)的擴展實現(xiàn)DH-Digest認(rèn)證。
本發(fā)明中定義的頭域如下1.WWW-Authenticate＝″WWW-Authenticate″HCOLON challenge2.Proxy-Authenticate＝″Proxy-Authenticate″HCOLON challenge其中，challenge＝(″Digest″|LWS digest-cln*(COMMA digest-cln))/dh-challenge/other-challengedh-challenge＝(″DH-Digest″｜LWS digest-cln*(COMMA digest-cln))other-challenge＝auth-scheme LWS auth-param*(COMMA auth-param)digest-cln＝realm/domain/nonce/opaque/stale/algorithm/qop-options/dh-b/dh-response-auth/auth-param
realm＝″realm″EQUAL realm-valuerealm-value＝quoted-stringdomain＝″domain″EQUAL LDQUOT URI*(1*SP URI)RDQUOTURI＝absoluteURI/abs-pathnonce＝″nonce″EQUAL nonce-valuenonce-value＝quoted-stringopaque＝″opaque″EQUAL quoted-stringstale＝″stale″EQUAL(″true″/″false″)algorithm＝″algorithm″EQUAL(″MD5″/″MD5-sess″/token)qop-options＝″qop″EQUAL LDQUOT qop-value*(″，″qop-value)RDQUOTqop-value＝″auth″/″auth-int″/tokendh-b＝″DH-B″EQUAL dh-b-valuedh-b-value＝quoted-stringdh-response-auth＝″DH-Rspauth″EQUAL dh-response-digestdh-response-digest＝LDQUOT 32LHEX RDQUOT其中，帶下劃線部分為頭域中新增的參數(shù)。
對上述WWW-Authenticate和Proxy-Authenticate頭域中的參數(shù)說明如下realmrealm-value必須是一個全局唯一的字符串，并且全部由可顯示的字符組成，用來呈現(xiàn)給用戶，指示用戶輸入用戶名及密碼。
Domain由雙引號包含的一個或多個URI列表，表明在這些domain域中，可以使用同樣的認(rèn)證信息。該參數(shù)對Proxy-Authenticate頭域無意義。
Noncenonce是由server提供的一串以16進制或base64表示的隨機字符串。
Opaqueopaque是由server提供的一串以16進制或base64表示的隨機字符串，客戶端應(yīng)不作任何改變，返回給server。
Stale該參數(shù)是一個標(biāo)志，有TRUE和FALSE兩個值，用來指示前一個請求，由于nonce過期而導(dǎo)致的認(rèn)證失敗。當(dāng)客戶端收到的401/407中，該參數(shù)值為TRUE時，只需使用新的nonce，重新計算一次摘要即可，不需再要求用戶輸入用戶名及密碼。只有當(dāng)server收到的request中nonce是過期的，但是該過期的nonce對應(yīng)的摘要正確時(也就是說用戶名和密碼是正確的)，才可將該參數(shù)設(shè)置為TRUE。
Algorithm用于指示兩邊計算摘要的算法，當(dāng)沒有該參數(shù)時，缺省為MD5算法。
qop-options為了兼容RFC2069而引入的任選參數(shù)，用于指示server所能支持的″quality of protection″，可以帶多個值，目前有兩個取值″auth″、″auth-int″(取值不同在加密算法上稍有不同)。具體使用方法參見后面的摘要計算方法。
dh-b為了實現(xiàn)DH Digest而特別引入的一個參數(shù)，代表了UAS或者Proxy的DH交換數(shù)；通過此參數(shù)，UAC可以用來計算出共享密鑰。
當(dāng)scheme為DH-Digest，而且WWW-Authentication和Proxy-Authentication中不包含此dh-b時，則意味著UAS或者Proxy已經(jīng)將db-b在以前的消息中發(fā)送給UAC了，當(dāng)前的這次認(rèn)證可以直接采用共享密鑰，而不需要采用初始密鑰(如果UAC不記得共享密鑰，如重啟后，也可以使用初始密鑰進行認(rèn)證)。當(dāng)其中包含dh-b時，則表示UAS或者Proxy希望重新發(fā)起一次共享密鑰的協(xié)商。
dh-response-auth為了防止惡意服務(wù)器發(fā)起的401或者407響應(yīng)，UAC需要對UAS或者Proxy發(fā)起的401或者407響應(yīng)進行認(rèn)證。UAS或者Proxy在發(fā)送401或者407響應(yīng)時，必須采用初始密鑰(當(dāng)dh-b參數(shù)存在時)或者采用共享密鑰(當(dāng)不存在dh-b參數(shù)時)進行認(rèn)證。
auth-param該參數(shù)是為了將來擴展引入的。
3.Proxy-Authorization＝″Proxy-Authorization″HCOLON credentials4.Authorization＝″Authorization″HCOLON credentials其中，credentials＝(″Digest″LWS digest-response)/dh-digest-response/other-responsedigest-response＝dig-resp*(COMMA dig-resp)dh-digest-response＝dig-resp*(COMMA dig-resp)dig-resp＝username/realm/nonce/digest-uri/dresponse/algorithm/cnonce/opaque/message-qop/nonce-count/dh-a/auth-paramusername＝″username″EQUAL username-valueusername-value＝quoted-stringdigest-uri＝″uri″EQUAL LDQUOT digest-uri-value RDQUOTdigest-uri-value＝rquest-uri；Equal to request-uri as specifiedby HTTP/1.1message-qop＝″qop″EQUAL qop-valuecnonce＝″cnonce″EQUAL cnonce-valuecnonce-value＝nonce-valuenonce-count＝″nc″EQUAL nc-valuenc-value＝8LHEXdresponse＝″response″EQUAL request-digestrequest-digest＝LDQUOT 32LHEX RDQUOTdh-a＝″DH-A″EQUAL dh-a-valuedh-a-value＝quoted-stringauth-param＝auth-param-name EQUAL(token/quoted-string)auth-param-name＝tokenother-response＝auth-scheme LWS auth-param*(COMMA auth-param)
auth-scheme＝token其中，帶下劃線部分為頭域中新增的參數(shù)。
對上述Authorization和Proxy-Authorization頭域中的參數(shù)說明如下response一個128比特的，由32個16進制數(shù)表示的字符串，它是由后面的公式計算而來的。
username在指定的realm范圍內(nèi)的用戶名。
digest-uri與最初的Request-Line的Request-URI相同，之所以不直接使用請求消息中的Request-URI，是因為中間的proxy可能會修改Request-URI。
message-qop為了兼容RFC2069而引入的任選參數(shù)，用于指示客戶端所能支持的“quality of protection(保護質(zhì)量)”，只能帶一個值，且只能是server過來的qop中的一個值。它將影響對摘要的計算。WWW-Authenticate或Proxy-Authenticate頭域中如果包含了qop參數(shù)，那么在Authorization或Proxy-Authorization頭域中必須帶此參數(shù)。
cnonce如果WWW-Authenticate或Proxy-Authenticate頭域中帶了qop參數(shù)，那么在Authorization或Proxy-Authorization頭域中必須帶此參數(shù)，否則不需要帶此參數(shù)。該參數(shù)由客戶端給出，用于避免plain text攻擊、提供message integrity protection、以及提供相互的認(rèn)證。
cnonce-count如果WWW-Authenticate或Proxy-Authenticate頭域中帶了qop參數(shù)，那么在Authorization或Proxy-Authorization頭域中必須帶此參數(shù)，否則不需要帶此參數(shù)。該參數(shù)是一個16進制的計算器，用于計數(shù)客戶端發(fā)出的包含nonce的請求消息個數(shù)。例如，對于server給定的一個nonce，客戶端發(fā)出的第一個請求消息，該參數(shù)為“nc＝00000001”，server會保存自己的一份nc拷貝，這樣server能對客戶端發(fā)過來的該參數(shù)的值與自己保存的值進行比較，這樣就可以判斷是否受到了replay攻擊。
dh-a為了實現(xiàn)DH Digest而特別引入的一個參數(shù)，代表了UAC的DH交換數(shù)；通過此參數(shù)，UAS或者Proxy可以用來計算出共享密鑰。
當(dāng)Authorization和Proxy-Authorization頭域中的scheme為“DH-Digest”，此時如果頭域中包含了dh-a參數(shù)，則當(dāng)前的這次認(rèn)證是使用初始密鑰進行加密的，此時不管Challenge(WWW-Authentication和Proxy-Authentication)中是否包含了dh-b參數(shù)，都應(yīng)該使用初始密鑰和dh-a的算法進行驗證(這種情況可能發(fā)生在UAC重啟后，發(fā)送新的請求，但是UAS或者Proxy并不知道UAC重啟了，而仍然希望UAC使用共享密鑰來進行驗證，此時UAC可以忽略UAS或者Proxy希望通過共享密鑰來加密的請求，而通過初始密鑰來實現(xiàn)驗證)；如果不包含dh-a參數(shù)，則意味著在以前的消息中UAC已經(jīng)將dh-a發(fā)送給UAS或者Proxy了，當(dāng)前的這次認(rèn)證是使用共享密鑰加密的。
根據(jù)Authentication-Info的ABNF定義不能擴展參數(shù)，所以在本發(fā)明中還新增加了一個頭域DH-Authentication-Info。
5.DH-Authentication-Info＝″DH-Authentication-Info″HCOLON dh-ainfo*(COMMA dh-ainfo)其中，dh-ainfo＝nextnonce/message-qop/response-auth/cnonce/nonce-count/dh-anextnonce＝″nextnonce″EQUAL nonce-valueresponse-auth＝″rspauth″EQUAL response-digestresponse-digest＝LDQUOT*LHEX RDQUOT對上述新增頭域DH-Authentication-Info中的參數(shù)說明如下UAS或者Proxy可以利用該頭域
A、改變nonce，客戶端收到帶nextnonce參數(shù)的該頭域后，如果要發(fā)送下一個請求，則應(yīng)使用新的nonce進行計算，否則如果客戶端仍使用老的nonce計算摘要，server會要求重新認(rèn)證，并且?guī)е甘綯RUE的stale參數(shù)。此時不需要包含dh-a參數(shù)。
B、UAS或Proxy向UAC認(rèn)證自己，需要攜帶response-digest參數(shù)；此時如果包含了dh-a參數(shù)，則此response-digest是采用初始密鑰進行加密的；如果沒有攜帶dh-a參數(shù)，則此response-digest是采用的共享密鑰進行加密的。
Nextnonce該參數(shù)是server給出的客戶端下一次發(fā)送請求消息時用的新nonce。
message-qop該參數(shù)應(yīng)與客戶端發(fā)來的qop參數(shù)取相同的值，指示server計算response摘要時的″quality of protection″。
為了防止replay攻擊，本發(fā)明方法規(guī)定在上述頭域WWW-Authenticate，Proxy-Authenticate，Authorization，Proxy-Authorization使用中必須攜帶qop參數(shù)。
上述參數(shù)中涉及的加密算法如下1、dh-response-digest(DH響應(yīng)摘要)的算法如下因為在WWW-Authenticate和Proxy-Authenticate中的qop是一個選項，可以包含auth或者auth-int等多種選擇。所以在此強制規(guī)定，qop-value為只使用auth。
dh-response-digest＝<″><MD5(MD5(A1)，unq(nonce-value)″″unq(qop-value)″″MD5(A2))<″>
其中，A1的算法如下
如果″algorithm″指示″MD5″或沒有帶該參數(shù)，并且沒有dh-b參數(shù)，則A 1＝unq(username-value)″″unq(realm-value)″″shared-key其中，shared-key＝<shared key calculated by dh-a and dh-b>
如果″algorithm″指示″MD5″或沒有帶該參數(shù)，并且有dh-b參數(shù)，則A1＝unq(username-value)″″unq(realm-value)″″passwd″″unq(dh-b)其中，passwd＝<user′s password>
dh-b＝<dh-b-value>
如果″algorithm″指示″MD5-sess″，并且沒有dh-b參數(shù)，則A 1＝MD5(unq(username-value)″″unq(realm-value)″″shared-key)″″unq(nonce-value))如果″algorithm″指示″MD5″或沒有帶該參數(shù)，并且有dh-b參數(shù)，則A1＝MD5(unq(username-value)″″unq(realm-value)″″passwd″″unq(dh-b))A2的算法如下A2＝Method ″″digest-uri-value2、request-digest(請求摘要)的算法如下如果″qop″值為″auth″或″auth-int″，則request-digest＝<″><MD5(MD5(A1)，unq(nonce-value)″″nc-value″″unq(cnonce-value)″″unq(qop-value)″″MD5(A2))<″>
其中，A1的算法如下如果″algorithm″指示″MD5″或沒有帶該參數(shù)，并且沒有dh-a參數(shù)，則A1＝unq(username-value)″″unq(realm-value)″″shared-key
其中，shared-key＝<shared key calculated by dh-a and dh-b>
如果″algorithm″指示″MD5″或沒有帶該參數(shù)，并且有dh-a參數(shù)，則A1＝unq(username-value)″″unq(realm-value)″″passwd″″dh-a其中，passwd＝<user′s password>
dh-a＝<dh-a-value>
如果″algorithm″指示″MD5-sess″，并且沒有dh-a參數(shù)，則A1＝MD5(unq(username-value)″″unq(realm-value)″″shared-key)″″unq(nonce-value)″″unq(cnonce-value)如果″algorithm″指示″MD5″或沒有帶該參數(shù)，并且有dh-a參數(shù)，則A1＝MD5(unq(username-value)″″unq(realm-value)″″passwd″″dh-a)″″unq(nonce-value)″″unq(cnonce-value)A2的算法如下如果″qop″指示″auth″，則A2＝Method″″digest-uri-value如果″qop″指示″auth-int″，則A2＝Method ″″digest-uri-value ″″MD5(entity-body)如果SIP的消息體為空，則在RFC2617中定義的A2中使用的H(entity-body)采用如下的定義H(entity-body)＝MD5(″″)＝″d41d8cd98f00b204e9800998ecf8427e″3、response-digest(響應(yīng)摘要)的算法response-digest的算法與前面的request-digest算法相似，區(qū)別在于A2的計算如果Authorization和Proxy-Authorization頭域中的″qop″指示″auth″，則A2＝″″digest-uri-value如果Authorization和Proxy-Authorization頭域中的″qop″指示″auth-int″，則A2＝″″digest-uri-value″″MD5(entity-body)
如果SIP的消息體為空，則在RFC2617中定義的A2中使用的H(entity-body)采用如下的定義H(entity-body)＝MD5(″″)＝″d41d8cd98f00b204e9800998ecf8427e″雖然通過實施例描繪了本發(fā)明，本領(lǐng)域普通技術(shù)人員知道，本發(fā)明有許多變形和變化而不脫離本發(fā)明的精神，希望所附的權(quán)利要求包括這些變形和變化而不脫離本發(fā)明的精神。
權(quán)利要求
1.一種會話初始協(xié)議認(rèn)證的方法，其特征在于，所述方法包括A、客戶端發(fā)送不帶認(rèn)證信息的請求消息到服務(wù)器端，請求接入；B、所述服務(wù)器端收到所述請求消息后回送帶有服務(wù)器端的認(rèn)證交換信息及服務(wù)器端DH認(rèn)證響應(yīng)信息的響應(yīng)消息；C、所述客戶端對收到的響應(yīng)消息進行認(rèn)證，認(rèn)證通過后，發(fā)送帶有客戶端認(rèn)證信息的請求消息到服務(wù)器端；D、所述服務(wù)器端根據(jù)收到的請求消息對所述用戶進行認(rèn)證，并回送包含服務(wù)器端認(rèn)證信息的響應(yīng)消息；E、所述用戶根據(jù)收到的所述包含服務(wù)器端認(rèn)證信息的響應(yīng)消息驗證所述服務(wù)器端的合法性。
2.根據(jù)權(quán)利要求1所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述步驟B包括服務(wù)器端根據(jù)用戶名和初始密碼生成所述服務(wù)器端DH認(rèn)證響應(yīng)信息。
3.根據(jù)權(quán)利要求1所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述帶有客戶端認(rèn)證信息的請求消息包括可選的客戶端的認(rèn)證交換信息、客戶端DH認(rèn)證響應(yīng)信息。
4.根據(jù)權(quán)利要求3所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述步驟C包括C1、所述客戶端根據(jù)所述服務(wù)器端的認(rèn)證交換信息及本端的認(rèn)證交換信息獲取共享密鑰；C2、根據(jù)所述共享密鑰生成所述客戶端DH認(rèn)證響應(yīng)信息。
5.根據(jù)權(quán)利要求3所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述步驟D包括當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中不包括所述客戶端的認(rèn)證交換信息時，所述服務(wù)器端使用用戶名和初始密碼對收到的請求消息進行認(rèn)證；當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中包括所述客戶端的認(rèn)證交換信息時，所述服務(wù)器端根據(jù)所述客戶端的認(rèn)證交換信息以及本端的認(rèn)證交換信息獲取共享密鑰，根據(jù)所述共享密鑰對收到的請求消息進行認(rèn)證。
6.根據(jù)權(quán)利要求3所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述步驟D還包括當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中不包括所述客戶端的認(rèn)證交換信息時，根據(jù)所述用戶名和初始密碼生成所述服務(wù)器端DH認(rèn)證響應(yīng)信息；當(dāng)所述帶有客戶端認(rèn)證信息的請求消息的頭域中包括所述客戶端的認(rèn)證交換信息時，所述服務(wù)器端根據(jù)所述客戶端的認(rèn)證交換信息以及本端的認(rèn)證交換信息獲取共享密鑰，根據(jù)所述共享密鑰生成服務(wù)器端DH認(rèn)證響應(yīng)信息。
7.根據(jù)權(quán)利要求1或3所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述包含服務(wù)器端認(rèn)證信息的響應(yīng)消息包括可選的DH認(rèn)證信息頭域。
8.根據(jù)權(quán)利要求7所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述DH認(rèn)證信息頭域包括服務(wù)器端的認(rèn)證信息。
9.根據(jù)權(quán)利要求6所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述方法還包括在所述客戶端和所述服務(wù)器端都獲取共享密鑰后，進行消息交互時，只使用所述共享密鑰對所述消息進行加密。
10.根據(jù)權(quán)利要求1所述的會話初始協(xié)議認(rèn)證的方法，其特征在于，所述服務(wù)器端包括代理服務(wù)器、背靠背服務(wù)器、重定向服務(wù)器和注冊服務(wù)器。
全文摘要
本發(fā)明公開了一種會話初始協(xié)議認(rèn)證的方法，該方法包括客戶端發(fā)送不帶認(rèn)證信息的請求消息到服務(wù)器端，請求接入；服務(wù)器端收到所述請求消息后回送帶有服務(wù)器端的認(rèn)證交換信息及服務(wù)器端DH認(rèn)證響應(yīng)信息的響應(yīng)消息；客戶端對收到的響應(yīng)消息進行認(rèn)證，認(rèn)證通過后，發(fā)送帶有客戶端認(rèn)證信息的請求消息到服務(wù)器端；服務(wù)器端根據(jù)收到的請求消息對用戶進行認(rèn)證，并回送包含服務(wù)器端認(rèn)證信息的響應(yīng)消息；用戶根據(jù)收到的包含服務(wù)器端認(rèn)證信息的響應(yīng)消息驗證服務(wù)器端的合法性。利用本發(fā)明，可以有效地提高SIP認(rèn)證的安全性。
文檔編號H04L9/32GK1716953SQ200410069510
公開日2006年1月4日 申請日期2004年6月28日 優(yōu)先權(quán)日2004年6月28日
發(fā)明者周思義 申請人:華為技術(shù)有限公司