WO2006081765A1 - Procede de distribution de la cle de session dans la gamme de gestion du portier transversal selon le mode du trajet le plus direct - Google Patents

Procede de distribution de la cle de session dans la gamme de gestion du portier transversal selon le mode du trajet le plus direct Download PDF

Info

Publication number
WO2006081765A1
WO2006081765A1 PCT/CN2006/000168 CN2006000168W WO2006081765A1 WO 2006081765 A1 WO2006081765 A1 WO 2006081765A1 CN 2006000168 W CN2006000168 W CN 2006000168W WO 2006081765 A1 WO2006081765 A1 WO 2006081765A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
calling
session key
called
message
Prior art date
Application number
PCT/CN2006/000168
Other languages
English (en)
French (fr)
Inventor
Kun Li
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=36776968&utm_source=***_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2006081765(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP06705589.7A priority Critical patent/EP1808978B2/en
Priority to ES06705589.7T priority patent/ES2402862T5/es
Publication of WO2006081765A1 publication Critical patent/WO2006081765A1/zh
Priority to US11/648,924 priority patent/US7983280B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1106—Call signalling protocols; H.323 and related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks

Definitions

  • the present invention relates to an authentication technique between a calling party and a called node in a direct routing mode of a communication system, and more particularly to a method for allocating a session key across a gatekeeper management scope in a direct routing mode.
  • the H323 system is implemented using a packet-free network (PBN) based on Quality of Service (QOS) guarantee. Due to the technical reasons of PBN itself, PBN cannot provide QOS and cannot provide security services. Therefore, in the H323 system, how to provide timely and secure services is a problem to be solved.
  • PBN packet-free network
  • QOS Quality of Service
  • Appendix I of the V3 version of the H235 protocol proposes a direct routing security scheme. This scheme mainly uses the basic features of Appendix D and Appendix F of the H235 protocol V3 version to provide security services for H323 system communication, but is limited to a GK management scope. Inside.
  • the H323 system usually includes two or more GKs.
  • the H323 system includes two GKs.
  • the logical block diagram of the networking is shown in Figure 1.
  • the dotted line indicates the registration access status (RAS) message transmission in the H225 protocol in the GK routing mode
  • the solid line indicates the Q931 message transmission in the H225 protocol in the direct routing mode.
  • EPa and EPb represent two different H323 nodes
  • GKg and GK represent two different GKs:.
  • GKg is the attribution of EPa to GK
  • GK is the attribution of EPb to GK.
  • the H323 system includes two or more GKs
  • both parties need to obtain the calling node EPa and the called node through reliable transmission of the RAS message.
  • the session key Kab of the Q931 message in the H225 protocol is directly transmitted between the EPbs.
  • the session key Kab is generated based on the home GKh of the called node EPb.
  • the session key Kab generated by the GKh is used for authentication. Methods.
  • the calling node EPa sends a call access request (ARQ) message to the home GKg, where the ARQ message carries a clear text token (ClearToken), and the tokenOID field in the ClearToken is set to "10".
  • ARQ call access request
  • ClearToken clear text token
  • the tokenOID field in the ClearToken is set to "10".
  • the home GKg of the calling node EPa After receiving the ARQ message sent by the calling node EPa, the home GKg of the calling node EPa determines the called node EPb information according to the destinationlnfo field or the destCallSignalAddress field carried by the ARQ message, and determines the called node according to the called node EPb information.
  • the EPb does not belong to the home GKg of the calling node EPa, and the home GKg of the calling node EPa initiates a location request (LRQ) message to query the home GKh of the called node EPb for the address of the called node EPb.
  • the endpointldentifier field in the LRQ message may carry the node identifier (ID) of the calling node EPa, which is used to indicate that the calling node EPa queries the address of the called node EPb.
  • ID node identifier
  • the home GK of the calling node EPa receives the ARQ message, if it finds that the tokenOID of the ClearToken in the message is ', 10", it is determined that the calling node EPa supports the H235 protocol V3 version. Record I, and then generate a ClearToken in the LRQ message, where the tokenOID field is also "10". If the GKg of the calling node EPa does not support Appendix I, it is not necessary to create a ClearToken with a tokenOID field of "10" in the LRQ message, and the subsequent processing of the LRQ message is performed in a normal manner that does not support the H235 protocol V3 version Appendix I. Message interaction, that is, when the message passes the GK, the message is not encrypted or decrypted.
  • the GKh of the called node After receiving the LRQ message, the GKh of the called node checks whether the tokenOID in the ClearToken of the LRQ message is "10". If the tokenOID is "10", it indicates that the calling node EPa supports the H235 version V3 version Appendix I. If the home GKh of the called node EPb also supports the H235 protocol V3 version Appendix I, according to the called node EPb information provided by the LRQ message, it is queried that the called node EPb supports the H235 protocol V3 version Appendix I and the called node EPb address. .
  • the home GKh of the called node EPb generates a session key Kab between the calling node EPa and the called node EPb, and randomly generates a random number challenge, with the home GKh of the called node EPb and the home GKg of the calling node EPa.
  • the shared key Kgh and the random number challenge ⁇ derive the key EKgh with the specified key derivation algorithm, then use EKgh to encrypt the session key Kab to get EKabl, and configure EKAbl and parameters used in encryption, such as random number challenge, into one Independent ClearToken. h235Key.
  • the corresponding subfield of the secureSharedSecret field The corresponding subfield of the secureSharedSecret field.
  • the called node EPb belongs to
  • GKh needs to set the EKabl to the ClearToken.h235Key.secureSharedSecret.generalID field and configure the key to use the specified key export algorithm to
  • the home GKh of the called node EPb uses the shared key Kbh between the home GKh of the called node EPb and the called node EPb and another random number challenge to derive the key EKbh using the set key derivation algorithm, and uses EKbh.
  • the encrypted session key Kab gets EKab2 and sets the parameters used by EKab2 and encryption, such as the set key derivation algorithm and another random number challenge used in encryption, to the h235Key.secureSharedSecret field of the other ClearToken.
  • the home GKh of the called node EPb needs to also set EKab2 to the ClearToken.h235Key.
  • secureSharedSecret.generalID field and set another random number challenge used to derive the key to ClearToken.
  • the challenge field, ClearToken.generallD field is set to the node ID of the called node EPb
  • ClearToken.senderlD is set to the node ID of the home GKh of the called node EPb
  • the tokenOID of this ClearToken is set to "12", as described below. Record this ClearToken as CTb.
  • GKh sends some Location Confirmation (LCF) messages carrying CTb and CTg to the home GKg of the calling node EPa.
  • LCF Location Confirmation
  • the home GKg of the calling node EPa After the home GKg of the calling node EPa receives the LCF message sent by the home GK of the called node EPb, it takes out the separate ClearToken information, that is, takes out two ClearTokens in the LCF message, and the tokenOID of one ClearToken is "13", that is, CTg The other tokenToken's tokenOID is "12", that is, CTb, indicating that the called node EPb's home GKh and the called node EPb support the H235 protocol V3 version of Appendix I and use the H235 protocol V3 version for security solutions.
  • the home GK of the calling node EPa sets a call access confirmation (ACF) message, and creates a ClearToken in the ACF message, where the tokenOID is set to ' ⁇ ', and a other random challenge is set to the CTa.challenge to obtain the CTg.
  • ACF call access confirmation
  • the Ekabl in the CTg.h235Key.secureSharedSecret field gets the session key Kab, and the home GKg of the calling node EPa is based on the shared key Kag and the other set in the CTa.challenge between the home GKg of the calling node EPa and the calling node EPa.
  • the random number challenge ⁇ derives the key EKag with the specified key derivation algorithm, encrypts the session key Kab with EKag, and sets the encryption result and the parameters used for encryption, such as other random number challenge and the specified encryption derivation algorithm to CTa. h235Key.
  • the encryption result of the EKag encryption Kab and the parameter used for encryption are called CTa, and the CTb.generallD field is copied to the CTa.h235Key. secureSharedSecret.generallD field, and the CTb is copied.
  • ACF Call Access Confirmation
  • the calling node EPa After receiving the ACF message, the calling node EPa extracts CTa and CTb, and according to other random number challenge in CTa and the set encryption derivation algorithm, etc., and uses the shared secret of the calling node EPa and the GKg to which the calling node EPa belongs.
  • the key Kag derives the key Ekag, decrypts the encrypted result in CTa, and obtains the session key Kab.
  • the calling node EPa can use the session key Kab to create a call setup request (Setup) message, copy the CTb in the ACF message to the Setup message, and then set the H235 protocol by using the session key Kab.
  • the authentication information of the Appendix D scheme of the V3 version the calling node EPa sends a Setup message to the EPb by using the direct routing mode.
  • the called node EPb After receiving the Setup message, the called node EPb extracts the CTb, according to the CTb.genmllD and CTb.sendersID and CTb. challenge information in the CTb, and the shared key between the GKh and the called node EPb to which the called node EPb belongs. Kbh derives the key EKbh and decrypts the Ebb2 in the CTb.h235Key. secureSharedSecret field in CTb to get the session Key Kab.
  • the called node EPb authenticates the authentication information in the Setup message according to the decrypted Kab, and after the authentication is passed, performs subsequent 0931 transmission transmission.
  • the session key Kab between the calling node EPa and the called node EPb is subjected to an encryption and decryption process in each hop GK that passes through, and is passed between the calling node EPa and the called node EPb.
  • the number of GKs is large, the delay of RAS message transmission is increased, and the session key Kab is exposed at each hop GK that passes through, and the security performance is poor.
  • Method 2 The session key Kab is generated by the DHHMANN key exchange process (DH) between the calling node EPa and the home GK of the called node EPb, and the calling node EPa and the called node EPb directly transmit the H225 protocol.
  • DH DHHMANN key exchange process
  • the calling node EPa and the called node EPb directly transmit the H225 protocol.
  • a method of authenticating the session key Kab generated based on the home GK of the called node EPa and the called node EPb is employed.
  • the calling node EPa sends an ARQ message to its home GKg, and sets an independent ClearToken in the ARQ message, wherein the tokenOID is ' ⁇ 0', and the calling node EPa generates a public key for DH negotiation. And set in the ClearToken.dhkey field, the calling node EPa transmits the ARQ message to the GKg to which it belongs.
  • the GKg of the H3 version of the V3 version of the H3 protocol determines that the called node EPb does not belong to the home GKg of the calling node EPa according to the information of the called node EPb carried by the ARQ message, and the home GKg of the calling node EPa is initiated.
  • the LRQ message is sent to the GKh to which the called node EPb belongs.
  • the LRQ message carries an independent ClearToken, where the tokenOID field is "10", and the content of the ClearToken.dhkey field is the same as the content in the ClearToken.dhkey field of the ARQ message, including the EPa generation.
  • the existing GK after receiving the LRQ message, copies the LRQ message and sends it to the upper-level GK until it is sent to The GKh to which the called node EPb belongs.
  • the ClearToken.tokenOID field and the called node EPM message determine that both the calling node EPa and the called node EPb support the H235 protocol V3 version Appendix I, the called node EPb belongs to the GKh to create a ClearToken, set the tokenOID to "12", in the back
  • the ClearToken is recorded as CTb in the narrative.
  • the GKh to which the called node EPb belongs generates the public key of the DH negotiation, and uses the DH algorithm together with the public key in the received LRQ message to calculate the session key Kab that the calling node EPa and the called node EPb directly transmit the Q931 message.
  • the GKh to which the called node EPb belongs randomly generates a random number challenge, which is set in the CTb.challenge field, and then according to the random number challenge and the shared key Kbh between the GKh and the called node EPb to which the called node EPb belongs.
  • the fixed key derivation algorithm derives the key EKbh and the key KSbh.
  • the GKh to which the called node EPb belongs generates a random initialization vector IV, which is set to CTb.h235Key, securitySharedSecret.paramS.IV.
  • the GKh to which the called node EPb belongs encrypts the session key Kab in the key Ekbh, the key KSbh and the initialization vector IV to obtain ENC EKbh , KSbh , IV (Kab), and sets ENC EKbh , KSbh , IV (Kab) to CTb.h235Key.securitySharedSecretencryptedSession in the ey field.
  • This method of encrypting the session key Kab is described in Appendix I of the H235 Protocol V3.
  • the GKh to which the called node EPb belongs includes the public key and CTb generated by the GKh to which the called node EPb belongs in the LCF message, and sends an LCF message to the GKg to which the calling node EPa belongs.
  • the GKg that the calling node EPa belongs After receiving the LCF message sent by the GK to which the called node EPb belongs, the GKg that the calling node EPa belongs to obtains the public key generated by the CTB and the GKh to which the called node EPb belongs, and copies it into the ACF message, and sends the ACF message. Give the calling node EPa.
  • the calling node EPa After receiving the ACF message, the calling node EPa calculates the session key Kab through the DH algorithm according to the public key generated by the GKh of the called node EPb in the message ACF.
  • the session node EPa After the session node EPa obtains the session key Kab, it can be created by using the session key Kab.
  • the Setup message copies the CTb in the ACF message to the Setup message, and then sets the authentication information of the Appendix D scheme of the H235 protocol V3 version by using the session key Kab, and the calling node EPa transmits the Setup message to the called node EPb.
  • the called node EPb After receiving the Setup message, the called node EPb extracts the CTb, and according to the information in the CTb, that is, the random number challenge and the set key derivation algorithm, using the GKh to which the called node EPb belongs and the called node EPb.
  • the shared key Kbh derives the key EKbh and the key KSbh, and decrypts the CTb.h235Key.
  • secureSharedSecret EncryptedSessionKey field ENC EKbh , KSbh , IV (Kab) in the CTb.h235Key. SecureSharedSecret.
  • the decrypted session key Kab authenticates the Setup message.
  • the method overcomes the problem of increasing the delay of RAS message transmission and the poor security performance caused by the session key Kab being exposed at each hop GK, the method requires the calling node EPa and the calling node. Both the EPa and the called node EPb support the DH negotiation process, which limits its scope of application.
  • the main object of the present invention is to provide a method for allocating session keys across a gatekeeper management scope in a direct routing mode, which enables a GK to which a node belongs to select a session key allocation mode to achieve an improvement.
  • a method for allocating session keys across a gatekeeper management scope in a direct routing mode comprising:
  • the calling node carries its supported session key allocation mode in the call access request message and transmits it to its home gatekeeper GK; b.
  • the GK to which the calling node belongs determines the calling party session key allocation mode according to the session key allocation mode information supported by the calling node carried in the call access request message, and carries it in the positioning request message to be transmitted to the Calling the GK to which the node belongs;
  • the GK to which the called node belongs determines the session key allocation mode of the called party according to the information carried in the location request message, and generates a session key between the calling party and the called party, and allocates the session key of the called party to the session.
  • the key is transmitted to the GK to which the calling node belongs by using the location confirmation message.
  • the GK to which the calling node belongs determines the session key according to the information carried in the location confirmation message, the session key allocation mode supported by the calling node, and the session is secreted.
  • the key is transmitted to the calling node through a call access confirmation message;
  • the calling node sends the session key to the called node through a call setup message.
  • the method for assigning the calling party session key according to step b is further according to a calling party predetermined rule, where the calling party predetermined rule includes an available computing resource of the GK, and/or a session key allocation mode supported by the calling node, and/or Or the security level of the calling node.
  • Step c The called party session key allocation mode is further determined according to a called party predetermined rule, where the called party predetermined rule includes an available computing resource of the GK, and/or a calling party session key distribution mode, and/or Or the security level of the called node.
  • the process of carrying the session key distribution mode supported by the step a to the call access request message is as follows:
  • the "10" is carried in the token OID of the call access request message and transmitted to the GK to which it belongs; the calling node supports the DH negotiation.
  • the "14" is carried in the token OID of the call access request message, and the DH public key of the calling node is carried in the dhkey of the plaintext tag and transmitted to the GK to which it belongs.
  • the calling party session key allocation manner described in step b includes: performing a DH negotiation, and/or a master between the GK generating session key to which the called node belongs, and/or the GK to which the calling party is assigned.
  • the DH is negotiated between the calling node and the GK to which the called node belongs.
  • Step b determining that the calling party session key allocation mode is carried in the location request message and transmitted to the GK to which the called node belongs is:
  • the GK of the calling node's affiliation determines that the calling party's session key is allocated to the GK to which the called node belongs.
  • the "10" is carried in the tokenOID of the plaintext tag in the location request message, and is transmitted to the called party.
  • the GK to which the calling node belongs determines that the calling party session key is allocated in the DH negotiation between the GKs to which the called node belongs, and the GK to which the calling node belongs generates the DH public key and carries the plaintext in the positioning request message.
  • the "14" is carried in the tokenOID of the plaintext tag, and transmitted to the GK to which the called node belongs;
  • the GK to which the calling node belongs determines the calling party session key allocation mode.
  • the plaintext flag in the call access request message is carried in the positioning request message.
  • the method for assigning the called party session key in step c includes: the home gateway of the called node generates a session key, and/or DH negotiation.
  • the process of transmitting the called party session key distribution mode and the session key through the location confirmation message to the GK of the calling node according to step c includes:
  • the GK to which the called node belongs determines that the called party session key allocation mode is the GK to which the called node belongs to generate the session key, generates the session key between the calling and called nodes, and generates the CTb and tokenOID whose tokenOID is "12".
  • the CTg of "13" is transmitted to the GK to which the calling node belongs by using the positioning confirmation message;
  • the GK to which the called node belongs determines that the DH public key is generated when the called party session key allocation mode is DH negotiation, and the DH public key and the DH public key obtained from the positioning request message are calculated by the DH algorithm.
  • the key is generated, and the tokenOID is "I 2 ,, the CTb and the tokenOID are "15", and the dhkey is the plaintext label of the DH public key generated by the GK to which the called node belongs. It is noted that the CTb and the plaintext token are transmitted to the GK to which the calling node belongs by using a positioning confirmation message.
  • the process of transmitting the session key through the call access confirmation message to the calling node in step d is:
  • the GK to which the calling node belongs obtains the information of the called party session key assignment method carried in the location confirmation message and determines:
  • the CTa is generated according to the CTg carried in the location confirmation message, and the CTb in the CTa and the location confirmation message is transmitted to the calling node through the call access confirmation message;
  • the session key is calculated by the DH algorithm according to the DH public key of the DH public key and the GK belonging to the called node in the location confirmation message, and CTa is generated, and The CTb in the CTa, the location confirmation message is transmitted to the calling node by using a call access confirmation message;
  • the plaintext flag in the location confirmation message is obtained and carried in the call access confirmation message and transmitted to the calling node.
  • step d The process of generating the session key between the calling and called nodes in step d is:
  • the calling node determines whether the call access confirmation message contains the plaintext tag 2 with a tokenOID of "15".
  • the session key is calculated according to the shared key between the GK and the home GK, and the CTa in the call access confirmation message;
  • the session key is calculated according to the DH public key and the DH public key of the GK to which the called node belongs in the call access confirmation message.
  • the process of sending the session key to the called node in step e is:
  • the calling node sets the authentication information of the call setup message according to the session key, and Transmitting the CTb in a call setup message to the called node;
  • the called node acquires the session key according to the CTb in the call setup message, and authenticates the call setup message according to the session key;
  • the called node determines the session key as a session key for the message transmission of the calling node with its direct routing mode.
  • the method further includes:
  • the calling and called nodes transmit the information supporting DH negotiation to the GK of the home gate discovery request or the registration request message in the plaintext mark.
  • the present invention sets the allocation mode of the selected session key in the GK to which the calling party is called, so that the GK to which the calling party is called can flexibly select the session between the calling party and the called node according to the specific conditions of the network.
  • the session key between the calling party and the called node is allocated by performing DH negotiation between the GKs of the calling party and the called node, and is the calling party node.
  • a new end-to-end security service is provided, which improves the security of the session key. Therefore, the technical solution provided by the invention improves the flexibility of assigning the session key to the home gatekeeper and the security level of the message transmission. Balance the message transmission delay. BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a networking logic diagram of an H323 system with two GKs. Mode for carrying out the invention
  • the present invention sets the GK to which the calling and called nodes belong according to the information carried in the received message, and the preset selection session key.
  • the predetermined rule of the allocation method determines the mode of the primary and called party session key distribution, and assigns the session key to the called party.
  • the invention is applicable to the direct routing mode of the H323 system across the GK management scope, that is, the main called node belongs to different GKs respectively, and the direct message interaction process between the calling and called nodes is in a network without security guarantee, such as an internet protocol (IP). ) On the network.
  • IP internet protocol
  • the premise of implementing the method provided by the present invention is: In the process of assigning the session key, GK authenticates all RAS messages of its jurisdiction node, and the node also authenticates the RAS message of the GK to which it belongs, so that the node and its attribution GK achieves mutual trust.
  • Mutual authentication is also performed between the interconnected GKs to avoid malicious attacks between GK domains, so that mutually connected GKs can achieve mutual trust.
  • the security of the RAS message between the network entities in the H323 system is ensured by the above authentication process.
  • the present invention first needs to set a predetermined rule for the GK to select a session key distribution mode, and the predetermined rule can be set in GK: by static configuration, dynamic configuration, and the like.
  • the predetermined rules can be divided according to the calling party and the called party where the GK is located: the calling party predetermined rule and the called party predetermined rule.
  • the content included in the reservation rule of the calling party and the called party may be set according to actual needs in the actual network.
  • the calling party predetermined rule may include one or more of the following: a computing resource available to the GK, and a session supported by the calling node.
  • the called party predetermined rule may include one or more of the following: a computing resource that can be GK, a calling party session key allocation mode, and a security level of the called node. Wait.
  • the GK to which the calling and called nodes belong can flexibly select the allocation method of the session key according to various factors.
  • the following describes the process of implementing the session key assignment by using the following three procedures to implement the session key assignment option for the GK to which the calling and called nodes of the present invention belong.
  • DRC I The primary and called party session key allocation methods are the GKs generated by the called node to generate the session key.
  • the calling party session key allocation mode is DH negotiation between the GKs belonging to the called party node and the called party session key allocation mode is DH negotiation.
  • the calling party session key allocation mode performs DH negotiation between the calling node and the GK to which the called node belongs, and the called party session key allocation mode is DH negotiation.
  • the node in the present invention can indicate to the home GK whether it supports the H235 protocol V3 version Appendix I during the GK discovery process or the node registration process, that is, whether the node supports the method provided by the present invention, such as the node in the gatekeeper discovery request (
  • the GRQ message or registration request (RRQ) message carries a separate ClearToken and sets the tokenOID field in the ClearToken to "10".
  • the node home GK After the node home GK receives the GRQ message or the RRQ message, when the tokenOID in the ClearToken of the message is identified as "10", the reply to the Gatekeeper Discovery Confirmation (GCF) message or the Registration Confirmation Message (RCF), the accepting node, the GCF message or the RCF The message carries the same ClearToken as the corresponding GRQ message or RRQ message.
  • GCF Gatekeeper Discovery Confirmation
  • RCF Registration Confirmation Message
  • the GK to which the calling node belongs may select the DRCI and DRCII processes respectively to allocate the session key between the calling and called nodes according to the calling party predetermined rule, and the GK to which the called node belongs may also The DRCI, DRCII process is selected to allocate the session key between the calling and called nodes.
  • the GK to which the calling node belongs may select the DRC I and DRC III procedures respectively to allocate the session key between the calling and called nodes, and the GK to which the called node belongs may also select the DRC I and the DRC.
  • the III process assigns a session key between the primary and the node.
  • Step 1 of the DRCI procedure Before the calling node EPa calls the called node EPb using the direct routing mode, the calling node EPa sends an ARQ message to its home GKg, which should include one A separate ClearToken, the ClearToken's tokenOID is set to "10", indicating that the calling node EPa does not support DH negotiation, and other fields of the ClearToken are not used.
  • Step 2 of the DRCI process the GKg to which the calling node EPa belongs receives the ARQ message, and determines, according to the information of the called node EPb carried in the ARQ message, that the called node EPb does not belong to the home GKg of the calling node EPa, and the calling node EPa belongs to The GKg initiates an LRQ message to query the address of the called node EPb to the GKh to which the called node EPb belongs.
  • the GKg to which the calling node EPa belongs generates an LRQ message, and the GKg to which the calling node EPa belongs is determined according to the tokenOID of the ClearToken of the ARQ message is "10" and the calling party predetermined rule determines that the calling party session key allocation mode is the called node attribution.
  • the LRQ message includes a ClearToken, and the ClearToken's tokenOID should be set to "10", indicating that the calling party session key is allocated in the manner that the called node belongs to the GK to generate the session key, the ClearToken The other fields in the field are not used.
  • the GKg to which the calling node EPa belongs sends an LRQ message to the GKh ⁇ to which the called node EPb belongs.
  • Step 3 of the DRCI process the GKh to which the called node EPb belongs receives the LRQ message, obtains the tokenOID of the ClearToken in the message as "10", and determines, according to the predetermined rule of the called party, that the session key is generated by using the GK to which the called node belongs. , using the random number to generate the session key Kab.
  • the GKh to which the called node EPb belongs firstly, generates a random number challenge, and uses the shared key Kgh and the random number challenge between the GK to which the called node EPb belongs and the GKg to which the calling node EPa belongs.
  • the specified key export algorithm exports the key EKgh.
  • the GKh to which the called node EPb belongs is EKgh ⁇ .
  • the secret session key Kab gets EKabl and sets the EKAbl and encryption parameters, such as the encryption algorithm and the initialization vector used for encryption, to a separate ClearToken. h235Key. secureSharedSecret field.
  • the tokenOID of this ClearToken is "13" and is called CTg.
  • the GKh to which the called node EPb belongs uses a similar process to generate another ClearToken whose tokenOID is "12", that is, CTb.
  • the GKh to which the called node EPb belongs generates LCF cancellation.
  • Interest, the LCF message contains CTg and CTb.
  • the GKh to which the called node EPb belongs sends the LCF message directly to the GKg to which the calling node EPa belongs, or sends the LCF message to the upper level GI of the GKh to which the called node EPb belongs, until it is transmitted to the GKg to which the calling node EPa belongs.
  • the GKh to which the called node EPb belongs receives the LCF message.
  • the CTg is decrypted and CTa is generated.
  • the specific process is as follows: First, the GKg to which the calling node EPa belongs derives the key EKgh through the random number challenge in CTg, IV and the specified key derivation algorithm. Then, the GKg to which the calling node EPa belongs decrypts EKabl with EKgh to obtain the session key Kab.
  • the GKg to which the calling node EPa belongs is derived from the shared key Kag and the random number challenge between the GKg to which the calling node EPa belongs and the calling node EPa, and the specified key derivation algorithm derives the key EKag.
  • the GKg to which the calling node EPa belongs encrypts the session key Kab with the key EKag to obtain EKabl, and sets the EKabl together with the encryption parameters, such as the encryption algorithm and the initialization vector used for encryption, to a separate ClearToken. h235Key. secureSharedSecret In the field.
  • the tokenOID of this ClearToken is ⁇ ", called CTa.
  • the GKg to which the calling node EPa belongs generates an ACF message containing the CTb copied from the CTa and the LCF message it receives.
  • the ACF message should include CTa and CTg, and the next-level GK uses the derived key of the GKg to which the calling node EPa belongs to encrypt Kab.
  • the GKg to which the calling node EPa belongs is sent to the calling node EPa.
  • Step 5 of the DRCI process the calling node EPa receives the ACF message, extracts the CTa from the message, and derives the key EKag according to the information in the CTa and the shared key Kag of the GKg to which the calling node EPa belongs, and then uses EKag decrypts CTa.h235Key. secureSharedSecret. encryptedSessionKey gets j session dense copper Kab.
  • the calling node EPa creates a Setup message, copies the CTb in the ACF message into the Setup message, and then sets the authentication information of Appendix D and Appendix F of the H235 protocol V3 version by using the session key Kab.
  • the calling node EPa issues a Setup message directly to the called node EPb.
  • the called node EPb receives the Setup message, extracts the CTb from the message, and derives the key EKbh according to the information in the CTb and its shared key Kbh with the GKh to which the called node EPb belongs, and then uses the EKbh angle "secret CTb.h235Key. secureSharedSecret encryptedSessionKey 'J session key Kab; At this time, the called node EPb can use the session key Kab to authenticate the Setup message. After the authentication is passed, the session key Kab is determined to be the calling node EPb and the called node EPa. The session key for the Q9'31 message transmission between.
  • Step 1 of the DRCII process 1 Before the calling node EPa calls the called node EPb using the direct routing mode, the calling node EPa sends an ARQ message to its home GKg, and the message should include an independent ClearToken, the ClearToken The tokenOID should be set to "10", indicating that the calling node EPa does not support DH negotiation, and other fields of the ClearToken are not used.
  • Step 2 of the DRCII process The GKg to which the calling node EPa belongs receives the ARQ message, and determines, according to the information of the called node EPb carried in the ARQ message, that the called node EPb does not belong to the home GKg of the calling node EPa, and the calling node EPa belongs to The GKg initiates an LRQ message to query the address of the called node EPb to the GKh to which the called node EPb belongs.
  • the GKg to which the calling node EPa belongs generates an LRQ message, and the GKg to which the calling node EPa belongs is determined according to the tokenOID of the ClearToken of the ARQ message is "10" and the calling party predetermined rule determines that the calling party session key allocation mode is the primary called node.
  • the message contains a TokenOID of "ClearToken' ClearToken of "14", indicating that the calling party session key distribution mode is DH negotiation for the GK to which the called party belongs.
  • the GKg to which the calling node EPa belongs generates a DH public key of the GKg to which the calling node EPa belongs, and is set in the dhkey of the ClearToken. 06 000168 After performing the above settings, the GKg to which the calling node EPa belongs sends an LRQ message to the GKh to which the called node EPb belongs.
  • Step 3 of the DRCII process the GKh to which the called node EPb belongs receives the LRQ message, and the tokenOID of the ClearToken is "14" in the message, and the called party session key allocation mode is determined as DH negotiation according to the predetermined rule of the called party.
  • the GKh to which the called node EPb belongs starts to determine the session key between the calling and called nodes using the DH negotiation process with the GKg to which the calling node EPa belongs.
  • the specific process is as follows: First, the GKh to which the called node EPb belongs generates its own DH public key, and together with the DH public key obtained from the LRQ message, uses the DH algorithm to calculate the session key Kab.
  • step 3 of the DRC I procedure uses the method of step 3 of the DRC I procedure to generate a CTb with a tokenOID of "12".
  • GKh uses the method of step 3 of the DRC I procedure to generate a CTb with a tokenOID of "12".
  • GKh uses the method of step 3 of the DRC I procedure to generate a CTb with a tokenOID of "12".
  • GKh generates an LCF message containing CTb and a separate ClearToken whose tokenOID is "15" and contains the DH public key generated by the GKh to which the called node EPb belongs.
  • the tokenOID of ClearToken is "15" indicating that the ClearToken contains the DH public key of the GK to which the called node belongs.
  • the GKh to which the node EPb belongs shall use the step 3 of the DRC I procedure to generate an LCF message.
  • the GKh to which the called node EPb belongs sends an LCF message to the GKg to which the calling node EPa belongs.
  • Step 4 of the DRC II process the GKg to which the calling node EPa belongs receives the LCF message, and when the check message includes a ClearToken with a tokenOID of "15", and the calling node does not support DH negotiation, the session key is calculated and CTa is generated.
  • the specific process is as follows: The DH public key is obtained from the ClearToken of the LCF message independent, and the session key Kab is calculated by using the DH algorithm together with the DH public key generated by itself. Then, CTa is generated using substantially the same procedure as step 4 of the DRC I process. Finally, the GKg to which the calling node EPa belongs generates an ACF message, which includes CTa and the slave. T N2006/000168
  • the CTb copied from the LCF message.
  • the GKg to which the calling node EPa belongs detects that the LCF message contains a ClearToken with a tokenOID of "15", and the calling node supports DH negotiation, the GKg to which the calling node EPa belongs should use the step 4 of the DRCIII process to generate an ACF message. .
  • the GKg to which the calling node EPa belongs detects that the LCF message contains a ClearToken with a tokenOID of "13"
  • the GKg to which the calling node EPa belongs shall use the step 4 of the DRC I procedure to generate an ACF message.
  • the GKg to which the calling node EPa belongs sends an ACF message to the calling node EPa.
  • Step 5 of the DRCII process the calling node EPa receives the ACF message, and if the calling node EPa does not include the ClearToken with the tokenOID of "15" in the ACF message, the CTa is extracted from the ACF message, and according to the information in the CTa It shares the key EKag with the shared key Kag of the GKg to which the calling node EPa belongs, and then uses EKag to decrypt CTa.h235Key. secureSharedSecret. encryptedSessionKey to obtain the session dense steel Kab.
  • the session key Kab is calculated according to step 5 of the DRCIII process.
  • the calling node EPa creates a Setup message, copies the CTb in the ACF message into the Setup message, and then uses the session key Kab to set the authentication information of Appendix D and Appendix F of the H235 protocol V3.
  • the calling node EPa sends a Setup message directly to the called node EPb.
  • the called node EPb receives the Setup message, extracts the CTb from the message, and derives the key EKbh according to the information in the CTb and its shared key Kbh with the GKh to which the called node EPb belongs, and then uses the EKbh to decrypt the CTb.h235Key.
  • secureSharedSecret gets the session key Kab.
  • the called node EPb can use the session key Kab to authenticate the Setup message.
  • the session key Kab is determined to be the session secret between the calling node EPb and the called node EPa for Q931 message transmission. key. Subsequent call procedures are identified using Appendix D and Appendix F of the H235 Protocol V3.
  • the calling node EPa supports the DH negotiation process. Before the calling node EPa calls the called node EPb using the direct routing mode, the calling node EPa generates a DH public key and sets the dhkey of the independent ClearToken of the ARQ message. In the ClearToken, the tokenOID is set to "14" and other fields are not used.
  • Step 2 of the DRCIII process The GKg to which the calling node EPa belongs receives the ARQ message, and determines, according to the information of the called node EPb carried in the ARQ message, that the called node EPb does not belong to the home GKg jurisdiction of the calling node EPa, and the calling node EPa belongs to The GKg initiates an LRQ message to query the address of the called node EPb to the GKh to which the called node EPb belongs.
  • the GKg to which the calling node EPa belongs generates an LRQ message
  • the GKg to which the calling node EPa belongs is determined according to the tokenOID of the ClearToken of the ARQ message is "14" and the calling party predetermined rule determines the calling party session key distribution mode as the calling node and
  • the ClearToken in the ARQ message is copied into the LRQ message, and the GKg to which the calling node EPa belongs sends an LRQ message to the GKh to which the called node EPb belongs.
  • Step 3 of the DRCIII process the GKh to which the called node EPb belongs receives the LRQ message, and detects that the LRQ message includes an independent ClearToken with a tokenOID of "14", and determines the called party session key allocation manner according to the predetermined rule of the called party.
  • the session key Kab is negotiated with the calling node EPa according to the use of the DH negotiation process.
  • the specific process is as follows: First, the GKh to which the called node EPb belongs generates a DH public key, and together with the DH public key of the GKg to which the calling node EPa is acquired from the LRQ, the session key Kab is calculated using the DH algorithm.
  • CTb is generated using the method of step 3 in the DRC I process, and the CTO has a tokenOID of "12".
  • the GKh to which the called node EPb belongs generates an LCF message containing CTb and a separate ClearToken, the tokenOID in the ClearToken is "15", and contains the DH public key of the GKh to which the called node EPb belongs.
  • the tokenOID of ClearToken is "15" indicating that the ClearToken contains the DH public key of the GK to which the called node belongs.
  • the GKh to which the called node EPb belongs does not support the DH algorithm or the security policy does not allow factors such as determining the called party session key distribution mode according to the predetermined rule of the called party to generate the session key for the GK to which the called node belongs, then The GKh to which the called node EPb belongs should use the step 3 of the DRCI procedure to generate an LCF message.
  • the GKh to which the called node EPb belongs sends an LCF message to the GKg to which the calling node EPa belongs.
  • Step 4 of the DRC III process the GKg to which the calling node EPa belongs receives the LCF message, and when the LCF message includes a ClearToken with a tokenOID of "15", and the calling node supports DH negotiation, the calling node EPa belongs to the GKg. Generate an ACF message containing all ClearTokens copied from the LCF message. GKg sends an ACF message to the calling node EPa.
  • the GKg to which the calling node EPa belongs detects that the LCF message contains a ClearToken with a tokenOID of "13", and it is determined that the calling node EPa does not support DH negotiation, the GKg to which the calling node EPa belongs should use the steps in the DRCI process. 4 Generate an ACF message.
  • Step of the DRCIII process 5 The calling node EPa receives the ACF message and calculates the session key when it checks that the message contains a separate ClearToken with a tokenOID of "15".
  • the specific process is as follows: the calling node, the person in the ClearToken, obtains the DH public key of the GKh to which the called node EPb belongs, and uses the DH algorithm to calculate the session key Kab together with the DH public key generated by itself.
  • the session key Kab should be calculated using the method of calculating the session key in step 5 of the DRCI procedure.
  • the calling node EPa creates a Setup message, copies the CTb in the ACF message into the Setup message, and then uses the session key Kab to set the authentication information of Appendix D and Appendix F of the H235 protocol V3.
  • the calling node EPa sends a Setup message directly to the called node EPb.
  • the called node EPb receives the Setup message, extracts the CTb from the message, and derives the key EKbh according to the information in the CTb and its shared key Kbh with the GKh to which the called node EPb belongs. Then use EKbh to decrypt CTb.h235Key. secureSharedSecret. encryptedSessionKey to get the session key Kab.
  • the called node EPb can use the session key Kab to authenticate the Setup message. After the authentication is passed, the session key Kab is determined as the main The session key Kab for Q931 message transmission between the node EPb and the called node EPa is called.
  • the explicit node Ep does not support the DH process.
  • the session key is included in the ClearToken. 3 49 ⁇
  • the session key is included in the ClearToken. 3 50 ⁇
  • Ming EP supports the DH process.
  • ClearToken contains the DH of the called party.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Description

直接路由模式下跨关守管理范围的会话密钥的分配方法 技术领域
本发明涉及通信***的在直接路由模式下主被叫节点之间的鉴权技 术， 特别涉及一种直接路由模式下跨关守管理范围的会话密钥的分配方 法。 发明背景
H323***采用基于无服务质量（QOS )保证的分组网络（PBN ) 实 现。 由于 PBN自身的技术原因， 使 PBN不能够提供 QOS, 也不能提供安 全的服务。 因此， 在 H323***中， 如何提供适时安全的服务是要解决的 问题。
H235协议 V3版以前的版本描述了一些用于 H323***的鉴别和保密 技术， 但都是假定在关守 （GK )路由模式下的技术方案。 H235协议 V3 版的附录 I提出了一种直接路由的安全方案， 这种方案主要利用 H235协 议 V3版附录 D和附录 F的基本特性， 提供 H323***通信的安全服务， 但 是限制在一个 GK管理范围内。
在实际的网络环境中， H323***通常会包括两个或多个 GK, H323 ***包括两个 GK的组网逻辑框图如附图 1所示。
图 1中， 虛线表示在 GK路由模式下的 H225协议中的注册接入状态 ( RAS )消息传输， 实线表示在直接路由模式下的 H225协议中 Q931消息 传输。 EPa和 EPb表示两个不同的 H323节点， GKg和 GK表示两个不同的 GK：。 GKg是 EPa的归属 GK, GK是 EPb的归属 GK。
当 H323***包括两个或多个 GK时，通常会通过呼叫前的预约机制， 使主叫节点 EPa和其归属 GKg之间有共享密钥 Kag, 被叫节点 EPb和其归 属 GKh之间有共享密钥 Kbh,主叫节点 EPa归属的 GKg和被叫节点归属的 GKh之间有共享密钥 Kgh, 以确保 RAS消息的可靠传输。
当主叫节点 EPa和被叫节点 EPb之间采用直接路由模式进行呼叫时， 为保证 H225协议中的 Q931消息的可靠传输，双方需要通过 RAS消息的可 靠传输来获取主叫节点 EPa和被叫节点 EPb之间直接传输 H225协议中的 Q931消息的会话密钥 Kab。
目前， 主叫节点 EPa和被叫节点 EPb直接传输 H225协议中的 Q931消 息时， 采用会话密钥 Kab进行鉴权的方法有两种， 以下分別对这两种方 法进行说明。
方法一、基于被叫节点 EPb的归属 GKh产生会话密钥 Kab, 主叫节点 EPa和被叫节点 EPb直接传输 H225协议中的 Q931消息时， 釆用由 GKh所 产生的会话密钥 Kab进行鉴权的方法。
具体实现过程为： 图 1中， 主叫节点 EPa向归属 GKg发送呼叫接入请 求（ARQ ) 消息， 该 ARQ消息中携带了一个明文标记（ClearToken ) , 该 ClearToken中的 tokenOID字段设置为 "10" , 用于表明主叫节点 EPa支 持 H235协议 V3版附录 I, 即支持 GK路由模式下的 RAS消息传输。
主叫节点 EPa的归属 GKg在接收到主叫节点 EPa发来的该 ARQ消息 后，根据该 ARQ消息承载的 destinationlnfo字段或者 destCallSignalAddress 字段确定被叫节点 EPb信息， 根据被叫节点 EPb信息确定被叫节点 EPb不 属于主叫节点 EPa的归属 GKg管辖， 主叫节点 EPa的归属 GKg发起定位请 求（ LRQ )消息向被叫节点 EPb的归属 GKh查询被叫节点 EPb的地址。 LRQ 消息中的 endpointldentifier字段可以携带主叫节点 EPa的节点标识符 ( ID ) , 用于标明是主叫节点 EPa查询被叫节点 EPb的地址。
主叫节点 EPa的归属 GKg在接收到 ARQ消息时， 如果发现消息中 ClearToken的 tokenOID为'，10"，则确定主叫节点 EPa支持 H235协议 V3版附 录 I, 于是在 LRQ消息中也生成一个 ClearToken, 其中的 tokenOID字段也 为 "10" 。 如果主叫节点 EPa的 GKg不支持附录 I, 就不需要在该 LRQ消 息中创建 tokenOID字段为 "10" 的 ClearToken, 且该 LRQ消息的后续处 理按照不支持 H235协议 V3版附录 I的普通方式进行消息交互， 即当消息 经过 GK时， 不再进行消息的加解密处理。
被叫节点 EPb的归属 GKh在接收到该 LRQ消息后， 检查该 LRQ消息 的 ClearToken中的 tokenOID是否为 "10" , 如果 tokenOID为 "10" ， 表明 主叫节点 EPa支持 H235协议 V3版附录 I。 如果被叫节点 EPb的归属 GKh也 支持 H235协议 V3版附录 I, 就根据该 LRQ消息提供的被叫节点 EPb信息， 查询到被叫节点 EPb支持 H235协议 V3版附录 I以及被叫节点 EPb的地址。
被叫节点 EPb的归属 GKh生成主叫节点 EPa和被叫节点 EPb之间的会 话密钥 Kab, 且随机产生随机数 challenge, 用被叫节点 EPb的归属 GKh和 主叫节点 EPa的归属 GKg之间的共享密钥 Kgh和随机数 challenge釆用指 定密钥导出算法导出密钥 EKgh , 然后用 EKgh加密会话密钥 Kab得到 EKabl ,将并将 EKabl和在加密使用的参数，如随机数 challenge配置到一 个独立的 ClearToken. h235Key. secureSharedSecret字段的对应子字段中。
如果 LRQ消息中设置了 endpointldentifier字段， 被叫节点 EPb的归属
GKh 需 要 把 EKabl 也 设 置 到 ClearToken.h235Key.secureSharedSecret.generalID字段中， 并将导出密钥 时 用 ' 到 的 指 定 密 钥 导 出 算 法 配 置 到
ClearToken.h235Key.secureSharedSecret.keyDerivationOID字段中， 将导 出密钥时用到的随机数 challenge设置到 ClearToken.challenge字段， 同时 将 ClearToken.generalID设置为主叫节点 EPa归属的 GKg的节点 ID , ClearToken.senderID设置为被叫节点 EPb的归属 GKh的节点 ID, 最后把 ClearToken的 tokenOID设置为 "13" , 在下面的叙述中把这个 ClearToken记 为 CTg。
被叫节点 EPb的归属 GKh用被叫节点 EPb的归属 GKh和被叫节点 EPb 之间的共享密钥 Kbh和另外一个随机数 challenge—起采用设定的密钥导 出算法导出密钥 EKbh, 并用 EKbh加密会话密钥 Kab得到 EKab2, 并把 EKab2和加密使用的参数， 如设定的密钥导出算法和加密时用到的另外 一 个 随机数 challenge一起设置 到 另 外 一个 ClearToken的 h235Key.secureSharedSecret字段中。
如果该 LRQ消息中设置了 endpointldentifier字段， 被叫节点 EPb的归 属 GKh 还 需 要 把 EKab2 也 设 置 到 ClearToken.h235Key. secureSharedSecret.generalID字段中， 将导出密钥时用到的另外一个随机 数 challenge设置到 ClearToken. challenge字段 , ClearToken.generallD字段 设置为被叫节点 EPb的节点 ID, ClearToken.senderlD设置为被叫节点 EPb 的归属 GKh的节点 ID, 最后把这个 ClearToken的 tokenOID设置为 "12",在 下面的叙述中把这个 ClearToken记为 CTb。
在进行了上述设置后， GKh把些携带 CTb和 CTg的定位确认（LCF ) 消息发给主叫节点 EPa的归属 GKg。
主叫节点 EPa的归属 GKg接收到被叫节点 EPb的归属 GK 发来的 LCF消息后， 取出独立的 ClearToken信息， 即取出 LCF消息中两个 ClearToken, 其中一个 ClearToken的 tokenOID为 "13", 即 CTg, 另外一个 ClearToken的 tokenOID为" 12", 即 CTb, 则表明被叫节点 EPb的归属 GKh、 被叫节点 EPb支持 H235协议 V3版附录 I并使用 H235协议 V3版进行安全方 案。
主叫节点 EPa的归属 GKg设置呼叫接入确认（ACF ) 消息， 在 ACF 消息中创建一个 ClearToken,其中的 tokenOID设置为 'ΊΓ',选取一个其他 随机的 challenge设置到 CTa.challenge中，获取 CTg提供的在加密时采用的 参数，如随机数 challenge、指定的密钥导出算法等，利用随机数 challenge 指定的密钥导出算法以及主叫节点 EPa的归属 GKg和被叫节点 EPb之间 的共享密钥 Kgh导出的密钥 Ekgh, 解密该 LCF消息的
CTg.h235Key.secureSharedSecret字段中的 Ekabl得到会话密钥 Kab, 主叫 节点 EPa的归属 GKg根据主叫节点 EPa的归属 GKg与主叫节点 EPa之间的 共享密钥 Kag和 CTa.challenge中设置的其他随机数 challenge釆用指定的 密钥导出算法导出密钥 EKag,用 EKag加密会话密钥 Kab并把加密结果和 加密采用的参数， 如其他随机数 challenge以及指定的加密导出算法设置 到 CTa. h235Key.secureSharedSecret字段中的对应子字段中， 在下面的叙 述中将用 EKag加密 Kab的加密结果和加密采用的参数称为 CTa, 把 CTb.generallD字段复制到 CTa.h235Key. secureSharedSecret.generallD字 段， 把 CTb复制到呼叫接入确认（ACF ) 消息中， 最后， 将携带 CTb以 及 CTa0 ACF消息发给主叫节点 EPa。
主叫节点 EPa接收到 ACF消息后， 提取 CTa和 CTb， 并根据 CTa中的 其他随机数 challenge和设定的加密导出算法等， 以及利用主叫节点 EPa 与主叫节点 EPa归属的 GKg的共享密钥 Kag导出密钥 Ekag, 解密 CTa中的 加密结果， 得到会话密钥 Kab。
主叫节点 EPa在获得会话密钥 Kab后 , 即可以利用该会话密钥 Kab创 建呼叫建立请求（ Setup )消息，将 ACF消息中的 CTb复制到 Setup消息中， 然后利用会话密钥 Kab设置 H235协议 V3版附录 D方案的鉴权信息， 主叫 节点 EPa采用直接路由模式向 EPb发送 Setup消息。
被叫节点 EPb接收到 Setup消息后， 提取 CTb , 根据 CTb中的 CTb.genmllD和 CTb.sendersID以及 CTb. challenge信息， 以及利用被叫节 点 EPb归属的 GKh与被叫节点 EPb之间的共享密钥 Kbh导出密钥 EKbh，并 解密 CTb中的 CTb.h235Key. secureSharedSecret字段中的 Ekab2得到会话 密钥 Kab。
被叫节点 EPb根据解密得到的 Kab对 Setup消息中的鉴权信息进行鉴 权， 鉴权通过后， 进行后续的 0931消¾传输。
在该方法中， 主叫节点 EPa与被叫节点 EPb之间的会话密钥 Kab在所 经过的每一跳 GK都要进行加密解密过程， 当主叫节点 EPa与被叫节点 EPb之间所经过的 GK级数较多时， 会增加 RAS消息传输的时延， 而且会 话密钥 Kab会在所经过的每一跳 GK处暴露， 安全性能差。
方法二、 基于主叫节点 EPa与被叫节点 EPb的归属 GK之间进行迪夫 赫曼密钥交换过程 ( DH )产生会话密钥 Kab, 主叫节点 EPa和被叫节点 EPb直接传输 H225协议中的 Q931消息时， 采用由基于主叫节点 EPa与被 叫节点 EPb的归属 GK所产生会话密钥 Kab进行鉴权的方法。
具体实现过程为： 图 1中，主叫节点 EPa向其归属 GKg发送 ARQ消息， 在 ARQ消息中设置独立的 ClearToken, 其中的 tokenOID为' Ί0" , 主叫节 点 EPa产生用于 DH协商的公钥， 并设置在 ClearToken.dhkey字段中， 主 叫节点 EPa将 ARQ消息传输至其所归属的 GKg。
支持 H235协议 V3版附录 I的 GKg接收到 ARQ消息后， 根据 ARQ消息 携带的被叫节点 EPb的信息确定被叫节点 EPb不属于主叫节点 EPa的归属 GKg管辖， 主叫节点 EPa的归属 GKg发起 LRQ消息到被叫节点 EPb归属的 GKh, LRQ消息中携带独立的 ClearToken, 其中 tokenOID字段为 "10", 且 ClearToken.dhkey字段的内容与 ARQ消息的 ClearToken.dhkey字段中的内 容一样， 包括 EPa产生的用于 DH协商的公钥。
如果在主叫节点 EPa归属的 GKg和被叫节点 EPb归属的 GKh之间还 存在 GK, 则所存在的 GK接收到 LRQ消息后， 对 LRQ消息进行复制， 发 送给上一级 GK, 直到发送给被叫节点 EPb归属的 GKh为止。
被叫节点 EPb归属的 GKh接收到 LRQ消息后 , 根据 LRQ消息中的 P T/CN2006/000168
ClearToken.tokenOID字段和被叫节点 EPM言息确定主叫节点 EPa和被叫 节点 EPb都支持 H235协议 V3版附录 I, 被叫节点 EPb归属的 GKh创建一个 ClearToken, 设置 tokenOID为" 12"， 在后面的叙述中将这个 ClearToken记 为 CTb。
被叫节点 EPb归属的 GKh产生 DH协商的公钥， 并与收到的 LRQ消息 中的公钥一起使用 DH算法计算出主叫节点 EPa与被叫节点 EPb直接传输 Q931消息的会话密钥 Kab。
被叫节点 EPb归属的 GKh随机产生一个随机数 challenge , 设置到 CTb.challenge字段中 ,然后根据这个随机数 challenge和被叫节点 EPb归属 的 GKh与被叫节点 EPb之间的共享密钥 Kbh采用设定的密钥导出算法导 出密钥 EKbh和密钥 KSbh。被叫节点 EPb归属的 GKh产生一个随机的初始 化向量 IV, 设置到 CTb.h235Key，securitySharedSecret.paramS.IV中。 被叫 节点 EPb归属的 GKh将会话密钥 Kab在密钥 Ekbh、 密钥 KSbh和初始化向 量 IV进行加密， 得到 ENCEKbh, KSbh，IV(Kab),把 ENCEKbh,KSbh，IV(Kab)设置到 CTb.h235Key.securitySharedSecretencryptedSession ey字段中。这种加密 会话密钥 Kab的方法在 H235协议 V3版附录 I中进行描述。
被叫节点 EPb归属的 GKh在 LCF消息中包含被叫节点 EPb归属的 GKh产生的公钥和 CTb , 向主叫节点 EPa归属的 GKg发送 LCF消息。
主叫节点 EPa归属的 GKg接收到被叫节点 EPb归属的 GK 发送的 LCF消息后， 获取 CTb和被叫节点 EPb归属的 GKh产生的公钥， 并将其复 制到 ACF消息中， 将 ACF消息发给主叫节点 EPa。
主叫节点 EPa接收到 ACF消息后，根据消息 ACF中的被叫节点 EPb归 属的 GKh产生的公钥，并与自己的公钥一起通过 DH算法计算出会话密钥 Kab。
主叫节点 EPa在获得会话密钥 Kab后， 即可以利用会话密钥 Kab创建 Setup消息， 将 ACF消息中的 CTb复制到 Setup消息中， 然后利用会话密钥 Kab设置 H235协议 V3版附录 D方案的鉴权信息， 主叫节点 EPa将 Setup消 息传输至被叫节点 EPb。
被叫节点 EPb接收到 Setup消息后， 提取 CTb， 并根据 CTb中的信息， 即随机数 challenge和和设定的密钥导出算法， 利用被叫节点 EPb归属的 GKh与被叫节点 EPb之间的共享密钥 Kbh导出密钥 EKbh和密钥 KSbh, 与 CTb中的初始化向量 IV—起解密 CTb.h235Key. secureSharedSecret. encryptedSessionKey 字段中的 ENCEKbh, KSbh, IV(Kab)得到会话密钥 Kab, EPb根据解密得到的会话密钥 Kab对 Setup消息进行鉴权。
该方法虽然克服了增加 RAS消息传输的时延， 以及由于会话密钥 Kab在所经过的每一跳 GK处暴露而导致的安全性能差的问题， 但是该方 法需要主叫节点 EPa以及主叫节点 EPa与被叫节点 EPb之间的 GK都支持 DH协商过程， 使其适用范围受到限制。
综上所述， 目前为主被叫节点分配会话密钥的方法不能够由主被叫 节点归属的 GK选择， 使分配会话密钥的方法不具有灵活性。 发明内容
有鉴于此， 本发明的主要目的在于提供一种直接路由模式下跨关守 管理范围的会话密钥的分配方法， 该方法能够使节点归属的 GK能够选 择会话密钥的分配方式， 以实现提高 GK分配会话密钥的灵活性。
根据上述目的， 本发明的具体方案是这样实现的：
一种直接路由模式下跨关守管理范围的会话密钥的分配方法， 该方 法包括：
a、主叫节点将其支持的会话密钥分配方式承载于呼叫接入请求消息 中传输至其归属的关守 GK; b、主叫节点归属的 GK根据呼叫接入请求消息中承载的主叫节点支 持的会话密钥分配方式信息确定主叫方会话密钥分配方式， 并将其承载 于定位请求消息中传输至被叫节点归属的 GK;
c、被叫节点归属的 GK根据定位请求消息中承载的信息确定被叫方 会话密钥分配方式， 并生成主被叫节点间的会话密钥， 将被叫方会话密 钥分配方式和会话密钥通过定位确认消息传输至主叫节点归属的 GK; d、 主叫节点归属的 GK根据定位确认消息中承载的信息、 主叫节点 支持的会话密钥分配方式确定会话密钥， 并将会话密钥通过呼叫接入确 认消息传输至主叫节点；
e、 主叫节点通过呼叫建立消息将会话密钥发送给被叫节点。
步骤 b所述主叫方会话密钥分配方式还根据主叫方预定规则， 所述 主叫方预定规则包括 GK的可用计算资源、和 /或主叫节点支持的会话密 钥分配方式、 和 /或主叫节点的安全级别。
步骤 c 所述被叫方会话密钥分配方式时还根据被叫方预定规则确 定， 所述被叫方预定规则包括 GK的可用计算资源、 和 /或主叫方会话密 钥分配方式、 和 /或被叫节点的安全级别。 ' 步骤 a所述将其支持的会话密钥分配方式承载于呼叫接入请求消息 的过程为：
主叫节点在不支持迪夫赫曼密钥交换过程 DH协商时， 将 "10" 承 载于呼叫接入请求消息的明文标记的 tokenOID中，传输至其归属的 GK; 主叫节点在支持 DH协商时， 将 "14" 承载于呼叫接入请求消息的 明文标记的 tokenOID中，将主叫节点的 DH公钥承载于所述明文标记的 dhkey中， 传输至其归属的 GK。
步骤 b所述的主叫方会话密钥分配方式包括： 被叫节点归属的 GK 产生会话密钥、和 /或主被叫节点归属的 GK之间进行 DH协商、和 /或主 叫节点与被叫节点归属的 GK之间进行 DH协商。
步驟 b所述将确定主叫方会话密钥分配方式承载于定位请求消息中 传输至被叫节点归属的 GK的过程为：
主叫节 Λ归属的 GK确定主叫方会话密钥分配方式为被叫节点归属 的 GK产生会话密钥时， 将 "10" 承载于定位请求消息中的明文标记的 tokenOID中， 传输至被叫节点归属的 GK;
主叫节点归属的 GK确定主叫方会话密钥分配方式为主被叫节点归 属的 GK之间进行 DH协商时， 主叫节点归属的 GK产生 DH公钥， 并 承载于定位请求消息中的明文标记的 dhkey中， 将 "14" 承载于所述明 文标记的 tokenOID中， 传输至被叫节点归属的 GK;
主叫节点归属的 GK确定主叫方会话密钥分配方式为主叫节点与被 叫节点归属的 GK之间进行 DH协商时， 将所述呼叫接入请求消息中的 明文标记承载于定位请求消息中， 传输至被叫节点归属的 GK。
步骤 c所述被叫方会话密钥分配方式包括： 被叫节点的归属关守产 生会话密钥、 和 /或 DH协商。
步驟 c所述将被叫方会话密钥分配方式和会话密钥通过定位确认消 息传输至主叫节点归属的 GK过程包括：
被叫节点归属的 GK确定被叫方会话密钥分配方式为被叫节点归属 的 GK产生会话密钥时，生成主被叫节点间的会话密钥 ,并生成 tokenOID 为 "12" 的 CTb、 tokenOID为 "13" 的 CTg, 通过定位确认消息传输至 主叫节点归属的 GK;
' 被叫节点归属的 GK确定被叫方会话密钥分配方式为 DH协商时， 产生 DH公钥， 并将所述 DH公钥和从定位请求消息中获取的 DH公钥 通过 DH算法计算出会话密钥，生成 tokenOID为" I2，，的 CTb及 tokenOID 为 "15" 且 dhkey为所述被叫节点归属的 GK产生的 DH公钥的明文标 记，将所述 CTb及所述明文标记通过定位确认消息传输至主叫节点归属 的 GK。
步骤 d所述将会话密钥通过呼叫接入确认消息传输至主叫节点的过 程为：
主叫节点归属的 GK获取定位确认消息中承载的被叫方会话密钥分 配方式信息并判断：
如果该信息为被叫节点归属的 GK产生会话密钥，根据定位确认消息 中承载的 CTg生成 CTa， 将 CTa和定位确认消息中的 CTb通过呼叫接入确 认消息传输至主叫节点；
如果该信息为 DH协商且确定主叫节点不支持 DH协商， 根据其 DH 公钥、定位确认消息中的被叫节点归属的 GK的 DH公钥通过 DH算法计算 会话密钥， 并产生 CTa, 将所述 CTa、 定位确认消息中的 CTb通过呼叫接 入确认消息传输至主叫节点；
如果该信息为 DH协商且确定主叫节点支持 DH协商， 获取所述定 位确认消息中的明文标记， 并将其承载于呼叫接入确认消息中传输至主 叫节点。
步驟 d所述生成主被叫节点间的会话密钥的过程为：
主叫节点判断呼叫接入确认消息中是否包含 tokenOID为 "15"的明 文标记二
如果不包含 tokenOID为 "15" 的明文标记， 根据其与归属的 GK之 间的共享密钥、 呼叫接入确认消息中的 CTa计算出会话密钥；
如果包含 tokenOID为 "15" 的明文标记， 根据其 DH公钥、 所述呼 叫接入确认消息中承载的被叫节点归属的 GK的 DH公钥计算会话密钥。
步骤 e所述将会话密钥发送给被叫节点的过程为：
主叫节点根据所述会话密钥设置呼叫建立消息的鉴权信息， 同时， 将所述 CTb承载于呼叫建立消息中传输至被叫节点；
被叫节点根据所述呼叫建立消息中的 CTb获取所述会话密钥，并根 据所述会话密钥对呼叫建立消息进行鉴权；
被叫节点将所述会话密钥确定为所述主叫节点与其进行直接路由模 式的消息传输的会话密钥。
在步骤 a之前， 所述方法还包括：
主被叫节点将其支持 DH协商的信息承载于网守发现请求或注册请 求消息的明文标记中传输至其归属的 GK。
从上述方案可以看出， 本发明通过在主被叫归属的 GK设置其选取 会话密钥的分配方式， 使主被叫节点归属的 GK能够根据网络的具体情 况灵活选择主被叫节点间的会话密钥， 本发明中能够在主被叫节点均不 支持 DH协商过程时， 通过主被叫节点归属的 GK之间进行 DH协商来 分配主被叫节点间的会话密钥， 为主被叫节点提供了一种新的端到端的 安全服务， 提高了会话密钥的安全性， 因此， 通过本发明提供的技术方 案实现了提高归属关守分配会话密钥的灵活性、 使消息传输的安全等级 与消息传输时延取得平衡的目的。 附图简要说明
图 1 为包括两个 GK的 H323***的组网逻辑框图。 实施本发明的方式
为了使本发明的目的、 技术方案和优点更加清楚明白， 以下举实施 例并参照附图， 对本发明进行进一步详细的说明。
为了使节点归属的 GK能够选择会话密钥的分配方式，本发明将主被 叫节点归属的 GK根据接收消息中承载的信息、预先设置的选择会话密钥 分配方式的预定规则确定主被叫方会话密钥分配方式， 并为主被叫节点 分配会话密钥。
以下对本发明提供的方法进行详细的叙述。
本发明适用于 H323***跨 GK管理范围的直接路由模式， 即主被叫 节点分别归属不同 GK,且主被叫节点之间直接的消息交互过程在没有安 全性保证的网络， 如网际协议（ IP ) 网絡上进行。
实施本发明提供方法的前提是： 在分配会话密钥的过程中， GK对其 管辖节点的所有 RAS消息进行鉴权，节点也对其归属的 GK的 RAS消息进 行鉴权， 使节点和其归属 GK之间达到相互信任的目的。 相互连接的 GK 之间也进行相互鉴权， 避免 GK域间的恶意攻击， 使相互连接的 GK之间 达到相互信任的目的。通过上述鉴权过程保证 H323***中网络实体之间 的 RAS消息的安全性。
本发明首先需要设置 GK选择会话密钥分配方式的预定规则，该预定 规则可通过静态配置、 动态配置等方式设置在 GK：。
预定规则可根据 GK所处的主被叫方分为：主叫方预定规则和被叫方 预定规则。 主被叫方预定规则包含的内容可根据实际网络中的实际需要 来设定，如主叫方预定规则可包括下述的一项或多项： GK可用的计算资 源、 主叫节点支持的会话密钥分配方式以及主叫节点的安全级别等， 被 叫方预定规则可包括下述的一项或多项： GK可以的计算资源、主叫方会 话密钥分配方式以及被叫节点的安全级别等。
在进行上述设置后，主被叫节点归属的 GK均可根据各种因素灵活选 取会话密钥的分配方式。
下面通过下述三种过程对本发明的主被叫节点归属的 GK行使会话 密钥分配选择权实现会话密钥分配过程进行详细描述。
三种会话密钥的分配过程分别为： DRC I ： 主被叫方会话密钥分配方式均为被叫节点归属的 GK产生 会话密钥。
DRC II ： 主叫方会话密钥分配方式为主被叫节点归属的 GK之间进 行 DH协商且被叫方会话密钥分配方式为 DH协商。
DRC III ： 主叫方会话密钥分配方式为主叫节点与被叫节点归属的 GK之间进行 DH协商、 且被叫方会话密钥分配方式为 DH协商。
本发明中的节点可以在 GK发现过程中或节点注册过程中向其归属 GK表明其是否支持 H235协议 V3版附录 I, 即表明节点是否支持本发明 提供的方法， 如节点在网守发现请求（GRQ ) 消息或注册请求（RRQ ) 消息中携带独立 ClearToken,并把该 ClearToken中的 tokenOID字段设置为 "10" 。 节点归属 GK接收 GRQ消息或 RRQ消息后， 在识别出消息的 ClearToken中的 tokenOID为 "10" 时， 回复网守发现确认（ GCF ) 消息 或注册确认消息 （RCF ) , 接受节点， GCF消息或 RCF消息中携带与所 对应的 GRQ消息或 RRQ消息中相同的 ClearToken。
当主叫节点不支持 DH协商过程时， 主叫节点归属的 GK可以根据主 叫方预定规则分别选择 DRCI、 DRCII过程来分配主被叫节点间的会话密 钥， 被叫节点归属的 GK同样可以选择 DRCI、 DRCII过程来分配主被叫 节点间的会话密钥。
当主叫节点支持 DH协商过程时， 主叫节点归属的 GK可以分别选择 DRC I、 DRC III过程来分配主被叫节点间的会话密钥， 被叫节点归属的 GK同样可以选择 DRC I、 DRC III过程来分配主被节点间的会话密钥。
下面结合附图 1对主被叫节点归属的 GK通过 DRC I、 DRC II、 DRC III 过程实现主被叫节点间的会话密钥分配过程进行详细描述：
DRCI过程的步骤 1、 主叫节点 EPa使用直接路由模式呼叫被叫节点 EPb前， 主叫节点 EPa向其归属的 GKg发送 ARQ消息，该消息中应包含一 个独立的 ClearToken, 该 ClearToken的 tokenOID设置为 "10" , 表明主叫 节点 EPa不支持 DH协商， 该 ClearToken的其他字段不使用。
DRCI过程的步骤 2、 主叫节点 EPa归属的 GKg接收 ARQ消息， 根据 ARQ消息携带的被叫节点 EPb的信息确定被叫节点 EPb不属于主叫节点 EPa的归属 GKg管辖， 主叫节点 EPa归属的 GKg发起 LRQ消息， 以便向被 叫节点 EPb归属的 GKh查询被叫节点 EPb的地址。
主叫节点 EPa归属的 GKg生成 LRQ消息， 主叫节点 EPa归属的 GKg根 据 ARQ消息的 ClearToken的 tokenOID为 "10" 和主叫方预定规则在确定 主叫方会话密钥分配方式为被叫节点归属的 GK产生会话密钥时，使 LRQ 消息中包含一个 ClearToken, 该 ClearToken的 tokenOID应设置为 "10" , 表明主叫方会话密钥分配方式为被叫节点归属的 GK产生会话密钥， 该 ClearToken中的其他字段不使用，在进行上述设置后， 主叫节点 EPa归属 的 GKg向被叫节点 EPb归属的 GKh^送 LRQ消息。
DRCI过程的步骤 3、被叫节点 EPb归属的 GKh接收 LRQ消息，获取该 消息中的 ClearToken的 tokenOID为 "10" 、 且根据被叫方预定规则确定 使用被叫节点归属的 GK产生会话密钥时， 使用随机数产生会话密钥 Kab。 被叫节点 EPb归属的 GKh为了加密会话密钥 Kab, 首先， 产生随机 数 challenge, 并使用被叫节点 EPb归属的 GK 和主叫节点 EPa归属的 GKg 之间的共享密钥 Kgh和随机数 challenge以及指定的密钥导出算法导出密 钥 EKgh。 然后， 被叫节点 EPb归属的 GKh用 EKgh^。密会话密钥 Kab得到 EKabl , 并把 EKabl和加密参数， 如加密算法和加密用到的初始化向量 等一起，设置到一个独立的 ClearToken. h235Key. secureSharedSecret字段 中。 这个 ClearToken的 tokenOID为 "13" , 称为 CTg。 同时，被叫节点 EPb 归属的 GKh使用类似的过程产生另一个 ClearToken , 该 ClearToken的 tokenOID为 "12" , 即 CTb。 最后， 被叫节点 EPb归属的 GKh生成 LCF消 息， 该 LCF消息中包含 CTg和 CTb。 被叫节点 EPb归属的 GKh将 LCF消息 直接发送至主叫节点 EPa归属的 GKg ,或向被叫节点 EPb归属的 GKh的上 一级 GI ^送 LCF消息， 直至传输至主叫节点 EPa归属的 GKg。
DRCI过程的步骤 4、被叫节点 EPb归属的 GKh接收 LCF消息， 获取该 消息中 ClearToken的 tokenOID为 "13" 时， 解密 CTg， 并产生 CTa。 具体 过程如下：首先，主叫节点 EPa归属的 GKg通过 CTg中的随机数 challenge, IV以及指定的密钥导出算法导出密钥 EKgh。 然后， 主叫节点 EPa归属的 GKg用 EKgh解密 EKabl得到会话密钥 Kab。 为了产生 CTa， 首先， 主叫节 点 EPa归属的 GKg用主叫节点 EPa归属的 GKg和主叫节点 EPa之间的共享 密钥 Kag和随机数 challenge, 以及指定的密钥导出算法导出密钥 EKag。 然后， 主叫节点 EPa归属的 GKg用密钥 EKag加密会话密钥 Kab得到 EKabl , 并把 EKabl和加密参数， 如加密算法和加密用到的初始化向量 等一起设置到一个独立的 ClearToken. h235Key. secureSharedSecret字段 中。 这个 ClearToken的 tokenOID为， Ή", 称为 CTa。 最后， 主叫节点 EPa 归属的 GKg生成 ACF消息，其中包含 CTa和其接收的 LCF消息中复制过来 的 CTb。
若主叫节点 EPa归属的 GKg管理范围内存在下一级 GK, 则 ACF消息 中应包含 CTa和 CTg , 下一级 GK使用其与主叫节点 EPa归属的 GKg的导 出密钥加密 Kab生成。
在进行上述设置后， 主叫节点 EPa归属的 GKg向主叫节点 EPa发送
ACF消息。
DRCI过程的步骤 5、 主叫节点 EPa接收 ACF消息， 从该消息中提取 CTa, 并根据 CTa中的信息和其与主叫节点 EPa归属的 GKg的共享密钥 Kag导 出 密钥 EKag , 然后 ， 使用 EKag解 密 CTa.h235Key. secureSharedSecret. encryptedSessionKey得 j会话密铜 Kab。 主叫节点 EPa创建 Setup消息， 把 ACF消息中的 CTb复制到 Setup消息 中， 然后利用会话密钥 Kab设置 H235协议 V3版附录 D和附录 F的鉴权信 息。 主叫节点 EPa直接向被叫节点 EPb发出 Setup消息。
被叫节点 EPb接收 Setup消息，从该消息中提取 CTb , 并根据 CTb中信 息和其与被叫节点 EPb所属 GKh的共享密钥 Kbh导出密钥 EKbh, 然后使 用 EKbh角 "密 CTb .h235Key. secureSharedSecret. encryptedSessionKey 'J 会话密钥 Kab; 此时， 被叫节点 EPb就可以使用会话密钥 Kab对 Setup消息 进行鉴权， 鉴权通过后将会话密钥 Kab确定为主叫节点 EPb与被叫节点 EPa之间进行 Q9'31消息传输的会话密钥。
后续的呼叫过程利用 H235协议 V3版附录 D和附录 F进行鉴别。
DRCII过程的步骤 1、 主叫节点 EPa使用直接路由模式呼叫被叫节点 被叫节点 EPb前，主叫节点 EPa向其归属的 GKg发送 ARQ消息，该消息中 应包含一个独立的 ClearToken,该 ClearToken的 tokenOID应设置为 "10" , 表明主叫节点 EPa不支持 DH协商， 该 ClearToken的其他字段不使用。
DRCII过程的步骤 2、 主叫节点 EPa归属的 GKg接收 ARQ消息， 根据 ARQ消息携带的被叫节点 EPb的信息确定被叫节点 EPb不属于主叫节点 EPa的归属 GKg管辖， 主叫节点 EPa归属的 GKg发起 LRQ消息， 以便向被 叫节点 EPb归属的 GKh查询被叫节点 EPb的地址。
主叫节点 EPa归属的 GKg生成 LRQ消息， 主叫节点 EPa归属的 GKg根 据 ARQ消息的 ClearToken的 tokenOID为 "10" 和主叫方预定规则在确定 主叫方会话密钥分配方式为主被叫节点归属的 GK进行 DH协商时产生会 话密钥时， 在该消息中包含一个 ClearToken' ClearToken中的 tokenOID 为 "14" , 表明主叫方会话密钥分配方式为主被叫节点归属的 GK进行 DH协商， 主叫节点 EPa归属的 GKg产生主叫节点 EPa归属的 GKg的 DH公 钥， 并设置在该 ClearToken的 dhkey中。 06 000168 在进行上述设置后， 主叫节点 EPa归属的 GKg向被叫节点 EPb归属的 GKh发送 LRQ消息。
DRCII过程的步骤 3、 被叫节点 EPb归属的 GKh接收 LRQ消息， 在检 验到该消息中 ClearToken的 tokenOID为 "14" 、 且根据被叫方预定规则 确定被叫方会话密钥分配方式为 DH协商时， 被叫节点 EPb归属的 GKh开 始与主叫节点 EPa归属的 GKg使用 DH协商过程确定主被叫节点间的会 话密钥。具体过程为： 首先，被叫节点 EPb归属的 GKh生成自身 DH公钥， 与从 LRQ消息中获取的 DH公钥一起， 使用 DH算法计算出会话密钥 Kab。 然后， 使用 DRC I过程的步骤 3的方法生成 tokenOID为 "12" 的 CTb。 最 后， GKh生成 LCF消息， 其中包含 CTb和一个独立的 ClearToken, 该 ClearToken的 tokenOID为 "15" , , 并包含被叫节点 EPb归属的 GKh生成的 DH公钥。 ClearToken的 tokenOID为 "15" 表明该 ClearToken中包含有被 叫节点归属的 GK的 DH公钥。
如果被叫节点 EPb归属的 GKh由于不支持 DH算法或安全策略不允 许等因素根据被叫方预定规则确定被叫方会话密钥分配方式为被叫节 点归属的 GK产生会话密钥时 , 则被叫节点 EPb归属的 GKh应该使用 DRC I过程的步驟 3生成 LCF消息。
在进行上述设置后， 被叫节点 EPb归属的 GKh向主叫节点 EPa归属的 GKg发送 LCF消息。
DRC II过程的步骤 4、 主叫节点 EPa归属的 GKg接收 LCF消息， 在检 验出消息中包含 tokenOID为 "15" 的 ClearToken, 且主叫节点不支持 DH 协商时， 计算会话密钥并产生 CTa。 具体过程为： 从 LCF消息独立的 ClearToken中获得 DH公钥， 与自己生成的 DH公钥一起使用 DH算法计算 出会话密钥 Kab。 然后， 使用与 DRC I过程中步骤 4基本相同的过程生成 CTa。 最后， 主叫节点 EPa归属的 GKg生成 ACF消息， 其中包含 CTa和从 T N2006/000168
LCF消息中复制过来的 CTb。
如果主叫节点 EPa归属的 GKg在检验出 LCF消息中包含 tokenOID为 "15" 的 ClearToken、 且主叫节点支持 DH协商时， 则主叫节点 EPa归属 的 GKg应该使用 DRCIII过程的步骤 4生成 ACF消息。
如果主叫节点 EPa归属的 GKg在检验出 LCF消息中包含有 tokenOID 为 "13" 的 ClearToken时， 主叫节点 EPa归属的 GKg应使用 DRC I过程的 步骤 4生成 ACF消息。
在进行上述设置后主叫节点 EPa归属的 GKg向主叫节点 EPa发送 ACF消息。
DRCII过程的步骤 5、主叫节点 EPa接收 ACF消息， 如果主叫节点 EPa 在检验出 ACF消息中不包含 tokenOID为 "15" 的 ClearToken时， 从 ACF 消息中提取 CTa, 并根据 CTa中的信息和其与主叫节点 EPa归属的 GKg的 共享密钥 Kag导出密钥 EKag , 然后使用 EKag解密 CTa.h235Key. secureSharedSecret. encryptedSessionKey得到会话密钢 Kab。
如果主叫节点 EPa在检验出 ACF消息中包含 tokenOID为 " 15 " 的 ClearToken时， 根据 DRCIII过程的步骤 5计算出会话密钥 Kab。
主叫节点 EPa创建 Setup消息， 把 ACF消息中的 CTb复制到 Setup消息 中， 然后，利用会话密钥 Kab设置 H235协议 V3版附录 D和附录 F的鉴权信 息。 主叫节点 EPa直接向被叫节点 EPb发送 Setup消息。
被叫节点 EPb接收 Setup消息， 并从该消息中提取 CTb, 并根据 CTb 中信息和其与被叫节点 EPb所属的 GKh的共享密钥 Kbh导出密钥 EKbh, 然 后 使 用 EKbh 解 密 CTb .h235Key. secureSharedSecret. encryptedSessionKey得到会话密钥 Kab。 此时， 被叫节点 EPb就可以使用 会话密钥 Kab对 Setup消息进行鉴权， 鉴权通过后将会话密钥 Kab确定为 主叫节点 EPb与被叫节点 EPa之间进行 Q931消息传输的会话密钥。 后续的呼叫过程利用 H235协议 V3版附录 D和附录 F进行鉴别。
DRCIII过程的步骤 1、 主叫节点 EPa支持 DH协商过程， 主叫节点 EPa 使用直接路由模式呼叫被叫节点 EPb前， 主叫节点 EPa生成 DH公钥， 并 设置在 ARQ消息的独立的 ClearToken的 dhkey中 , 该 ClearToken的 tokenOID设置为 "14" , 其他字段不使用。
DRCIII过程的步骤 2、 主叫节点 EPa归属的 GKg接收 ARQ消息， 根据 ARQ消息携带的被叫节点 EPb的信息确定被叫节点 EPb不属于主叫节点 EPa的归属 GKg管辖， 主叫节点 EPa归属的 GKg发起 LRQ消息， 以便向被 叫节点 EPb归属的 GKh查询被叫节点 EPb的地址。
主叫节点 EPa归属的 GKg生成 LRQ消息， 主叫节点 EPa归属的 GKg根 据 ARQ消息的 ClearToken的 tokenOID为 "14" 和主叫方预定规则在确定 主叫方会话密钥分配方式为主叫节点与被叫节点归属的 GK进行 DH协商 时，将 ARQ消息中的 ClearToken复制到 LRQ消息中，主叫节点 EPa归属的 GKg向被叫节点 EPb归属的 GKh发送 LRQ消息。
DRCIII过程的步骤 3、 被叫节点 EPb归属的 GKh接收 LRQ消息， 在检 验出 LRQ消息中包含有 tokenOID为 "14" 的独立 ClearToken、 且根据被 叫方预定规则确定被叫方会话密钥分配方式为 DH协商时， 根据使用 DH 协商过程开始与主叫节点 EPa协商会话密钥 Kab。 具体过程为： 首先， 被 叫节点 EPb归属的 GKh生成 DH公钥， 与从 LRQ中获取的主叫节点 EPa归 属的 GKg的 DH公钥一起， 使用 DH算法计算出会话密钥 Kab。 然后, 使 用与 DRC I过程中的步骤 3的方法生成 CTb, 该 CTb的 tokenOID为 "12" 。 最后， 被叫节点 EPb归属的 GKh生成 LCF消息， 其中包含 CTb和一个独立 的 ClearToken,该 ClearToken中的 tokenOID为 "15" ,并包含被叫节点 EPb 归属的 GKh的 DH公钥。 ClearToken的 tokenOID为 "15"表明该 ClearToken 中包含有被叫节点归属的 GK的 DH公钥。 如果被叫节点 EPb归属的 GKh由于不支持 DH算法或安全策略不允 许等因素根据被叫方的预定规则确定被叫方会话密钥分配方式为被叫 节点归属的 GK产生会话密钥时， 则被叫节点 EPb归属的 GKh应该使用 DRCI过程的步骤 3生成 LCF消息。
在进行上述设置后 ,被叫节点 EPb归属的 GKh向主叫节点 EPa归属的 GKg发送 LCF消息。
DRC III过程的步骤 4、 主叫节点 EPa归属的 GKg接收 LCF消息， 在检 验出 LCF消息中包含有 tokenOID为 "15" 的 ClearToken、 且主叫节点支持 DH协商时，主叫节点 EPa归属的 GKg生成 ACF消息，该消息中包含从 LCF 消息中复制过来的所有 ClearToken。 GKg向主叫节点 EPa发送 ACF消息。
如果主叫节点 EPa归属的 GKg在检验出 LCF消息中包含有 tokenOID 为 " 13" 的 ClearToken、 且确定主叫节点 EPa不支持 DH协商时， 主叫节 点 EPa归属的 GKg应使用 DRCI过程中的步骤 4生成 ACF消息。
DRCIII过程的步骤 5、 主叫节点 EPa接收 ACF消息， 在检验出该消息 中包含有 tokenOID为 "15" 的独立 ClearToken时， 计算会话密钥。 具体 过程为：主叫节点 人 ClearToken中获得被叫节点 EPb归属的 GKh的 DH 公钥， 与自己生成的 DH公钥一同使用 DH算法计算出会话密钥 Kab。
主叫节点 EPa在检验出该消息中包含有 tokenOID为 "13" 的独立 ClearToken时 , 应使用 DRCI过程的步骤 5的计算会话密钥的方法来计算 会话密钥 Kab。
主叫节点 EPa创建 Setup消息， 把 ACF消息中的 CTb复制到 Setup消息 中， 然后利用会话密钥 Kab设置 H235协议 V3版附录 D和附录 F的鉴权信 息。 主叫节点 EPa直接向被叫节点 EPb发出 Setup消息。
被叫节点 EPb接收 Setup消息, 从该消息中提取 CTb, 并根据 CTb中 的信息和其与被叫节点 EPb所属的 GKh的共享密钥 Kbh导出密钥 EKbh， 然 后 使 用 EKbh 解 密 CTb .h235Key. secureSharedSecret. encryptedSessionKey得到会话密钥 Kab, 此时， 被叫节点 EPb就可以使用 会话密钥 Kab对 Setup消息进行鉴权， 鉴权通过后将会话密钥 Kab确定为 主叫节点 EPb与被叫节点 EPa之间进行 Q931消息传输的会话密钥 Kab。
后续的呼叫过程利用 H235协议附录 D和附录 F进行鉴别。
本发明中 tokenOID标识符的意义如表 1所示:
Object Object Identifier Description
Identifier Value
Reference
"10" {itu-t (0) 在 GRQ/RRQ、 GCF/RCF、 recommendation (0) ARQ的独立 ClearToken中使用，表 h (8) 235 version (0)
明节点 Ep不支持 DH过程。
3 48}
在 LRQ的独立 ClearToken中 使用， 表明此 ClearToken包含主叫 方的 DH公钥。
"11" {itu-t (0) 在交给主叫 节点的独立 recommendation (0) ClearToken中 使用 ， 表明 此 h (8) 235 version (0)
ClearToken中包含会话密钥。 3 49}
"12" {itu-t (0) 在交给被叫 节点的独立 recommendation (0) ClearToken中 使用 ， 表明 此 h (8) 235 version (0)
ClearToken中包含会话密钥。 3 50}
"13" {itu-t (0) 在 LCF的独立 ClearToken中使 recommendation (0) 用， 表明此 ClearToken包含会话密 h (8) 235 version (0)
钥。 3 51}
"14" {itu-t (0) 在 GRQ/RRQ、 GCF/RCF、 recommendation (0) ARQ的独立 ClearToken中使用，表 h (8) 235 version (0)
明 EP支持 DH过程。
3 52}
在 LRQ的独立 ClearToken中 使用， 表明此 ClearToken包含主叫 方的 DH公钥。
"15" {itu-t (0) 在交给主叫 节点的独立 recommendation (0) ClearToken中 使用 ， 表明 此 h (8) 235 version (0)
ClearToken中包含被叫方的 DH公 3 53}
钥。
虽然通过实施例描绘了本发明， 本领域普通技术人员知道， 本发明 有许多变形和变化而不脱离本发明的精神， 本发明的申请文件的权利要 求包括这些变形和变化。

