Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like reference numerals indicate corresponding, analogous or similar elements, and in which:
It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.
A communication device may store an application that is able to communicate time-sensitive information with a VPN server/gateway over a VPN tunnel, for example, audio, video and/or control information. A user of the communication device may interact with the device, for example, to launch the application or to generate an input to the application. An input to the application may be, for example, an identification of another communication device (e.g. a phone number) or a command for the application to initiate a communication session with the other communication device.
According to an embodiment of the invention, the communication device may commence a negotiation of at least one VPN tunnel establishment parameter, for example, an encryption key, with the VPN server/gateway in response to an interaction of a user with the communication device. The communication device may begin the negotiation, for example, if at the time of the user interaction no VPN tunnel between the communication device and the VPN server/gateway exists.
In another example, the communication device may begin the negotiation if at the time of the interaction, a VPN tunnel exists between the communication device and the VPN server/gateway but one or more of the tunnel establishment parameters will expire in less than a predefined amount of time. By renegotiating the tunnel parameters immediately, the communication device may prevent the destruction of the VPN tunnel and the resulting interruption to a communication session during use of the application.
Reference is made now to
Device 106 includes a processor 112 and a memory 114 coupled to processor 112. Device 106 includes an audio input element 116, for example a microphone, an audio output element 118, for example, a speaker, and an audio coder-decoder (codec) 120. Device 106 may optionally include a video camera 122, coupled to processor 112.
Device 106 includes a display 124 coupled to processor 112. Device 106 also includes one or more user input elements 126 coupled to processor 112. A non-exhaustive list of examples for user input elements 126 includes a keyboard, a joystick, a trackball and a thumbwheel. Any of input elements 126 may be embedded in full or in part within display 124, e.g. display 124 may be a touch screen.
Device 106 includes a communication interface 128, which is compatible with one or more wireless and/or wired communication standards and coupled to processor 112. By way of interface 128, device 106 may be able to communicate with network 104.
It should be understood that the architecture of device 106 is merely an example and that embodiments of the invention are applicable to communication devices having any other architecture. For example, a communication device may not include audio elements and/or a camera and/or a display and/or user input elements but rather may be connectable to external such elements.
Memory 114 stores a system management application module 130 and an application module 132, and a VPN client 134. Application module 132 is adapted to communicate time-sensitive information, for example, audio, video, control information and/or gaming information. Examples for application module 132 include a VoIP (Voice over Internet Protocol) application, a voice streaming application, a VoIP phone application, a teleconferencing application, a video streaming application and any other suitable application.
VPN server/gateway 108 includes a processor 136 and a memory 138 coupled to processor 136. VPN server/gateway 108 includes communication interfaces 140 and 142, each of which is compatible with one or more wireless and/or wired communication standards and is coupled to processor 136. By way of interface 140, VPN server/gateway 108 is able to communicate with network 104. By way of interface 142, VPN server/gateway 108 is able to communicate with network 102. Memory 138 stores a system management application module 144.
VPN server/gateway 108 and VPN client 134 are able to negotiate creation of VPN tunnel 110 using any one or more current or future technologies. The following are some exemplary technologies that may be used to secure VPN tunnel 110:
In the following description, IPSEC is used as an example, however, it would be obvious to one skilled in the art how to implement embodiments of the invention with any other technology. In this example, memories 114 and 138 store IPSEC packet processing modules 148 and 150, respectively, and IKE modules 152 and 154, respectively. IKE modules 152 and 154 may function at least for creating security associations 156 and 158 in memories 114 and 138, respectively. IPSEC modules 148 and 150 require security associations 156 and 158, respectively, for securing communication packets over tunnel 110.
The IKE protocol is defined to create security associations and it does this in two phases. In the first phase, communication device 106 and VPN server/gateway 108 authenticate each other and provide each other with their authentication credentials. In addition, using the Diffie-Hellman algorithm, “phase 1” shared keys 160 are generated and are stored in memories 114 and 138. In the second phase, IKE modules 152 and 154 negotiate security policy identities, algorithms and other security properties, and generate “phase 2” keys 162 and 164, respectively, for bulk encryption and HMAC (Hashed Message Authentication Code) authentication. This information is stored in security associations 156 and 158.
The IKE protocol defines main mode and aggressive mode for phase 1 exchange. It defines quick mode for phase 2. In the main mode, the user/machine identities are protected. It takes six UDP (User Datagram Protocol) messages to complete phase 1. In aggressive mode, the user/machine identities are sent in the clear and the transaction is completed in three UDP messages.
In the main mode, the parties (e.g. device 106 and VPN server/gateway 108) use the first two messages to negotiate security properties for phase 1 and phase 2 exchanges. Both parties perform a Diffie-Hellman key exchange in the next two messages. In addition, they exchange nonces, which are used later to authenticate peers with their identities. The last two messages are used to send and receive identities and authentication information.
In aggressive mode, the Initiator (e.g. device 106) uses the first message to inform the other party of security properties, the Diffie-Hellman public key component, identity and nonces. The second message is used by the Responder (e.g. VPN server/gateway 108) to pass selected security properties, its own Diffie-Hellman key information, nonces, its identity and any certificate information. In the third message, the Initiator authenticates itself to the Responder.
In quick mode, both parties generate keying material (e.g. keys 162 and 164) to secure the data traffic. Optionally, the Diffie-Hellman operation can be performed to support Perfect Forward Secrecy (PFS) for keys.
In communication device 106, IPSEC module 148 informs IKE module 152 if it cannot find information for the security policy in security association 156. IKE module 152 identifies the required security profile from information provided by IPSEC module 148, and extracts and stores an IP address 166 of VPN server/gateway 108 in memory 114.
Communication device 106 then initiates the phase 1 exchange. As part of the phase 1 exchange, communication device 106 and VPN server/gateway 108 identify security properties to secure the rest of the exchange in phases 1 and 2. They generate a shared secret using the Diffie-Hellman algorithm and they mutually authenticate each other using a defined authentication mode.
Once phase 1 is completed, the quick mode negotiation starts with the exchange of security policy information. Optionally, if PFS is enabled, new shared keys are generated using the Diffie-Hellman algorithm and stored as shared keys 160. Keys 162 and 164 are produced using nonces and phase 1 shared keys 160. At the end of phase 2, security associations 156 and 158 are created with keys 162 and 164, respectively, keys lifetimes, algorithms, etc., and are given to IPSEC modules 148 and 150, respectively. For example, security association 156 may include a lifetime 168 of phase 1 keys 160, a lifetime 170 of phase 2 keys 162 and a shorter lifetime 172 for keys 160 and/or 162 in case tunnel 110 is idle.
In VPN server/gateway 108, IKE module 154 receives phase 1 messages and completes phase 1 with the exchange of security properties, key exchange payload and identity payload, as part of main and aggressive mode exchanges. On receiving the phase 2 message, VPN server/gateway 108 finds out the validity of the security policy attributes it received from communication device 106, by referring to a security policy database that may be external to VPN server/gateway 108 and is not shown. If a matching inbound security policy is found, phase 2 continues and results in the creation of security association 158 with keys 164, and life times of keys 160 and 164. Security association 158 may include additional information such as algorithms.
IKE 154 informs IPSEC module 150 of the newly created security association 158. From this point onwards, tunnel 110 is considered to be established, IPSEC module 150 honors packets received from device 106, decrypts them, validates the authenticity of the packets, and sends clear packets to network 102.
If tunnel 110 is established and the life of any of keys 160, 162 and 164 expires, tunnel 110 ceases to exist. Memory 114 may optionally store a re-key time-margin parameter 174. To preserve tunnel 110 in an established state, device 106 may be triggered to renegotiate phase 1 shared keys 160 an amount of time equal to re-key time-margin parameter 174 before the expiration of phase 1 keys 160.
At 200, device 106 recognizes an interaction of a user with application 132. For example, a user may attempt to launch application 132 or to provide input to application 132. If device 106 recognizes at 202 that at the time of the interaction tunnel 110 does not exist, the method continues to 204. Otherwise, at 206, device 106 determines the amount of time left until any establishment parameter of tunnel 110 will expire. For example, device 106 may determine the time until any of keys 160, 162 and/or 164 will expire.
At 208, if any establishment parameter of tunnel 110 is about to expire sooner than threshold 176, the method continues to 204. Otherwise, the method terminates. At 204, device 106 triggers a negotiation of one or more establishment parameters of tunnel 110, for example, any of keys 160, 162 and 164, to ensure tunnel 110 remains in an established state for a duration of no less than time threshold 176.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.