CN101207478B

CN101207478B - Method for key agreement of guard end-to-end conversation in cross-domain multi-network

Info

Publication number: CN101207478B
Application number: CN2006101678455A
Authority: CN
Inventors: 卢忱; 王云峰; 陈剑勇; 胡焰龙; 张则宝
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2006-12-18
Filing date: 2006-12-18
Publication date: 2010-07-14
Anticipated expiration: 2026-12-18
Also published as: CN101207478A

Abstract

The invention discloses a cross-domain multi network keeper end-to-end session key negotiation method, which dynamically negotiates a best key negotiation method in the end-to-end communication through signaling execution flows of ARQ/ACF and LRQ/LCF based on that whether D-H key exchange algorithm and security strategy are supported by endpoints and the network keepers. The method comprises the following steps: a called network keeper generates the a sharing secret, a calling network keeper and a calling endpoint obtain the a session key according to the sharing secret, the calling network keeper and the called network keeper generate the session key by using the D-H key exchange algorithm, and the calling endpoint and the called network keeper generate the session key by using the D-H key exchange algorithm, thereby the generation and the exchange of the sharing secret or the session key are carried out among each endpoint, thus the limits of low efficiency and bad interconnection and interoperability, which are caused by the fact that the key negotiation method is based on pre-configuration, are overcome under the prior cross-domain multi network keeper end-to-end calling mode.

Description

A kind of method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field

Technical field

The present invention relates to the packet network communication security fields, relate in particular to end-to-end communication session keys machinery of consultation under the direct routing call pattern of a kind of cross-domain many gatekeepers.

Background technology

Based on the packet network communication security fields, key is of paramount importance, on the network H.323 between the end points by cipher key change resulting share or session key can be to RAS (registration, access and state) signaling, call signaling, H.245 control signaling etc. and implement identity and confirm, signaling message integrity checking and media data flow carried out safety measure such as enciphering/deciphering.

At present, many gatekeepers route pattern is shared down or the session key exchange method, and basic what adopt is pre-configured and out-of-band methods such as phone, E-Mail.

Directly routing call (hereinafter to be referred as DRC) pattern is an important method of call setup in the H.323 packet-based multimedia communications system.Because under the DRC pattern, (shared secret is with information such as user ID, password and random numbers can not to suppose have a pre-shared secret or session key between two end points, can generate session key by hashing algorithm), therefore, above institute's using method or be difficult to difficult arrangement, otherwise dangerous and can't use in practice.

H.235 standard definition a kind of based on protocol suite H.323; realize the communication security method; comprise Diffie-Hellman (Defo-Hellman is called for short D-H) public key cryptography IKE, random number generates shared secret and is carried out the key generation and the switching method of encipherment protection by symmetric cryptography.But a kind of cross-domain many gatekeepers' end-to-end key agreement and switching technology are not proposed, also do not consider the disposal ability that makes full use of end points and gatekeeper, and how dynamic negotiation goes out the cryptographic methods that a kind of both sides support to have the terminal of different key agreement abilities.Particularly under the direct routing call pattern of many gatekeepers environment H.323, existing terminal equipment possesses the multiple session key method of setting up, and under can not situation that in advance can be pre-configured between two end points of communication, brings difficulty for the communication security that interconnects.

Summary of the invention

The technical problem to be solved in the present invention just provides a kind of method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field, overcome under the present end-to-end call model of cross-domain many gatekeepers, cryptographic key negotiation method is based on pre-configured and efficient that bring is not high, the restriction of interconnecting property difference.

In order to solve the problems of the technologies described above, the invention provides a kind of method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field, comprise the steps:

(1) before calling endpoint is used direct routing call DRC calling called end point, calling endpoint is according to self-ability and security strategy, select whether to support the D-H Diffie-Hellman, and this information is put into calling insert request ARQ message, send to the gatekeeper that it belongs to, this gatekeeper is the caller gatekeeper;

