[發明專利]組密鑰管理中實現新組員注冊的方法、裝置及系統

無效

• 申請號: 200710136336.0
• 申請日: 2007-07-24
• 公開（公告）號: CN101355425A
• 公開（公告）日: 2009-01-28
• 發明（設計）人: 劉亞
• 申請（專利權）人: 華為技術有限公司
• 主分類號: H04L9/32
• 分類號: H04L9/32;H04L12/56;H04L29/06
• 代理公司: 北京德琦知識產權代理有限公司
• 代理人: 宋志強;麻海明

技術領域

本發明涉及組密鑰管理技術，特別涉及組密鑰管理中實現新組員注冊的方法、裝置及系統。

背景技術

互聯網協議安全(IPsec，IP?Security)是一組安全協議的總稱，包括密鑰管理和數據安全，以點對點的方式工作在IP層，能夠提供授權、認證、密鑰協商、密鑰更新、數據安全等服務。開放最短路徑優先路由協議第3版(OSPFv3，Open?Shortest?Path?First?version?3)是一種域內路由協議。RFC4552提出了如何用IPsec來解決OSPFv3的安全問題，針對OSPFv3運行于多播網絡上的情況，提出了用組安全聯盟(GSA，Group?Security?Association)來解決安全問題，讓網絡上的路由器共享同樣的組安全算法以及密鑰，即路由器在獲得的GSA的保護下進行OSPF通信，建立路由。

但RFC4552只規定了如何使用GSA來解決OSPFv3的安全問題，但并沒有同時提供一種自動組密鑰管理機制，只建議了手工配置的方式。組密鑰管理中很重要的一部分為組密鑰的動態更新，即當組密鑰到期或泄漏時，必須用新的密鑰替換原來的密鑰，即路由器必須在組密鑰更新后，獲得更新后的GSA。這種情況下手工配置就存在可擴展性差、安全性低的缺點，不適合多播網絡較多、路由器數量較大的情況。

基于上述問題，OSPF和路由協議安全需求(RPSEC，Routing?ProtocolSecurity?Requirements)工作組提出了組密鑰管理機制，該組密鑰管理機制基于多播安全(MSEC，Multicast?Security)工作組制定的組密鑰管理(GKM，Group?Key?Management)協議，目的在于在組密鑰動態更新后使路由器能自動獲得更新后的GSA，以此來代替手工配置的方法。

draft-liu-ospfv3-automated-keying-req討論了基于MSEC的GKM協議實現OSPFv3?IPsec組密鑰管理中具體的需求。

用MSEC的GKM協議實現組密鑰管理存在如下問題：MSEC的GKM協議基于客戶端/服務器模型，要求客戶端和服務端之間必須可達，也就是該協議運行時必須存在從客戶端到服務器的路由。但在OSPFv3?IPsec的應用場景中，路由是由OSPFv3路由器建立的，建立過程需要MSEC的GKM協議的保護，這種保護由組控制器和密鑰管理服務器(GCKS，GroupController?Key?Server)中的組安全聯盟(GSA，Group?Security?Association)協議提供。路由器必須先從GCKS下載GSA后才能建立路由，但沒有建立路由之前，路由器又無法從GCKS下載GSA，形成了矛盾。

進一步，由于GSA的傳輸也需要安全保護，通常將路由器從GCKS獲得GSA的過程包含在MSEC的GKM協議注冊過程中。所述注冊的第一階段為路由器作為組員向GCKS請求認證和密鑰協商，此處的密鑰指保證傳輸GSA安全的由路由器和GCKS兩兩協商的密鑰，成功后與GCKS建立經過認證的加密通道，加密通道即指路由器和GCKS在交互中使用協商的密鑰解析接收到的各種消息；所述注冊的第二階段為路由器通過所述加密通道向GCKS請求GSA下載，并獲得GSA。不論在哪一個階段，都可以將從路由器向GCKS發送的請求報文稱為原始注冊請求報文，而將GCKS返回的攜帶請求處理結果的響應報文稱為原始響應報文，區別在于不同注冊階段的上述報文中攜帶的參數和內容不同。路由器和GCKS不斷重復通過原始注冊請求報文和原始響應報文進行的交互，直到路由器通過原始響應報文獲得GCKS提供的GSA，注冊過程的所有階段結束。

考慮到GSA傳輸的安全性，解決MSEC的GKM協議實現OSPFv3?IPsec組密鑰管理中存在的問題，需要GCKS本地可達，即路由器必須能在一跳內訪問GCKS，運行注冊過程以獲得GSA。為此，draft-liu-ospfv3-automated-keying-req提出了3種可能的GCKS部署場景，下面簡述這3種部署場景。

第一、在每個需要自動組密鑰管理服務的OSPFv3多播網絡上都部署一個GCKS，該GCKS可以是物理的，也可以是邏輯的，即GCKS由OSPFv3路由器擔任。