Dynamic Group Creation for Managed Key Servers

TECHNICAL FIELD

p-0002The present disclosure relates to management of secure communications in communication networks.

BACKGROUND

p-0003Encryption is used to provide secure communications between entities over communication networks. In the case of communications involving a group of participants, cryptographic keys may be distributed to the group members and employed to encrypt messages or content sent over the network during a communication session. To facilitate secure group communication, a group can be created on a key server that authenticates group members and generates and supplies keys to the members. A group keying protocol, such as the Group Domain of Interpretation (GDOI) protocol, can be used for interactions between the key server and group members.

p-0004Currently, a static group created on a key server persists indefinitely or until the group is explicitly cleared on the key server through configuration. The GDOI protocol commonly used for group keying is designed primarily for implementation of such static groups, which are not deleted or terminated at a certain point in time or after a given period of time.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0005<figref idrefs="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example of a communication network in which a key server is configured to generate a dynamic group to support a secure group communication session among group members.

p-0006<figref idrefs="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an example of a key server capable of dynamically creating and deleting groups to support secure group communication sessions.

p-0007<figref idrefs="DRAWINGS">FIG. 3</figref> is a flow diagram illustrating an example of operations performed by a key server to facilitate a secure group communication session.

p-0008<figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram illustrating an example of a communication network in which a key server, accessed via a pseudo group member, is configured to generate a dynamic group to support a secure group communication session among group members.

p-0009<figref idrefs="DRAWINGS">FIG. 5</figref> is a flow diagram illustrating an example of a sequence of exchanges for managing a secure group communication session employing a pseudo group member.

DESCRIPTION OF EXAMPLE EMBODIMENTS

p-0010Overview

p-0011A technique for dynamically creating and deleting groups to support secure group communication sessions is provided herein. A request for creation of a dynamic group that enables group members to participate in a secure group communication session is received by a network authentication device such as a key server. Creation of the dynamic group includes generating a lifetime attribute indicating when the dynamic group is to exist based on timing information provided in the request, along with security policies required for generating the keys, and generating a unique group identifier (ID) associated with the dynamic group for distribution to the group members. The keys for the secure group communication session are supplied in response to a request containing the unique group ID identifying the dynamic group. The dynamic group is deleted in response to determining from the lifetime attribute that the secure group communication session has expired. The key server can extend the group lifetime in response to a request to extend the secure group communication session.

Example Embodiments

p-0012Referring first to <figref idrefs="DRAWINGS">FIG. 1</figref>, a simplified network environment is shown in which entities are configured to communicate in secure group communication sessions with the support of a key server <b>10</b> capable of dynamically creating and deleting groups. A secure group communication session involves at least two group members <b>12</b> and <b>14</b> that are participants in the session and which can be any entities capable of communicating over a network with each other in a secure manner using cryptographic keys. For example, the group members can be virtually any type of electronic equipment suitable for transmitting or receiving content for a human user, including but not limited to: data signals, audio/voice signals, video or visual display signals, and any other types of media or content. Any one or combination of network media such as wire, cable, optical fiber, wireless link, satellite, etc. can be used to network the group members. As indicated by the ellipsis between host <b>12</b> and group member <b>14</b> in <figref idrefs="DRAWINGS">FIG. 1</figref>, any practical number of group members may belong to the group, depending on the type of application used for the session. The group members may be in physically separate locations and connected via a wide area network (WAN) or the Internet. Likewise, key server <b>10</b> may be at a separate site or location from the group members and accessed via a WAN or the like.

p-0013As shown in the embodiment in <figref idrefs="DRAWINGS">FIG. 1</figref>, one of the group members participating in the group communication session can be a session host <b>12</b>. Host <b>12</b> is an entity that initiates a secure group communication session and which may interact either directly or indirectly with key server <b>10</b> to request establishment of a dynamic group to support the session.

