CN101174944A

CN101174944A - Conversation key distribution method across-gatekeeper control limit under direct routing mode

Info

Publication number: CN101174944A
Application number: CNA2007101814702A
Authority: CN
Inventors: 李昆
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2005-02-04
Filing date: 2005-02-04
Publication date: 2008-05-07

Abstract

The present invention provides the distribution method of conversation encryption keys striding the gatekeeper management range under the mode of direct route; the core is that the attributive gatekeeper of the calling/called node decides the distribution pattern of the conversation encryption keys of the calling and the called side according to the information bearing in the received message and the preset regulation of selecting the distribution pattern of the conversation encryption keys and then distributes the conversation encryption keys for the calling and the called nodes. The attributive gatekeeper of the calling node can flexibly select the distribution method of the conversation encryption keys between the calling and the called nodes according to the actual situation of network; in this way, the distribution of conversation encryption keys by the attributive gatekeeper is more flexible and the security level of the message transmission and the delay of the message transmission can be balanced.

Description

The conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern

Technical field

The present invention relates to the network communications technology field, be specifically related to the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern.

Background technology

The H323 system is based on that PBN (packet network) that no QOS (service quality) guarantees realizes.Because the technical reason of PBN itself makes PBN that QOS can not be provided, and safe service can not be provided.In the H323 system, how in good time safe service is provided is very important.

Description of before the H235 agreement V3 version some be used for the discriminating and the secrecy technology of H323 system, but all be the technical scheme of supposition under GK (pass is kept) route pattern situation.The appendix I of H235 agreement V3 version has proposed a kind of safety approach of direct route, and this scheme is mainly utilized the fundamental characteristics of H235V3 appendix D and appendix F, and the security service of H323 system communication is provided, but is limited in the GK range of management.

In the network environment of reality, the H323 system can comprise two or more GK usually, and the networking logic diagram that the H323 system comprises two GK as shown in Figure 1.

Among Fig. 1, dotted line is represented the RAS message transmission in the H225 agreement, and solid line is represented Q931 transmission of messages in the H225 agreement.EPa represents two different H323 nodes with EPb, and GKg represents two different GK with GKh.GKg is the ownership GK of EPa, and GKh is the ownership GK of EPb.

When the H323 system comprises two or more GK; usually can be by the booking-mechanism before calling out, making has shared key K ag between caller node EPa and the GKg, between called node EPb and the GKh shared key K bh is arranged; shared key K gh is arranged, to guarantee the reliable transmission of RAS message between GKg and the GKh.

When adopting direct route pattern to call out between EPa and the Epb, for guaranteeing the reliable transmission of Q931 message, both sides need obtain the session key that directly transmits Q931 message between EPa and the Epb by the reliable transmission of RAS message.

At present, the distribution method of calling and called node session key mainly contains two kinds:

Method one, close the encryption key distribution mode that produces session key of keeping based on the ownership of called node.

The specific implementation process is: among Fig. 1, caller node EPa sends ARQ (calling out the request of access) message to GKg, carried a ClearToken (expressly mark) in the ARQ message, the tokenOID among this ClearToken is set to " I0 " and shows that EPa supports H235V3 appendix I.

GKg is after receiving the ARQ message that EPa sends, destinationInfo or destCallSignalAddress field according to the ARQ message bearing determine that called node is Epb, because Epb does not belong to its administration, so GKg initiates the address of LRQ (Location Request) message to GKh inquiry EPb.EndpointIdentifier in the LRQ message is the node ID (identifier) of caller node EPa.

GKg if find that the tokenOID of ClearToken in the message is " I0 ", determines that then EPa supports H235V3 appendix I function when transforming ARQ message, so also generate a ClearToken in LRQ message, tokenOID wherein also is " I0 ".If GKg does not support appendix I, just need not create tokenOID in LRQ message is the ClearToken of " I0 ", and the subsequent treatment of message is carried out interacting message according to the common mode of not supporting appendix I.

GKh is after receiving LRQ message, and whether the tokenOID among the ClearToken of inspection message is " I0 ", if tokenOID is " I0 ", shows opposite end support appendix I.If GKh oneself also supports appendix I, just the called nodal information that provides according to LRQ is inquired about called node EPb and whether is supported appendix I.

GKh generates the shared key K ab between EPa and the EPb, and produce challenge at random, and with the shared key K gh between GKh and the GKg and challenge and specify key to derive algorithm key derivation EKgh, encrypt Kab with EKgh then and obtain EKab1, and EKab1 and encryption parameter are configured to one independently in the corresponding son field of ClearToken.h235Key.secureSharedSecret field.

