A survey of key management for secure group communication <s> INTRODUCTION <s> This memo specifies the extensions required of a host implementation ::: of the Internet Protocol (IP) to support multicasting. Recommended ::: procedure for IP multicasting in the Internet. This RFC obsoletes RFCs ::: 998 and 1054. [STANDARDS-TRACK] <s> BIB001 </s> A survey of key management for secure group communication <s> INTRODUCTION <s> Security issues in multicast communication have rarely been touched upon to date. We believe that wide-area multicast communication is at a substantially increased risk from specific security threats, compared with the same threats in unicast. This arises both from the lack of any form of effective group access control, and from the fact that multicast traffic traverses potentially many more communication links than does a single unicast communication, thereby creating more opportunity for a link attack. We discuss specific threats that are relevant to multicast, and explain why they are so. We propose security mechanisms specifically for multicast groups requiring safeguards that afford protection against some of these threats. More precisely, we propose a version of the IGMP protocol that can reliably enforce subnet-level group access control. We also describe a scalable mechanism to control multicast traffic in transit that can, for example, prevent a misbehaving source from causing undue congestion over the wide-area. > <s> BIB002 </s> A survey of key management for secure group communication <s> INTRODUCTION <s> This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. <s> BIB003
Group communication applications can use IP multicast BIB001 ] to transmit data to all n group members using minimum resources. Efficiency is achieved because data packets need to be transmitted once and they traverse any link between two nodes only once, hence saving bandwidth. This contrasts with unicastbased group communication where the sender has to transmit n copies of the same packet. However scalable, IP multicast does not provide mechanisms to limit the access The work presented here was done within the context of ShopAware-a research project funded by the European Union in the Framework V IST Programme. Authors' address: D. Hutchison, Computing Department, Faculty of Applied Sciences, Engineering Building, Lancaster University, Lancaster LA1 4YR, United Kingdom; S. Rafaeli, Rua Atanasio Belmonte, 175/828, Porto Alegre, Brazil, CEP 90520-550; email: sandro@hydra.trix.net. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or direct commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 1515 Broadway, New York, NY 10036 USA, fax: +1 (212) 869-0481, or permissions@acm.org. c 2003 ACM 0360-0300/03/0900-0309 $5.00 to the data being transmitted to authorised group members only BIB002 . Any multicast-enabled host can send IGMP BIB003 ] messages to its neighbour router and request to join a multicast group. There is no authentication or access control enforced in this operation  . The security challenge for multicast is in providing an effective method for controlling access to the group and its information that is as efficient as the underlying multicast. A primary method of limiting access to information is through encryption and selective distribution of the keys used to encrypt group information. An encryption algorithm takes input data (e.g., a group message) and performs some transformations on it using a cryptographic key. This process generates a ciphered text. There is no easy way to recover the original message from the ciphered text other than by knowing the right key  ]. Applying such a technique, one can run secure multicast sessions. The messages are protected by encryption using the chosen key, which in the context of group communication is called the group key. Only those who know the group key are able to recover the original message. Furthermore, the group may require that membership changes cause the group key to be refreshed. Changing the group key prevents a new member from decoding messages exchanged before it joined the group. If a new key is distributed to the group when a new member joins, the new member cannot decipher previous messages even if it has recorded earlier messages encrypted with the old key. Additionally, changing the group key prevents a leaving or expelled group member from accessing the group communication (if it keeps receiving the messages). If the key is changed as soon as a member leaves, that member will not be able to decipher group messages encrypted with the new key. However, distributing the group key to valid members is a complex problem. Although rekeying a group before the join of a new member is trivial (send the new group key to the old group members encrypted with the old group key), rekeying the group after a member leaves is far more complicated. The old key cannot be used to distribute a new one, because the leaving member knows the old key. Therefore, a group key distributor must provide another scalable mechanism to rekey the group. A simple scheme for rekeying a group with n members has the key distribution centre (KDC) assigning a secret key to each member of the group. In order to distribute the group key, the KDC encrypts it with each member's secret key. This operation generates a message O(n) long which is then transmitted to the whole group via multicast. On receiving the message, a member can recover the group key from the appropriate segment of the message using its own secret key. In fact, this is not so simple or scalable. Generating one copy of the group key for each member means that the KDC has to encrypt the group key n times. The size of the broadcast message has to be considered as well. For example, a message including all n copies of the encrypted group key, assuming n equal to one million and using a cryptographic algorithm with a key 56 bits long, the message would have size 10253 KB. A session where the membership changes very frequently becomes difficult to administrate. Even though the process is simple, the cost of using the simple scheme in large groups is very high. The literature presents us with several different approaches to group key management. We can divide them into three main classes: -Centralized group key management protocols. A single entity is employed for controlling the whole group, hence a group key management protocol seeks to minimize storage requirements, computational power on both client and server sides, and bandwidth utilization; -Decentralized architectures. The management of a large group is divided among subgroup managers, trying to minimize the problem of concentrating the work in a single place; -Distributed key management protocols. There is no explicit KDC, and the members themselves do the key generation. All members can perform access control and the generation of the key can be either contributory, meaning that all members contribute some information to generate the group key, or done by one of the members. This survey will unfold as follows: In Section 2, we give an overview of the common goals of those classes cited above. The main contribution of this paper is described in Section 3. In Section 4, we present and analyse the group key management protocols. The decentralised architectures are described in Section 5. Finally, the distributed key management schemes are analysed in Section 6.