p-0014By way of an example, the group members may communicate via an on-demand application, such as Telepresence, WebEx, or pay-per-view TV, in which users join the session for a given period of time, after which there is no need to maintain the existence of the group. Thus, as used herein, the term secure group communication session includes: video conferencing; network-supported meetings, such as meetings that include a combination of voice and data/video display; and customer access of on-demand or pay-per-view content from a provider (e.g., web-based, satellite, cable, fiber optic delivery, etc.). Another example of a secure group communication session is a temporary subscription to a premium channel or content offered by a provider (e.g., as a result of a promotion), where access to the premium channel/content terminates at some point in time. Thus, group members may be active participants in the session (e.g., an on-line meeting) or passive participants (e.g., listening to a lecture or viewing on-demand content). With an on-demand application, individual group members may be capable of joining and leaving a session throughout the course of the session, provided the group members have been authenticated and have been provided with the cryptographic keys required to participate. Current on-demand applications include a variety of security solutions, which are typically proprietary and implemented at a higher architecture layer such as the application layer. Such solutions do not employ network layer (layer 3) encryption that can be provided by a key server capable of establishing a group.

p-0015Key server <b>10</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref> is responsible for dynamically creating groups, authenticating group members, and either directly or indirectly supplying to the group members the cryptographic keys and security policies to be used in the secure group communication session. One example of a key-server-based group encryption technology is Group Encrypted Transport Virtual Private Network (GETVPN) offered by Cisco Systems, Inc. GETVPN eliminates the need to create point-to-point Internet Protocol Security (IPSec) tunnels between each entity and uses Group Domain of Interpretation (GDOI) as the group keying protocol and IPSec for encryption, providing network layer encryption. IPSec is a set of protocols for securing Internet Protocol (IP) communications by authenticating and encrypting IP packets of a data stream. IPSec also includes protocols for establishing mutual authentication between agents at the beginning of a session and for negotiating cryptographic keys to be used during the session. IPSec uses the Internet Key Exchange (IKE) protocol to set up a security association by handling negotiation of protocols and algorithms and to generate the encryption and authentication keys to be used.

p-0016Conventionally, static groups created on a key server persist indefinitely or until they are explicitly cleared on the key server through configuration. This static group approach is not efficient for a range of on-demand applications, and GDOI and other group keying protocols are not equipped to expire or delete groups after a given period of time or to stop the rekeying process in which keys are periodically updated. In the described system, key server <b>10</b> is capable of dynamically create and delete (destroy) groups as needed to conduct time-limited secure group communication sessions, thereby expanding the scope of key-server-based, group-keying technologies such as GETVPN and making them usable by a wide variety of on-demand applications. Dynamic group creation on the key server reduces the rekey and group formation overhead and makes the overall process more efficient.

p-0017Turning now to <figref idrefs="DRAWINGS">FIG. 2</figref>, a block diagram illustrating an example of key server <b>10</b> configured to dynamically create groups is shown. Key server <b>10</b> can be implemented using one or more network routers; however other devices may also be configured to perform the key server functions described herein. Key server <b>10</b> can also be a pure computational element and not configured to forward packets in the network. Generally, key server <b>10</b> comprises at least a network interface unit <b>20</b>, a processor <b>22</b>, and a memory <b>24</b>. Processor <b>22</b> is, for example, a microprocessor, a microcontroller, a digital signal processor, etc. Network interface unit <b>20</b> is a device, e.g., Ethernet card or module, configured to enable communications over a network according to any of a variety of networking protocols.

p-0018Memory <b>24</b> is a tangible processor-readable or computer-readable memory that stores or is encoded with instructions that, when executed by processor <b>22</b>, cause processor <b>22</b> to perform the functions described herein. For example, memory <b>24</b> is encoded with group ID manager logic <b>26</b> and key generator logic <b>28</b>. While <figref idrefs="DRAWINGS">FIG. 2</figref> shows a processing environment comprising a data processor <b>22</b> that executes software stored in memory <b>24</b>, an alternative processing environment is a fixed data processing element, such as an application specific integrated circuit (ASIC) that is configured, through fixed hardware logic, to perform the functions of the logic <b>26</b> and <b>28</b>. Yet another possible data processing environment is one involving one or more field programmable logic devices, or a combination of fixed processing elements and programmable logic devices. In one form, logic <b>26</b> and <b>28</b> may be embodied in a processor-readable medium that is encoded with instructions for execution by a processor that, when executed by the processor, operate to cause the processor to perform the functions described herein in connection with logic <b>26</b> and <b>28</b>.