If be provided with endpointIdentifier in the LRQ message, GKh need also be set to this field in the ClearToken.h235Key.secureSharedSecret.generalID field, and the algorithm configuration of using during with key derivation is to the ClearToken.h235Key.secureSharedSecret.keyDerivationOID field, the challenge that uses during with key derivation is set to the ClearToken.challenge field, ClearToken.generalID is set to the node ID of GKg simultaneously, ClearToken.senderID is set to the node ID of GKh, the tokenOID of ClearToken is set to " I3 " at last, below this ClearToken is designated as CTg.

Shared key K bh between GKh usefulness GKh and the EPb and other challenge be key derivation EKbh together, and encrypt Kab with EKbh and obtain EKab2, and the initialization vector of using encrypted result EKab2 and encryption parameter such as cryptographic algorithm with when encrypting etc. is set in the h235Key.secureSharedSecret field of another one ClearToken together.

If be provided with endpointIdentifier in the LRQ message, GKh also needs this field also is set in the ClearToken.h235Key.secureSharedSecret.generalID field, the challenge that uses during with key derivation is set to the ClearToken.challenge field, ClearToken.generalID is set to the node ID of EPb, ClearToken.senderID is set to the node ID of GKh, the tokenOID of this ClearToken is set to " I2 " at last, below, this ClearToken is designated as CTb.

After having carried out above-mentioned the setting, GKh issues GKg to LCF message.

After GKg receives the LCF message that GKh sends, take out independently ClearToken information, if plural ClearToken is arranged in the LCF message, and the tokenOID of one of them ClearToken is " I3 ", be CTg, the tokenOID of another one ClearToken is " I2 ", and promptly CTb shows that then GKh, EPb agree to use the safety approach of appendix I.

GKg structure ACF (calling admission confirm) message, create a ClearToken, tokenOID wherein is set to " I1 ", choosing a challenge at random is set among the CTa.challenge, the parameter such as the challenge that utilize CTg to provide, key is derived algorithm, cryptographic algorithm, initialization vector that encryption is used etc. and the key Ekgh that utilizes challenge and Kgh to derive, deciphering CT3.h235Key.secureSharedSecret.encryptedSessionKey obtains key K ab, GKg is according to Kag and CTa.challenge key derivation EKag, encrypt Kab and encrypted result and encryption parameter are set in the corresponding son field among the CTa.h235Key.secureSharedSecret with EKag, CTb.generalID is copied to CTa.h235Key.secureSharedSecret.generalID, CTb is copied in the ACF message, at last, ACF message is issued node EPa.

After Epa receives ACF message, extract CTa and CTb, and obtain key K ab with the key EKag deciphering CTa.h235Key.secureSharedSecret.encryptedSessionKey that the shared key K ag that utilizes EPa and GKg derives according to the information among the CTa.

Epa is after obtaining session key Kab, promptly can utilize this key to create Setup message, CTb in the ACF message is copied in the Setup message, utilize then and share the authentication information that key K ab is provided with H235V3 appendix D scheme, EPa directly sends Setup message to Epb.

After Epb receives Setup message, extract CTb, utilize Kbh key derivation EKbh according to CTb.genralID and CTb.sendersID and CTb.challenge information, and deciphering CTb.h235Key.secureSharedSecret.encryptedSessionKey obtains key K ab.

EPb carries out authentication according to Kab to Setup message, and carries out follow-up Q931 transmission of messages.

In the method, session key Kab between caller node, the called node will encrypt in each jumping of GK, decrypting process, when GK progression more for a long time, can increase message transmission time delay, and session key only closes by the ownership of called node and keeps generation, and security service end to end can not be provided.

Method two, close based on the ownership of caller node and called node and to carry out the session key distribution mode that DH consults between keeping.

The specific implementation process is: among Fig. 1, when caller node Epa sends ARQ message to GKg, independently ClearToken is set in ARQ message, tokenOID wherein is " I0 ", EPa produces and is used for the public-key cryptography that DH consults, and be arranged among the ClearToken.dhkey, EPa with the ARQ transmission of messages to GKg that it belonged to.

After the GKg of support appendix I receives ARQ message, inquire about called node Epb, because EPb is not in its range of management, so GKg initiates LRQ message to GKh, carry independently ClearToken in the LRQ message, wherein the tokenOID field is " I0 ", and the content in the dhkey field of the content of dhkey field and ARQ message is the same.

After GKg receives LRQ message, when determining that according to the ClearToken.tokenOID among the LRQ and called Pb the calling and called node is all supported appendix I, GKh creates a ClearToken, tokenOID is set is " I2 ", below, this ClearToken is designated as CTb.

GKh produces the PKI that DH consults, and the DH PKI in the LRQ message of receiving uses the session key Kab that directly transmits Q931 message between DH algorithm computation egress.