Claims

权利要求书
1、一种直接路由模式下跨关守管理范围的会话密钥的分配方法，其 特征在于， 该方法包括：
a、主叫节点将其支持的会话密钥分配方式承载于呼叫接入请求消息 中传输至其归属的关守 GK;
b、主叫节点归属的 GK根据呼叫接入请求消息中承载的主叫节点支 持的会话密钥分配方式信息确定主叫方会话密钥分配方式， 并将其承载 于定位请求消息中传输至被叫节点归属的 GK;
c、被叫节点归属的 GK根据定位请求消息中承载的信息确定被叫方 会话密钥分配方式， 并生成主被叫节点间的会话密钥， 将被叫方会话密 钥分配方式和会话密钥通过定位确认消息传输至主叫节点归属的 GK; d、 主叫节点归属的 GK根据定位确认消息中承载的信息、 主叫节点 支持的会话密钥分配方式确定会话密钥， 并将会话密钥通过呼叫接入确 认消息传输至主叫节点；
e、 主叫节点通过呼叫建立消息将会话密钥发送给被叫节点。
2、 如权利要求 1所述的方法， 其特征在于， 步骤 b所述主叫方会话 密钥分配方式还根据主叫方预定规则， 所述主叫方预定规则包括 GK的 可用计算资源、 和 /或主叫节点支持的会话密钥分配方式、 和 /或主叫节 点的安全级别。
3、 如权利要求 1所述的方法， 其特征在于， 步骤 c所述被叫方会话 密钥分配方式时还根据被叫方预定规则确定， 所述被叫方预定规则包括 GK的可用计算资源、和 /或主叫方会话密钥分配方式、 和 /或被叫节点的 安全级别。
4、 如权利要求 1所述的方法， 其特征在于， 步骤 a所述将其支持的 会话密钥分配方式承载于呼叫接入请求消息的过程为：
主叫节点在不支持迪夫赫曼密钥交换过程 DH协商时， 将 "10" 承 载于呼叫接入请求消息的明文标记的 tokenOID中，传输至其归属的 GK; 主叫节点在支持 DH协商时， 将 "14" 承载于呼叫接入请求消息的 明文标记的 tokenOID中，将主叫节点的 DH公钥承载于所述明文标记的 dhlcey中， 传输至其归属的 GK。
5、 如权利要求 1或 4所述的方法， 其特征在于， 步骤 b所述的主叫 方会话密钥分配方式包括： 被叫节点归属的 GK产生会话密钥、 和 /或主 被叫节点归属的 GK之间进行 DH协商、和 /或主叫节点与被叫节点归属 的 GK之间进行 DH协商。
6、如权利要求 5所述的方法， 其样征在于， 步骤 b所述将确定主叫 方会话密钥分配方式承载于定位请求消息中传输至被叫节点归属的 GK 的过程为：
主叫节点归属的 GK确定主叫方会话密钥分配方式为被叫节点归属 的 GK产生会话密钥时， 将 "10" 承载于定位请求消息中的明文标记的 tokenOID中， 传输至被叫节点归属的 GK;
主叫节点归属的 GK确定主叫方会话密钥分配方式为主被叫节点归 属的 GK之间进行 DH协商时， 主叫节点归属的 GK产生 DH公钥， 并 承载于定位请求消息中的明文标记的 dhkey中， 将 "14" 承载于所述明 文标记的 tokenOID中， 传输至被叫节点归属的 GK;
主叫节点归属的 GK确定主叫方会话密钥分配方式为主叫节点与被 叫节点归属的 GK之间进行 DH协商时， 将所述呼叫接入请求消息中的 明文标记承载于定位请求消息中， 传输至被叫节点归属的 GK。
7、 如权利要求 1或 4所述的方法， 其特征在于， 步骤 c所述被叫方 会话密钥分配方式包括： 被叫节点的归属关守产生会话密钥、 和 /或 DH 协商。
8、 如权利要求 7所述的方法， 其特征在于， 步骤 c所述将被叫方会 话密钥分配方式和会话密钥通过定位确认消息传输至主叫节点归属的 GK过程包括：
被叫节点归属的 GK确定被叫方会话密钥分配方式为被叫节点归属 的 GK产生会话密钥时，生成主被叫节点间的会话密钥，并生成 tokenOID 为 "12" 的 CTb、 tokenOID为 "13" 的 CTg, 通过定位确认消息传输至 主叫节点归属的 GK;
被叫节点归属的 GK确定被叫方会话密钥分配方式为 DH协商时， 产生 DH公钥， 并将所述 DH公钥和从定位请求消息中获取的 DH公钥 通过 DH算法计算出会话密钥，生成 tokenOID为 "12"的 CTb及 tokenOID 为 "15" 且 dhkey为所述被叫节点归属的 GK产生的 DH公钥的明文标 记，将所述 CTb及所述明文标记通过定位确认消息传输至主叫节点归属 的 GK。
9、 如权利要求 8所述的方法， 其特征在于， 步骤 d所述将会话密钥 通过呼叫接入确认消息传输至主叫节点的过程为：
主叫节点归属的 GK获取定位确认消息中承载的被叫方会话密钥分 配方式信息并判断：
如果该信息为被叫节点归属的 GK产生会话密钥 ,根据定位确认消息 中承载的 CTg生成 CTa , 将 CTa和定位确认消息中的 CTb通过呼叫接入确 认消息传输至主叫节点；
如果该信息为 DH协商且确定主叫节点不支持 DH协商， 根据其 DH 公钥、定位确认消息中的被叫节点归属的 GK的 DH公钥通过 DH算法计算 会话密钥， 并产生 CTa, 将所述 CTa、 定位确认消息中的 CTb通过呼叫接 入确认消息传输至主叫节点； 如果该信息为 DH协商且确定主叫节点支持 DH协商， 获取所述定 位确认消息中的明文标记， 并将其承载于呼叫接入确认消息中传输至主 叫节点。
10、 如权利要求 8所述的方法， 其特征在于， 步骤 d所述生成主被 叫节点间的会话密钥的过程为：
主叫节点判断呼叫接入确认消息中是否包含 tokenOID为 "15"的明 文标记：
如果不包含 tokenOID为 "15" 的明文标记， 根据其与归属的 GK之 间的共享密钥、 呼叫接入确认消息中的 CTa计算出会话密钥；
如果包含 tokenOID为 "15" 的明文标记， 根据其 DH公钥、 所述呼 叫接入确认消息中承载的被叫节点归属的 GK的 DH公钥计算会话密钥。
11、 如权利要求 9所述的方法， 其特征在于， 步骤 e所述将会话密 钥发送给被叫节点的过程为：
主叫节点根据所述会话密钥设置呼叫建立消息的鉴权信息， 同时， 将所述 CTb承载于呼叫建立消息中传输至被叫节点；
被叫节点根据所述呼叫建立消息中的 CTb获取所述会话密钥，并根 据所述会话密钥对呼叫建立消息进行鉴权；
被叫节点将所述会话密钥确定为所述主叫节点与其进行直接路由模 式的消息传输的会话密钥。
12、 如权利要求 1所述的方法， 其特征在于， 在步骤 a之前， 所述 方法还包括：
主被叫节点将其支持 DH协商的信息承载于网守发现请求或注册请 求消息的明文标记中传输至其归属的 GK。
PCT/CN2006/000168 2005-02-04 2006-01-26 Procede de distribution de la cle de session dans la gamme de gestion du portier transversal selon le mode du trajet le plus direct WO2006081765A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP06705589.7A EP1808978B2 (en) 2005-02-04 2006-01-26 A method and system for distributing the session key across Gatekeeper zones in the direct routing mode
ES06705589.7T ES2402862T5 (es) 2005-02-04 2006-01-26 Un método y sistema para distribuir la clave de sesión a través de las zonas con múltiples controladores de acceso, Gatekeeper, según el modo de encaminamiento directo
US11/648,924 US7983280B2 (en) 2005-02-04 2007-01-03 Method and system for distributing session key across gatekeeper zones in a direct-routing mode

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200510005397.4 2005-02-04
CNB2005100053974A CN100382484C (zh) 2005-02-04 2005-02-04 一种直接路由模式下跨关守管理范围的会话密钥分配方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/648,924 Continuation US7983280B2 (en) 2005-02-04 2007-01-03 Method and system for distributing session key across gatekeeper zones in a direct-routing mode