p-0019<figref idrefs="DRAWINGS">FIG. 3</figref> is a flow chart illustrating operations performed by key server <b>10</b>, in particular by processing group ID manager logic <b>26</b> and key generator logic <b>28</b>, to dynamically create and delete a group and manage implementation of a secure group communication session between group members <b>12</b> and <b>14</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. In operation <b>30</b>, key server <b>10</b> receives a request from host <b>12</b> for creation of a dynamic group in order to conduct a secure group communication session. The group-creation request can be implemented as a sequence of exchanges between host <b>12</b> and key server <b>10</b>.

p-0020In particular, a secure connection can be established between host <b>12</b> and key server <b>10</b> using a key exchange protocol such as IKEv1, IKEv2, or other key exchange protocol. IKE phase 1 can be used to establish a secure connection with key server <b>10</b> and to authenticate the group members. Instead of passing an existing group ID to key server <b>10</b> at this initial registration time, host <b>12</b> supplies to key server <b>10</b> information for creating a dynamic group. Key server <b>10</b> receives this information and, if capable of creating dynamic groups, key server <b>10</b> acknowledges the request. In response, host <b>12</b> further supplies to key server <b>10</b> timing information about when the session is to occur and other information that is applicable for the session (e.g., policies, default/specific transform-set, etc.). IKE phase 2 can be used to exchange the meeting details, for example. The timing information can be specified in any of a variety ways. According to one option, the timing information can indicate a starting date and time and an ending date and time for the session. According to another option, the timing information can indicate a starting date and time and a duration of the session (from which an ending date and time can be determined).

p-0021With a conventional, static group, an entity contacting the key server at this point is already a member of an established, static group, so there is no need to supply a group ID to the group member. Thus, the key server supplies the keys in response to a request from a group member. With dynamic group creation, the keys are not immediately supplied to the group member. Rather, the dynamic group ID is supplied at this point, and keys are supplied at a later time upon request by the group member, e.g., at the time the group member wishes to join the secure group communication session.

p-0022Referring again to <figref idrefs="DRAWINGS">FIG. 3</figref>, in operation <b>32</b>, processor <b>22</b> processes group ID manager logic <b>26</b> to create a dynamic group based on the information received from host <b>12</b>. In particular, based on the timing information provided in the request, group ID manager logic <b>26</b> generates a lifetime attribute of the dynamic group that indicates when the dynamic group is to exist. The starting time and expiration time of the dynamic group indicated by the lifetime attribute essentially correspond to the starting and expiration time of the secure group communication session to be held among the group members. The lifetime attribute is associated with the dynamic group and is stored in memory <b>24</b> of key server <b>10</b> for later determining when to delete the dynamic group. As with the timing information, the lifetime attribute can be specified in a number of different ways (e.g., start and end times, start time and duration, etc.).

p-0023Group ID manager logic <b>26</b> also generates a unique group ID that identifies the dynamic group for the upcoming secure group communication session. Key server <b>10</b> then supplies the unique group ID to the group members. In the example shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, this can be accomplished by sending the group ID to host <b>12</b> and having host <b>12</b> disseminate the group ID to the other group members. Another option is to have key server <b>10</b> directly send the group ID to each of the group members, including host <b>12</b>.

p-0024To participate in the secure group communication session, each group member can register with key server <b>10</b> (e.g., via GDOI registration) by sending a request that identifies the group by the unique group ID previously disseminated. In operation <b>34</b>, processor <b>22</b> executes key generator logic <b>28</b> to generate and supply the cryptographic keys in response to such a request, e.g., using the GDOI protocol. Security policies can also be sent along with the keys. According to another option, host <b>12</b> may register with key server <b>10</b> using the unique group ID and request the keys for all of the group members. In this case, key server <b>10</b> supplies the keys (and, optionally, security polices) to host <b>12</b>, which can then distribute the keys to the remaining group members. In either case, dissemination of keys to an individual group member does not need to occur until the member wishes to join the group session. Once the group members have been authenticated and have received the keys, the group members can use these keys to secure (encrypt) the traffic (e.g., multicast/unicast data) that is sent during the session. Note that key server <b>10</b> does not encrypt the traffic within the secure group communication session in the embodiment shown in <figref idrefs="DRAWINGS">FIG. 1</figref>.