(2) after the caller gatekeeper receives ARQ, initiate Location Request LRQ message, with inquiry address, called end point to called gatekeeper; In this LRQ message, the caller gatekeeper is according to calling endpoint and self-ability and security strategy, selects whether to support the D-H Diffie-Hellman, thereby selects a kind of method that generates session key for calling endpoint;

(3) after called gatekeeper receives LRQ, selection according to calling endpoint, caller gatekeeper, and whether called gatekeeper supports D-H Diffie-Hellman and security strategy, the final method of determining to generate session key, and put into positioning confirmation LCF message with this information and according to the shared secret that this method generates, be used for communicating by letter between calling endpoint and the called end point, LCF is sent to the caller gatekeeper;

(4) after the caller gatekeeper receives LCF message,, the shared secret that is used for calling endpoint is decrypted and then encrypts forwarding or directly transmits this shared secret, generate ACF message in view of the above and send to calling endpoint according to the method for fixed generation session key; Also duplicated the shared secret that is used for the called end point among the LCF in this ACF message;

(5) after calling endpoint is received ACF message,, extract the secret of sharing with the called end point, and then obtain session key according to fixed encryption key method.

Further, the method for generation session key comprises:

(a) produce shared secret by called gatekeeper, caller gatekeeper and calling endpoint obtain session key according to this shared secret;

(b) use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper;

(c) use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper.

Further, described ARQ, LRQ, LCF, ACF all comprise expressly mark ClearToken, tokenOID among the ClearToken is used to represent whether calling endpoint, caller gatekeeper, called gatekeeper support the D-H Diffie-Hellman, be used to perhaps represent that this ClearToken comprises shared secret, give calling endpoint or called end point and use.

Further, in the described step (1),, then its D-H PKI is placed in the dhkey territory among the ClearToken if select to use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper.

Further, in the described step (2), if calling endpoint is not supported the D-H Diffie-Hellman, and the caller gatekeeper supports the D-H Diffie-Hellman, selection uses the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, the caller gatekeeper produces the D-H PKI, and deposits this PKI among the LRQ dhkey territory among the ClearToken.

Further, in the described step (2), if use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper, then the ClearToken of the ARQ that calling endpoint is sent copies among the ClearToken of LRQ.

Further, in the described step (3), if calling endpoint and caller gatekeeper do not support the D-H Diffie-Hellman, perhaps called gatekeeper does not support D-H Diffie-Hellman or security strategy not to allow to use the D-H Diffie-Hellman, then produce shared secret by called gatekeeper, after this shared secret encrypted, put into the CTg.h235Key.secureSharedSecret field of LCF message with encryption parameter; Simultaneously, after called gatekeeper produced shared secret and encrypts, another that put into LCF message with encryption parameter was used for called end point ClearToken.

Further, in the described step (3), if calling endpoint is not supported the D-H Diffie-Hellman, but the security strategy of supporting D-H Diffie-Hellman and called gatekeeper between caller gatekeeper and the called gatekeeper allows to use the D-H Diffie-Hellman, then generate the D-H PKI by called gatekeeper, with the D-H PKI of caller gatekeeper in the LRQ together, use the D-H Diffie-Hellman to calculate the shared secret of session, this shared secret generates the ClearToken that the D-H PKI is put into LCF message with encryption parameter and called gatekeeper after encrypting; Simultaneously, after the shared secret that calculates was encrypted, another that put into LCF message with encryption parameter was used for called end point ClearToken.

Further, in the described step (3), calling endpoint selects to use the D-H Diffie-Hellman, and called gatekeeper's security strategy allows to use the D-H Diffie-Hellman, the D-H PKI that then called gatekeeper generates with the PKI that obtains from LRQ, uses the D-H Diffie-Hellman to calculate shared secret, this shared secret generates the ClearToken that the D-H PKI is put into LCF message with encryption parameter and called gatekeeper after encrypting; Simultaneously, after the shared secret that calculates was encrypted, another that put into LCF message with encryption parameter was used for called end point ClearToken.

