[發(fā)明專利]一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法

無效

• 申請?zhí)枺?/td>: 200710181470.2
• 申請日: 2005-02-04
• 公開（公告）號: CN101174944A
• 公開（公告）日: 2008-05-07
• 發(fā)明（設(shè)計）人: 李昆
• 申請（專利權(quán)）人: 華為技術(shù)有限公司
• 主分類號: H04L9/08
• 分類號: H04L9/08;H04L12/56
• 代理公司: 暫無信息
• 代理人: 暫無信息

技術(shù)領(lǐng)域

本發(fā)明涉及網(wǎng)絡(luò)通訊技術(shù)領(lǐng)域，具體涉及一種直接路由模式下跨關(guān)守管理范圍的會話密鑰分配方法。

背景技術(shù)

H323系統(tǒng)是基于無QOS(服務(wù)質(zhì)量)保證的PBN(分組網(wǎng)絡(luò))實現(xiàn)的。由于PBN本身的技術(shù)原因，使PBN不能夠提供QOS，也不能提供安全的服務(wù)。在H323系統(tǒng)中，如何提供適時安全的服務(wù)是非常重要。

H235協(xié)議V3版以前的版本描述了一些用于H323系統(tǒng)的鑒別和保密技術(shù)，但都是假定在GK(關(guān)守)路由模式情況下的技術(shù)方案。H235協(xié)議V3版的附錄I提出了一種直接路由的安全方案，這種方案主要利用H235V3附錄D和附錄F的基本特性，提供H323系統(tǒng)通信的安全服務(wù)，但是限制在一個GK管理范圍內(nèi)。

在實際的網(wǎng)絡(luò)環(huán)境中，H323系統(tǒng)通常會包括兩個或多個GK，H323系統(tǒng)包括兩個GK的組網(wǎng)邏輯框圖如附圖1所示。

圖1中，虛線表示H225協(xié)議中的RAS消息傳輸，實線表示H225協(xié)議中Q931消息傳輸。EPa和EPb表示兩個不同的H323節(jié)點，GKg和GKh表示兩個不同的GK。GKg是EPa的歸屬GK，GKh是EPb的歸屬GK。

當(dāng)H323系統(tǒng)包括兩個或多個GK時，通常會通過呼叫前的預(yù)約機(jī)制，使主叫節(jié)點EPa和GKg之間有共享密鑰Kag，被叫節(jié)點EPb和GKh之間有共享密鑰Kbh，GKg和GKh之間有共享密鑰Kgh，以確保RAS消息的可靠傳輸。

當(dāng)EPa和Epb之間采用直接路由模式進(jìn)行呼叫時，為保證Q931消息的可靠傳輸，雙方需要通過RAS消息的可靠傳輸來獲取EPa和Epb之間直接傳輸Q931消息的會話密鑰。

目前，主被叫節(jié)點會話密鑰的分配方法主要有兩種：

方法一、基于被叫節(jié)點的歸屬關(guān)守產(chǎn)生會話密鑰的密鑰分配方式。

具體實現(xiàn)過程為：圖1中，主叫節(jié)點EPa向GKg發(fā)送ARQ(呼叫接入請求)消息，ARQ消息中攜帶了一個ClearToken(明文標(biāo)記)，這個ClearToken中的tokenOID設(shè)置為″I0″表明EPa支持H235V3附錄I。

GKg在接收到EPa發(fā)來的ARQ消息后，根據(jù)ARQ消息承載的destinationInfo或者destCallSignalAddress字段確定被叫節(jié)點為Epb，由于Epb不屬于其管轄，所以，GKg發(fā)起LRQ(定位請求)消息向GKh查詢EPb的地址。LRQ消息中的endpointIdentifier為主叫節(jié)點EPa的節(jié)點ID(標(biāo)識符)。

GKg在轉(zhuǎn)化ARQ消息時，如果發(fā)現(xiàn)消息中ClearToken的tokenOID為″I0″，則確定EPa支持H235V3附錄I功能，于是在LRQ消息中也生成一個ClearToken，其中的tokenOID也為″I0″。如果GKg不支持附錄I，就不需要在LRQ消息中創(chuàng)建tokenOID為″I0″的ClearToken，且消息的后續(xù)處理按照不支持附錄I的普通方式進(jìn)行消息交互。

GKh在接收到LRQ消息后，檢查消息的ClearToken中的tokenOID是否為″I0″，如果tokenOID為″I0″，表明對端支持附錄I。如果GKh自己也支持附錄I，就根據(jù)LRQ提供的被叫節(jié)點信息，查詢被叫節(jié)點EPb是否支持附錄I。

GKh生成EPa和EPb之間的共享密鑰Kab，且產(chǎn)生隨機(jī)的challenge，并用GKh和GKg之間的共享密鑰Kgh和challenge以及指定密鑰導(dǎo)出算法導(dǎo)出密鑰EKgh，然后用EKgh加密Kab得到EKab1，并將EKab1和加密參數(shù)配置到一個獨立的ClearToken.h235Key.secureSharedSecret字段的對應(yīng)子字段中。

如果LRQ消息中設(shè)置了endpointIdentifier，GKh需要把這個字段也設(shè)置到ClearToken.h235Key.secureSharedSecret.generalID字段中，并將導(dǎo)出密鑰時用到的算法配置到ClearToken.h235Key.secureSharedSecret.keyDerivationOID字段，將導(dǎo)出密鑰時用到的challenge設(shè)置到ClearToken.challenge字段，同時將ClearToken.generalID設(shè)置為GKg的節(jié)點ID，ClearToken.senderID設(shè)置為GKh的節(jié)點ID，最后把ClearToken的tokenOID設(shè)置為″I3″，在后文中把這個ClearToken記為CTg。