GKh produces a challenge at random, is set among the CTb.challenge, then according to this challenge and Kbh key derivation EKbh and KSbh.GKh produces an initialization vector IV at random, is set among the CTb.h235Key.securitySharedSecret.paramS.IV respectively.GKh is ENC _{EKbh, KSbh, IV}(K _Ab) be set among the CTb.h235Key.securitySharedSecret.encryptedSessionKey.

GKh comprises DH PKI and the CTb that GKh produces in LCF, send LCF message to GKg.

GKg obtains CTb and dhkey information, and it is copied in the ACF message after receiving the LCF message that GKh sends, and ACF message is issued node EPa.

After Epa receives ACF message, obtain the DH PKI, and go out session key Kab by the DH algorithm computation with oneself DH PKI according to the dhkey in the message.

Epa is after obtaining session key Kab, promptly can utilize this key to create Setup message, CTb in the ACF message is copied in the Setup message, utilize to share the authentication information that key K ab is provided with H235V3 appendix D scheme then, Epa with the Setup transmission of messages to Epb.

After Epb receives Setup message, extract CTb, and utilize Kbh key derivation EKbh according to CTb.genralID and CTb.sendersID and CTb.challenge information, deciphering CTb.h235Key.secureSharedSecret.encryptedSessionKey obtains key K ab, and EPb carries out authentication according to Kab to Setup message.

This method needs terminal and GK all to support the DH negotiations process, and its scope of application is restricted.

In sum, existingly can not keep selection by the pass for the method for calling and called node assign sessions key, exist message transmission time delay big, can not provide security service end to end, the scope of application not extensively, shortcomings such as conversation key distribution method very flexible.

Summary of the invention

The objective of the invention is to, the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern is provided, make the ownership pass of node keep the method for salary distribution that to select session key, close the law-abiding purpose that the flexibility of session key, the safe class that makes transmission of messages and message transmission time delay average out of joining to realize raising.

For achieving the above object, the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern provided by the invention comprises:

The ownership of calling/called node is closed the pre-defined rule of keeping according to loaded information in the message that receives, the selection session key distribution mode that sets in advance and is determined calling/called side's session key distribution mode, and is calling and called node assign sessions key.

Described pre-defined rule comprises: calling party's pre-defined rule, callee's pre-defined rule;

Described calling party's pre-defined rule comprises: close available computational resources and/or the session key distribution mode of caller node support and/or the level of security of caller node of keeping;

Described callee's pre-defined rule comprises: the available computational resources that the pass is kept and/or the level of security of calling party's session key distribution mode and/or called node.

Described method specifically comprises:

A, caller node are carried on the session key distribution mode of its support to call out and insert the pass that transfers to its ownership in the request message and keep;

The ownership of b, described caller node is closed to keep according to calling out the session key distribution mode information, the described pre-defined rule that insert the caller node support of carrying in the request message and is determined calling party's session key distribution mode, and it is carried on the ownership that transfers to called node in the locating request message closes and keep;

The ownership of c, described called node is closed to keep according to loaded information, described pre-defined rule in the locating request message and is determined callee's session key distribution mode, and calculate the internodal session key of described calling and called, callee's session key distribution mode, described session key are closed to the ownership of caller node by the positioning confirmation transmission of messages keep;

The ownership of d, described caller node is closed to keep according to the session key distribution mode of loaded information, the support of caller node in the positioning confirmation message and is determined session key, and described session key is transferred to described calling and called node by calling out access confirmation message.

Described step a further comprises:

The caller node is carried on " I0 " among the tokenOID that calls out the plaintext mark that inserts request message when not supporting that DH consults, and the pass that transfers to its ownership is kept;

The caller node is carried on " I4 " among the tokenOID of the plaintext mark of calling out the access request message when supporting that DH consults, and the DH PKI of caller node is carried among the dhkey of described plaintext mark, and the pass that transfers to its ownership is kept.

Calling party's session key distribution mode among the described step b comprises: the ownership of called node is closed and is kept the ownership that produces session key and/or calling and called node and close and carry out that DH consults between keeping and/or the ownership of caller node and called node is closed and carried out the DH negotiation between keeping.

Described step b further comprises:

Close to keep when the ownership of described caller node and determine that calling party's session key distribution mode is that the ownership of called node is closed and kept when producing session key, " I0 " is carried among the tokenOID of the plaintext mark in the locating request message, the ownership pass that transfers to called node is kept;

Close to keep when the ownership of described caller node and determine that calling party's session key distribution mode is that the ownership of calling and called node is closed and carried out DH between keeping when consulting, the ownership of described caller node is closed to keep and is produced its DH PKI, and be carried among the dhkey of the plaintext mark in the locating request message, " I4 " is carried among the tokenOID of described plaintext mark, and the ownership pass that transfers to called node is kept;