Further, in the described step (4), the caller gatekeeper checks and receives LCF, if produce shared secret by called gatekeeper, then with the shared secret deciphering of encrypting among this LCF, encrypt again, and be saved in the CTA.h235Key.secureSharedSecret field of ClearToken of ACF with encryption parameter; To be used for called end point ClearToken simultaneously and copy to ACF.

Further, in the described step (4), the caller gatekeeper checks and receives LCF, if use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, from the ClearToken of LCF, obtain called gatekeeper's D-H PKI, the D-H PKI of preserving with the caller gatekeeper together uses the D-H Diffie-Hellman to calculate shared secret, and this shared secret is saved among the ClearToken of ACF with encryption parameter after encrypting; To be used for called end point ClearToken simultaneously and copy to ACF.

Further, in the described step (4), the caller gatekeeper checks and receives LCF, if use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper, then directly ClearToken all among the LCF is copied among the ClearToken of ACF.

Further, in the described step (5), the ACF that the calling endpoint inspection is received, if use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper, then obtain called gatekeeper's D-H PKI from the ClearToken of ACF, the D-H PKI of preserving with calling endpoint together uses the D-H Diffie-Hellman to calculate session key.

Further, in the described step (5), the ACF that the calling endpoint inspection is received, if called gatekeeper produces shared secret, or use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, then the shared secret key decryption according to the ClearToken information among the ACF and calling endpoint and caller gatekeeper obtains session key.

By above-mentioned steps, communicating pair (end points) is negotiable to go out a believable dynamic session, utilizes cryptography that itself and call authorization are bundled, and comprises calling out that session key refreshes demand in the control channel.

Advantage of the present invention has:

1. by dynamic adaptation terminal and gatekeeper's security capabilities, can improve the efficient of cipher key change, reduce time-delay and gatekeeper's processing load, in implementing the secure communication process, increase the flexibility that different security capabilities terminals interconnect simultaneously.

2. by means of ARQ/ACF, the LRQ/LCF signaling is carried out flow process, whether support public key cryptography and symmetric cryptographic algorithm based on end points and gatekeeper, dynamic negotiation goes out cryptographic key negotiation method optimum in a kind of end-to-end communication, and finish the shared secret between the end points or the generation and the exchange of session key with the method, set up security relationship for the subsequent voice calls signaling, prevent that signaling and data-message are forged, integrality and possible confidentiality lose.

3. safe practice of Cai Yonging and existing standard are compatible, and the layout of security system is also fairly simple, and do not need to suppose any additional security infrastructure method.

Along with the extensive H.323 arrangement and the application of multimedia communications system, as the VoIP net of global range or range of countries video conference/video-phone system towards the public etc., at this multi-operator, stride under a plurality of many gatekeepers of management domain layering DRC environment, use the more convenient practicality of method provided by the invention.

4. the inventive method also can be applied to other many gatekeepers call model, as part/routing mode, directly/and route, route/direct mode and gatekeeper's routing mode etc.

Description of drawings

Fig. 1 is the direct routing call pattern of a many gatekeepers scene;

Fig. 2 is that shared secret is consulted flow chart under the direct routing call pattern of many gatekeepers.

Embodiment

The present invention is described in detail below in conjunction with drawings and the specific embodiments.

Be explanation the inventive method, quote ability or the two combination that following symbol is represented end points and gatekeeper, perhaps be used for distinguishing the shared secret that preserve caller/called end point.

Symbol	The meaning of expression
Symbol	The meaning of expression	" I0 "	Show that calling endpoint do not support D-H, caller gatekeeper or called gatekeeper do not support the D-H Diffie-Hellman.

[0041]

" I1 "	Give among the upright ClearToken of calling endpoint and use, show among this ClearToken to comprise shared secret.
" I1 "		" I2 "	Give among the independent ClearToken of called end point and use, show among this ClearToken to comprise shared secret.
" I3 "	Show that calling endpoint do not support the G-H process, but the calling and called gatekeeper supports the D-H Diffie-Hellman.	" I2 "
" I3 "		" I4 "	The expression calling endpoint is supported the D-H Diffie-Hellman, and called gatekeeper supports the D-H Diffie-Hellman

