專利名稱：Ip網(wǎng)絡(luò)委托域中的身份處理的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)部分中的身份處理。本發(fā)明進(jìn)一步涉及在越過委托域的邊界而且尊重與主張的身份有關(guān)的用戶隱私要求時對用戶所主張的身份的插入或者去除。
背景技術(shù)：
在第5次發(fā)布的第3代合作伙伴項目(3GPP)IP多媒體子系統(tǒng)(IMS)中，將系統(tǒng)考慮為受托方的閉合網(wǎng)絡(luò)。IMS會話總是在IMS網(wǎng)絡(luò)中起源或者終止，而且所有IMS網(wǎng)絡(luò)相互委托。這一模型排除了對在公共因特網(wǎng)中起源或者終止的IMS會話的建立。另一方面，由于所有IMS網(wǎng)絡(luò)相互委托，會話發(fā)起協(xié)議(SIP)代理(呼叫會話控制功能(CSCF)、中斷網(wǎng)關(guān)控制功能(BGCF)等)無需采取與在SIP請求中的所主張的身份有關(guān)的任何動作。如果在從另一IMS(受托)網(wǎng)絡(luò)接收到請求時存在所主張的身份，則它將是受托的。如果SIP代理要發(fā)送SIP請求到另一網(wǎng)絡(luò)，則該所主張的身份被保持于消息中。
第6次發(fā)布的3GPP IMS允許IMS會話建立到互聯(lián)網(wǎng)SIP客戶端和從互聯(lián)網(wǎng)SIP客戶端建立IMS會話。然而，這要求新的委托模型，因為對于特定網(wǎng)絡(luò)，只有選定的(IMS或者非IMS)網(wǎng)絡(luò)才被認(rèn)為是受托的。要求SIP代理(例如CSCF、BGCF等)能在業(yè)務(wù)尋路由到未受托網(wǎng)絡(luò)時采取關(guān)于所主張的身份的動作(例如去除)。如果SIP代理從受托網(wǎng)絡(luò)接收SIP請求而且存在有所主張的身份，則將之保持。然而，如果SIP代理從未受托網(wǎng)絡(luò)接收SIP請求而且存在有所主張的身份，則SIP代理去除該身份，因為它不是受托的。類似地，如果SIP代理要轉(zhuǎn)發(fā)請求到受托網(wǎng)絡(luò)，則它保持任何主張的身份。但是如果SIP代理要轉(zhuǎn)發(fā)請求到未受托網(wǎng)絡(luò)，則所主張的身份被去除。
IMS中委托網(wǎng)絡(luò)的概念受到了在相互委托的兩個網(wǎng)絡(luò)之間存在互連協(xié)議的支持。當(dāng)兩個網(wǎng)絡(luò)簽署互連協(xié)議時，它們交換安全信息。第5次發(fā)布的3GPP IMS不支持受托節(jié)點(diǎn)和未受托節(jié)點(diǎn)的混合。第5次發(fā)布的3GPP IMS指定所有IMS網(wǎng)絡(luò)相互委托；換句話說，不允許到非IMS網(wǎng)絡(luò)的連接。第5次發(fā)布的3GPP IMS提供了任何兩個IMS網(wǎng)絡(luò)之間的網(wǎng)際互聯(lián)協(xié)議安全(IPsec)網(wǎng)關(guān)和IPsec隧道。然而，IPsec網(wǎng)關(guān)在第6次發(fā)布中對于受托/未受托模型是無用的，因為IPsec網(wǎng)關(guān)利用對IP層而不是SIP層進(jìn)行操作，而且因為IPsec網(wǎng)關(guān)在物理上和在邏輯上是不同于SIP代理的單元。此外，在兩個IMS運(yùn)營商之間存在IPsec隧道仍不足以假定在這些運(yùn)營商之間有SIP層的委托關(guān)系。
因此，需要一種用于為接收SIP請求的特定SIP代理確定特定請求是從受托源還是從未受托源接收的方法。另外，也有必要在轉(zhuǎn)發(fā)SIP請求之前為要轉(zhuǎn)發(fā)SIP請求到另一網(wǎng)絡(luò)的特定SIP代理確定下一SIP代理是否為受托的。