Close to keep when the ownership of described caller node and determine that calling party's session key distribution mode is that the ownership of caller node and called node is closed when carrying out the DH negotiation between keeping, the plaintext mark that described calling is inserted in the request message is carried in the locating request message, and the ownership pass that transfers to called node is kept.

Callee's session key distribution mode comprises among the described step c: the ownership of called node is closed to keep and is produced session key and/or DH negotiation.

Described step c further comprises:

Close to keep when the ownership of described called node and determine that callee's session key distribution mode is that the ownership of called node is closed and kept when producing session key, generate the internodal session key of calling and called, and to generate tokenOID be CTb, the tokenOID of " I2 " CTg for " I3 ", keeps by positioning confirmation transmission of messages to the ownership pass of caller node;

Close to keep when the ownership of described called node and determine that callee's session key distribution mode is that DH is when consulting, produce the DH PKI, and described DH PKI and the DH PKI that obtains gone out session key by the DH algorithm computation together from locating request message, generating tokenOID is the plaintext mark that the ownership of described called node is closed the DH PKI of keeping generation for the CTb of " I2 " and tokenOID for " I5 " and dhkey, described CTb and described plaintext mark is closed to the ownership of caller node by the positioning confirmation transmission of messages keep.

Described steps d specifically comprises:

The ownership of described caller node is closed the callee's session key distribution mode information of carrying in the positioning confirmation message of obtaining of keeping, and judges;

Keep the generation session key if this information is the ownership pass of called node, generate CTa, the CTb in described CTa, the positioning confirmation message is transferred to the caller node by calling out access confirmation message according to the CTg that carries in the positioning confirmation message;

Consult and determine that the caller node do not support DH to consult if this information is DH, close the DH PKI of keeping according to the ownership of the called node in its DH PKI, the positioning confirmation message and pass through DH algorithm computation session key, and produce CTa, the CTb in described CTa, the positioning confirmation message is transferred to the caller node by calling out access confirmation message;

If this information is DH consults and determine that the caller node supports DH to consult, obtain the plaintext mark in the described positioning confirmation message, and it is carried on to call out in the access confirmation message transfers to the caller node;

Described caller node judges to call out whether comprise the plaintext mark of tokenOID for " I5 " in the access confirmation message;

Be not the plaintext mark of " I5 " if do not comprise tokenOID, according to itself and ownership close the shared key between keeping, the CTa in the calling access confirmation message calculates session key;

If comprise the plaintext mark of tokenOID, close the DH PKI session key of keeping according to the ownership of the called node that carries in its DH PKI, the described calling access confirmation message for " I5 ";

Described caller node is provided with the authentication information of call setup message according to described session key, simultaneously, described CTb is carried on transfers to called node in the call setup message;

Described called node obtains described session key according to the CTb in the described call setup message, and according to described session key call setup message is carried out authentication, determines the caller node;

Described called node is defined as described caller node carries out the transmission of messages of direct route pattern with it session key with described session key.

Described method also comprised before step a:

Node finds its information-bearing of supporting DH to consult to ask in the gatekeeper/and the pass that transfers to its ownership in the plaintext mark of login request message is kept.

Description by technique scheme as can be known, the present invention is provided with the method for salary distribution that it chooses session key by closing to keep at calling and called, the ownership of calling and called node is closed keep and can select the internodal session key of calling and called flexibly according to the concrete condition of network; Pass among the present invention is kept can be when the calling and called node not all be supported the DH negotiations process, carry out DH between ownership by the calling and called node is closed and kept and consult to distribute the internodal session key of calling and called, for the calling and called node provides a kind of new security service end to end, the fail safe that has improved session key; Thereby realized improving ownership by technical scheme provided by the invention and closed the law-abiding purpose that the flexibility of session key, the safe class that makes transmission of messages and message transmission time delay average out of joining.

Description of drawings

Fig. 1 is the networking logic diagram that comprises the H323 system of two GK.

Embodiment

Core of the present invention is: the ownership of calling/called node is closed the pre-defined rule of keeping according to loaded information in the message that receives, the selection session key distribution mode that sets in advance and is determined calling/called side's session key distribution mode, and is calling and called node assign sessions key.

Based on core concept of the present invention technical scheme provided by the invention is further described below.

The present invention is applicable to that the H323 system strides the direct route pattern of GK range of management, and promptly calling/called node is registered in respectively on the different calling/called GK, and communication process carries out on the IP network that does not have fail safe to guarantee.