The embodiment of the invention adopts the H.323 direct route pattern of system's cross-gate keeper range of management, and supposes that calling/called end points is registered in respectively on the different calling/called gatekeepers, and communication process is to carry out on the IP network that does not have fail safe to guarantee.The scene of using as shown in Figure 1.

Fig. 1 is the direct communication scenes figure in routing mode of many gatekeepers.Gatekeeper's cloud among the figure comprises one or more gatekeepers, and end points can be connected to identical or different gatekeeper.Directly in the routed call models, the gatekeeper does not participate in H.225.0 call control signalling, does not therefore carry out the signaling tunnel in H.225.0.Like this, the gatekeeper does not influence two tunnels between the end points of supporting the signaling tunnels.Directly in the routed call models, H.245 control channel can only directly connect between end points.Based on control channel H.245, finish real time data flow host-host protocol (RTP).

In communication process shown in Figure 1, at first, on the RAS channel, end points and gatekeeper exchange access message, exchange call signaling then on call signaling channel, are the H.245 foundation of control channel then.The gatekeeper has determined whether to use direct routing call pattern to the response that inserts message.Though end points can be specified preference, not receiving end point control of model selection.

In the embodiment of the invention, the gatekeeper authenticates and integrity checking all RAS messages of its management end points, end points authenticates and integrity checking the also RAS message to the gatekeeper, thereby make between end points and the affiliated gatekeeper and reach the mutual trust purpose, so that can check out the entity of swindle, and will be dropped to minimum by the swindle possibility.Also differentiate mutually between gatekeeper and the gatekeeper in the mid-level net cloud, avoid the malicious attack between the gatekeeper territory.Under these conditions, the H.323 fail safe of RAS channel between the end points can be guaranteed, the fail safe of call signaling can be realized based on this.

In the embodiment of the invention, method 1 expression produces shared secret by called gatekeeper, and then can generate session key; Method 2 expressions use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper; Method 3 expressions use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper.

Below in conjunction with Fig. 2 dynamic decision flow chart, illustrate according to the logical order of RAS signaling and call signaling three kinds of methods of the present invention are how to come out according to the security strategy dynamic negotiation, to carry out key agreement between the common support end points.

1.ARQ request stage:

Calling endpoint EpA is before using direct routing call call by pattern called end point EpB, EpA sends ARQ message to ownership GkG, comprise an independently ClearToken in the message, be assumed to be CTA, wherein whether tokenOID is according to supporting D-H to adopt different settings, and this can be set according to terminal capability and security strategy by the user.If hope on behalf of generating safe shared secret, provides a sign " I0 " by GK, other fields are not used; If EpA wishes to adopt D-H and called gatekeeper to consult shared secret, then in the dhkey territory that its D-H PKI is placed on, tokenOID is set a correlated identities " I4 ", other fields are not used.

2.LRQ request stage:

GkG judges and does not belong to same management domain after receiving the ARQ that EpA sends, and initiates the address of LRQ message to GkH inquiry EpB.LRQ message comprises a ClearToken, and the rule that is provided with of its inner each subdomain is adopted concrete key agreement rules to decide by EpA ability and GkG, specifically is provided with as follows:

When the tokenOID of the ClearToken among the ARQ is " I0 " time, if the caller gatekeeper does not support D-H cipher key change and negotiation, at this moment GkG generates LRQ (Fig. 2 numeral 1), comprise a ClearToken, wherein tokenOID is set to " I0 ", other fields of ClearToken are not used, and these are provided with explanation and will adopt method 1 to carry out key agreement, promptly need called GK to distribute shared secret, be assumed to be Kab.

When the tokenOID of the ClearToken among the ARQ is " I0 " time, GkG generates LRQ, if calling/called gatekeeper supports the D-H Diffie-Hellman, then comprise a ClearToken, wherein tokenOID is provided with an identifier, as " I3 ", show that it is the shared secret that two limit end points negotiate session that expectation is used the D-H Diffie-Hellman with called GK.(Fig. 2 numeral 4) GkG produces and is provided with dhkey among the ClearToken as the D-H PKI.