Publications (1)

Publication Number Publication Date
WO2006081765A1 true WO2006081765A1 (fr) 2006-08-10

Family

ID=36776968

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/000168 WO2006081765A1 (fr) 2005-02-04 2006-01-26 Procede de distribution de la cle de session dans la gamme de gestion du portier transversal selon le mode du trajet le plus direct

Country Status (5)

Country Link
US (1) US7983280B2 (zh)
EP (1) EP1808978B2 (zh)
CN (1) CN100382484C (zh)
ES (1) ES2402862T5 (zh)
WO (1) WO2006081765A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050238174A1 (en) * 2004-04-22 2005-10-27 Motorola, Inc. Method and system for secure communications over a public network
EP3439345A1 (en) * 2013-03-05 2019-02-06 Huawei Technologies Co., Ltd. Key exchange method and apparatus
CN104756440A (zh) * 2013-08-28 2015-07-01 华为技术有限公司 分发密钥的方法、m2m平台及m2m终端
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004107115A2 (en) * 2003-05-28 2004-12-09 Sony Electronics, Inc. Distributing and controlling rights of digital content
US20050008153A1 (en) * 1999-06-25 2005-01-13 Barton Colleen A. Method and logic for capturing and analyzing conduit data

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU6758898A (en) * 1997-03-12 1998-09-29 Visa International Secure electronic commerce employing integrated circuit cards
US6681017B1 (en) * 1997-09-03 2004-01-20 Lucent Technologies Inc. Simplified secure shared key establishment and data delivery protocols for electronic commerce
US6775253B1 (en) * 1999-02-25 2004-08-10 Telcordia Technologies, Inc. Adaptive signaling for wireless packet telephony
US6996716B1 (en) * 1999-04-15 2006-02-07 Avaya Technology Corp. Dual-tier security architecture for inter-domain environments
US6775255B1 (en) * 1999-09-16 2004-08-10 At&T Corp. H.323 mobility architecture for terminal, user and service mobility
CN1180573C (zh) * 2001-08-29 2004-12-15 华为技术有限公司 Ip网络***中的节点跨区域呼叫方法
JP3746713B2 (ja) * 2001-12-28 2006-02-15 株式会社日立製作所 インターネット電話システムおよび情報処理装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050008153A1 (en) * 1999-06-25 2005-01-13 Barton Colleen A. Method and logic for capturing and analyzing conduit data
WO2004107115A2 (en) * 2003-05-28 2004-12-09 Sony Electronics, Inc. Distributing and controlling rights of digital content

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1808978A4 *

