專利名稱：一種實現(xiàn)組播成員認證的方法及系統(tǒng)的制作方法
技術(shù)領域：
本發(fā)明涉及組播技術(shù)，特別涉及一種實現(xiàn)組播成員認證的方法及系統(tǒng)。
背景技術(shù)：
隨著視頻會議、遠程教學、視頻點播等應用在因特網(wǎng)上的開展，組播技 術(shù)的優(yōu)勢和重要性逐漸顯現(xiàn)出來。采用組播技術(shù)后，主機可以動態(tài)地加入或 離開某一個組，發(fā)送源只需將一個報文發(fā)送到一個組地址，網(wǎng)絡中的路由器 就會將這個報文轉(zhuǎn)發(fā)給每一個組成員。組播既不向廣播那樣產(chǎn)生大量的廣播 報文，也不像單播那樣需要發(fā)送者給每一個接收者都傳送一次報文。因此，組 播技術(shù)能夠有效地降低某些應用的網(wǎng)絡帶寬。在網(wǎng)絡中為了支持組播技術(shù)，
前提條件有兩個①所有的主機和路由器需要運行因特網(wǎng)組管理協(xié)議；②所 有路由器至少要支持一種組播路由協(xié)議。因特網(wǎng)組管理協(xié)議的主要功能是在 一個子網(wǎng)內(nèi)，為主機和路由器提供必要的信息交互，以幫助主機動態(tài)地加入 和離開某個特定的組播組。在IPv4網(wǎng)絡中使用的組管理協(xié)議是IGMP。
下面先介紹IGMPvl,雖然目前大多數(shù)設備都支持IGMPv2,但是仍有許 多設備在使用IGMPvl。 IGMPvl的工作原理是路由器定期向子網(wǎng)內(nèi)廣播查 詢報文，探察子網(wǎng)內(nèi)是否有組成員，主機如果想加入某個組播組，就向路由 器發(fā)送報告報文；主機如果想離開某個組播組，就對路由器的查詢保持沉默， 經(jīng)過一定時間，路由器便知道子網(wǎng)內(nèi)沒有組成員了。 IGMP報文利用IP協(xié)議 發(fā)送。在IP數(shù)據(jù)報文中，將協(xié)議字段置為2,表示承載的是IGMP報文；同 時，將TTL字段置為1，表示IGMP報文只能在本子網(wǎng)內(nèi)傳送。
而針對IGMPvl的主要缺點，離開延遲過大和選擇查詢路由器需要依賴 組播路由協(xié)議進行，IGMPv2做了相關的改進。在IGMPv2中，增加了離開 組的報文格式，當主機想要離開時，只需向路由器發(fā)送離開報文即可，這樣
4可以有效地縮短離開延遲。另外在IGMPv2中，還明確了查詢路由器的選舉 機制。除此之外，IGMPv2的工作原理與IGMPvl基本一致。
而IGMPv3的提出，主要是為了配合源特定組播的實現(xiàn)。源特定組播 (Source Specific Multicast, SSM)是一種區(qū)別于傳統(tǒng)組4番的新的業(yè)務才莫型， 它使用組，燔組地址和組播源地址同時來標志一個組"t番會話，而不是向傳統(tǒng)的 組播服務那樣只使用組播組地址來標志一個組播會話。
IGMPv3的報文類型有以下幾種
0xl 1 ，成員關系查詢才艮文(Membership Query);
0x22,片反本3成員關系才艮告l艮文(version 3 Membership Report);
0x12,版本1成員關系才艮告才艮文(version 1 Membership Report);
0x16 ，版本2成員關系報告才艮文(version 2 Membership Report);
0x17,版本2離開報文(version 2 Leave Group)。
報文類型的值填寫在報文中的類型字段。在IGMPv3中,查詢報文和報告 報文格式有較大差異，需要分別描述。
圖1為查詢"t艮文的格式，其中
類型字段，8bits。置為Oxll，代表該報文為查詢報文。
最大響應時間字段，8bits。指明了主機發(fā)出響應報告的最長時間。
組地址字l殳，32bits。功能與v2—樣，可以用于通用查詢和組特定查詢。
S字段，lbit。置為1時，其他路由器不對該報文進行處理。
QRV字段，3bits。查詢路由器的健壯值(Querier，s Robustness Variable),該 值影響計時器和重試次數(shù)的取值。
QQIC字I殳，8bits。查詢i 各由器的查詢間隔碼(Querier，s Query Interval Code),該值影響查詢路由器的查詢間隔時間，非查詢路由器按照此值更 新自己的缺省值。
源地址數(shù)目字段，16bits。該值代表在這個報文中包含了多少個源地址。 當進行通用查詢(General Query)或者組特定查詢(Group-specific Query)時，該值置為0;當進行組-源特定查詢(Group-Source-specific Query,用于 PIM-SSM)時，該值為源特定地址的數(shù)目。
源地址地段，每個源地址占用4個字節(jié)，32bits。
IGMPv3報告報文的格式較為復雜，如圖2所示。其主要內(nèi)容有
類型字段，8bits。置為0x22,表示該報文為IGMPv3報告報文。
組記錄數(shù)目字段，16bits。表示此報文中包含的組記錄數(shù)目。
組記錄字段，包含若干個組記錄，每個組記錄長度不固定，其內(nèi)容如圖 2所示。
組記錄類型字段，8bits。表示該組記錄中包含的數(shù)據(jù)的類型，目前定義 了六種類型，分別是
MODE—ISJNCLUDE,表示該主機的過濾模式為INCLUDE,也就是說， 后面列出的地址都是主機想要接收的組播源地址。
MODE—IS—EXCLUDE,表示該主才幾的過濾才莫式為EXCLUDE,也就是i兌， 后面列出的地址都是主機想要拒絕的組播源地址。
CHANGE—TO—INCLUDE—MODE,表示該主才幾的過濾才莫式從EXCLUDE 切換為INCLUDE模式。
CHANGE—TO—EXCLUDE—MODE,表示該主機的過濾模式從INCLUDE 切換為EXCLUDE模式。
ALLOW—NEW—SOURCES,表示該主才幾中新增的想要4妄收的源地址。
BLOCK—OLD—SOURCES，表示從該主才幾中刪除的不想接收的源地址。
② 輔助數(shù)據(jù)長度字段，8bits。在組記錄的最后，可以增加以4字節(jié)為單 位的輔助數(shù)據(jù)，如果沒有輔助數(shù)據(jù)，則置為0。
③ 源地址數(shù)目字段，8bits。表示該記錄中包含了多少個組播源地址。
④ 組地址字段，32bits。與源地址共同表示源特定組播。
⑤ 源地址字段，每個長度為32bits。標志源地址，數(shù)目由源地址數(shù)目字 段表示。⑥輔助數(shù)據(jù)字段，為將來的應用預留，在IGMPv3中并不需要。
IGMPv3除了支持原特定組播外，其工作原理與IGMPv2相比，并沒有 本質(zhì)的改變，只是在某些地方做了改進和優(yōu)化。以下列出了 IGMPv3的主要 特點和改進支持源特定組播SSM;向后兼容IGMPvl和IGMPv2;主機可 以定義要接收的組播源地址；非查詢路由器可以與查詢路由器保持參數(shù)值同 步；最大響應時間從25.5s增加到53min,適合于較大的網(wǎng)絡；輔助數(shù)據(jù)字段 為將來的應用預留了空間；關系成員報告報文發(fā)送給目的地址224. 0. 0. 22, 可以幫助二層交換機更有效地實現(xiàn)IGMP監(jiān)聽(IGMP Snooping)功能；報 告報文中可以包含多個組記錄，可以有效地減少網(wǎng)絡通信量；在IGMPv3中， 取消了前面版本中的響應抑制功能。在查詢報文中，增加了S標志位，可以 提高系統(tǒng)的健壯性。
但是，在當前的IP組播通信模型中，任何主機都可以加入組播組從而接 收組播數(shù)據(jù)，任何主機都可以向組播組發(fā)送組播數(shù)據(jù)。其中沒有任何組播組 成員認證、訪問控制機制，這樣容易導致拒絕服務(DoS)攻擊和重放攻擊 (有人可以在認證信息在網(wǎng)絡中傳輸?shù)臅r候?qū)λM行復制，即使這些信息經(jīng) 過了加密，然后在以后進行重放，從而獲得不正當?shù)脑L問)。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是，提供一種實現(xiàn)組播成員認證的方法及系統(tǒng)。
為了解決上述問題，本發(fā)明公開了一種實現(xiàn)組播成員認證的方法，包括
主機向路由器發(fā)送組管理協(xié)議IGMPv3才艮文以請求加入組，播組，其中， 所述IGMPv3報文中攜帶有組播成員認證信息；
所述路由器收到所述IGMPv3報文后，獲取其中的組播成員認證信息， 根據(jù)所述組播成員認證信息對所述主機客戶進行認證，并將認證成功或者失 敗的信息返回給所述主機。
進一步地，上述方法中，所述主機向所述路由器發(fā)送的組管理協(xié)議 IGMPv3報文為IGMPv3報告報文，其中，所述IGMPv3報告報文的源地址字段中攜帶有所述組播成員認證信息。
進一步地，上述方法中，所述路由器通過IGMPv3查詢報文將認證成功 或者失敗的信息返回給所述主機，其中，所述IGMPv3查詢報文的Resv字段 中攜帶認證成功或者失敗的信息。
其中，所述主機通過Kerberos認證服務獲取所述組播成員認證信息，其 中，所述組播成員認證信息包括加密的認證列表以及服務票據(jù)。
所述路由器收到攜帶所述組播成員認證信息的IGMPv3報文后，對所述 組播成員認證信息中的認證列表以及服務票據(jù)分別進行解密，若解密后的服 務票據(jù)中的列表信息與解密后的認證列表信息相一致，則所述路由器將認證
成功的信息返回給所述主機。
本發(fā)明還公開了一種實現(xiàn)組播成員認證的系統(tǒng)，包括主機和路由器，其
中
所述主機，用于向所述路由器發(fā)送組管理協(xié)議IGMPv3報文以請求加入 組播組，其中，所述IGMPv3報文中攜帶有組播成員認證信息；
所述路由器，用于接收所述IGMPv3報文，從中獲取組播成員認證信息， 根據(jù)所述組播成員認證信息對所述主機客戶進行認證，以及用于將認證成功 或者失敗的信息返回給所述主機。
進一步地，上述系統(tǒng)中，所述主機向所述路由器發(fā)送的組管理協(xié)議 IGMPv3報文為IGMPv3報告報文，其中，所述IGMPv3報告報文的源地址 字段中攜帶所述組播成員認證信息。
進一步地，上述系統(tǒng)中，所述路由器通過IGMPv3查詢報文將認證成功 或者失敗的信息返回給所述主機，其中，所述IGMPv3查詢報文的Resv字段 中攜帶認證成功或者失敗的信息。
其中，該系統(tǒng)還包括Kerberos認證服務器，所述Kerberos認i正服務器， 用于向所述主機提供所述組播成員認證信息，其中，所述組播成員認證信息 包括加密的認證列表以及服務票據(jù)。
8所述路由器，從所述IGMPv3報文中獲取組播成員認證信息后，對所述
組播成員認證信息中的認證列表以及服務票據(jù)分別進行解密，若解密后的服 務票據(jù)中的列表信息與解密后的認證列表信息相一致，則所述3各由器將認證
成功的信息返回給所述主機。
本發(fā)明技術(shù)方案，使得組播的安全性有了很大保證，結(jié)合了當前廣泛流 行的IGMP協(xié)議在管理組播成員的同時既實現(xiàn)了對特定組播成員的認證又可 以防止DoS和重方丈攻擊，而且還可以降低網(wǎng)絡流量。