The tokenOID of ClearToken in ARQ is " I4 ", should can select the process of using method 3 according to security strategy.GkG generates LRQ (Fig. 2 numeral 9), wherein comprises the ClearToken that duplicates from ARQ.

3.LCF confirm

GkH receives behind the LRQ and identifies EpA and EpB supports this call model, carry out different cipher key agreement process according to the tokenOID of contained ClearToken and generate ClearToken independently based on the shared secret of calling out (, generating session key when communicating by letter later on) Kab and two based on this shared secret.One is used for caller gatekeeper Gkg, supposes to be called CTg; Another is used for called end point EpB, supposes to be called CTb.This Kab is then by using CTg and CTB to be pushed to GkG and EpB respectively.

According to the different value of tokenOID, the LCF specific practice of returning distinct methods is as follows:

3.1 if the tokenOID among the LRQ is " I0 ", show employing method 1.

" I0 " among the LRQ shows that calling endpoint and its ownership gatekeeper do not support the D-H Diffie-Hellman, requires called gatekeeper to generate shared secret for it.Under (Fig. 2 numeral 2) this situation, the LCF employing method of returning 1, its concrete setting up procedure is as follows:

GkH produces Kab at random.In order to encrypt Kab, at first, GkH produces challenge at random, and with and GkG between shared key K gh and key of key derivation algorithm derivation of challenge and configured in advance, as be made as EKgh.Then, GkH encrypts Kab with EKgh and obtains a shared secret, as be set at EKab1, and together EKab1 and encryption parameter (cryptographic algorithm and use initialization vector), be set in the CTg.h235Key.secureSharedSecret field, detail can be with reference to appendix I H.235, and the tokenOID that CTg is set is " I0 ".Simultaneously, GkH uses similar process to produce another ClearToken, tokenOID is set is " I2 ", is called CTb.At last, GkH generates LCF (Fig. 2 numeral 2), wherein comprises CTg and CTb.

3.2 if the tokenOID among the LRQ is " I3 ", show employing method 2 or method 1.

" I3 " shows that end points do not support the D-H Diffie-Hellman among the LRQ, but expectation supports the security strategy of D-H Diffie-Hellman and GkH to allow to use D-H Diffie-Hellman (Fig. 2 numeral 4) between the gatekeeper.Detailed process is as follows:

Be complementary when GkH supports D-H Diffie-Hellman and security capabilities, then GkH generates own D-H PKI, and and LRQ in GkG the D-H PKI together, use the D-H algorithm computation to go out session shared secret Kab.Then, use with top method 1 similar procedure and generate CTb, tokenOID is " I2 ".At last, GkH generates LCF (Fig. 2 numeral 5), wherein comprises CTb and an independent ClearToken (tokenOID is " I3 ") CTg, and the D-H PKI of the expectation of setting is wherein arranged.

If GkH does not support D-H algorithm or security strategy not to allow to use the D-H Diffie-Hellman, then GkH uses said method 1 process to generate LCF (Fig. 2 numeral 7).

3.3 if tokenOID is " I4 " among the LRQ, show employing method 3 or method 1.

" I4 " expression expectation GkH supports the D-H algorithm among the LRQ, if the security strategy of GkH allows to use the D-H Diffie-Hellman, then GkH begins and EpA consulting session key (Fig. 2 numeral 10-11).Detailed process is as follows:

At first, GkH generates the D-H PKI of expectation, with the PKI that obtains from LRQ, uses the D-H algorithm computation to go out shared secret Kab.Then, use generates CTb with the process steps of method 1, and tokenOID can be made as " I2 " expression.At last, GkH generates LCF, wherein comprises CTb and independent ClearToken (tokenOID can be made as " I4 ") CTg, and the D-H PKI of the expectation of setting is wherein arranged.

If GkH does not support that D-H algorithm or security strategy do not allow to use the D-H Diffie-Hellman, but GkH using method 1 process generates LCF.

4.ACF confirm