The prerequisite of implementing technical solution of the present invention is: GK carries out authentication to all RAS messages of its management node, and node also carries out authentication to the RAS message of the GK of its ownership, makes the purpose that reaches mutual trust between the GK of node and its ownership.Also carry out mutual authentication between the interconnective GK, avoid the malicious attack between the GK territory, make the purpose that reaches mutual trust between the interconnective GK.Guaranteed the H.323 fail safe of RAS channel between the entity by above-mentioned authentication process.

The present invention at first needs to be provided with closes the pre-defined rule of keeping selection session key distribution mode, and this pre-defined rule can be arranged on to close and keep by modes such as static configuration, dynamic-configuration.

Pre-defined rule can be kept residing calling and called side according to the pass and is divided into: calling party's pre-defined rule and callee's pre-defined rule.The content that calling/called side's pre-defined rule comprises can be set according to the actual needs in the real network, can comprise following one or multinomial as calling party's pre-defined rule: close the session key distribution mode of keeping available computational resource, caller node and supporting, the level of security of caller node etc., callee's pre-defined rule can comprise following one or multinomial: close the level of security of keeping passable computational resource, calling party's session key distribution mode, called node etc.

After carrying out above-mentioned the setting, calling and called close keeps the method for salary distribution that all can choose session key according to factors such as its busy extent flexibly.

Below by following three kinds of processes the ownership of calling and called node of the present invention is closed to keep and exercise the session key distribution right to choose simultaneously and realize that the session key distribution process is described in detail.

The assigning process of three kinds of session keys is respectively:

DRC I: the ownership GK that caller, called party's session key distribution mode is called node produces session key.

DRC II: calling party's session key distribution mode is that the ownership of calling and called node is closed and to be carried out that DH consults and callee's session key distribution mode is that DH consults between keeping.

DRC III: calling party's session key distribution mode is that the ownership of caller node and called node is closed and to be carried out that DH consults and callee's session key distribution mode is that DH consults between keeping.

Node among the present invention can show to the GK of its ownership whether it supports DH to consult in the GK discovery procedure or in the node registration process, in GRQ/RRQ (gatekeeper finds request/register requirement) message, carry independent ClearToken as node, tokenOID in this ClearToken of node is set to " I0 ", show that it does not support DH to consult, when the tokenOID among this ClearToken of node is set to " I4 ", show that its support DH consults.The GK of node ownership receives GRQ/RRQ message, and according to the tokenOID loaded information of the ClearToken that independently carries in the message, can determine whether this node supports the DH negotiations process, the ownership GK of node determines whether to accept this node according to management strategy, and reply GCF/RCF (gatekeeper finds affirmation/accreditation verification) message, carry in the GCF/RCF message with GRQ/RRQ message in identical ClearToken.

When the caller node is not supported the DH negotiations process, the ownership GK of caller node can select DRCI, DRCII process to distribute the internodal session key of calling and called respectively according to calling party's pre-defined rule, and the ownership GK of called node can select DRCI, DRCII process to distribute the internodal session key of calling and called equally.

When the caller node is supported the DH negotiations process, the ownership GK of caller node can select DRCI, DRC III process to distribute the internodal session key of calling and called respectively, and it is main by internodal session key that the ownership GK of called node can select DRC I, DRC III process to distribute equally.

Ownership GK below in conjunction with 1 pair of calling and called node of accompanying drawing realizes that by DRC I, DRC II, DRC III process the internodal session key distribution process of calling and called is described in detail:

Before the step 1 of DRCI process, caller node EPa use direct route pattern to call out called node EPb, caller node EPa sends ARQ message to the GKg of its ownership, should comprise an independently ClearToken in this message, the tokenOID of this ClearToken should be set to " I0 ", show that the caller node do not support DH to consult, other fields of this ClearToken are not used.

The step 2 of DRCI process, GKg are after receiving the ARQ message that EPa sends, determine that according to destinationInfo in the ARQ message or destCallSignalAddress called node is Epb, because EPb is the node in the compass of competency to one's name not, so GKg need initiate the address information of LRQ message to GKh inquiry EPb.

GKg generates LRQ message, GKg is determining that for " I0 " and calling party's pre-defined rule calling party's session key distribution mode is that the ownership of called node is closed when keeping the generation session key according to the tokenOID of the ClearToken of ARQ message, make and comprise a ClearToken in the LRQ message, the tokenOID of this ClearToken should be set to " I0 ", show that calling party's session key distribution mode is that the ownership of called node is closed and to be kept the generation session key, other fields among this ClearToken are not used, after carrying out above-mentioned the setting, GKg sends LRQ message to GKh.