發(fā)明內(nèi)容
本發(fā)明揭示了一種用于處理用戶身份和隱私的方法，其中第一會話發(fā)起協(xié)議(SIP)代理要轉(zhuǎn)發(fā)SIP請求到下一SIP代理，而且包括確定在去往下一SIP代理的跳躍中是否支持傳輸層安全(TLS)的步驟。當(dāng)TLS被支持時，該方法包括建立到去往下一SIP代理的跳躍的TLS連接，請求來自下一SIP代理的證書，接收證書，驗證證書和下一SIP代理的網(wǎng)絡(luò)的可信度，而當(dāng)證書和網(wǎng)絡(luò)的可信度被驗證時保持身份信息。當(dāng)TLS未被支持時，或者當(dāng)證書未被驗證時，或者當(dāng)網(wǎng)絡(luò)的可信度未被驗證時，去除身份信息。隨后，通過TLS連接轉(zhuǎn)發(fā)SIP請求。
本發(fā)明也涉及一種用于為了處理用戶身份和隱私的目的而確定第一SIP代理是否屬于受托網(wǎng)絡(luò)的方法，其中下一會話發(fā)起協(xié)議(SIP)代理從第一SIP代理接收SIP請求。該方法包括從第一SIP代理接收SIP請求以及確定SIP請求是否是經(jīng)由TLS接收的步驟。當(dāng)SIP請求是經(jīng)由TLS接收的時，該方法包括請求來自第一SIP代理的證書，接收證書，驗證證書和第一SIP代理的網(wǎng)絡(luò)的可信度，而當(dāng)證書和網(wǎng)絡(luò)的可信度被驗證時保持身份信息。當(dāng)TLS未被支持時，或者當(dāng)證書未被驗證時，或者當(dāng)網(wǎng)絡(luò)的可信度未被驗證時，去除身份信息。隨后，該方法包括對SIP請求做出響應(yīng)。
本發(fā)明也涉及一種通信設(shè)備，包括建立裝置，用于建立到去往下一SIP代理的跳躍的傳輸層安全(TLS)連接；確定裝置，用于確定在去往下一SIP代理的跳躍中是否支持TLS；請求裝置，用于請求來自下一SIP代理的證書；接收裝置，用于接收證書；驗證裝置，用于驗證證書和下一SIP代理的網(wǎng)絡(luò)的可信度；以及轉(zhuǎn)發(fā)裝置，用于通過TLS連接轉(zhuǎn)發(fā)SIP請求。該通信設(shè)備被配置用以當(dāng)證書被驗證時、當(dāng)網(wǎng)絡(luò)的可信度被驗證時、而且當(dāng)TLS被支持時保持身份信息，以及被配置用以當(dāng)TLS未被支持時、或者證書未被驗證、或者當(dāng)網(wǎng)絡(luò)的可信度未被驗證時去除身份信息。
本發(fā)明也涉及一種通信系統(tǒng)，包括傳輸層安全(TLS)連接建立器，被配置用以建立到去往下一SIP代理的跳躍的TLS連接；TLS支持分析器，被配置用以確定在去往下一SIP代理的跳躍中是否支持TLS；驗證模塊，被配置用以請求來自下一SIP代理的證書、接收證書、以及驗證證書和第一SIP代理的網(wǎng)絡(luò)的可信度；SIP請求處理器，被配置用以通過TLS連接轉(zhuǎn)發(fā)SIP請求。該通信系統(tǒng)被配置用以當(dāng)證書被驗證時、當(dāng)網(wǎng)絡(luò)的可信度被驗證時、而且當(dāng)TLS被支持時保持身份信息，以及被配置用以當(dāng)TLS未被支持時、或者證書未被驗證、或者當(dāng)網(wǎng)絡(luò)的可信度未被驗證時去除身份信息。
參照與附圖相結(jié)合的以下描述，本發(fā)明的這些和其它特征、方面及優(yōu)點(diǎn)將變得明顯。然而應(yīng)當(dāng)理解，附圖僅被設(shè)計用于說明之目的而不是用于對本發(fā)明的限制進(jìn)行定義。