After GkG receives LCF, when the tokenOID of the CTg in the check message is " I3 " (Fig. 2 numeral 5), adopt the D-H Diffie-Hellman to calculate Kab, produce CTa, tokenOID is made as " I1 " in it.Specific practice is: obtain the D-H PKI of GkH from independent ClearToken, together use the D-H algorithm computation to go out shared secret Kab with the D-H PKI of oneself preserving; Use then with following same procedure and generate CTa.At last, GkG generates ACF (Fig. 2 numeral 6), the CTb that wherein comprises CTa (tokenOID for " I1 ") and duplicate from LCF (tokenOID for " I2 ").

If the tokenOID of CTg is " I0 " (possible corresponding diagram 2 numerals 1,5,9 three kinds of situations, the called sign of not supporting D-H and being returned) time, at first, GkG can derive algorithm key derivation Ekgh by the key of challenge, IV among the CTg and appointment, or derives by other security mechanism; Then, GkG obtains Kab with EKgh deciphering EKab1; Produce CTa at last, tokenOID is made as " I1 " in it.The generation way of CTa is as follows: at first, GkG derives algorithm key derivation EKag with the key of the shared secret Kag between GkG and the EpA and challenge and appointment.Then, GkG encrypts Kab with EKag and obtains EKab1, and EKab1 and encryption parameter (cryptographic algorithm and the initialization vector of using) together, is set to one independently in the CTA.h235Key.secureSharedSecret field.At last, GkG generates ACF (one of 3,8,13 3 kinds of situations of possible corresponding diagram 2 numerals, caller or the called sign of not supporting D-H and being returned), the CTb that wherein comprises CTa and duplicate from LCF.

If the tokenOID of ClearToken is " I4 " in the LCF message that GkG receives, then GkG generates ACF, wherein comprises all ClearToken (corresponding diagram 2 digital 10-11 kind situations) that duplicate from LCF.

5.Setup

After EpA received ACF, the tokenOID of independent ClearToken was " I4 " in the check message, then is judged to be calling endpoint and called gatekeeper, utilizes D-H algorithm computation session key.Way is:

From ClearToken, obtain callee's D-H PKI, together use the D-H algorithm computation to go out shared secret Kab with the D-H PKI of oneself preserving, and then can calculate session key.

Other situation is then directly extracted CTa, and according to the shared key K ag key derivation EKag of information among the CTa and itself and GkG, use EKag deciphering CTa.h235Key.secureSharedSecret.encryptedSessionKey to obtain shared secret Kab then, and then can calculate session key.

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

6. the call signaling setting of back:

After EpB receives Setup message, extract CTb, and, use EKbh to decipher CTb.h235Key.secureSharedSecret.encryptedSessionKey then and obtain shared secret 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 and follow-up call-signaling message are carried out authentication.

By above ARQ, LRQ, LCF, the order of ACF signaling flow is carried out in the flow process, according to caller eventually, whether caller gatekeeper and called gatekeeper possess 8 kinds of states of D-H ability, and (method 1 is minimum according to different security capabilities, priority, method 3 is the highest) and other security strategy come common implementing how dynamic negotiation go out the consistent key of supporting of both sides between gatekeeper and gatekeeper or terminal and gatekeeper to generate and switching method, i.e. method 1, method 2 or method 3.

Claims

1. a method for multi-network guard end-to-end conversation cryptographic key negotiation of striding field comprises the steps:

2. method according to claim 1 is characterized in that:

The method that generates session key comprises:

3. method according to claim 2, it is characterized in that: described ARQ, LRQ, LCF, ACF all comprise expressly mark ClearToken, tokenOID among the ClearToken is used to represent whether calling endpoint, caller gatekeeper, called gatekeeper support the D-H Diffie-Hellman, be used to perhaps represent that this ClearToken comprises shared secret, give calling endpoint or called end point and use.

4. method according to claim 3 is characterized in that: in the described step (1), if select to use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper, then its D-H PKI is placed in the dhkey territory among the ClearToken.