p-0025Referring once again to <figref idrefs="DRAWINGS">FIG. 3</figref>, in operation <b>36</b>, processor <b>22</b> executes group ID manager logic <b>26</b> to delete the dynamic group in response to expiration of the secure group communication session, as indicated by the stored lifetime attribute of the dynamic group. According to one option, when the session expires according to the stored lifetime attribute, key server <b>10</b> sends a delete or expiration notification to all of the group members or sends a delete/expiration notification to host <b>12</b>, which disseminates the delete/expiration notification to the other group members. The notification informs the group members that the session is expiring and that key server <b>10</b> is deleting the dynamic group. The delete notification can be enforced by host <b>12</b> and the other participants by terminating the session and/or by locally deleting the keys. Optionally, before sending the delete notification, key server <b>10</b> can send an inquiry to host <b>12</b> asking whether there is a need to extend the meeting. In this case, key server <b>10</b> can await a response from host <b>12</b> prior to sending the delete notification.

p-0026Thus, the dynamic group creation technique described herein allows groups to be dynamically created on a key server as needed, such as in response to the scheduling of a new WebEx meeting or a pay-per-view event. Once the dynamic group is created on the key server, it has a lifetime attribute which indicates to the key server when this group is no longer valid and should be deleted. On the group member side, the keys will expire when the lifetime period is over, and the group states are cleared.

p-0027Optionally, in the event the host or one of the other participant group members wishes to extend the session, an extension request can be sent to key server <b>10</b>. In response to such an extension request, group ID manager logic <b>26</b> can modify the lifetime attribute of the dynamic group in accordance with the extension request to modify the expiration time of the dynamic group and the secure group communication session, confirm extension of the session with host <b>12</b> (or all group members), and supply new keys and any change in policies via rekeying if necessary.

p-0028When using a group keying protocol such as GDOI, a rekeying mechanism is employed to refresh the keys by providing new or updated keys to the group members at certain points in time specified in the security policies (e.g., periodically, as-needed, etc.). This GDOI rekey property can be retained in the dynamic group creation scheme described herein, such that rekeying can occur, as desired, during the secure group communication session (e.g., keys can be refreshed every half-hour in an hour-long session). Note that it is not necessary to rekey if a group member joins or leaves the session.

p-0029In some applications, such as certain on-demand applications, a server or other network device may function to coordinate or facilitate a session among group members. For example, a WebEx server may be used to manage a WebEx meeting among a host and other participants. In this case, the coordinating network device can serve as a proxy or intermediary for the group members and handle exchanges with the key server. In this sense, the intervening network device operates as a “pseudo group member” (or “pseudo GM”), since, from the key server's perspective, the network device assumes the role of a group member, but is a facilitator or coordinator of the group session rather than a participant. <figref idrefs="DRAWINGS">FIG. 4</figref> is a block diagram illustrating a network environment where a pseudo GM <b>16</b> resides between key server <b>10</b> and group members <b>12</b> and <b>14</b>. Pseudo GM <b>16</b> can be in a physically separate location or at a different site and can be connected via a WAN or the like to group members <b>12</b> and <b>14</b> and key server <b>10</b>.

p-0030Turning to <figref idrefs="DRAWINGS">FIG. 5</figref>, a flow diagram illustrating a sequence of exchanges for managing a secure group communication session by employing a pseudo group member is shown. Many operations described in connection with <figref idrefs="DRAWINGS">FIG. 5</figref> are performed by execution of the group ID manager logic <b>26</b> and key generator logic <b>28</b> (<figref idrefs="DRAWINGS">FIG. 2</figref>). In operation <b>50</b>, host <b>12</b> sends a request to pseudo GM <b>16</b> to authenticate with pseudo GM <b>16</b> and to set up a secure group communication session, such as a WebEx meeting for example. After authenticating host <b>12</b>, in operation <b>51</b>, pseudo GM <b>16</b> sends a request to key server <b>10</b> on behalf of host <b>12</b> for creation of a dynamic group for the secure group communication session among the group members. This request can be similar to the request made directly by host <b>12</b> in the previous example described in connection with <figref idrefs="DRAWINGS">FIGS. 1-3</figref>. Thus, for example, pseudo GM <b>16</b> registers with key server <b>10</b>, establishes a secure link, and supplies timing information about the upcoming group communication session to key server <b>10</b>.