所包含的附圖以便提供對本發(fā)明的進(jìn)一步理解，而且將附圖結(jié)合于本說明書中并構(gòu)成本說明書的一部分，這些附示了本發(fā)明的實(shí)施例，與說明書一起用以說明本發(fā)明的原理，在附圖中圖1圖示了IMS安全架構(gòu)；以及圖2圖示了根據(jù)本發(fā)明一個實(shí)施例示出隱私處理的流程圖。
具體實(shí)施例方式
在分組交換(PS)域中，直至在移動設(shè)備與網(wǎng)絡(luò)之間建立了安全關(guān)聯(lián)才提供服務(wù)。IP多媒體核心網(wǎng)絡(luò)子系統(tǒng)(IMS)實(shí)質(zhì)上是對PS-域的覆蓋而且具有與PS-域的低相關(guān)性。因此在準(zhǔn)許對多媒體服務(wù)的訪問之前，在多媒體客戶端與IMS之間要求單獨(dú)的安全關(guān)聯(lián)。在圖1中示出了IMS安全架構(gòu)。
圖1圖示了在歸屬/服務(wù)網(wǎng)絡(luò)110、受訪/歸屬網(wǎng)絡(luò)120和用戶設(shè)備102之間的關(guān)系，其中該歸屬/服務(wù)網(wǎng)絡(luò)具有歸屬用戶服務(wù)器111(HSS)。圖1圖示了在移動設(shè)備(即用戶設(shè)備102(UE)、用戶等)與比如服務(wù)呼叫會話控制功能113(S-CSCF)、代理呼叫會話控制功能121(P-CSCF)和詢問呼叫會話控制功能112(I-CSCF)這樣的各種網(wǎng)絡(luò)單元之間的呼叫控制協(xié)議。
用戶側(cè)的IMS認(rèn)證密鑰和功能被存儲于通用集成電路卡(UICC)上。對于IMS認(rèn)證密鑰和功能來說有可能在邏輯上是獨(dú)立的，而且是用于PS域認(rèn)證的密鑰和功能。然而，這并不排除將普通的認(rèn)證密鑰和功能用于IMS和PS域認(rèn)證。IP多媒體服務(wù)身份模塊103(ISIM)在UICC上提供了IMS安全數(shù)據(jù)和功能的集合。
對于IMS的安全保護(hù)有五個不同的安全關(guān)聯(lián)和不同的需要，而在圖1中將它們編號為1、2、3、4和5。第一關(guān)聯(lián)即編號1提供相互認(rèn)證。HSS向S-CSCF授予用戶認(rèn)證性能。然而HSS負(fù)責(zé)生成密鑰和口令。ISIM和HSS中的長期密鑰與IMPI相關(guān)聯(lián)。用戶將具有一個(網(wǎng)絡(luò)內(nèi)部)用戶隱私身份(IMPI)和至少一個外部用戶公共身份(IMPU)。第二關(guān)聯(lián)即編號2為保護(hù)Gm參考點(diǎn)而在UE與P-CSCF之間提供安全鏈路和安全關(guān)聯(lián)。提供了數(shù)據(jù)起源認(rèn)證，即證實(shí)所接收的數(shù)據(jù)的源正是所聲稱的源。
第三關(guān)聯(lián)即編號3內(nèi)部地為Cx-接口提供網(wǎng)絡(luò)域之內(nèi)的安全。第四關(guān)聯(lián)即編號4為具有SIP功能的節(jié)點(diǎn)提供不同網(wǎng)絡(luò)之間的安全。這一安全關(guān)聯(lián)僅在P-CSCF駐留于VN中時適用，而如果P-CSCF駐留于HN中則編號五適用。最后的關(guān)聯(lián)即編號5內(nèi)部地在具有SIP功能的節(jié)點(diǎn)之間提供網(wǎng)絡(luò)之內(nèi)的安全。
在IMS中存在有上文未提及的其它接口和參考點(diǎn)。這些接口和參考點(diǎn)駐留于IMS之內(nèi)，要么在同一安全域之內(nèi)要么在不同的安全域之間。在UE與HN之間要求相互認(rèn)證。獨(dú)立的IMS安全機(jī)制提供了防范違反安全的附加保護(hù)。例如，如果破壞了PS-域安全，則IMS將繼續(xù)受它自己的安全機(jī)制的保護(hù)。
對于委托模型的支持是由在受托網(wǎng)絡(luò)之間存在互連協(xié)議來保證的，如上文所述。每個SIP代理包含如下數(shù)據(jù)庫，該數(shù)據(jù)庫包含受托網(wǎng)絡(luò)的列表以及在證書中可見的安全參數(shù)。安全參數(shù)可以是證書權(quán)限或者公共名或者組織。
隱私在許多實(shí)例中可以等效于保密。這可以包括通過使用加密和加密密鑰來向被授權(quán)理解信息的實(shí)體之外的所有實(shí)體隱藏該信息。用于IMS網(wǎng)絡(luò)的SIP隱私擴(kuò)展不提供這樣的保密。該機(jī)制的用途實(shí)際上在于給予IMS用戶保留某些身份信息的可能性。用于IMS網(wǎng)絡(luò)的隱私機(jī)制在CSCF中不創(chuàng)建除正常SIP狀態(tài)之外的狀態(tài)，這是有用的。
根據(jù)至少一個實(shí)施例，當(dāng)?shù)?次發(fā)布的IMS與非IMS網(wǎng)絡(luò)相互作用時，IMS網(wǎng)絡(luò)中的CSCF基于用于該相互作用的安全機(jī)制是否被應(yīng)用以及相互作用協(xié)議的可用性來決定委托關(guān)系。如果相互作用網(wǎng)絡(luò)不是受托的，則將隱私信息從面向外部網(wǎng)絡(luò)的業(yè)務(wù)中去除。當(dāng)接收SIP信令時，CSCF也驗證是否已經(jīng)包含任何隱私信息。如果相互作用網(wǎng)絡(luò)不是受托的，則該信息由CSCF去除，反之則保持。
由于缺乏安全機(jī)制，當(dāng)相互作用網(wǎng)絡(luò)指示未受托的非IMS網(wǎng)絡(luò)時，通常需要單獨(dú)的CSCF以與IMS網(wǎng)絡(luò)和非IMS網(wǎng)絡(luò)對接。與IMS網(wǎng)絡(luò)對接的CSCF隱含地委托可經(jīng)由進(jìn)行安全建立的SEG可達(dá)的所有IMS網(wǎng)絡(luò)。第5次發(fā)布的CSCF總是采用這一委托關(guān)系和網(wǎng)絡(luò)配置。對于第6次發(fā)布的CSCF，這一隱含的委托設(shè)置是運(yùn)營商可以根據(jù)網(wǎng)絡(luò)和接口配置來設(shè)置的配置選項。
圖2圖示了根據(jù)本發(fā)明實(shí)施例示出隱私處理的流程圖。要轉(zhuǎn)發(fā)SIP請求到下一SIP代理的IMS SIP代理在步驟201建立到該下一跳躍的傳輸層安全(TLS)連接。如果在下一跳躍中不支持TLS，則該網(wǎng)絡(luò)是未受托的，而且在步驟203中去除隱私信息。如果在判決202中支持TLS，則IMS SIP代理在步驟204中請求來自其它SIP代理的證書。在收到證書時，IMS SIP代理在步驟205中評價證書是否有效以及它是否屬于受托網(wǎng)絡(luò)。在它屬于受托網(wǎng)絡(luò)的情況下，IMS代理保持所主張的身份，否則將之去除。然后，它在步驟206中通過TLS連接轉(zhuǎn)發(fā)SIP請求。也有可能SIP代理由于先前的連接而已經(jīng)具有關(guān)于其它方的證書。然后僅驗證證書是否依然有效就足夠了。
類似地，接收SIP請求的IMS SIP代理應(yīng)用這些相同的規(guī)則。如果沒有經(jīng)由TLS收到請求，則進(jìn)行發(fā)送的SIP代理不被委托。如果經(jīng)由TLS發(fā)送請求，則IMS SIP代理向進(jìn)行發(fā)送的SIP代理請求證書。然后IMS SIP代理針對受托網(wǎng)絡(luò)的列表來驗證證書，確定進(jìn)行發(fā)送的SIP代理是否是受托的。同樣，可以有來自較早連接的證書。
此外，每個IMS網(wǎng)絡(luò)將域名服務(wù)器(DNS)命名權(quán)限指針(NAPTR)記錄配置為針對SIP服務(wù)將較高的優(yōu)選賦予給借助用戶數(shù)據(jù)報協(xié)議(UDP)、傳輸控制協(xié)議(TCP)、流控制傳輸協(xié)議(STCP)(或者其它傳送協(xié)議)的TLS。這允許IMS網(wǎng)絡(luò)總是先嘗試TLS作為傳送協(xié)議。
關(guān)于與第5次發(fā)布的網(wǎng)絡(luò)之間的互用性，第6次發(fā)布的IMS網(wǎng)絡(luò)使用了向后兼容的解決方案，即經(jīng)由安全網(wǎng)絡(luò)(SGW)的因特網(wǎng)互聯(lián)協(xié)議安全(IPsec)。進(jìn)行接收的SGW需要將SIP消息的端口號改變?yōu)镃SCF的受保護(hù)端口，以便向進(jìn)行接收的CSCF指示分組已經(jīng)受到IPsec保護(hù)。如果存在有互連協(xié)議，則在接收時轉(zhuǎn)發(fā)或者委托用戶身份。否則去除用戶身份。本發(fā)明的另一方面涉及如何提供在第5次發(fā)布的IMS與第6次發(fā)布的IMS網(wǎng)絡(luò)之間的向后兼容性。
在第一例子中，第5次發(fā)布的IMS SIP代理發(fā)送SIP請求到第6次發(fā)布的IMS節(jié)點(diǎn)。第5次發(fā)布的IMS SIP代理不采取關(guān)于所主張的身份的任何動作，因為它認(rèn)為第6次發(fā)布的IMS網(wǎng)絡(luò)是受托的。然而，第6次發(fā)布的IMS SIP將去除所主張的身份，因為該請求不使用TLS。
根據(jù)本發(fā)明的實(shí)施例，隨著該請求穿越在兩個IMS網(wǎng)絡(luò)之間的域間邊界，SIP消息將穿越在第5次發(fā)布的網(wǎng)絡(luò)中的SGW，然后穿越在第6次發(fā)布的IMS網(wǎng)絡(luò)中的另一SGW。這一業(yè)務(wù)是使用IPsec ESP來保護(hù)的。在第6次發(fā)布的IMS網(wǎng)絡(luò)中的SGW可以將(在第6次發(fā)布的網(wǎng)絡(luò)中的SIP代理的)目的地端口號重新設(shè)定目標(biāo)為受保護(hù)的端口號。在第6次發(fā)布的IMS網(wǎng)絡(luò)中的SIP代理分配兩個端口號，在一個端口上接收常規(guī)業(yè)務(wù)，在另一個端口上安全網(wǎng)關(guān)發(fā)送已經(jīng)經(jīng)由IPsec隧道(來自第5次發(fā)布的IMS網(wǎng)絡(luò))接收的業(yè)務(wù)。IPsec隧道的存在指示了另一端是IMS網(wǎng)絡(luò)(而且受托于第5次發(fā)布的指導(dǎo))。
在第二例子中，第5次發(fā)布的IMS SIP代理從第6次發(fā)布的IMS網(wǎng)絡(luò)接收SIP請求。由于第5次發(fā)布的IMS網(wǎng)絡(luò)認(rèn)為所有都是受托的，所以第5次發(fā)布的IMS SIP代理將不會采取任何關(guān)于所主張的身份的動作。根據(jù)第5次發(fā)布的指導(dǎo)，該請求在這一情況下應(yīng)當(dāng)經(jīng)由安全網(wǎng)關(guān)而來，但是這并不影響動作。
在第三例子中，第6次發(fā)布的IMS SIP代理發(fā)送SIP請求到第5次發(fā)布的IMS網(wǎng)絡(luò)。在默認(rèn)情況下，由于第5次發(fā)布的IMS不支持TLS，所以第6次發(fā)布的IMS SIP代理將去除所主張的身份。根據(jù)本發(fā)明的實(shí)施例，優(yōu)選的動作是不進(jìn)行進(jìn)一步動作的。如果出于某一原因而需要發(fā)送所主張的身份，則運(yùn)營商需要進(jìn)行如下互連協(xié)議，該互連協(xié)議包含由于另一方屬于第5次發(fā)布這樣的理由而免于使用TLS。現(xiàn)在，進(jìn)行發(fā)送的代理將必須向它自己網(wǎng)絡(luò)的安全網(wǎng)關(guān)指示必須應(yīng)用IPsec ESP。這一指示可以通過為進(jìn)行發(fā)送的代理而使用專用源IP地址來實(shí)現(xiàn)。
在第四例子中，第6次發(fā)布的IMS SIP代理從第5次發(fā)布的IMS網(wǎng)絡(luò)接收SIP請求。由于第5次發(fā)布的IMS網(wǎng)絡(luò)不支持TLS，所以第6次發(fā)布的IMS SIP代理將默認(rèn)地認(rèn)為該請求來自于未受托網(wǎng)絡(luò)。在這一情況下，該解決方案與上面針對第一例子而討論的解決方案相同。
受傳輸層安全(TLS)保護(hù)的SIP信令可以用來保護(hù)在IMS CSCF與位于外部網(wǎng)絡(luò)中的代理/CSCF之間的SIP互用性。CSCF可以通過公布SIPDNS服務(wù)器中的URI，來請求與外部代理的TLS連接，該URI可以經(jīng)由NAPTR/SRV機(jī)制來解析。當(dāng)在TLS握手階段期間發(fā)送/接收證書時，CSCF針對相互作用伙伴的列表來驗證證書上的名稱?？梢詮娜我痪W(wǎng)絡(luò)發(fā)起TLS會話。TLS連接能進(jìn)行多個SIP對話。
前面的描述已經(jīng)涉及到本發(fā)明的具體實(shí)施例。然而顯然的是，在達(dá)到所述實(shí)施例的一些或者所有優(yōu)點(diǎn)情況下，可以對它們進(jìn)行其它變形和改進(jìn)。因此，所附權(quán)利要求的目的在于涵蓋落入本發(fā)明的真實(shí)精神范圍之內(nèi)的所有這種變形和改進(jìn)。
權(quán)利要求
1.一種用于處理用戶身份和隱私的方法，其中第一會話發(fā)起協(xié)議(SIP)代理要轉(zhuǎn)發(fā)SIP請求到下一SIP代理，包括以下步驟確定在去往下一SIP代理的跳躍中是否支持傳輸層安全(TLS)；當(dāng)TLS被支持時，建立到去往所述下一SIP代理的所述跳躍的TLS連接；請求來自所述下一SIP代理的證書；接收所述證書；驗證所述證書和所述下一SIP代理的網(wǎng)絡(luò)的可信度；當(dāng)所述證書和所述網(wǎng)絡(luò)的所述可信度被驗證時保持身份信息；當(dāng)TLS未被支持時，或者當(dāng)所述證書未被驗證時，或者當(dāng)所述網(wǎng)絡(luò)的所述可信度未被驗證時，去除所述身份信息；以及通過所述TLS連接轉(zhuǎn)發(fā)所述SIP請求。
2.根據(jù)權(quán)利要求1所述的方法，其中所述驗證所述證書的步驟包括確定所述證書是否有效。
3.根據(jù)權(quán)利要求1所述的方法，其中所述驗證所述網(wǎng)絡(luò)的所述可信度的步驟包括確定所述網(wǎng)絡(luò)屬于受托網(wǎng)絡(luò)組。
4.根據(jù)權(quán)利要求3所述的方法，其中所述確定所述網(wǎng)絡(luò)是否屬于受托網(wǎng)絡(luò)組的步驟包括確定所述網(wǎng)絡(luò)是否在受托網(wǎng)絡(luò)的列表上。
5.根據(jù)權(quán)利要求1所述的方法，其中所述下一SIP代理先前發(fā)送過在先的證書，而所述驗證所述證書的步驟包括確定所述在先的證書是否仍然有效。
6.根據(jù)權(quán)利要求1所述的方法，還包括為受托SIP代理和未受托SIP代理維護(hù)單獨(dú)的呼叫會話控制功能(CSCF)。
7.根據(jù)權(quán)利要求1所述的方法，還包括將域名服務(wù)器(DNS)命名權(quán)限指針(NAPTR)配置為給以TLS較高的優(yōu)選。
8.一種用于為了處理用戶身份和隱私的目的而確定第一SIP代理是否屬于受托網(wǎng)絡(luò)的方法，其中下一會話發(fā)起協(xié)議(SIP)代理從所述第一SIP代理接收SIP請求，包括以下步驟從第一SIP代理接收SIP請求；確定所述SIP請求是否是經(jīng)由TLS接收的；當(dāng)所述SIP請求是經(jīng)由TLS接收的時，請求來自所述第一SIP代理的證書；接收所述證書；驗證所述證書和所述第一SIP代理的網(wǎng)絡(luò)的可信度；當(dāng)所述證書和所述網(wǎng)絡(luò)的所述可信度被驗證時保持身份信息；當(dāng)TLS未被支持時，或者當(dāng)所述證書未被驗證時，或者當(dāng)所述網(wǎng)絡(luò)的所述可信度未被驗證時，去除所述身份信息；以及對所述SIP請求做出響應(yīng)。
9.根據(jù)權(quán)利要求8所述的方法，其中所述驗證所述證書的步驟包括確定所述證書是否有效。
10.根據(jù)權(quán)利要求8所述的方法，其中所述驗證所述網(wǎng)絡(luò)的所述可信度的步驟包括確定所述網(wǎng)絡(luò)是否屬于受托網(wǎng)絡(luò)組。
11.根據(jù)權(quán)利要求10所述的方法，其中所述確定所述網(wǎng)絡(luò)是否屬于受托網(wǎng)絡(luò)組的步驟包括確定所述網(wǎng)絡(luò)是否在受托網(wǎng)絡(luò)的列表上。
12.根據(jù)權(quán)利要求8所述的方法，其中所述第一SIP代理先前發(fā)送過在先的證書，而所述驗證所述證書的步驟包括確定所述在先的證書是否仍然有效。
13.根據(jù)權(quán)利要求8所述的方法，還包括為受托SIP代理和未受托SIP代理維護(hù)單獨(dú)的呼叫會話控制功能(CSCF)。
14.根據(jù)權(quán)利要求8所述的方法，還包括將域名服務(wù)器(DNS)命名權(quán)限指針(NAPTR)配置為給以TLS較高的優(yōu)選。
15.一種通信設(shè)備，包括建立裝置，用于建立到去往下一SIP代理的跳躍的傳輸層安全(TLS)連接；確定裝置，用于確定在去往所述下一SIP代理的所述跳躍中是否支持TLS；請求裝置，用于請求來自所述下一SIP代理的證書；接收裝置，用于接收所述證書；驗證裝置，用于驗證所述證書和所述下一SIP代理的網(wǎng)絡(luò)的可信度；以及轉(zhuǎn)發(fā)裝置，用于通過所述TLS連接轉(zhuǎn)發(fā)所述SIP請求，其中所述通信設(shè)備被配置為用以當(dāng)所述證書被驗證時、當(dāng)所述網(wǎng)絡(luò)的所述可信度被驗證時、而且當(dāng)TLS被支持時保持身份信息，以及被配置為用以當(dāng)TLS未被支持時、或者所述證書未被驗證、或者當(dāng)所述網(wǎng)絡(luò)的所述可信度未被驗證時去除所述身份信息。
16.根據(jù)權(quán)利要求15所述的通信設(shè)備，其中所述驗證裝置包括用于確定所述證書是否有效的裝置。
17.根據(jù)權(quán)利要求15所述的通信設(shè)備，其中所述驗證裝置包括用于確定所述網(wǎng)絡(luò)屬于受托網(wǎng)絡(luò)組的裝置。
18.根據(jù)權(quán)利要求17所述的通信設(shè)備，其中所述用于確定所述網(wǎng)絡(luò)是否屬于受托網(wǎng)絡(luò)組的裝置包括用于確定所述網(wǎng)絡(luò)是否在受托網(wǎng)絡(luò)的列表上的裝置。
19.根據(jù)權(quán)利要求15所述的通信設(shè)備，其中當(dāng)所述下一SIP代理先前發(fā)送過在先的證書時，所述驗證裝置包括用于確定所述在先的證書是否仍然有效的裝置。
20.根據(jù)權(quán)利要求15所述的通信設(shè)備，還包括用于為受托SIP代理和未受托SIP代理維護(hù)單獨(dú)的呼叫會話控制功能(CSCF)的裝置。
21.根據(jù)權(quán)利要求15所述的通信設(shè)備，還包括用于將域名服務(wù)器(DNS)命名權(quán)限指針(NAPTR)配置為給以TLS較高優(yōu)選的裝置。
22.一種通信系統(tǒng)，包括傳輸層安全(TLS)連接建立器，被配置為用以建立到去往下一SIP代理的跳躍的TLS連接；TLS支持分析器，被配置為用以確定在去往所述下一SIP代理的所述跳躍中是否支持TLS；驗證模塊，被配置為用以請求來自所述下一SIP代理的證書，接收所述證書，以及驗證所述證書和所述第一SIP代理的網(wǎng)絡(luò)的可信度；SIP請求處理器，被配置為用以通過所述TLS連接轉(zhuǎn)發(fā)所述SIP請求，其中所述通信系統(tǒng)被配置為用以當(dāng)所述證書被驗證時、當(dāng)所述網(wǎng)絡(luò)的所述可信度被驗證時、而且當(dāng)TLS被支持時保持身份信息，以及被配置為用以當(dāng)TLS未被支持時、或者所述證書未被驗證、或者當(dāng)所述網(wǎng)絡(luò)的所述可信度未被驗證時去除所述身份信息。
23.根據(jù)權(quán)利要求15所述的通信系統(tǒng)，其中所述驗證模塊被配置為用以確定所述證書是否有效。
24.根據(jù)權(quán)利要求15所述的通信系統(tǒng)，其中所述驗證模塊被配置用以確定所述網(wǎng)絡(luò)屬于受托網(wǎng)絡(luò)組。
25.根據(jù)權(quán)利要求17所述的通信系統(tǒng)，其中所述驗證模塊被配置為用以確定所述網(wǎng)絡(luò)是否在受托網(wǎng)絡(luò)的列表上。
26.根據(jù)權(quán)利要求15所述的通信系統(tǒng)，其中當(dāng)所述下一SIP代理先前發(fā)送過在先的證書時，所述驗證模塊被配置為用以確定所述在先的證書是否仍然有效。
27.一種用于處理用戶身份和隱私的、在計算機(jī)可讀介質(zhì)上實(shí)施的計算機(jī)程序，其中第一會話發(fā)起協(xié)議(SIP)代理要轉(zhuǎn)發(fā)SIP請求到下一SIP代理，所述計算機(jī)程序控制數(shù)據(jù)處理設(shè)備執(zhí)行以下步驟確定在去往下一SIP代理的跳躍中是否支持傳輸層安全(TLS)；當(dāng)TLS被支持時，建立到去往所述下一SIP代理的所述跳躍的TLS連接；請求來自所述下一SIP代理的證書；接收所述證書；驗證所述證書和所述下一SIP代理的網(wǎng)絡(luò)的可信度；當(dāng)所述證書和所述網(wǎng)絡(luò)的所述可信度被驗證時保持身份信息；當(dāng)TLS未被支持時，或者當(dāng)所述證書未被驗證時，或者當(dāng)所述網(wǎng)絡(luò)的所述可信度未被驗證時，去除所述身份信息；以及通過所述TLS連接轉(zhuǎn)發(fā)所述SIP請求。
28.根據(jù)權(quán)利要求27所述的計算機(jī)程序，其中所述驗證所述證書的步驟包括確定所述證書是否有效。
29.根據(jù)權(quán)利要求27所述的計算機(jī)程序，其中所述驗證所述網(wǎng)絡(luò)的所述可信度的步驟包括確定所述網(wǎng)絡(luò)屬于受托網(wǎng)絡(luò)組。
30.根據(jù)權(quán)利要求29所述的計算機(jī)程序，其中所述確定所述網(wǎng)絡(luò)是否屬于受托網(wǎng)絡(luò)組的步驟包括確定所述網(wǎng)絡(luò)是否在受托網(wǎng)絡(luò)的列表上。
31.根據(jù)權(quán)利要求27所述的計算機(jī)程序，其中所述下一SIP代理先前發(fā)送過在先的證書，而所述驗證所述證書的步驟包括確定所述在先的證書是否仍然有效。
32.一種用于為了處理用戶身份和隱私的目的而確定第一SIP代理是否屬于受托網(wǎng)絡(luò)的、在計算機(jī)可讀介質(zhì)上實(shí)施的計算機(jī)程序，其中下一會話發(fā)起協(xié)議(SIP)代理從所述第一SIP代理接收SIP請求，所述計算機(jī)程序控制數(shù)據(jù)處理設(shè)備執(zhí)行以下步驟從第一SIP代理接收SIP請求；確定所述SIP請求是否是經(jīng)由TLS接收的；當(dāng)所述SIP請求是經(jīng)由TLS接收的時，請求來自所述第一SIP代理的證書；接收所述證書；驗證所述證書和所述第一SIP代理的網(wǎng)絡(luò)的可信度；當(dāng)所述證書和所述網(wǎng)絡(luò)的所述可信度被驗證時保持身份信息；當(dāng)TLS未被支持時，或者當(dāng)所述證書未被驗證時，或者當(dāng)所述網(wǎng)絡(luò)的所述可信度未被驗證時，去除所述身份信息；以及對所述SIP請求做出響應(yīng)。
33.根據(jù)權(quán)利要求32所述的計算機(jī)程序，其中所述驗證所述證書的步驟包括確定所述證書是否有效。
34.根據(jù)權(quán)利要求32所述的計算機(jī)程序，其中所述驗證所述網(wǎng)絡(luò)的所述可信度的步驟包括確定所述網(wǎng)絡(luò)是否屬于受托網(wǎng)絡(luò)組。
35.根據(jù)權(quán)利要求34所述的計算機(jī)程序，其中所述確定所述網(wǎng)絡(luò)是否屬于受托網(wǎng)絡(luò)組的步驟包括確定所述網(wǎng)絡(luò)是否在受托網(wǎng)絡(luò)的列表上。
36.根據(jù)權(quán)利要求32所述的計算機(jī)程序，其中所述第一SIP代理先前發(fā)送過在先的證書，而所述驗證所述證書的步驟包括確定所述在先的證書是否仍然有效。
全文摘要
一種用于處理用戶身份和隱私的方法，其中第一會話發(fā)起協(xié)議(SIP)代理要轉(zhuǎn)發(fā)SIP請求到下一SIP代理，包括確定在去往下一SIP代理的跳躍中是否支持傳輸層安全(TLS)的步驟。當(dāng)TLS被支持時，該方法包括建立到去往下一SIP代理的跳躍的TLS連接，請求來自下一SIP代理的證書，接收證書，驗證證書和下一SIP代理的網(wǎng)絡(luò)的可信度，而當(dāng)證書和網(wǎng)絡(luò)的可信度被驗證時保持身份信息。當(dāng)TLS未被支持時，或者當(dāng)證書未被驗證時，或者當(dāng)網(wǎng)絡(luò)的可信度未被驗證時，去除身份信息。隨后，通過TLS連接轉(zhuǎn)發(fā)SIP請求。
文檔編號H04L12/56GK1951061SQ200580014131
公開日2007年4月18日 申請日期2005年4月29日 優(yōu)先權(quán)日2004年5月3日
發(fā)明者加博·巴科, 米格爾·A·加西亞·馬丁, 瓦爾特里·尼米, 托·奧克卡 申請人:諾基亞公司