圖1為現(xiàn)有IGMPv3查詢報文格式示意圖； 圖2為現(xiàn)有IGMPv3報告報文格式示意圖； 圖3為Kerberos認證協(xié)議流程圖； 圖4為本實施例中組播成員認證系統(tǒng)結(jié)構(gòu)示意圖； 圖5為本實施例的方法流程圖6為本實施例中擴展的IGMPv3報告報文格式示意圖； 圖7為本實施例中擴展的IGMPv3查詢報文格式示意圖。
具體實施例
本發(fā)明的主要構(gòu)思是，可以利用IGMPv3的輔助數(shù)據(jù)字段傳輸Kerberos 認證信息，即在每個第一次加入的組播報文中添加得到的用會話密鑰加密票 據(jù)信息，而路由器得到第一次加入請求解密認證信息，實現(xiàn)成員認證。并在 發(fā)送給組播成員的查詢信息中加入成功或者失敗認證信息。
其中，Kerberos認證是一種在開放式網(wǎng)絡環(huán)境下進行身份認證的方法， 其采用的加密體制是對稱密鑰體制，其動作過程如圖3所示
①客戶請求Kerberos認證服務器發(fā)給接入Kerberos TGS(門票分配服務 器)的門票。查找客戶機，如果存在則產(chǎn)生一個會話密
鑰,Kerberos使用客戶的密鑰對此會話密鑰進行加密；然后生成一個TGT(門 票分配許可證),該許可證包括客戶實體名、地址、TGS名、時間印記、時限、 會話密鑰等信息；并用TGS的秘密密鑰(此密鑰只有認證服務器和TGS知道) 對TGT進行加密；認證服務器把這兩個加密報文發(fā)還給客戶。
③ 客戶將第一個報文解密得到會話密鑰,然后生成一個認證列表，包括客 戶實體名、地址及時間印記，并用會話密鑰對認證列表進行加密。然后，向 TGS發(fā)出請求，申請接入某一 目標服務器的門票。此請求包括目標服務名稱、 收到Kerberos發(fā)來的加過密的TGT以及加密的認證列表。
④ TGS用其密鑰對TGT進行解密，使用TGT中的會話密鑰對認證列表 進行解密。然后將認證列表中的信息與TGT中的信息進行比較。此時，TGS 產(chǎn)生新的會話密鑰供客戶實體與目標服務器使用,利用客戶實體和TGS用的 會話密鑰將新的會話密鑰加密;還將新的會話密鑰加入客戶向該服務器提交 的有效門票之中，門票中還包括客戶實體名、網(wǎng)絡地址、服務器名、時間印記、 時限等，并用目標服務器的密鑰將此門票加密；然后將這兩個報文發(fā)送給客 戶。
⑤ 客戶將接收到的報文解密后,獲得與目標服務器共用的會話密鑰。這時, 客戶制作一個新的認證列表，并用獲得的會話密鑰對該認證列表進行加密。 當請求進入訪問目標服務器時,將加密的認證列表和從TGS收到的門票一并 發(fā)送給目標服務器。由于此認證列表有會話密鑰加密的明文信息，從而證明發(fā) 信人知道該密鑰。
目標服務器對門票和認證列表進行解密檢查,包括地址、時間印記、時 限等。如果一切都核對無誤,服務器則知道了客戶實體的身份,并與之共享一個 可用于他們之間秘密通信的加密密鑰。
下面結(jié)合附圖及具體實施例對本發(fā)明技術(shù)方案作進一步詳細說明。
一種實現(xiàn)安全組播成員認證的系統(tǒng)，如圖4所示，包括主機HOST、路 由器，以及Kerberos認證服務器，其中，Kerberos認證服務器進一步包括KDC( Key Distribution Center,密鑰分配中心)和TGS( Ticket-Granting Server, 票據(jù)授權(quán)服務器)。下面介紹各部分的功能。
HOST,用于在加入組播之前，根據(jù)當前的用戶名、密鑰和IP地址用TCP 連接發(fā)送票據(jù)請求給KDC，獲得TGS票據(jù)，并在成功獲得TGS票據(jù)后繼續(xù) 用TCP連接發(fā)送用戶名、密鑰和TGS票據(jù)給TGS獲得SERVER票據(jù)；如果 獲得TGS票據(jù)不成功則直接按照正常IGMPv3協(xié)議運行，即發(fā)送無認證信息 的IGMPv3 report報文，如果成功獲得SERVER票據(jù)，則通過IGMPv3報告 報文將組播成員認證信息(即用戶本身信息組成的認證列表以及SERVER票 據(jù))發(fā)送給路由器；
其中，HOST成功獲得SERVER票據(jù)后，先4全查當前加入組播的方式是 否包括源地址，即是否有IN或EX的地址信息，如果有則將源地址先加入源 地址字段，后面加入組播成員認證信息，設置類型并將列表信息長度設為源 地址數(shù)+認證信息長度。
HOST必須運行TCP/IP協(xié)議棧；協(xié)議棧實現(xiàn)的IGMP為第三版本；并且 要有協(xié)議棧的源代碼。本實施例中，修改IGMPv3的協(xié)議格式，包括輔助字 段設為1,即使用最后4個字節(jié)。在輔助字段設置為認證類型(8位)、源地 址數(shù)目(16位)和認證數(shù)據(jù)長度(8位)；其中認證類型為設置為3種分別 為
① EXCLUDE—WITHOUT—SRC
在第一次加入組播的報告報文中沒有需要排除的源地址，即可以接收任 何源地址發(fā)送給該組的數(shù)據(jù)。
② EXCLUDE—WITH—SRC
在第 一次加入組播的報告報文中有需要排除的源地址，即不接收源地址 列表中的源地址發(fā)送給改組的數(shù)據(jù)，可以接收其他源地址發(fā)送給該組的數(shù)據(jù)。
③ INCLUDE—WITH—SRC
在第一次加入組播的報告報文中指定了接收哪些源地址發(fā)送的數(shù)據(jù)，即 只接收源地址列表中的源地址發(fā)送給該組的數(shù)據(jù)。在第 一次加入組播的報告報文中有需要排除的源地址，即不接收排除列 表中源地址發(fā)送給改組的數(shù)據(jù)，可以接收其他源地址發(fā)送給該組的數(shù)據(jù)。
路由器，用于管理組播成員，發(fā)送IGMPv3查詢報文，負責轉(zhuǎn)發(fā)組播報 文等，當其收到用戶的加入組播的report報文，首先檢查是否有Kerberos認 證信息，如果有再檢查是否有源地址要包括或排除，如果有按照源地址數(shù)目 找到認證信息，如果沒有可以直接取出組播成員認證信息；以及用于使用user 和Server的會話密鑰解密整個組^番成員iU正信息，用server密鑰解密 SERVER票據(jù)；檢查用戶的信息；通過時間戳來檢查票據(jù)的有效性；通過已 有的票據(jù)來判斷該票據(jù)是否重用。如果驗證成功則對該組發(fā)送組播查詢報文， 在查詢報文中加入認證成功信息，并將該票據(jù)存儲，用來保證后面的票據(jù)重 用。如果驗證失敗則在查詢才艮文中加入失敗信息。并且對成功加入的組l番組 定時發(fā)送組播查詢報文。
在其他實施例中，如果路由器沒有發(fā)現(xiàn)Kerberos認證信息，檢查該用戶 是否已經(jīng)加入到組播中，如果已經(jīng)加入則繼續(xù)維護該用戶；如果沒有則直接 發(fā)送組播查詢信息，在查詢報文中加入失敗信息。
Kerberos認證服務器中KDC和TGS可以用任何形式實現(xiàn)，既可以運行 在主機上、服務器上或者任何可以實現(xiàn)socket程序的平臺上。且這兩個服務 器均采取TCP服務器端設計來保證數(shù)據(jù)傳輸?shù)目煽啃?，支持多線程的運行， 保證可以多個TCP連接。整個KDC和TGS服務器里保存有各個用戶的信息， 包括用于Kerberos認i正的用戶名、密鑰、IP地址、時間戳等。由于Kerberos 認證協(xié)議是基于堆成密鑰提出的，因此要保證KDC中保存有用戶密鑰和TGS 密鑰；TGS中保存有TGS密鑰和SERVER密鑰。
其中，KDC,主要用于向HOST返回TGS票據(jù)，具體地，KDC收到HOST 發(fā)送的成員信息后，在數(shù)據(jù)庫中查找該用戶，如果該用戶存在，則產(chǎn)生第一 會話密鑰，并使用該用戶的客戶密鑰對第一會話密鑰進行加密，然后生成一 個TGT,該TGT包括客戶實體名、地址、TGS名、時間印記、時限、會話
12密鑰等信息，再用TGS密鑰對所述TGT進行加密，并將對加密的會話密鑰 以及加密的TGT返回給HOST。
TGS，主要用于向HOST返回SERVER票據(jù)，具體地，TGS收到HOST 的SERVER票據(jù)請求后，TGS根據(jù)自己的TGS密鑰對加密的TGT進行解密， 使用第一會話密鑰對加密的認證列表進行解密，然后將解密后的認證列表中 的各種信息與TGT中的認證列表的各種信息進行比較，如果比較后發(fā)現(xiàn)兩者 一致，TGS則產(chǎn)生第二會話密鑰供客戶實體與目標服務器使用，并使用第 一會話密鑰對第二會話密鑰進行加密；TGS還根據(jù)客戶實體名、網(wǎng)絡地址、 服務器名、時間印記、時限等信息生成SERVER票據(jù)，并用路由器密鑰將 SERVER票據(jù)加密，之后，TGS將加密后的第二會話密鑰以及加密后的 SERVER票據(jù)一起返回給HOST。
在其他實施例中，上述系統(tǒng)也可以采用除Kerberos認證以外的其他認證 方式來給主機提供組播成員認證信息，而路由器則根據(jù)主機發(fā)送的播成員認 證信息進行認證處理即可。
下面介紹上述系統(tǒng)實現(xiàn)組播成員認證的具體過程，如圖5所示，包括以 下步驟
步驟501: HOST向KDC發(fā)送成員信息，請求接入Kerberos TGS的門
票；
步驟502: KDC收到HOST發(fā)送的成員信息后，在數(shù)據(jù)庫中查找該用戶， 如果該用戶存在，則產(chǎn)生第一會話密鑰，并使用該用戶的客戶密鑰對第一會 話密鑰進行加密，然后生成一個TGT,該TGT包括客戶實體名、地址、TGS 名、時間印記、時限、會話密鑰等信息，再用TGS密鑰對所述TGT進行加 密，并將對加密的會話密鑰以及力口密的TGT返回給HOST;
步驟503: HOST收到加密的第一會話密鑰以及力口密的TGT后，根據(jù)自 己的客戶密鑰對加密的第一會話密鑰解密得到第一會話密鑰，然后生成一個 認證列表，該認證列表包括客戶實體名、地址及時間印記信息，然后使用第一會話密鑰對生成的認證列表進行加密，并向TGS發(fā)出請求以申請接入某一 目標服務器的門票(即SERVER票據(jù))，該請求中包括目標服務器信息(如 服務器名稱及網(wǎng)絡地址等)、加密的TGT以及加密的認證列表；
步驟504: TGS收到上述請求后，TGS根據(jù)自己的TGS密鑰對加密的 TGT進行解密，使用第一會話密鑰對加密的認證列表進行解密，然后將解密 后的認證列表中的各種信息與TGT中的認證列表的各種信息進行比較，如果 比較后發(fā)現(xiàn)兩者一致，TGS則產(chǎn)生第二會話密鑰供客戶實體與目標服務器 使用，并使用第一會話密鑰對第二會話密鑰進行加密；TGS還根據(jù)客戶實體 名、網(wǎng)絡地址、服務器名、時間印記、時限等信息生成SERVER票據(jù)，并用 路由器密鑰將SERVER票據(jù)加密，之后，TGS將加密后的第二會話密鑰以及 加密后的SERVER票據(jù)一起返回給HOST;
步驟505: HOST收到加密后的第二會話密鑰以及力口密后的SERVER票 據(jù)后，使用第 一會話密鑰對加密的第二會話密鑰進行解密以得到第二會話密 鑰，然后，HOST制作一個新的認證列表，并用第二會活密鑰對新的認證列 表進行加密，將加密后的新的認證列表以及收到的SERVER票據(jù)一起作為組 播成員認證信息，通過IGMPv3報告報文發(fā)送給路由器；
該步驟中，HOST通過對IGMPv3協(xié)議字段的擴展以組播成員認證信息， IGMPv3報告報文的擴展如圖6，其中
輔助數(shù)據(jù)長度設置為l，即用輔助數(shù)據(jù)來配置擴展字段信息。
列表信息長度源地址數(shù)目+認證數(shù)據(jù)長度。
認證數(shù)據(jù)長度即獲得的組播成員認證信息和用戶信息加密后的長度。 源地址數(shù)目即IN或EX的地址數(shù)目。
認證類型在第一次加入組播的時候，每個網(wǎng)口對于新建組播組的初始 狀態(tài)均為MODE—IS_INCLUDE{NULL};這樣對于用戶加入設定組播組便有 3種方式 CHANGE—TO—EXCLUDE—MODE:直接加入組播組，沒有IN 或EX地址報；②CHANGE—TO—EXCLUDE—MODE:加入組播組并且不接收 EX內(nèi)的地址發(fā)來的報文③CHANGE—TO—INCLUDE—MODE:加入組播組并 且只接收IN內(nèi)地址發(fā)來的報文。
14步驟506:路由器收到上述IGMPv3報告報文后，從中獲取組播成員認 證信息，根據(jù)組播成員認證信息對該HOST進行認證，并將認證成功或者失 敗的信息通過IGMPv3查詢報文返回給HOST,在本實施例中，路由器通過 IGMPv3查詢報文的Resv字段表示認證成功或者失敗的信息，如圖7所示， 具體地，當認證成功時，路由器將Resv字段置為0,當認證失敗時，路由器 將Resv字段置為1;
該步驟中，路由器從IGMPv3報告報文中獲取力口密后的新的認證列表以 及收到的SERVER票據(jù)，根據(jù)第二會話密鑰解密新的認證列表，根據(jù)自身的 路由器密鑰解密SERVER票據(jù)，若解密后的新的認證列表的信息與解密后的 SERVER票據(jù)中的用戶信息相一致，則認為該HOST通過認證，則在IGMPv3 查詢報文中添加認證成功的信息，若解密后的新的認證列表的信息與解密后 的SERVER票據(jù)中的用戶信息不一致，則認為該HOST未通過認證，則在 IGMPv3查詢報文中添加認證失敗的信息。
在其他實施例中，路由器端還對擴展的IGMPv3報告報文中的組播成員 認證信息進行檢查，如果收到的組播報告報文中沒有需要排除/包括的地址 數(shù)目，則可以直接取出里面的組播成員認證信息進行驗證，包括SERVER票 據(jù)的有效性，用戶的合法性等。如果收到的組播報告中有需要排除/包括的地 址數(shù)目，則需要先按照地址數(shù)目提出這些地址后取出組播成員認證信息進行 驗證。
從上述實施例可以看出，本發(fā)明技術(shù)方案利用目前研究和應用都很廣泛 的Kerberos認證協(xié)議來擴展IGMPv3未使用的輔助字段，達到既兼容IGMP 的組播管理功能，又擴展實現(xiàn)組播成員認證，在組播的安全性上做了很大的 提高。并且，本發(fā)明技術(shù)方案屬于安全組播和組播用戶管理的研究領域，可 以廣泛應用在視頻會議、遠程教學、視頻點播等應用領域。
以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本 領域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和 原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明所附的 權(quán)利要求的保護范圍之內(nèi)。
權(quán)利要求
1、一種實現(xiàn)組播成員認證的方法，其特征在于，包括主機向路由器發(fā)送組管理協(xié)議IGMPv3報文以請求加入組播組，其中，所述IGMPv3報文中攜帶有組播成員認證信息；所述路由器收到所述IGMPv3報文后，獲取其中的組播成員認證信息，根據(jù)所述組播成員認證信息對所述主機客戶進行認證，并將認證成功或者失敗的信息返回給所述主機。
2、 如權(quán)利要求1所述的方法，其特征在于，所述主機向所述路由器發(fā)送的組管理協(xié)議IGMPv3報文為IGMPv3報告 報文，其中，所述IGMPv3報告報文的源地址字段中攜帶有所述組播成員認 證信息。
3、 如權(quán)利要求l所述的方法，其特征在于，所述路由器通過IGMPv3查詢報文將認證成功或者失敗的信息返回給所 述主機，其中，所述IGMPv3查詢報文的Resv字段中攜帶認證成功或者失敗 的信息。
4、 如權(quán)利要求l、 2或3所述的方法，其特征在于，所述主機通過Kerberos認證服務獲取所述組播成員認證信息，其中，所 述組播成員認證信息包括加密的認證列表以及服務票據(jù)。
5、 如權(quán)利要求4所述的方法，其特征在于，所述路由器收到攜帶所述組播成員認證信息的IGMPv3報文后，對所述 組播成員認證信息中的認證列表以及服務票據(jù)分別進行解密，若解密后的服 務票據(jù)中的列表信息與解密后的認證列表信息相一致，則所述路由器將認證 成功的信息返回給所述主機。
6、 一種實現(xiàn)組播成員認證的系統(tǒng)，其特征在于，包括主機和路由器， 其中所述主機，用于向所述路由器發(fā)送組管理協(xié)議IGMPv3報文以請求加入 組播組，其中，所述IGMPv3報文中攜帶有組播成員認證信息；所述路由器，用于接收所述IGMPv3報文，從中獲取組播成員認證信息， 根據(jù)所述組播成員認證信息對所述主機客戶進行認證，以及用于將認證成功 或者失敗的信息返回給所述主機。
7、 如權(quán)利要求6所述的系統(tǒng)，其特征在于，報文，其中，所述IGMPv3報告報文的源地址字段中攜帶所述組播成員認證信息。
8、 如權(quán)利要求6所述的系統(tǒng)，其特征在于，所述路由器通過IGMPv3查詢才艮文將認證成功或者失敗的信息返回給所 述主機，其中，所述IGMPv3查詢報文的Resv字段中攜帶認證成功或者失敗 的信息。
9、 如權(quán)利要求6、 7或8所述的系統(tǒng)，其特征在于，該系統(tǒng)還包括Kerberos認證服務器，所述Kerberos認證服務器，用于向 所述主機提供所述組播成員認證信息，其中，所述組播成員認證信息包括加 密的認證列表以及服務票據(jù)。
10、 如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述路由器，從所述IGMPv3報文中獲取組播成員認證信息后，對所述組播成員認證信息中的認證列表以及服務票據(jù)分別進行解密，若解密后的服 務票據(jù)中的列表信息與解密后的認證列表信息相一致，則所述路由器將認證成功的信息返回給所述主機。
全文摘要
本發(fā)明涉及一種實現(xiàn)組播成員認證的方法及系統(tǒng)，屬于組播技術(shù)。本發(fā)明方法包括主機向路由器發(fā)送組管理協(xié)議IGMPv3報文以請求加入組播組，其中，所述IGMPv3報文中攜帶有組播成員認證信息；所述路由器收到所述IGMPv3報文后，獲取其中的組播成員認證信息，根據(jù)所述組播成員認證信息對所述主機客戶進行認證，并將認證成功或者失敗的信息返回給所述主機。本發(fā)明技術(shù)方案，使得組播的安全性有了很大保證，結(jié)合了當前廣泛流行的IGMP協(xié)議在管理組播成員的同時既實現(xiàn)了對特定組播成員的認證又可以防止DoS和重放攻擊，而且還可以降低網(wǎng)絡流量。
文檔編號H04L29/06GK101635724SQ20091015980
公開日2010年1月27日 申請日期2009年6月30日 優(yōu)先權(quán)日2009年6月30日
發(fā)明者姚愛娣, 超 童, 軍 苗, 笑 譚, 鄧紅平, 研 閆 申請人:中興通訊股份有限公司