Also Published As

Publication number Publication date
ES2402862T5 (es) 2018-03-08
US20070168527A1 (en) 2007-07-19
US7983280B2 (en) 2011-07-19
EP1808978B1 (en) 2013-03-13
EP1808978A4 (en) 2008-02-20
EP1808978A1 (en) 2007-07-18
CN100382484C (zh) 2008-04-16
EP1808978B2 (en) 2017-11-15
CN1815950A (zh) 2006-08-09
ES2402862T3 (es) 2013-05-09

Similar Documents

Publication Publication Date Title
US9537837B2 (en) Method for ensuring media stream security in IP multimedia sub-system
US7813509B2 (en) Key distribution method
US7334125B1 (en) Facilitating secure communications among multicast nodes in a telecommunications network
JP5106682B2 (ja) マシン・ツー・マシン通信のための方法及び装置
WO2005096644A1 (fr) Procede d'etablissement d'une association de securite entre l'abonne itinerant et le serveur du reseau visite
WO2010083695A1 (zh) 安全协商会话密钥的方法及装置
WO2011041962A1 (zh) 一种支持合法监听的端到端会话密钥协商方法和***
WO2007073659A1 (fr) Methode d'acces des terminaux a base de protocole h.323 applique a un reseau de paquets
US20060005010A1 (en) Identification and authentication system and method for a secure data exchange
WO2008040213A1 (fr) Procédé, système et dispositif de chiffrement et de signature de messages dans un système de communication
US20070074022A1 (en) Method for providing message transmission in H.323 communication system
WO2005104423A1 (fr) Procede de communication secrete entre deux points limites
WO2006081765A1 (fr) Procede de distribution de la cle de session dans la gamme de gestion du portier transversal selon le mode du trajet le plus direct
CN109995723B (zh) 一种域名解析***dns信息交互的方法、装置及***
WO2007093079A1 (fr) Procédé de mise en oeuvre d'une politique de sécurité en matière de négociation-clé dans un réseau interdomaine de commutation de paquets à plusieurs garde-portes
WO2008074226A1 (fr) Procédé pour négocier la clé secrète de session entre les points d'extrémité à travers des zones à multiples contrôleurs d'accès
WO2006081764A1 (fr) Procede pour attribuer la cle de session a travers le domaine de gestion du portier, en vertu du mode du trajet le plus direct
WO2009094813A1 (fr) Procédé et appareil de négociation de paramètres de sécurité pour sécuriser le flux multimédia
JP2000261428A (ja) 分散処理システムにおける認証装置
CN101174944A (zh) 一种直接路由模式下跨关守管理范围的会话密钥分配方法
KR100738353B1 (ko) 홈 네트워크 보안성 최적화 장치 및 그 방법
Harney et al. RFC 4535: GSAKMP: Group Secure Association Key Management Protocol
CA2471171A1 (en) Identification and authentication system and method for a secure data exchange
WO2006081712A1 (fr) Méthode de commutation de niveau de texte normal et de texte chiffré pendant une conversation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11648924

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2006705589

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2006705589

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11648924

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE