Re-keying

This section describes re-keying protocols of the cryptographic keys that are needed for a multicast group communication, in particular the traffic key

T₋Key and the area key A₋Key.

As mentioned in Section 4.3.2, re-keying may need to occur if the provision of backward and/or forward secrecy is necessary for a multicast group com- munication. In addition, dynamic mobile environments may also require a multicast group to re-key (or update) group members with a new set of keys (see Section 5.3).

We explicitly describe re-keying operations for the following two types of key:

(a) Re-keying the traffic key

This protocol governs re-keying of a traffic key of a multicast group. In par- ticular, re-keying of a traffic key occurs to satisfy the design requirements of Protocol II(b): Member joining with backward secrecy (seeSection 9.4), andProtocol III(b): Member leaving with forward secrecy (seeSection 9.6). Note that re-keying of a traffic key does not always need to occur during a host mobility protocol (see Section 8.4.4).

The main functional requirements of this protocol are to distribute a new traffic key to:

• all group members of a multicast group (including the newly joined member) during the commencement ofProtocol II(b)(seeSection 9.4).

• all remaining group members of a multicast group (excluding the leaving member) during the commencement of Protocol III(b) (see

Section 9.6).

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

• the distribution of the new traffic keyT₋Keynewto all group members of a multicast group (including the newly joined member) during

8.4 Protocol Functionalities

• the distribution of the new traffic key T₋Keynew to all remaining members (excluding the leaving member) during Protocol III(b) (see

Section 9.6) is protected. (b) Re-keying the area key

This protocol governs re-keying of an area key. In particular, re-keying of an area key occurs not only to satisfy the design requirements of Proto- col II(b) (see Section 9.4) and Protocol III(b) (see Section 9.6), but also

Protocol IV(b): Member moving with backward secrecy (see Section 9.8). The main functional requirements of this protocol are to distribute a new area key to:

• all group members in an area (including the newly joined member) during the commencement of Protocol II(b) (see Section 9.4).

• all remaining group members in an area (excluding the leaving mem- ber) during the commencement of Protocol III(b) (see Section 9.6).

• all group members in a visited area (including the moving member) during the commencement of Protocol IV(b) (see Section 9.8).

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

• the distribution of the new area key A₋Keynew to all group members in an area (including the newly joined member) during Protocol II(b) (see

Section 9.4) is protected.

• the distribution of the new area keyA₋Keynew to all remaining members in an area (excluding the leaving member) during Protocol III(b) (see

Section 9.6) is protected.

• the distribution of the new area key A₋Keynew to all group members in a visited area (including the moving member) duringProtocol IV(b)(see

Section 9.8) is protected.

As discussed inSection 6.2.5, re-keying operations in a domain can be divided into two levels, depending on the entity responsible for re-keying. In this protocol, re-keying is initiated by trusted key managers:

8.5 Summary

(a) At the domain level

A domain key manager (DKM) is responsible for the initiation and control of the re-keying of keys, in particular the traffic keys.

(b) At the area level

Each area key manager (AKM) is responsible for the initiation and control of the re-keying of an area key within its area.

Only re-keying of a traffic key and an area key are described here because these keys are the ones which need regular updates to achieve secure group communication. Other cryptographic keys such asDomain-Area key, Domain key andArea-Member key (which are long-term keys) are not explicitly treated here because they do not need to be updated so often.

8.5

Summary

In this chapter, we determined the scope of our GKMF, and looked at the main components in the proposed architecture. We have also stated our reasons for choosing the design and have described each of the underlying protocol requirements identified within our GKMF.

Chapter 9

GKMF for WMobE: GKMF Protocols

This chapter specifies the design of the main protocols identified with our group key management framework (GKMF).

We organize this chapter as follows. In Section 9.1we introduce the notation and assumptions used in the protocol designs. Our protocol designs begin in

Section 9.2 with creation of new group and initial distribution of keys. In

Section 9.3 and Section 9.4, we specify the protocols for new member joining without and with provision of backward secrecy. InSection 9.5andSection 9.6, we describe the protocols for existing member leaving without and with provi- sion of forward secrecy. InSection 9.7andSection 9.8, we specify the protocols for members moving without and with provision of backward secrecy. Finally, inSection 9.10and Section 9.11, we describe the re-keying protocols for traffic key and area key.

9.1

Introduction

In this section, we describe notation as well as important assumptions that we will make during our protocol designs. We also introduce the use of lists as part of our protocol design, in particular for members moving to other areas.

9.1 Introduction