Elaboración de procedimientos, planes, informes y otros

In dynamic wireless mobile environments, group members are not just allowed to join (and/or leave) a multicast group, but are also allowed to move between

8.4 Protocol Functionalities

areas while remaining in a group session. As each area may have different security requirements, as well as keeps its own security information (such as old keys), members moving to other areas can be viewed as new joins, each of which may require protection of its local information from an entering member. Because a moving member may accumulate information for each area it visits, two options can be adopted depending on whether the provision of backward secrecy is necessary or not for controlling access to an area’s past security information (which could be used for malicious purposes). This protocol will thus consider both options of members moving with and without backward secrecy.

In the first option, where provision of backward secrecy is not necessary, no update of keying material will occur (in particular an AKM of a visited area does not need to re-key its area key). On the other hand, the second option requires an AKM to re-key its area key when a group member moves in. In dynamic mobile environments, group members may frequently move be- tween a number of areas while still remaining in a group session. Every time a member moves into an area, re-keying of an area key may need to occur. As frequent re-keying may cause disruption of group communication, it may be necessary to keep track of the mobility of a highly dynamic group member. This can be useful to avoid frequent re-keying of an area key. This protocol will thus consider this circumstance.

To facilitate this, each key manager in a domain (DKM and AKMs) will need to maintain a list which contains information on the moving member, such as area(s) visited (which also indicates how many area keys the member pos- sesses). This list is referred to as a mobility list (MobList) and is discussed in

Section 9.1.4. In cases where a group member moves back into an area that

it recently visited, an AKM can look up its MobList, and if the member is on the list (and is still a valid member of the multicast group) the AKM can determine that the member is a returning member who is moving back into the area. In this case, the area key of that particular area may not need to be re-keyed.

8.4 Protocol Functionalities

On the other hand, the area key of the visited area may need to be re-keyed if such a member is not on the MobList, and it is the member’s first time entering the area.

Note that this process is completely separate to the re-keying that needs to occur whenever there is a change in group membership due to new member joins and/or existing member leaves. In any of these circumstances, group members (including the moving member) will need to be updated with new cryptographic keys.

The main functional requirements of this protocol are divided into the two

moving options, as follows:

(a) For members moving without backward secrecy, the main functional re- quirements are to:

• transfer a group member from one area to another area. • deliver an area key of a visited area to a moving member.

(b) For members moving with backward secrecy, in addition to those specified in (a), the other main functional requirements are to:

• initiate a re-keying of an area key of a visiting area.

• deliver a new area key of a visited area to a moving member.

A further protocol is required to govern the establishment of a short-term key to support host mobility.

For secure transfer of a group member from one area to another, secu- rity information (such as cryptographic keys) may need to be exchanged between communicating entities (in particular between a moving member and an AKM of a visited area) via a secure channel. This requires both entities (the moving member and the AKM of a visited area) to share a common secret key prior to the commencement of the move protocol. This type of key is referred to as a session mobility key (see Section 8.3.6.2). This protocol governs the establishment of a session mobility key between a group member that wishes to move to another area and an AKM of a

8.4 Protocol Functionalities

visited area. The generation and initial distribution of a session mobility key is conducted by a DKM in a domain and the key is delivered to the intended member via an AKM in the area where the member is currently residing. The same key is delivered to an AKM of a visited area by the DKM.

(c) The main functional requirements of this protocol are to:

• establish a session mobility key between a moving member and an AKM of a visited area.

• deliver a session mobility key to a moving member and to an AKM of a visited area.

The main security requirements of this protocol are to ensure that:

• only transfers from authorized group members are processed.

• communications between the group member and the area key manager are secure.

• communications between the area key manager and the domain key man- ager are secure.

• for member moving without backward secrecy, the distribution of area key A−Key of the visited area to the moving member is protected.

• for member moving with backward secrecy, the distribution of new area key A−Keynew of the visited area to the moving member is protected.

• the establishment of session mobility key between a moving member and an area key manager of the visited area is secure.

• the distribution of session mobility key to the moving member and to the area key manager of the visited area is protected.

8.4 Protocol Functionalities