JP6414630B2 - Method and apparatus for provisioning traversal (TURN) credential information and servers using relays for network address translation - Google Patents

Description

This application is a U.S. non-provisional application filed 14/15/2014 entitled `` Method and Apparatus for Provisioning Traversal using Relays Around Network Address Translation (TURN) Credential and Servers ''. The priority and benefit of 461,162 is claimed and this non-provisional application is incorporated herein by reference.

  The present disclosure relates generally to provisioning TURN credentials.

  Network address translation (NAT) devices modify Internet Protocol (IP) headers as packets pass through the NAT device. NAT devices are widely deployed in home / enterprise networks and the Internet. However, NAT devices hang up Voice over Internet Protocol (VoIP) calls.

  Some firewalls typically block User Datagram Protocol (UDP) for security reasons and allow Hypertext Transfer Protocol (HTTP) (TCP 80) or HTTP Secure (HTTPS) (TCP 443) to pass. Configured to allow only. Since voice packets are sent over UDP, firewalls that block UDP also block voice traffic. In summary, both NAT and firewalls that block UDP block VoIP media communication, which can result in one-way audio or no audio at all.

  It is therefore desirable to provide improved NAT / firewall traversal.

  According to one embodiment, a method for provisioning TURN credentials and servers in a communication system including a signaling gateway, a traversal (TURN) server using network address translation relay, and an electronic device is provided. The method includes the signaling message from the first electronic device at the signaling gateway when the first electronic device (ED) registers with the signaling gateway or sends other signaling messages to request TURN credential information. Receiving. The signaling message includes one or more signaling message parameters. The signaling message further includes a request for the signaling gateway to generate TURN credential information for the first ED. The TURN credentials are associated with one or more authentication message parameters. The method includes transmitting TURN credential information from the signaling gateway to the first ED.

  In another embodiment, an electronic device is provided for TURN credential information and server provisioning in a communication system including a traversal (TURN) server using a signaling gateway and network address translation relay. The electronic device includes a processor and a memory coupled to the processor. The electronic device is configured to send a signaling message to the signaling gateway. The signaling message includes one or more signaling message parameters. The signaling message further includes a request for the signaling gateway to generate TURN credential information for the first ED. The TURN credential information is associated with one or more signaling message parameters. The electronic device is configured to receive TURN credential information from the signaling gateway.

  In another embodiment, a signaling gateway is provided. The signaling gateway includes a processor and a memory coupled to the processor. The signaling gateway is configured to receive a signaling message from the first electronic device (ED). The signaling message includes one or more signaling message parameters. The signaling message further includes a request for the signaling gateway to generate TURN credential information for the first ED. The TURN credentials are associated with one or more authentication message parameters. The signaling gateway is configured to send TURN credential information to the first ED.

  For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description, considered in conjunction with the accompanying drawings, in which like numerals indicate like elements.