The step 3 of DRCI process, GKh receive LRQ message, at the tokenOID of the ClearToken of check in this message be " I0 " and when determining to use the ownership GK of called node to produce session key according to callee's pre-defined rule, uses random number generation session key Kab.GKh at first, produces challenge at random in order to encrypt Kab, and the key of the shared key K gh between use GKh and the GKg and challenge and appointment is derived algorithm key derivation EKgh.Then, GKh encrypts Kab with EKgh and obtains EKab1, and EKab1 and encryption parameter such as cryptographic algorithm and the initialization vector of using etc. together, is set to one independently in the ClearToken.h235Key.secureSharedSecret field.The tokenOID of this ClearToken is " I3 ", is called CTg.Simultaneously, GKh uses similar process to produce another ClearToken, and the tokenOID of this ClearToken is " I2 ", i.e. CTb.At last, GKh generates LCF message, comprises CTg and CTb in this LCF message.GKh directly is sent to GKg with LCF message, or sends LCF message to the upper level GK of GKh, until transferring to GKg.

The step 4 of DRCI process, GKh receive LCF message, when the tokenOID of ClearToken is " I3 " in this message of check, and deciphering CTg, and produce CTa.Detailed process is as follows: at first, GKg derives algorithm key derivation EKgh by the key of challenge, IV among the CTg and appointment.Then, GKg obtains Kab with EKgh deciphering EKab1.In order to produce CTa, at first, GKg derives algorithm key derivation EKag with the key of the shared key K ag between GKg and the EPa and challenge and appointment.Then, GKg encrypts Kab with EKag and obtains EKab1, and EKab1 and encryption parameter such as cryptographic algorithm and the initialization vector of using etc. are set to one independently in the ClearToken.h235Key.secureSharedSecret field together.The tokenOID of this ClearToken is " I1 ", be called CTa.At last, GKg generates ACF, wherein comprises the CTb that duplicates in the LCF message of CTa and its reception.

If have next stage GK in the GKg range of management, then should comprise CTa and CTg among the ACF, next stage GK uses its key derivation with GKg to encrypt the Kab generation.

After carrying out above-mentioned the setting, GKg sends ACF message to EPa.

The step 5 of DRCI process, Epa receive ACF message, from this message, extract CTa, and according to the shared key K ag key derivation EKag of the information among the CTa and itself and GKg, then, use EKag deciphering CTa.h235Key.secureSharedSecret.encryptedSessionKey to obtain session key Kab.

EPa creates Setup message, and the CTb in the ACF message is copied in the Setup message, utilizes session key Kab that the authentication information of H235V3 appendix D/ appendix F is set then.EPa directly sends call setup request message Setup to EPb.

Epb receives Setup message, from this message, extract CTb, and, use EKbh to decipher CTb.h235Key.secureSharedSecret.encryptedSessionKey then and obtain session key Kab according to information among the CTb and its shared key K bh key derivation EKbh with GKh; At this moment, EPb just can use Kab that Setup message is carried out authentication, according to the definite caller node that sends Setup message of authenticating result, session key K ab is defined as carrying out between Epb and the Epa session key of Q931 transmission of messages.

Follow-up calling procedure utilizes H235 appendix D/ appendix F to differentiate.

Before the step 1 of DRCII process, caller node EPa use direct route pattern to call out called node EPb, caller node EPa sends ARQ message to the GKg of its ownership, should comprise an independently ClearToken in this message, the tokenOID of this ClearToken should be set to " I0 ", show that the caller node do not support DH to consult, other fields of this ClearToken are not used.

The step 2 of DRCII process, GKg receive the ARQ message that EPa sends, determine that according to destinationInfo in the ARQ message or destCallSignalAddress called node is Epb, because the node that EPb does not to one's name administer, so GKg initiates the address of LRQ message to GKh inquiry EPb.

GKg generates LRQ message, GKg is determining that for " I0 " and calling party's pre-defined rule calling party's session key distribution mode is that the ownership GK of calling and called node carries out DH when consulting during the generation session key according to the tokenOID of the ClearToken of ARQ message, in this message, comprise a ClearToken, tokenOID among the ClearToken is " I4 ", show that calling party's session key distribution mode is that the ownership GK of calling and called node carries out DH and consults, GKg produces the DH PKI of GKg, and is arranged among the dhkey of this ClearToken.

After carrying out above-mentioned the setting, GKg sends LRQ message to GKh.

The step 3 of DRCII process, GKh receive LRQ message, when the tokenOID of ClearToken determined that for " I4 " and according to callee's pre-defined rule callee's session key distribution mode is the DH negotiation in checking this message, GKh began to use the DH negotiations process to determine the internodal session key of calling and called with GKg.Detailed process is: at first, GKh generates the DH PKI of expectation GKh, with the PKI of the GKg that obtains from LRQ message, uses the DH algorithm computation to go out session key Kab.Then, using the method generation tokenOID of the step 3 of DRC I process is the CTb of " I2 ".At last, GKh generates LCF message, wherein comprises independently ClearToken of CTb and, and the tokenOID of this ClearToken is " I5 ", and comprises the DH PKI of GKh.The tokenOID of ClearToken includes called node for " I5 " promptly shows among this ClearToken ownership is closed the DH PKI of keeping.