p-0031In operation <b>52</b>, key server <b>10</b> creates a dynamic group based on the information received from pseudo GM <b>16</b>, e.g., by processing group ID manager logic <b>26</b> (<figref idrefs="DRAWINGS">FIG. 2</figref>). In particular, based on the timing information provided in the request, key server <b>10</b> generates the lifetime attribute of the dynamic group based on the timing information, as previously described. Key server <b>10</b> also generates the unique group ID that identifies the dynamic group for the upcoming secure group communication session. Key server <b>10</b> then supplies the unique group ID to pseudo GM <b>16</b> for distribution to the group members. In operation <b>53</b>, pseudo GM <b>16</b> sends the group ID to host <b>12</b> which, in operation <b>54</b>, distributes the group ID to the remaining group member(s) <b>14</b>. According to another option, pseudo GM <b>16</b> can directly send the group ID to each of the group members, including host <b>12</b>.

p-0032To participate in the secure group communication session, each group member can register with key server <b>10</b> (e.g., via GDOI registration) by sending a request that identifies the group by the unique group ID previously disseminated. In the arrangement shown in <figref idrefs="DRAWINGS">FIG. 4</figref>, the group members authenticate with and send the key request to pseudo GM <b>16</b> (operation <b>55</b>), which in turn registers with key server <b>10</b> and requests the keys on behalf of the group members (operation <b>56</b>). According to another option, host <b>12</b> can send a key request to pseudo GM <b>16</b> on behalf of the remaining group members instead of all group members sending key requests to pseudo GM <b>16</b>. In either case, pseudo GM <b>16</b> sends the request for keys to key server <b>10</b>. By executing key generator logic <b>28</b>, in operation <b>57</b>, key server <b>10</b> generates and supplies the cryptographic keys to pseudo GM <b>16</b> in response to such a request, e.g., using the GDOI protocol or other group keying protocol. Security policies can also be sent along with the keys.

p-0033In operation <b>58</b>, pseudo GM <b>16</b> supplies the keys (and, optionally, security policies) to the group members. According to another option, pseudo GM <b>16</b> can supply the keys to host <b>12</b>, which can then distribute the keys to the remaining group members. In either case, dissemination of keys to an individual group member does not need to occur until the member wishes to join the group session. Once the group members have been authenticated and have received the keys, the group members can use these keys to secure the traffic that is sent during the session (operation <b>59</b>).

p-0034In operation <b>60</b>, key server <b>10</b>, via group ID manager logic <b>26</b>, deletes the dynamic group in response to expiration of the secure group communication session, as indicated by the stored lifetime attribute of the dynamic group. Key server <b>10</b> can send a delete or expiration notification to pseudo GM <b>16</b> to inform the group members that the session is expiring and that key server <b>10</b> is deleting the dynamic group. If the host or one of the other participant group members wishes to extend the session, an extension request can be sent to key server <b>10</b> via pseudo GM <b>16</b> to extend the session. Key server <b>10</b> can modify the lifetime attribute of the dynamic group in accordance with the extension request to modify the expiration time of the dynamic group and the secure group communication session, confirm extension of the session with pseudo GM <b>16</b>, and supply new keys and any change in policies via rekeying, if necessary, to pseudo GM <b>16</b> for dissemination to the group members.

p-0035The dynamic group creation technique described herein avoids the need for on-demand applications to have their own versions of encryption and allows group keying protocol based systems such as GETVPN to be the encryption backbone of such applications. This approach provides a more standardized encryption mechanism that can simplify implementation of current and future on-demand applications, potentially avoiding costly network, hardware, and software modifications. Systems such as GETVPN provide layer 3 (network layer) encryption. By expanding GETVPN and other group keying protocol based systems to provide dynamic group creation, applications can easily leverage these systems to encrypt their data. Consequently, such systems can provide a unified back end to these applications and simplify the use of various security schemes. Creating the groups dynamically eliminates the need to statically configure all the groups in advance, and gives the key server the flexibility to create the groups as requests are received. In addition, there is less overhead in maintaining the groups when they are no longer needed. This adds efficiency and greater flexibility to the key server deployment.

p-0036Although the apparatus, system, and method are illustrated and described herein as embodied in one or more specific examples, it is nevertheless not intended to be limited to the details shown, since various modifications and structural changes may be made therein without departing from the scope of the apparatus, system, and method and within the scope and range of equivalents of the claims. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the apparatus, system, and method, as set forth in the following claims.