It is a figure which shows the NAT device which converts the transmission origin IP / port of a packet into a new value. It is a figure which shows the solution of ICE / STUN / TURN NAT / firewall traversal for P2P communication. It is a figure which shows the solution of ICE / STUN / TURN NAT / firewall traversal for P2P communication. It is a figure which shows the solution of ICE / STUN / TURN NAT / firewall traversal for P2P communication. FIG. 4 is an exemplary VoIP call flow diagram using ICE / STUN / TURN. FIG. 2 is a call flow diagram of a system for provisioning TURN credentials and servers for NAT / FW traversal over a VoIP / WebRTC signaling channel according to one embodiment. FIG. 2 is a call flow diagram of a system for dynamic TURN server provisioning or dynamic TURN credential provisioning according to one embodiment. 2 is a block diagram of a signaling gateway according to one embodiment. FIG. 1 is a block diagram of an electronic device (ED) according to one embodiment. 2 is a flow diagram illustrating a method of NAT traversal according to one embodiment.

  An exemplary NAT device 102 is shown in FIG. 1, in which the NAT device 102 converts the packet's source IP / port 104 to a new value 106 as the packet passes through the NAT device 102 ( For example, 10.0.1.1:6554-> 1.2.3.4:8877). NAT devices can solve the problem of lack of Internet Protocol version 4 (IPv4) addresses by reusing private IP addresses. The NAT device also hides the internal network topology from the outside for security protection. However, NAT devices hang up Voice over Internet Protocol (VoIP) calls. NAT disconnects a VoIP call when the call is set up because the originating UE sends its private address (not NATed) as a media address in a signaling message. Since the private address is not routable in the public network, the media packet sent to the private address is discarded by the router or switch on the route and does not reach the peer UE.

  One solution to solve the above NAT / firewall problem is by using ICE / STUN / TURN. 2A-2C show simplified steps of ICE / STUN / TURN. As shown in FIG. 2A, during the first step, the first UE 202 sends its request to the STUN or TURN server (shown as TURN server 210 in FIG. 2A) by sending its request to the first UE. Collect 202 public and relay addresses. As shown in FIG. 2B, during the second step, the first UE 202 transmits the collected media candidates to the peer or the second UE 204. The peer or second UE 204 collects the public and relay addresses of that peer or second UE 204 by sending a request to the TURN server 210 and sends the collected media candidates to the first UE 202 To do. As shown in FIG. 2C, during the third step, the first and second UEs 202, 204 examine the media path 208 by sending connectivity check messages for each possible path. Select a functioning route.

  FIG. 3 shows an exemplary VoIP call flow diagram 300 using ICE / STUN / TURN. In the example shown, two UEs 302, 304 collect candidate addresses (public and relay addresses), exchange media candidates through signaling messages (steps 306, 308), and perform connectivity checks (steps). 310, 312), media are exchanged via the selected media path (step 314). Since the UEs 302, 304 are behind the symmetric NAT 303, their UE 302, 304 connectivity check for public addresses fails (step 310). The UEs 302 and 304 switch to use the TURN relay server 316 for media communication (step 312). The UE registration process is not shown in FIG. 3 for simplicity.

  ICE / STUN / TURN is among the most common NAT / firewall traversal solutions for P2P communication, and is an essential NAT traversal mechanism for Web Real-Time Communication (WebRTC) worldwide. Recently adopted by the Web Consortium (W3C) and the IETF. WebRTC allows a user to make an audio or video call using a web browser. Because browsers are readily available on most types of electronic devices (desktops, smartphones, tablets / pads, etc.), WebRTC has its potential for large numbers of users and its ability to incorporate audio / video into web applications. Thanks to that, it is considered a disruptive technology. Therefore, a scalable, safe and efficient ICE / TURN / STUN solution is desirable.

  The existing ICE / STUN / TURN solution has several drawbacks. One drawback is provisioning of TURN credentials. For example, the TURN standard defines a mechanism for user authentication using TURN long-term credential. When the UE sends a request to the TURN server, the TURN server challenges the UE with a random value, and the UE must send an authentication code calculated using the shared credentials to authenticate the UE. I must. This is very important for security. Otherwise, hackers can send huge requests to run out of resources on the TURN server, such as relay addresses or table entries.

However, the current standard does not prescribe how long-term credentials should be provisioned to the UE. Common practices include the following:
a. Manual configuration: This approach is not scalable for a large number of users, for example in the case of WebRTC where credentials need to be configured for millions of users.
b. Use device management channel: This approach works only for devices that support device management functions, such as smartphones. This technique does not work for WebRTC because the browser does not use device management functions.
c. Shared username / password: This approach works only when the number of users is small, and is not secure for users who are large or who frequently join / leave the group, so Unacceptable to service providers.
d. Reuse of other service credentials similar to WebRTC username / password: This approach has several drawbacks:
i. If the TURN server may not know the service credential information (for example, the TURN server belongs to a third party) and therefore the TURN server and the service credential information belong to different parties or organizations Difficult to use.
ii. Using service credential information increases the risk of username leakage and offline password cracking attacks, as TURN usernames and authentication codes may be sent in clear text.

Several approaches have recently been proposed to other standards bodies related to the management of IETF and TURN credentials.
RFC 7065 “Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers” by M. Petit-Huguenin et al. This RFC defines a format for encoding messages, eg, TURN server addresses and protocols in HTTP responses. However, this RFC does not define a mechanism for provisioning TURN credentials.
b. Retrieve TURN credentials by REST API call to web server. In this approach, the UE sends an HTTP request to a URL (API) on the web server to retrieve the TURN parameters including username and password (credential information). However, this mechanism does not specify how the UE can be authenticated by the web server. For example, if the TURN server belongs to a third party, or the web server does not have a user authentication function (for example, the user uses the IMS identity to access the WebRTC service, not the web identity) If. Therefore, this approach only moves the authentication problem from the TURN server to the web server. Since there is no guarantee that the web server always authenticates the user, the applicability of the approach is limited and depends on the functionality of the web server.
c. OAuth token method: In this method, the TURN server redirects the user to the WebRTC server first. The WebRTC server then returns an OAuth token, which is used by the UE to authenticate to the TURN server. Some of the disadvantages of this approach are:
I. The TURN protocol needs to be changed to send / process OAuth tokens.
II. OAuth token may not be available in existing service architecture. For example, for a WebRTC service, when a user uses an IMS ID to authenticate, there is no OAuth token used according to the 3GPP proposed service architecture. Therefore, existing architecture needs to be changed.
III. Token leakage. Since TURN messages are usually sent unencrypted, if a UE sends a token with a TURN message, an attacker can intercept or hack the TURN message and capture an OAuth token. This is a serious security issue that can be used by an attacker to steal user identity or hijack a session.
d. Provisioning TURN credentials using VoIP signaling channel. In this approach, the user first authenticates to the VoIP / WebRTC server, and then the server returns a username and password to the user. This approach has the advantage of being secure since the user is authenticated by the WebRTC or VoIP server during registration. Also, this approach is simple and scalable because it uses the scalability of the signaling channel. One drawback is that this approach does not explain how the generated credentials should be sent (from a WebRTC or VoIP server) to the TURN server, for example for anonymous calls discussed below. Does not support dynamic modification of user credentials.

  Since TURN messages are often sent in clear text, it is possible for an attacker or a third party to find the user's call information by tracking the username in the TURN message. This may reveal the user's call time, call destination (IP), call duration, etc. When an attacker uses active attack technology, for example, when the attacker first calls the user and analyzes the TURN message from the user to find the user's TURN username, the user call ID May be revealed. Therefore, it may be desirable to change the TURN username periodically. For example, it is desirable to change the TURN username to a different username for anonymous calls. Current approaches do not allow users to pick up new TURN usernames for anonymous calls or to change usernames periodically to avoid privacy issues.

  In accordance with the present disclosure, a method for provisioning TURN credentials (eg, username / password) using a VoIP / WebRTC signaling channel is provided. The method provides a mechanism for managing credential information between a signaling gateway (eg, VoIP / WebRTC signaling gateway) and a TURN server. The method provides a mechanism for handling users with respect to different realms. The method provides a mechanism for controlling credential expiration time and credential revocation. The method provides a mechanism for refreshing credentials at any time by the ED, for example, before an anonymous call, to protect user privacy. The method provides a mechanism for dynamically retrieving a TURN server based on, for example, network conditions or security issues.

  An embodiment of a system 400 for provisioning TURN credentials and servers for NAT / FW traversal over a VoIP / WebRTC signaling channel according to this disclosure will be described with reference to the call flow diagram of FIG. The system 400 includes a first electronic device (ED) 402, a first NAT / firewall 404, a signaling gateway 406 such as a VoIP / WebRTC signaling gateway, a second NAT / firewall 409, a TURN server 408, and a second ED. Includes 412. The signaling gateway 406 may integrate signaling, media, and TURN functions. The first and second EDs 402, 412 are configured to operate and / or communicate within the system 400. For example, the EDs 402, 412 are configured to transmit and / or receive wireless or wired signals. Each ED 402, 412 represents any suitable end user device, user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, pager, cellular phone, mobile It may include (or may be referred to as) a device such as an information terminal (PDA), smart phone, laptop, computer, touchpad, wireless sensor, or consumer electronic device. An exemplary signaling protocol used in the system is Session Initiation Protocol over WebSocket (SIP over WS).

  The signaling gateway 406 may include an operating system that provides executable program instructions for the overall management and operation of the gateway, and when executed by the signaling gateway 406 processor, the signaling gateway 406 typically It includes a computer readable medium that stores instructions that allow the intended function of signaling gateway 406 to be performed. Suitable implementations of the signaling gateway operating system and general functionality are known or commercially available and are easily implemented by those skilled in the art.

When the first ED 402 registers with a signaling gateway 406 such as a VoIP signaling server (eg Proxy Call Session Control Function (P-CSCF)) or WebRTC signaling server (eg eP-CSCF) Includes one or more parameters such as a TURN credential provision request and a “tun-cred” parameter to request the signaling gateway 406 to provide the TURN credential information to the first ED 402 REGISTER (eg, SIP SIP over WS REGISTER) or other registration or authentication message is sent (step 405). The format of the “tun-cred” parameter is
"Tun-cred: [realm = value;] [exp = value;] [revoke;]", where
(a) The “realm” parameter is optional and, if present, requests credentials for a specific realm; (b) the “exp” parameter is optional, and if present, the specified Request credential information for revocation time, and (c) the “revoke” parameter is optional, and if present, requests the signaling gateway 406 to revoke previously generated credential information.

When the signaling gateway 406 receives a registration message having a “tun-cred” parameter, it validates the “tun-cred” parameter and selects a realm and a TURN server for the realm. For example, the signaling gateway 406 may determine that the realm format is recognized, the realm is recognized, and the expiration time value is not negative or infinite. A realm can be a string that is used to describe a server or a context within the server, and tells the client device what username and password combination to use to authenticate the request. There is a possibility to inform. Then, the signaling gateway 406 generates a user part (TURN-USR) of the TURN credential information (step 410). The user part of the TURN credential information (TURN-USR) may be in the following format:
"Turn-USR = user-name [@ realm-value;] [exp = value;] [revoke;]"
here,
(a) “user-name” is the user name portion of the TURN credential information.
(b) “realm-value” is optional and specifies the user's realm.
(c) The “exp” value is optional and specifies the expiration time of the credential information.
(d) The “revoke” keyword is optional and instructs the TURN server to revoke all TURN credential information generated prior to this credential information.

The signaling gateway 406 identifies the pre-shared key (k _m ) for the selected TURN server and uses the pre-shared key to hash the user part of the credential information by hashing the TURN credential information password. A part (TURN-PWD) is generated (step 410). The password part of the TURN credential information (TURN-PWD) may be in the following format:
"TURN-PWD = hmac (TURN-USR, pre-shared-key)"

  The signaling gateway 406 sends the generated TURN credentials (TURN-USR and TURN-PWD) to the first ED 402 in a response to the registration message (e.g., SIP `` 200 OK '') (step 415) . The result may be encoded as “tur-cred = usr-name @ realm; exp = val; revoke; tur-pwd = turn-password”. One skilled in the art will recognize that other formats can also be used.

  The first ED 402 receives a response regarding registration with TURN credential information from the signaling gateway 406 and requests a TURN relay address using the TURN credential information. The first ED 402 uses the entire TURN-USR string as the TURN username in its first ED 402 Alloc request (i.e., the TURN username is user-name @ realm; exp -value; including revoke), a message authentication code (MAC) for the Alloc request is generated using TURN-PWD (step 420).

  The TURN server 408 receives the Alloc request from the first ED 402, parses the user string (for example, user-name @ realm; exp-value; revoke), TURN username, realm, expiration time, and revocation Keywords are extracted (step 425). The TURN server 408 verifies the validity of the extracted value and the parameters are invalid (e.g., unknown or unrecognized format of the realm, unknown or unrecognized realm, negative expiration time The request is discarded. The TURN server 408 identifies a pre-shared key from the realm and calculates the TURN-PWD by hashing the received TURN user string in the Alloc request with the pre-shared key (step 425). The TURN server 408 verifies the validity of the received message using the TURN-PWD generated by hashing the received TURN user string in the Alloc request with a pre-shared key. If the user string in the Alloc request contains a revocation keyword, the TURN server 408 revokes previously received non-revoked credentials (eg, has not revoked for the user using the local cache) Record credentials and status of credentials). If the credential information is revoked, the credential information is rejected by the TURN server 408. After verifying the validity of the received message, the TURN server 408 sends an Alloc response including the relay address to the first ED 402 (step 430).

  If the first ED receives the relay address from the TURN server, the first ED proceeds to place the call using the existing protocol or procedure, for example, the first ED 402 sends an INVITE request to the signaling gateway 406. Send (step 435) and start the call. The signaling gateway 406 receives the INVITE request from the first ED 402 and checks whether the call can proceed. If the call cannot proceed, for example, if the called party (e.g., the second ED 412) is not registered or not online, the signaling gateway 406 returns an error code to the first ED 402 ( The call is terminated.

  If the call can proceed, the signaling gateway 406 forwards the INVITE message to the called party (eg, the second ED 412) (step 435). The called party (eg, the second ED 412) receives the INVITE message, processes the INVITE message, and sends a response message (eg, “200 OK” message) to the signaling gateway 406. The signaling gateway 406 forwards the response message to the first ED 402 (step 440). Each of the EDs 402, 412 is behind a respective symmetric NAT / firewall 404, 409.

  The first ED 402 receives the response message and sends a ChannelBind request to the TURN server 408 to reserve the channel (step 445). The TURN server 408 receives the ChannelBind request and transmits a ChannelBind response to the first ED 402 (step 450). After the channel is set up, the first and second EDs 402, 412 may exchange messages for connectivity check (eg, using a STUN binding request). For example, the TURN server 408 receives data from the first ED 402 via the connectivity check request message and relays the data to the second ED 412 (step 455). The second ED 412 receives the data and responds with a connectivity check response message. The TURN server 408 receives the connectivity check response message and relays the data in the connectivity check response message to the first ED 402 (step 460). The first and second EDs 402, 412 then find the media path and begin sending media packets to each other, such as via real-time transport protocol (RTP) (step 465).

  FIG. 5 is a call flow diagram illustrating a system 500 for dynamic TURN server provisioning or dynamic TURN credential provisioning. As shown in the call flow diagram of FIG. 5, the first ED 402 requests TURN credential information in its initial registration message (eg, REGISTER). The registration message may include the “tun-cred” parameter described above in connection with FIG. The signaling gateway 406 identifies the user's realm, selects one TURN server or list of TURN servers, and the TURN credentials selected in the response of that signaling gateway 406 (eg SIP “200 OK”) To the first ED 402. As described above in connection with FIG. 4, when the first ED receives a relay address from the TURN server 408, it proceeds to make a call using an existing protocol or procedure, eg, the first ED The ED 402 sends an INVITE request to the signaling gateway 406 to initiate the call.

  The signaling gateway 406 is configured to protect the user's privacy, for example, dynamically refreshing credential information before an anonymous call, or avoid using one credential information too long Can be done. In order to receive a new TURN username and password before the next registration cycle (eg, before placing an anonymous call), the first ED 402 is as described above in connection with FIG. , An update request such as an OPTION or INFORM request including parameters such as the “tur-cred” parameter is transmitted to the signaling gateway 406 (step 505). The format of the “tur-cred” parameter is the same as described above in connection with FIG. As described above in connection with FIG. 4, signaling gateway 406 verifies the validity of the user request and generates new TURN credential information (eg, TURN-USR and TURN-PWD). The signaling server 406 sends the new credential information back to the first ED 402 in a response to the OPTION or INFORM request (eg, “200 OK” in SIP) (step 510). The first ED 402 receives the new TURN credential information from the signaling gateway 406 and places an anonymous call using the new TURN credential information.

  Alternatively or additionally, signaling gateway 406 may be configured to support TURN server reselection based on network conditions (eg, quality of service (QoS)) or security conditions. For example, if the first ED 402 detects a problem with a TURN server, such as a TURN server received before not responding to the request for that first ED 402 (e.g., QoS or security), at step 505 `` An update request such as an OPTION or INFORM request including parameters such as a “tur-serv” parameter may be sent to the signaling gateway 406. The update request may include a reason code indicating why the first ED needs a new TURN server. The signaling gateway 406 verifies the validity of the user request and based on the knowledge of the signaling gateway 406 and the feedback from the first ED 402 on the operational status of other TURN servers in the communication system, Multiple TURN servers are selected and a list of new TURN servers is sent back to the first ED 402 in response to an OPTION or INFORM request (eg, “200 OK” in SIP) (step 510). The first ED 402 receives a list of new TURN servers from the signaling gateway 406 and selects a new TURN server.

  FIG. 6 shows a block diagram of signaling gateway 406. In a specific embodiment, the signaling gateway 406 is configured by a server computer such as a SIP server or an H.323 server. As shown in FIG. 6, the signaling gateway 406 serves as a server such as a communication interface 602 coupled to the IP network 604, an operating system (not shown), and a VoIP server in its hardware configuration. A storage device 608 for storing the program and a control device 610 (eg, processor or CPU) that executes the program in the storage device 608 to control the overall operation.

  The storage device 608 defines, for example, an OS, a communication protocol stack for controlling data communication based on IP packets, a database, and a control program, for example, a voice communication procedure (for example, calling and receiving calls). A call control protocol such as .323, SIP, and a server program that defines processing procedures for NAT and firewall traversal methods.

  The control device 610 can be a general purpose, dedicated, or digital signal processor, and can be a plurality of processors, or a combination of such processors. The control device 610 can perform signal encoding, data processing, input / output processing, and / or any other function that allows the signaling gateway 406 to operate within the system 400 or system 500. including. In addition, the control device 610 is coupled to a storage device 608 that is operable to store and retrieve data. Can include any suitable type of memory storage device such as random access memory (RAM), read only memory (ROM), hard disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card There is sex.

  FIG. 7 shows a block diagram of an example electronic device (ED) or user equipment (UE). The electronic device 710 can be, for example, a portable wireless electronic device. For example, the electronic device 710 is a cellular phone, a media player with wireless communication capability, a handheld computer (sometimes called a personal digital assistant), a remote controller, a global positioning system (GPS) device, a tablet computer, a handheld game console. There is a possibility. The electronic device 710 includes a processor 700, a transceiver 702, an antenna element 704, one or more input / output devices 706 (eg, speaker / microphone, keypad, display / touchpad), and memory 708. Electronic device 710 may be wirelessly coupled to a base station (not shown) via wireless link 790.

  Electronic device 710 may include one or more other components, devices, or functions (not shown). The electronic device 710 may include relatively few or relatively many of the elements described above.

  The processor 700 may be a general purpose, dedicated, or digital signal processor, and may be a plurality of processors, or a combination of such processors. The processor 700 is capable of performing signal encoding, data processing, power control, input / output processing, and / or any other that allows the electronic device 710 to operate within the system 400 or system 500. Includes features. The processor 700 is coupled to a transceiver 702 that is coupled to an antenna element 704. It will be appreciated that the processor 700 and the transceiver 702 may be separate components or may be integrated. Similarly, the antenna element 704 can be a single element or several elements (multiple antennas or elements).

  Transceiver 702 is configured to modulate data or signals for transmission by antenna 704 and to demodulate data or signals received by antenna 704.

  The processor 700 is coupled to one or more input / output devices 706 (including ports or buses) that are operable to input / output user data. In addition, processor 700 is coupled to a memory 708 that is operable to store and retrieve data. Can include any suitable type of memory storage device such as random access memory (RAM), read only memory (ROM), hard disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card There is sex.

  Other elements or devices that may be included within electronic device 710 are not described herein unless necessary or relevant to an understanding of this disclosure.

  FIG. 8 shows a flow diagram illustrating a method 800 for provisioning traversal (TURN) credentials and servers using network address translation relays in a communication system according to one embodiment. The method includes, at step 802, receiving a signaling message from the first electronic device at the signaling gateway when the first electronic device registers or authenticates with the signaling gateway. The signaling message includes one or more signaling message parameters. The signaling message further includes a request for the signaling gateway to generate TURN credential information for the first electronic device. The TURN credential information is associated with one or more signaling message parameters. For example, a registration message from the first electronic device 402 is received at the signaling gateway 406 (step 405). The registration message includes TURN credential provision request parameters and may include parameters such as realm parameters, revocation parameters, and revocation parameters.

  In step 804, the validity of the signaling message parameters is verified at the signaling gateway. For example, the validity of the registration message is verified by the signaling gateway 406 (step 410). Illustratively, the signaling gateway 406 validates the realm parameter “realm” (if any) against the signaling gateway 406's security policy and discards the request with an invalid realm value. If there is no realm parameter, the signaling gateway selects a default realm. The signaling gateway 406 verifies the validity of the revocation parameter “exp” (if any) and discards the request having an invalid value. If there is no revocation parameter, the signaling gateway selects a revocation value such as a revocation value of an authentication message (eg, a REGISTER message).

  In step 806, TURN credential information is transmitted by the signaling gateway to the first electronic device. For example, the signaling gateway 406 transmits the TURN credential information to the first electronic device 402 in the response message “200 OK” of the signaling gateway 406 (step 415).

  One of the advantages of the present disclosure is that the signaling gateway authenticates the user during the registration process and ensures that only authenticated users can receive TURN credential information. Other techniques such as OAuth Token or REST API use a web server to deliver TURN credentials. The web server may authenticate the user or may not authenticate the user. For example, in the WebRTC architecture defined by 3GPP, the web server only hosts the WebRTC JS code and does not authenticate the user when the IMS identity is used to access the WebRTC service. In such a case, the signaling gateway based approach is more secure than the web server based approach.

  Another advantage of the present disclosure is that the signaling gateway based approach reuses the existing ICE / TURN protocol with little or no change or addition of new interfaces. This approach does not require an extra step to verify TURN credentials (for example, a step to verify a token in an OAuth solution), thereby requiring overhead to implement and operate The nature becomes less.

  Another advantage of the present disclosure is that a signaling gateway based approach allows the ED to retrieve new credential information for anonymous calls to prevent call information leakage due to TURN username analysis. By providing user-friendly privacy protection than other approaches.

  In some embodiments, some or all of the functions or processes of one or more devices are implemented or supported by a computer program formed from computer-readable program code and embodied in a computer-readable medium. The The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer-readable medium” refers to a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, compact disk (CD), digital video disk (DVD), or any other type of memory. Including any kind of media that can be accessed by.

  In an exemplary embodiment, an electronic device is used for provisioning traversal (TURN) credentials and servers using network address translation relays in a communication system. The electronic device is a transmitting element that sends a signaling message to the signaling gateway, the signaling message including one or more signaling message parameters, wherein the signaling message is a TURN credential for the first ED. Further comprising a request to generate information, wherein the TURN credential information includes a sending element associated with the one or more signaling message parameters and a receiving element for receiving the TURN credential information from the signaling gateway. In some embodiments, the electronic device may include other or additional elements for performing any one or combination of the steps described in the embodiments.

  In an exemplary embodiment, a signaling gateway is used for provisioning traversal (TURN) credentials and servers using network address translation relays in a communication system. A signaling gateway is a receiving element that receives a signaling message from a first electronic device (ED), wherein the signaling message includes one or more signaling message parameters, and the signaling message is the signaling gateway of the first ED. Further comprising a request to generate TURN credential information for transmitting the TURN credential information to the receiving element and the first electronic device, wherein the TURN credential information is associated with one or more signaling message parameters Including a sending element. In some embodiments, the signaling gateway may include other or additional elements for performing any one or combination of the steps described in the embodiments.

  It may be convenient to describe the definitions of specific words and phrases used throughout this patent specification. The terms “include” and “comprise” and their derivatives mean inclusion without limitation. The term “or” is inclusive and / or means and / or. The phrases `` associated with '' and `` associated therewith '' and their derivatives are included, included within, and interconnected ( interconnect with, to contain, to be contained within, to or connect to, to or to, to communicate with, to cooperate with Means that interleave ~, juxtapose ~, close to ~, or be associated with ~, or have the characteristics of ~.

  While this disclosure has described particular embodiments and broadly related methods, alternatives and modifications to these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or limit the present disclosure. In addition, other changes, substitutions, and alternatives are possible without departing from the spirit and scope of the present disclosure as defined by the following claims.

102 NAT device
104 packet source IP / port
106 New value
202 1st UE
204 2nd UE
208 Media Path
210 TURN server
302 UE
303 Symmetric NAT
304 UE
316 TURN relay server
400 system
402 1st ED
404 First NAT / Firewall
406 Signaling gateway
408 TURN server
409 Second NAT / Firewall
412 2nd ED
500 system
602 communication interface
604 IP network
608 storage devices
610 Control device
700 processor
702 transceiver
704 Antenna element
706 input / output devices
708 memory
710 electronic devices
790 wireless link

Claims (23)

A method for provisioning TURN credentials and servers in a communication system including a signaling gateway, a traversal (TURN) server using relay of network address translation, and an electronic device, comprising:
When the first electronic device (ED) registers with the signaling gateway or sends other signaling messages for requesting TURN credential information, the signaling message from the first electronic device at the signaling gateway Wherein the signaling message includes one or more signaling message parameters, the signaling message comprising:
Generated by the signaling gateway further comprising a request for the signaling gateway to generate TURN credential information for the first ED, wherein the TURN credential information is associated with the one or more signaling message parameters Hashed the user part of the TURN credential information using a pre-shared key, wherein the TURN credential information identified includes a hashed user part having a username and identifying the TURN server The signaling gateway uses the key previously shared with the TURN server to hash the user part to generate a password part of the TURN credential information by:
TURN credential information from the signaling gateway to the first ED, such that the TURN credential information is used by the first ED to obtain a relay address from the TURN server. Sending as part of the request;
Verifying the validity of the one or more signaling message parameters;
Selecting a realm and a TURN server for the realm based on the signaling message. In response to the signaling message including a revocation parameter, requesting credential information for a revocation time defined by the revocation parameter;
2. The method of claim 1, further comprising: requesting the signaling gateway to revoke previously generated credential information in response to the signaling message including a revocation parameter. In response to the user part including a user part realm parameter, generating a user realm defined by the user part realm parameter;
Responsive to the user part including an expiration parameter of the user part, generating an expiration time of the user part defined by the expiration parameter of the user part;
The method of claim 1, further comprising: sending an indication to the TURN server to revoke previously generated TURN credential information in response to the user part including a user part revocation parameter. .   In response to determining that the signaling gateway and the TURN server have a shared key, the password of the TURN credential information by hashing the user part of the TURN credential information with the shared key 4. The method of claim 3, further comprising generating a portion. Receiving the allocation request from the first ED by the TURN server after the TURN credential information is received by the first ED, wherein the allocation request includes a TURN relay address and one or Further comprising requesting a plurality of assignment request parameter values, wherein the one or more assignment request parameter values are based on the user portion of the TURN credential information and the password portion of the TURN credential information;
In the TURN server,
Receiving the assignment request from the first ED, wherein the assignment request includes a message authentication code based on the password portion of the TURN credential information;
Extracting the one or more assignment request parameter values from the assignment request;
Verifying the validity of one or more extracted assignment request parameter values;
5. The method of claim 4, further comprising discarding the assignment request if one or more of the one or more assignment request parameter values are invalid. Identifying the shared key;
Generating a TURN server password by hashing the one or more assignment request parameter values based on the user portion of the TURN credential information with the shared key;
6. The method of claim 5, further comprising verifying validity of the received assignment request using the TURN server password. In response to the assignment request including a cancellation parameter,
Revoking previously received TURN credentials; and
6. The method of claim 5, further comprising rejecting the revoked credential information. Receiving a second TURN credential information update request for the first ED different from the TURN credential information in the signaling gateway, wherein the update request is an expiration of a registration cycle time of the signaling message; Received before the step, and
Verifying the validity of the update request at the signaling gateway;
8. The method of claim 7, further comprising: transmitting the second TURN credential information to the first ED. Receiving the second TURN credentials in the first ED; and
9. The method of claim 8, further comprising: placing an anonymous call using the second TURN credential information. Receiving an update request to provision a second TURN server for the first ED at the signaling gateway, the update request being received before expiration of a registration cycle time of the signaling message; The update request is based on network conditions or security conditions; and
Verifying the validity of the update request at the signaling gateway;
10. The method of claim 9, further comprising: generating second TURN credential information for the first ED; and transmitting the second TURN credential information to the first ED. Receiving the second TURN credentials in the first ED; and
11. The method of claim 10, further comprising calling using the second TURN server. An electronic device for provisioning TURN credentials and servers in a communication system including an electronic device (ED), a signaling gateway, and a traversal (TURN) server using network address translation relay,
A processor;
And a memory coupled to the processor,
Sending a signaling message to the signaling gateway, the signaling message comprising:
Including one or more signaling message parameters, the signaling message further including a request for the signaling gateway to generate TURN credential information for a first ED, wherein the TURN credential information is the one or more The TURN credential information generated by the signaling gateway, associated with a plurality of signaling message parameters, identifies the TURN server and includes a hashed user part with a username and uses a pre-shared key In order to generate a password part of the TURN credential information by hashing the user part of the TURN credential information, the signaling gateway is pre-shared with the TURN server to hash the user part. Send using the key Doo Doo,
Receiving the TURN credential information from the signaling gateway as part of a request for a TURN relay address such that the TURN credential information is used by the first ED to obtain a relay address from the TURN server and that,
After receiving the TURN credential information , configured to send an allocation request to a first TURN server selected based on the signaling message , wherein the first TURN server An electronic device coupled to the signaling gateway, wherein the allocation request includes a request for a TURN relay address . In response to the signaling message including a revocation parameter, requesting credential information for a revocation time defined by the revocation parameter;
13. The electronic device of claim 12, further configured to request the signaling gateway to revoke previously generated credential information in response to the signaling message including a revocation parameter. Sending a second TURN credential information update request for the first ED that is different from the TURN credential information, wherein the update request is sent before expiration of a registration cycle time of the signaling message. Sending,
Receiving the second TURN credential information;
13. The electronic device of claim 12 , further configured to place an anonymous call using the second TURN credential information. Transmitting an update request of a second TURN server for the first ED different from the first TURN server, wherein the update request is based on network conditions or security conditions, Sending before the expiration of the registration cycle time of the signaling message;
Receiving a second TURN credential, and
13. The electronic device of claim 12 , further configured to make a call using the second TURN server. A signaling gateway for provisioning of TURN credentials and servers in a communication gateway, including a signaling gateway, a traversal (TURN) server using network address translation relay, and an electronic device,
A processor;
And a memory coupled to the processor,
Receiving a signaling message from a first electronic device (ED), the signaling message comprising:
Including one or more signaling message parameters, the signaling message further including a request for the signaling gateway to generate TURN credential information for the first ED, wherein the TURN credential information is the one Or the TURN credential information generated by the signaling gateway, associated with a plurality of signaling message parameters, identifies the TURN server and includes a hashed user part with a username, and a pre-shared key The signaling gateway is pre-shared with the TURN server to hash the user part to use to hash the user part of the TURN credential information to generate a password part of the TURN credential information. Receive using the key And Rukoto,
A request for the TURN relay address for the first electronic device, and for the TURN credential information to be used by the first ED to obtain a relay address from the TURN server. Sending as a part,
Verifying the validity of the one or more signaling message parameters;
A signaling gateway configured to select a realm and a TURN server for the realm based on the signaling message. In response to the signaling message including a revocation parameter, generating credential information for a revocation time defined by the revocation parameter;
The signaling gateway of claim 16 , further configured to revoke previously generated credential information in response to the signaling message including a revocation parameter. The signaling gateway according to claim 17 , wherein the TURN credential information includes a user part and a password part, and the signaling gateway is further configured to generate the user part of the TURN credential information. 19. The signaling gateway of claim 18 , further configured to generate a user realm defined by the user part realm parameter in response to the user part including a user part realm parameter. In response to the user part including a revocation parameter for the user part, generating a revocation time for the user part defined by the revocation parameter;
The apparatus of claim 19 , further configured to send an indication to the TURN server to revoke previously generated TURN credential information in response to the user part including a user part revocation parameter. Signaling gateway. Determining that the signaling gateway and the TURN server have a shared key;
21. The signaling gateway of claim 20 , further configured to generate the password portion of the TURN credential information by hashing the user portion of the TURN credential information with the shared key. Receiving an update request for second TURN credential information related to the first ED that is different from the TURN credential information, wherein the update request is received prior to expiration of a registration cycle time of the signaling message. Receiving,
Verifying the validity of the update request;
The signaling gateway according to claim 21 , further configured to: transmit the second TURN credential information to the first ED. Receiving an update request to provision a second TURN server for the first ED, wherein the update request is received prior to expiration of a registration cycle time of the signaling message; Receiving based on network conditions or security conditions;
Verifying the validity of the update request;
24. The signaling gateway according to claim 21 , further configured to: send the second TURN server to the first ED.