If GKh is not owing to support factors such as DH algorithm or security strategy do not allow to determine that according to callee's pre-defined rule callee's session key distribution mode is the ownership GK of called node when producing session key, then GKh should use the step 3 of DRCI process to generate LCF message.

After carrying out above-mentioned the setting, GKh sends LCF message to GKg.

The step 4 of DRC II process, GKg receive LCF message, and when comprising tokenOID not supporting that for the ClearToken of " I5 " and caller node DH consults in the check outbound message, session key also produces CTa.Detailed process is: the DH that independently obtains Gkh the ClearToken from LCF message is key altogether, uses the DH algorithm computation to go out session key Kab with the DH PKI of the GKg of own preservation.Then, the essentially identical process of step 4 generates CTa in use and the DRC I process.At last, GKg generates ACF message, the CTb that wherein comprises CTa and duplicate from LCF message.

If GKg comprises tokenOID in checking out LCF message when supporting that for the ClearToken of " I5 " and caller node DH consults, then GKg should use the step 4 of DRCIII process to generate ACF message.

When if GKg includes tokenOID for the ClearToken of " I3 " in checking out LCF message, GKg should use the step 4 of DRC I process to generate ACF message.

Carrying out the above-mentioned back GKg that is provided with to EPa transmission ACF message.

The step 5 of DRCII process, Epa receive ACF message, when if Epa does not comprise tokenOID for the ClearToken of " I5 " in checking out ACF message, from ACF message, extract CTa, and, use EKag to decipher CTa.h235Key.secureSharedSecret.encryptedSessionKey then and obtain session key Kab according to the information among the CTa and its shared key K ag key derivation EKag with GKg.

When if Epa comprises tokenOID for the ClearToken of " I5 " in checking out ACF message, calculate session key Kab according to the step 5 of DRCIII process.

EPa creates Setup message, and the CTb in the ACF message is copied in the Setup message, then, utilizes the internodal session key Kab of calling and called that the authentication information of H235V3 appendix D/ appendix F is set.EPa directly sends call setup request message Setup to EPb.

Epb receives Setup message, and from this message, extract CTb, and, use EKbh to decipher CTb.h235Key.secureSharedSecret.encryptedSessionKey then and obtain session key Kab according to information among the CTb and its shared key K bh key derivation EKbh with GKh.At this moment, EPb just can use session key Kab that Setup message is carried out authentication, according to the definite caller node that sends Setup message of authenticating result, session key K ab is defined as carrying out between Epb and the Epa session key of Q931 transmission of messages.

The step 1 of DRCIII process, caller node are supported the DH negotiations process, before caller node EPa uses direct route pattern to call out called node EPb, EPa generates the DH PKI of its expectation, and be arranged among the dhkey of independently ClearToken of ARQ message, the tokenOID of this ClearToken is set to " I4 ", and other fields are not used.

The step 2 of DRCIII process, GKg receive ARQ message, determine that according to destinationInfo in the ARQ message or destCallSignalAddress called node is Epb, because the node that EPb does not to one's name administer is so GKg initiates the address of LRQ message to GKh inquiry EPb.

GKg generates LRQ message, GKg is determining that for " I4 " and calling party's pre-defined rule calling party's session key distribution mode is that the ownership pass of caller node and called node is kept when carrying out the DH negotiation according to the tokenOID of the ClearToken of ARQ message, ClearToken in the ARQ message is copied in the LRQ message, and GKg sends LRQ message to GKh.

The step 3 of DRCIII process, GKh receive LRQ message, in checking out LRQ message, include tokenOID and determine that for the independent ClearToken of " I4 " and according to callee's pre-defined rule callee's session key distribution mode is that DH is when consulting, according to using the DH negotiations process to begin the consulting session key with EPa.Detailed process is: at first, GKh generates the DH PKI of expectation, with the DH PKI of the GKg that obtains from LRQ, uses the DH algorithm computation to go out session key Kab.Then, the method for the step 3 in use and the DRC I process generates CTb, and the tokenOID of this CTb is " I2 ".At last, GKh generates LCF message, wherein comprises independently ClearToken of CTb and, and the tokenOID among this ClearToken is " I5 ", and comprises the DH PKI of GKh.The tokenOID of ClearToken includes called node for " I5 " promptly shows among this ClearToken ownership is closed the DH PKI of keeping