5. method according to claim 3, it is characterized in that: in the described step (2), if calling endpoint is not supported the D-H Diffie-Hellman, and the caller gatekeeper supports the D-H Diffie-Hellman, selection uses the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, the caller gatekeeper produces the D-H PKI, and deposits this PKI among the LRQ dhkey territory among the ClearToken.

6. method according to claim 4, it is characterized in that: in the described step (2), if use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper, then the ClearToken of the ARQ that calling endpoint is sent copies among the ClearToken of LRQ.

7. method according to claim 3, it is characterized in that: in the described step (3), if calling endpoint and caller gatekeeper do not support the D-H Diffie-Hellman, perhaps called gatekeeper does not support D-H Diffie-Hellman or security strategy not to allow to use the D-H Diffie-Hellman, then produce shared secret by called gatekeeper, after this shared secret encrypted, put into the CTg.h235Key.secureSharedSecret field of LCF message with encryption parameter; Simultaneously, after called gatekeeper produced shared secret and encrypts, another that put into LCF message with encryption parameter was used for called end point ClearToken.

8. method according to claim 5, it is characterized in that: in the described step (3), if calling endpoint is not supported the D-H Diffie-Hellman, but the security strategy of supporting D-H Diffie-Hellman and called gatekeeper between caller gatekeeper and the called gatekeeper allows to use the D-H Diffie-Hellman, then generate the D-H PKI by called gatekeeper, with the D-H PKI of caller gatekeeper in the LRQ together, use the D-H Diffie-Hellman to calculate the shared secret of session, this shared secret generates the ClearToken that the D-H PKI is put into LCF message with encryption parameter and called gatekeeper after encrypting; Simultaneously, after the shared secret that calculates was encrypted, another that put into LCF message with encryption parameter was used for called end point ClearToken.

9. method according to claim 6, it is characterized in that: in the described step (3), calling endpoint selects to use the D-H Diffie-Hellman, and called gatekeeper's security strategy allows to use the D-H Diffie-Hellman, the D-H PKI that then called gatekeeper generates with the PKI that obtains from LRQ, uses the D-H Diffie-Hellman to calculate shared secret, this shared secret generates the ClearToken that the D-H PKI is put into LCF message with encryption parameter and called gatekeeper after encrypting; Simultaneously, after the shared secret that calculates was encrypted, another that put into LCF message with encryption parameter was used for called end point ClearToken.

10. method according to claim 7, it is characterized in that: in the described step (4), the caller gatekeeper checks and receives LCF, if produce shared secret by called gatekeeper, then with the shared secret deciphering of encrypting among this LCF, encrypt again, and be saved in the CTA.h235Key.secureSharedSecret field of ClearToken of ACF with encryption parameter; To be used for called end point ClearToken simultaneously and copy to ACF.

11. method according to claim 8, it is characterized in that: in the described step (4), the caller gatekeeper checks and receives LCF, if use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, from the ClearToken of LCF, obtain called gatekeeper's D-H PKI, the D-H PKI of preserving with the caller gatekeeper together uses the D-H Diffie-Hellman to calculate shared secret, and this shared secret is saved among the ClearToken of ACF with encryption parameter after encrypting; To be used for called end point ClearToken simultaneously and copy to ACF.

12. method according to claim 9, it is characterized in that: in the described step (4), the caller gatekeeper checks and receives LCF, if use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper, then directly ClearToken all among the LCF copied among the ClearToken of ACF.

13. method according to claim 12, it is characterized in that: in the described step (5), the ACF that the calling endpoint inspection is received, if use the D-H Diffie-Hellman to generate session key by calling endpoint and called gatekeeper, then obtain called gatekeeper's D-H PKI from the ClearToken of ACF, the D-H PKI of preserving with calling endpoint together uses the D-H Diffie-Hellman to calculate session key.

14. method according to claim 3, it is characterized in that: in the described step (5), the ACF that the calling endpoint inspection is received, if called gatekeeper produces shared secret, or use the D-H Diffie-Hellman to generate session key by caller gatekeeper and called gatekeeper, then the shared secret key decryption according to the ClearToken information among the ACF and calling endpoint and caller gatekeeper obtains session key.