After carrying out above-mentioned the setting, GKh sends LCF message to GKg.

The step 4 of DRC III process, GKg receive LCF message, when in checking out LCF message, including tokenOID and supporting that for the ClearToken of " I5 " and caller node DH consults, GKg generates ACF message, comprises all ClearToken that duplicate from LCF message in this message.GKg sends ACF message to EPa.

If GKg includes tokenOID in checking out LCF message when not supporting that for the ClearToken of " I3 " and definite caller node DH consults, GKg should use the step 4 in the DRCI process to generate ACF message.

The step 5 of DRCIII process, Epa receive ACF message, when in checking out this message, including tokenOID for the independent ClearToken of " I5 ", and session key.Detailed process is: Epa obtains called node from ClearToken ownership is closed the DH keep key altogether, together uses the DH algorithm computation to go out session key Kab with the common key of the own DH that preserves.

When Epa includes tokenOID for the independent ClearToken of " I3 " in checking out this message, should use the method for session key of the step 5 of DRCI process to come session key.

EPa creates Setup message, and the CTb in the ACF message is copied in the Setup message, utilizes then and shares the authentication information that key K ab is provided with H235V3 appendix D/ appendix F.EPa directly sends call setup request message Setup to EPb.

Epb receives Setup message, from this message, extract CTb, and according to the shared key K bh key derivation EKbh of the information among the CTb and itself and GKh, use EKbh deciphering CTb.h235Key.secureSharedSecret.encryptedSessionKey to obtain session key Kab then, at this moment, EPb just can use Kab that Setup message is carried out authentication, according to the definite caller node that sends Setup message of authenticating result, session key K ab is defined as carrying out between Epb and the Epa session key of Q931 transmission of messages.

The meaning of tokenOID identifier is as shown in table 1 among the present invention:

Table 1

Object Identifier Reference	Obj ect Identifier Value	Description
Object Identifier Reference	Obj ect Identifier Value	Description	" I0 "-	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 48}	1. in the independent ClearToken of GRQ/RRQ, GCF/RCF, ARQ, use, show that node Ep does not support the DH process.2. in the independent ClearToken of LRQ, use, show that this ClearToken comprises calling party's DH PKI.
" I1 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 49}	In giving the independent ClearToken of caller node, use, show among this ClearToken to comprise session key.	" I0 "-	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 48}
" I1 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 49}		" I2 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 50}	In giving the independent ClearToken of called node, use, show among this ClearToken to comprise session key.
" I3 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 51}	In the independent ClearToken of LCF, use, show that this ClearToken comprises session key.	" I2 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 50}
" I3 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 51}		" I4 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 52}	1. in the independent ClearToken of GRQ/RRQ, GCF/RCF, ARQ, use, show that EP supports the DH process.2. in the independent ClearToken of LRQ, use, show that this ClearToken comprises calling party's DH PKI.
" I5 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 53}	In giving the independent ClearToken of caller node, use, show the DH PKI that comprises the callee among this ClearToken.	" I4 "	{ itu-t (0) recommendation (0) h (8) 235 version (0) 3 52}

Though described the present invention by embodiment, those of ordinary skills know, the present invention has many distortion and variation and do not break away from spirit of the present invention, and the claim of application documents of the present invention comprises these distortion and variation.

Claims

1. the conversation key distribution method of across-gatekeeper control limit under the direct route pattern is characterized in that, comprising:

2. the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern as claimed in claim 1 is characterized in that described pre-defined rule comprises: calling party's pre-defined rule, callee's pre-defined rule;

3. the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern as claimed in claim 1 is characterized in that described method specifically comprises:

4. the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern as claimed in claim 3 is characterized in that described step a further comprises:

5. as the conversation key distribution method of across-gatekeeper control limit under claim 3 or the 4 described a kind of direct route patterns, it is characterized in that the calling party's session key distribution mode among the described step b comprises: the ownership of called node is closed and is kept the ownership that produces session key and/or calling and called node and close and carry out that DH consults between keeping and/or the ownership of caller node and called node is closed and carried out the DH negotiation between keeping.

6. the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern as claimed in claim 5 is characterized in that described step b further comprises:

7. as the conversation key distribution method of across-gatekeeper control limit under claim 3 or the 4 described a kind of direct route patterns, it is characterized in that callee's session key distribution mode comprises among the described step c: the ownership of called node is closed to keep and is produced session key and/or DH negotiation.

8. the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern as claimed in claim 7 is characterized in that described step c further comprises:

9. the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern as claimed in claim 8 is characterized in that described steps d specifically comprises:

10. the conversation key distribution method of across-gatekeeper control limit under a kind of direct route pattern as claimed in claim 3 is characterized in that described method also comprised before step a: