INTERNET DRAFT O. Paridaens ULB D. Ooms B. Sales Alcatel July, 2000 Expires January, 2001 Security Framework for Explicit Multicast Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the general issues related to securing explicit multicast traffic. Explicit multicast is a mechanism aiming at providing multicast services for small groups of users. The distinctive characteristics of explicit multicast is that the sender specifies the list of receivers. This document reviews and discusses security issues related to the explicit IP multicast model, hence providing a general framework for securing explicit multicast IP traffic once the exact mechanism for achieving explicit IP multicast is specified. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Paridaens, et al Expires January 2001 [Page 1] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 1 Introduction Explicit multicast [11, 12, 13, 14] is a mechanism providing multicast services for small groups of users. One major particularity of explicit multicast is that the sender normally explicitly specifies the list of recipients (how this is exactly achieved is further specified in companion documents). Such a multicast model is already used for electronic messaging but the idea here is to apply it at the IP level. As it is well-known, "traditional" multicast brings complex issues in terms of applying security services to such traffic. This has been a subject of research for several years and is now being more specifically studied within the IRTF SmuG group [1-9]. Explicit multicast distinguishes from traditional multicast at least in terms of scalability issues and membership control. Indeed, an explicit multicast session is made of few members, which significantly reduces scalability issues being dealt with in SmuG. Also, the receivers are known by the sender(s), which plays a role in membership management issues (e.g. access control, anonymity). Explicit multicast brings specificities compared to traditional multicast, specificities which have consequences on security aspects. Based on the work being done in SmuG, this document discusses those security matters related to explicit IP multicast, hence providing a general framework for securing explicit multicast IP traffic. The first section reviews security services usually considered in multicast environments. For each such service, we determine whether the solution(s) being developed for traditional multicast solely apply, or whether simpler or better solution(s) can apply, taking benefit of the explicit multicast specificities. The following section covers aspects linked to the existing IPsec technology [10]. It reviews issues in the use of IPsec for multicast traffic and discusses possible scenarios that might be applied for securing explicit IP multicast traffic with IPsec AH and/or ESP. The last section is devoted to the important problem of Security Association (SA) and key management, identifying issues and suggesting possible solutions in a generic way. 2 Security Services This section discusses basic security services that can be required in the context of explicit IP multicast. Problems may seem similar to those arising in "traditional" multicast environments and which are being discussed within the SmuG IRTF group but the explicit aspect leads to specificities which we have considered throughout Paridaens, et al Expires January 2001 [Page 2] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 this document. For each identified security aspect, we discuss whether solutions being developed for traditional multicast apply or whether simpler, better solutions can apply by taking benefit of the explicit multicast model characteristics. Because the explicit multicast model being considered applies at the IP level, our discussions focus on security aspects at the IP level. 2.1 Membership Management This section covers the various aspects linked to the group membership that influence or are directly related to the provision of security services in an explicit multicast environment, main characteristic of which is that the list of recipient IP addresses explicitly appears in the IP datagram. 2.1.1 Access Control 2.1.1.1 Membership Control Controlling the membership of the session is obviously a (possible) security requirement. Such a control can be achieved merely to identify who is part of the session without applying any restriction or to control access to the session (hence applying yes/no decisions on join requests). Control can also be achieved thanks to "invite" requests whereby receivers are invited to join the multicast session. The entity responsible for controlling the membership is termed the group controller (GC). As further discussed in section 4, in traditional multicast, the work of the GC is not so obvious. Current proposed multicast routing schemes do not enable a central GC to always know which IP entities are joining the multicast group (as the entity's IP address is lost on the way). In any case, a scalable solution for traditional multicast will probably require the use of a distributed GC model. With explicit multicast, control of the group membership is eventually under the sole authority of the sender since it specifies the list of destination IP addresses. If there is a single sender, it can easily act as the GC. In a "join" model, a membership management protocol (possibly located within the application itself) could be used to enable members to join and leave the group by sending requests to the GC (ie. the sender). In an "invite" model, the GC (ie. the sender) issues invitations to receivers, thereby controlling membership. If there are multiple senders, the solution becomes more complex Paridaens, et al Expires January 2001 [Page 3] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 since membership updates must be distributed amongst all senders. A typical solution would be to use a central GC (either one of the senders or a third-party entity) tasked with managing the group. Membership updates could then be reported to all senders thanks to some management protocol (a simple unicast protocol can be designed to achieve this given the small number of senders and that each sender is known). 2.1.1.2 Senders Control Access control also covers "who is allowed to send traffic to the group". Because we focus on IP multicast, access control is discussed here in terms of IP entities, not end-users. Several strategies can be envisaged to control the sending entities. In traditional multicast, it does not seem easy to control senders in an efficient way (ie. detect and drop IP traffic from unauthorized senders as soon as possible). In multicast routing schemes where the IP traffic passes through a root entity, this can be used as a filtering point. Even with such schemes however, it is still usually possible to bypass the root entity (for routing efficiency reasons). Senders control policy should then be distributed to routers located upfront multicast members. Those routers could then be tasked with the job of filtering on senders to the group (ie. IP datagrams from unauthorized senders are discarded). This would however require that those routers keep track of such policies attached to multicast groups they are aware of. Such filtering could anyway be achieved by members themselves, which has the obvious disadvantage of potentially wasting bandwidth on the network infrastructure but members can set up individual policies on whom they want to receive from (in addition to the group policy itself which may have been received when joining the group). In explicit multicast , there is normally no central point through which the IP traffic passes. In addition, because the purpose itself of explicit multicast is to avoid keeping state in routers, routers cannot be tasked with the job of filtering on senders to the group (i.e. IP datagrams from unauthorized senders are discarded when detected). This would indeed require that (at least some) routers keep track of explicit multicast sessions and their authorized senders. Receivers will therefore have to filter by themselves (although some basic policy can be distributed to members by the GC). In any case, filtering on senders requires that the sender be correctly authenticated. Otherwise, valid senders could easily be spoofed. Some individual authentication must therefore be provided as further discussed in section 2.2.4. Paridaens, et al Expires January 2001 [Page 4] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 2.1.2 Anonymity In certain environments, members' anonymity can be a requirement. Because we talk about IP multicast issues, we focus here on anonymity at the IP level, hence in terms of IP addresses. Group membership anonymity can be provided in various flavors. A first type of anonymity can be required amongst members : no member is aware of the other members. Within traditional multicast , this can somewhat be achieved because member IP addresses are "hidden" behind the multicast group address and the IP addresses of the entities joining the routing tree are not widely distributed. A sender's anonymity is obviously less obvious to keep since it is the source of datagrams. An entity located "near" a member can determine its membership by looking at its "join" or "invite" operations but this is still rather limited. In explicit multicast this is clearly not possible for the sender(s). By the very nature of explicit multicast, each sender is aware of the group membership. Regarding pure receivers, anonymity amongst them can only be achieved if other receiver IP addresses are removed before the IP datagram is relayed to the final destination. The receiver still knows the sender and some routers "on the path" can determine (at least partially) the list of other recipients. Anonymity towards the external world (i.e. non-members) can also be required. Within traditional multicast, this can somewhat be achieved for the same reasons as given above. In explicit multicast, this seems difficult to achieve. Third-party entities located on the IP traffic paths can determine at least partially the receivers (as long as their IP addresses remain in the IP datagrams). Membership, join, leave and invite operations can also be seen by third-parties located on such traffic paths between the GC and the members. The use of unicast IPsec/IKE tunnel connections between the GC and the members can provide some level of confidentiality and hence anonymity at that level. 2.1.3 Group Dynamics The dynamics of the group membership can have an important impact on the security mechanisms put in place. The fact that members can dynamically join and leave the group has consequences on the scheme used to provide data privacy for example, as discussed in section Paridaens, et al Expires January 2001 [Page 5] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 2.2.6 below. The rate at which members join and/or leave is also an important factor in the design of a solution. The policy regarding the access control to the multicast data exchanged on the group is a factor that can be combined with the group dynamics. This will lead to different strategies as to how keying material is distributed to members and how often this is done. The policy may indeed require that a new member not be able to read previously exchanged data. It may also require that a member leaving (forcibly or not) the group not be able to read future traffic. In both cases, new keying material must be distributed to members so that new traffic is protected (i.e. encrypted) using this new keying material. Clearly, a static group in which members have been predefined or have pre-joined the group (in the sense that they know in advance all the keying material necessary in order to receive and send traffic) is much simpler to manage from a security point of view. In traditional multicast, this is a very complex problem to solve efficiently in a scalable way. In explicit multicast, it is possible to design simple solutions as the complex scalability issue vanishes. Section 4 discusses in more detail the group dynamics aspects since these heavily influence key management strategies. 2.1.4 Group Density The distribution and size of the membership over the network greatly influence any solution that can be developed to provide security services, especially with regards to key management schemes. The problem becomes more complex as the group is widely dispersed and made of many members, since the solution must scale. This is therefore a major problem for traditional multicast. The characteristics of explicit multicast (in terms of size at least) greatly reduce the problem of designing a key management scheme for explicit multicast traffic. 2.1.5 Non-repudiation Membership management policy might require that join, leave or invite operations cannot be later on denied by a member or the GC (whether a central controller or the sender itself). The basis for such a non- repudiation service is the use of digital signatures with timestamps on join/leave/invite operations. Such a security service is not linked to the multicast scheme itself (whether traditional or explicit). Paridaens, et al Expires January 2001 [Page 6] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 2.1.6 Membership Verification An additional service may be provided to members to enable these to query and obtain the membership of the multicast group. In traditional multicast, this can become practically unfeasible as the group size increases, spreads and the exact detailed membership is no longer known by any single entity. In explicit multicast, such a service can be automatically provided if the list of receivers is left untouched in each IP datagram delivered to final destinations. If this is not the case, it would still be easy to design a simple solution whereby the GC is queried about membership. 2.2 Data Handling This section deals with security aspects linked to the explicit multicast traffic itself, between sender(s) and receiver(s) in the group. 2.2.1 Anti-replay Depending on the type of application data carried within multicast IP datagrams, a third-party may try and replay old IP traffic (hence mounting a replay attack). Anti-replay would normally be achieved by sequentially numbering every IP datagram (such as in IPsec) and protecting this sequence number with some data integrity mechanism (see 2.2.2 below). Section 3.1.2 below discusses issues with the use of IPsec to provide anti-replay. It also suggests solutions applicable to explicit multicast scenarios. 2.2.2 Data Integrity Data integrity is normally combined with authentication and is therefore discussed in the context of group and individual authentication in the following sections. 2.2.3 Group Authentication Group authentication means that receivers can ensure that the traffic comes from another group member, without necessarily being able to determine exactly which one (a mere check of the source IP address is not sufficient since this can be spoofed). One possible solution is to have a secret key shared between all members and the sender(s) that can be used to compute a MAC (Message Authentication Code) for Paridaens, et al Expires January 2001 [Page 7] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 each packet sent by the sender(s). Aspects linked to the distribution of such keying material are discussed in section 4. IPsec can be used as is to provide group authentication in traditional or explicit multicast models (apart from the problem of keying material distribution as discussed in section 4). Group authentication could be achieved via confidentiality since the ability to correctly decrypt received data indirectly shows that it was encrypted by an entity knowing the correct encryption key, hence a group member. This is however only possible if the data format is such that individual encrypted blocks cannot be successfully replaced by an attacker so that decrypted data looks correct. In such situations, separate authentication/integrity would still be required (and this is the recommended strategy). 2.2.4 Individual Authentication Individual authentication enables the receivers to ensure that the traffic comes from a particular entity (sender). This is therefore more fine-grained than the above group authentication but is much more difficult to provide since a simple shared secret is not enough. This is typically a hard problem to solve for secure multicasting in general. A solution based on digital signatures would theoretically make it but at the expense of decreased performance. In most multicast applications, such a mechanism would not stand. Considering explicit multicast, it would be practically feasible to set up a different IPsec SA (Security Association) for each sender (as discussed in section 3). Each sender would then use its own "personal" SA when sending IPsec traffic to other session members. Receivers can then determine that the traffic comes from a given sender. However, because IPsec authentication is based on shared secret key and because these are actually distributed to all receivers (to enable verification on reception), this does not guarantee individual authentication. 2.2.5 Anonymity As already mentioned in section 2.1.2 above, anonymity in explicit multicast traffic can only be provided in a limited way during the data traffic exchange. Senders know the receivers and vice-versa. Receivers would not know each other only if there is a mechanism by which other receiver addresses are removed prior to datagram relay to the final destination (such a mechanism would still need to be compatible with other security mechanisms such as data integrity Paridaens, et al Expires January 2001 [Page 8] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 covering the IP datagram). 2.2.6 Data Confidentiality Data confidentiality requires that the sender and the receivers commonly agree on a shared secret key used for traffic encryption. Issues linked to the distribution of the shared secret are further discussed in section 4 below. The major problems linked to data confidentiality are when members join or leave the group. When a new member joins the group, two situations may arise. First, the member may be allowed to see the traffic that was exchanged prior to its joining. In such a case, it is sufficient to give a copy of the current group encryption key to that new member. On the contrary, the member may be prevented from seeing the traffic previously exchanged. In that case, a new encryption key must be generated and distributed to all members for use. When a member leaves the group, the leaving member may be prevented from seeing the future traffic. It is therefore necessary to change the shared secret key used for data encryption between the remaining members. 2.2.7 Denial of Service Some forms of denial of service attacks can take advantage of the multicast characteristics to increase their "effects". Such an attack is the smurf attack whereby an ICMP Echo request (ping) is sent to a multicast address with a source address which is the target of the attack. Measures have been taken in traditional multicast schemes to forbid replies on such ICMP requests : a router or host can be configured so as to reply or not to ICMP requests with a multicast address, the Reverse Path Forwarding check is inherent traditional multicast architectures also helps in preventing such attacks. However, in explicit multicast, it can be more difficult to simply forbid it because the destination may not recognize that this is an explicit multicast IP datagram (if all other receiver IP addresses have been removed). The effect is however greatly diminished because of the small number of members. Obviously, the use of IPsec to provide confidentiality and/or authentication can diminish those risks. 3 Use of IPsec This section focuses on the possibility to use IPsec for securing Paridaens, et al Expires January 2001 [Page 9] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 explicit multicast traffic. The discussion is trying to be independent of the actual method chosen to realize the explicit multicast service, in particular how the exact list of destination IP addresses is placed in the IP datagram (e.g. new option field or new payload) and of the key management mechanism adopted (see section 4 for discussions of this aspect). 3.1 IPsec Issues 3.1.1 SPI Generation The SPI value , which is used by the IP datagram receiver to uniquely identify the SA, is chosen by the recipient itself when setting up the SA. In a multicast environment, this becomes unfeasible. If left to the sender, the choice of the SPI value should be done so by the sender that it cannot possibly conflict with SPI values chosen by other entities sending IPsec traffic to any of the receivers (given that from the receiver's point of view, the SPI value in the received IP datagram solely identifies which SA to use for processing the datagram). To overpass this problem, the rule could be that the SPI value chosen by the sender is based on unique information such as its IP address. However, this does not solve the problem if several senders exist for the multicast group : no single sender can generate the unique SPI value usable by other senders (the unique SPI value should then be distributed to other senders so that they can use it as if they were the SPI creator). Generation of the SPI value (together with the shared keying material) can be left to some designated server which then distributes this SPI value to all members for use. The set up of the multicast SA would then be under the control of this central entity rather than the sender(s), using some key distribution protocol as discussed in section 4. Another possibility is to let each sender generate and distribute the SPI value (together with the shared secret material) to every receiver. Each sender therefore creates and makes use of its own IPsec SA. This avoids problems linked to sharing an IPsec SA between several senders. This is further discussed in section 4 below. 3.1.2 Anti-replay Protection The anti-replay mechanism provided by IPsec (AH and ESP) is based on the use of a sequence number which is always set (and incremented) by the sender and may optionally be verified by the receiver. Such a mechanism does not scale when several senders would make use Paridaens, et al Expires January 2001 [Page 10] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 of the same Security Association previously set up to protect the multicast traffic. Each sender would indeed handle its own counter out of synchronization with other senders. Receivers would consequently detect duplicates by examining the sequence number in incoming IP datagrams although these would actually have been generated by different entities. A possible solution to this problem is to have the receivers take account of the couple (SPI, source IP address) when checking for duplicates, hence maintaining a separate window for each potential sender. Because explicit multicast groups are not large, this is achievable. Another possible solution would be to set up different SA's per sender. Each SPI would therefore be implicitly related to the corresponding sender. This is further discussed in section 4.2 below on key management. 3.2 AH We hereby assume that the sender makes use of a single SA (hence SPI) for all receivers. Issues and solutions to achieve this are further discussed in sections 3.1.1 and 4.2. In case several senders co- exist, it is suggested as discussed in section 4 that each sender has its own SA. The AH payload is inserted between the IP header and the IP data being carried (e.g. TCP, UDP, ICMP, ...). Its integrity protection basically covers the header source and destination IP addresses and any header option defined to be protected (whether, and how, the option is covered, is specified within the specification defining that option, together with the setting of a "mutability flag" in the context of IPv6 header options). Care must be taken when designing the mechanism to carry the list of destination IP addresses. If they are covered by AH, they cannot be modified "en-route" and transforming the explicit multicast packet into a unicast packet becomes unfeasible before reaching the final destination(s). An indirect consequence of this is that "partial" anonymity (as discussed in section 2.2.5) cannot be provided. In addition, modifications on the list of destination IP addresses may also be required "en-route" in order to reflect the current list of addresses to be routed upon (e.g. after a split of the datagram in a router). If AH covers the list, this cannot be done. One mechanism to overcome this problem would be to have a separate bitmap representing the destination IP addresses. AH would then cover the list but not the bitmap which can then be modified by routers on the Paridaens, et al Expires January 2001 [Page 11] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 way. 3.3 ESP We hereby assume that the sender makes use of a single SA (hence SPI) for all receivers. Issues and solutions to achieve this are further discussed in sections 3.1.1 and 4.2. In case several senders co- exist, it is suggested as discussed in section 4 that each sender has its own SA. The ESP payload is added after the IP header and "wraps" the IP data (e.g. TCP, UDP, ICMP, ...) being covered with ESP. Hence, the IP header and any payload placed in front of the ESP payload is left unprotected (by ESP). Because the list of destination IP addresses must be accessed by routers, this cannot logically be placed into the ESP "wrapped" data part (routers would need to go into the ESP payload to find routing information). The ESP payload would therefore not interact with the field (whether option or payload) containing the explicit multicast information. 3.4 Scenario Examples This section presents possible constructions that can be built to provide IPsec protection for explicit multicast IP datagrams. Because we do not consider any specific mechanism use for implementing explicit multicast within IP datagrams, various alternatives are discussed, including as to whether the list of receiver addresses are encoded into a new IP header option (layer 3 encoding) or a new header "above" IP (layer 3.5 encoding). 3.4.1 Layer 3 Address List Encoding A first scenario with the use of AH, described in figure 1, is to have the list of addresses "merely" in a new header option defined as mutable (so that addresses can be removed from the list on the way). The header destination address is set to some "fake" address M. AH does not cover the option field so malicious modifications can occur in there. The transport header checksum is left unchanged. +-------------------------------+ | S M | D1 D2 D3 | AH | payload | +-------------------------------+ Figure 1 A second scenario with the use of AH, described in figure 2, is to add a bitmap in the option fields. The bitmap is defined as mutable but the list of destination addresses is defined as not mutable. With this technique, the list of destination addresses is also Paridaens, et al Expires January 2001 [Page 12] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 protected by AH. +--------------------------------------+ | S M | bitmap D1 D2 D3 | AH | payload | +--------------------------------------+ Figure 2 The third scenario using AH is to tunnel the IP datagram (AH being applied within the tunnel and not outside). The list of IP destination addresses is located in the outer IP header. Only the inner IP datagram is delivered to the final host which must be xcast-aware. +-----------------------------------+ | S D1 | D2 D3 | S M | AH | payload | +-----------------------------------+ Figure 3 The fourth figure describes a possible use of ESP where the source S and (fake) destination M IP addresses are indirectly covered by the transport layer checksum (itself protected under ESP) but the list of destination IP addresses Di (in a header option) is not protected. +-------------------------------+ | S M | D1 D2 D3 | ESP(payload) | +-------------------------------+ Figure 4 The next figure illustrates the use of a bitmap together with the list of destination IP addresses Di, with ESP. This is similar to the fourth scenario above. +--------------------------------------+ | S M | bitmap D1 D2 D3 | ESP(payload) | +--------------------------------------+ Figure 5 3.4.2 Layer 3.5 Address List Encoding It is possible to encode the list of destination IP addresses into a new header "above" IP (hereby termed "xcast header") rather than an IP header option. Considerations are then broadly similar to those discussed above in section 3.4.1. Regarding the application of AH, it is worth noting that the current AH model as described in [10, 15] may be a problem for the use of a new 3.5 header in general. The whole IPsec model is indeed based on the fact that AH is applied on the whole IP datagram after it has Paridaens, et al Expires January 2001 [Page 13] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 been built (hence after the xcast header has been inserted into the IP datagram). This gives the following resulting construction. [IP] [AH] [xcast header] [app payload] Clearly, any mutable information such as a bitmap cannot be located within the xcast header but should be put into a mutable IP header option. If the xcast header is inserted after AH has been generated and placed (hence physically located before AH such as in the figure below), then it would not be protected by AH at all. [IP] [xcast header] [AH] [app payload] Regarding the use of ESP, similar considerations apply : the xcast header could technically be placed in front of the ESP payload, in which case, it would then not be protected by ESP (ESP generation and insertion into the IP datagram would have taken place before the xcast header is). If the xcast header is protected by ESP (hence located within the ESP payload), then routers would need to go into the ESP to find xcast information (which must then not be encrypted of course). Such layer 3.5 xcast header could also be a problem for the set up of policies for IPsec SA's. The actual protocol value may be further hidden by the presence of the xcast header (although this problem is already foreseen in the IPsec general architecture). 4 Key Management One important aspect in secure multicast communications is the distribution (and renewal) of the keying material to all partners There are several aspects to be considered in multicast key management. However, because we are here focusing on explicit multicast, some simple solutions can probably be considered to resolve the problems in a practical way. We first discuss three problem aspects and we then suggest solutions for key management. in an explicit multicast context. 4.1 Key Management Issues 4.1.1 Key Distribution Key distribution mechanisms where each group member contributes to the generation of the shared secret keying material do not scale very well. A scheme whereby some designated entity (a central entity or the sender) distributes the keying material to every member is Paridaens, et al Expires January 2001 [Page 14] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 therefore a better path towards a solution. Within the model under development in SmuG, such an entity (KS - Key Server) is combined with the GC and is hence termed GCKS. A scheme whereby a single GCKS is responsible for generating the keying material and distributing it to members is probably the best way. However, this requires that members fully trust the GCKS for this task. Depending on the application, the role of the GCKS (and in particular the KS aspect) can be better left to a third-party entity and not a participant such as a sender. If there are several senders however (i.e. in a n-m multicast context), the problem remains of coordinating the key generation and distribution between all the senders. One possibility is therefore to have each sender to generate and distribute its own secret material to all other potential receivers (including other senders). Because explicit multicast is dedicated to very sparse groups (up to the order of 10 members), this is practically feasible as we avoid scalability problems. If access control or confidentiality are required (one could indeed imagine a group to which anyone can subscribe but still requires subscription to read the multicast traffic), key distribution must be combined with strong member authentication (iow. keys must be distributed to authenticated members only). This is also better achieved by some designated entity. Moreover, one can benefit from the protocol used to control the access (which would usually be unicast) to authenticate and distribute the keying material. 4.1.2 Membership Dynamics Traffic confidentiality also severely impacts on the key distribution scheme when non-current members are not allowed to read the traffic. This indeed means that the keying material must be changed each time a member joins or leaves the group so as to prevent it from reading past or future traffic. 4.1.3 Security Association Negotiation Key management (initial keying material distribution, updates) naturally apply within the context of SA management (as achieved with IKE for unicast IPsec connections). Key management is however not the sole aspect of SA management, which also includes negotiating cryptographic algorithms, use of AH and/or ESP is IPsec is used, SA lifetime, ... In a 1-1 unicast context, this is "readily" achieved with a protocol such as IKE which enables two entities to negotiate services and algorithms based on their respective capabilities. In a multicast Paridaens, et al Expires January 2001 [Page 15] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 context, this becomes somewhat unfeasible and the negotiation is limited to accept or reject what the sender or GCKS imposes. In an explicit multicast context, the capabilities and policy of the (few) members could be made available in a directory (DNS, LDAP) so that sender(s) and GCKS can try and take account of everyone's desiderata as much as possible before making a final choice. 4.2 Possible Solutions 4.2.1 Manual Configuration Given the small number of members in an explicit multicast session, it is possible to manually configure each member. However, this is not very practical when the configuration needs to be updated because a member joins or leaves or because rekeying must occur after some period. 4.2.2 IPsec-based Configuration Protocol IKE is defined to provide key management for IPsec in a 1-1 unicast context. There is currently no key management protocol for n-m multicast environments. One possibility is to take advantage of the very low membership which characterizes explicit multicast together with the fact that each sender knows all the receivers. Considering each sender separately, it sets up a different IPsec connection with each receiver (this IPsec connection is built as usual using IKE since this is a 1-1 unicast "connection"). The sender then generates, on its own, the Security Association (all the necessary keying material, crypto algorithms, unique SPI value, ...). The sender distributes that material (SA parameters) to each other member safely over the individual IPsec connections (using some simple protocol). The whole keying material is therefore generated under the sole responsibility of the sender. All in all, this results in the set up of maximum nxm (unicast) IPsec connections (this number can be reduced if some senders are also receivers). 4.2.3 SIP-based Management This solution is applicable when SIP is used to create the explicit multicast session itself. SIP contains provision for carrying encrypted material using a PGP data blob for example. This functionality can be used to distribute SA parameters amongst members at the same time as the member is being invited using SIP. With this method, a single SA can be created (under the control of a SIP Paridaens, et al Expires January 2001 [Page 16] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 server) and made known to all members. It also becomes difficult to update the SA since SIP is normally used once at the beginning (and once when leaving the session but the remaining members are not contacted then). 4.2.4 New IKE Phase 2 Exchange Type This is a variant of the scenario described in 4.2.2 above. Considering each sender separately, it sets up a unicast IKE connection (IKE phase 1) with each other member. A new exchange type for phase 2 is defined that enables the sender to distribute ("push") the SA parameters to the other side (ie. other members). Each sender generates a single SA that will be distributed to all other members. 5 Security Considerations This whole memo is about security considerations. References [1] Canetti et al, "A taxonomy of multicast security issues", draft-irtf-smug-taxonomy-01.txt, April 1999. [2] Hardjono et al, "Secure IP Multicast : Problem areas, Framework and Building Blocks", draft-irtf-smugframework-00.txt, November 1999. [3] Canetti et al, "An Architecture for Secure Internet Multicast", draft-irtf-smug-sec-mcast-arch-00.txt, February 1999. [4] Harney et al, "GKM Building Block : Group Security Association (GSA) Definition", draft-irtf-smug-gkmbbgsadef-00.txt, February 2000. [5] Ballardie, "Scalable Multicast Key Distribution", RFC 1949, May 1996. [6] Wallner et al, "Key Management for Multicast : Issues and Archi- tectures", RFC 2627, June 1999. [7] Moyer et al, "Maintaining Balanced Key Trees for Secure Multi- cast", draft-irtf-smug-key-tree-balance00.txt, June 1999. [8] Harney et al, "Group Key Management Protocol (GKMP) Specifica- tion", RFC 2093, July 1997. [9] Harney et al, "Group Key Management Protocol (GKMP) Paridaens, et al Expires January 2001 [Page 17] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 Architecture", RFC 2094, July 1997. [10] Kent et al, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [11] Ooms et al, "Connectionless Multicast", draft-ooms-cl- multicast-02.txt, April 2000. [12] Boivie et al, "Small Group Multicast", draft-boivie-sgm-00.txt, March 2000. [13] Imai, "Multiple Destination option in IPv6 (MDO6)", draft-imai- mdo6-01.txt, March 2000. [14] http://www.alcatel.com/xcast [15] Kent et al, "IP Authentication Header", RFC 2402, November 1998. Authors' Addresses Olivier Paridaens Universite Libre de Bruxelles, Service Telematique et Communication Bd du Triomphe, CP230 B-1050 Brussels Belgium Phone : +32 (0)2 6505703 Email : paridaens@helios.iihe.ac.be Dirk Ooms Alcatel Fr. Wellensplein, 1 B-2018 Antwerpen Belgium Phone : +32 (0)3 2404732 E-mail : Dirk.Ooms@alcatel.be Bernard Sales Alcatel Fr. Wellensplein, 1 B-2018 Antwerpen Belgium Phone : +32 (0)3 2409574 E-mail : Bernard.Sales@alcatel.be Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to Paridaens, et al Expires January 2001 [Page 18] Internet Draft draft-paridaens-xcast-sec-framework-00.txt July 2000 others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Paridaens, et al Expires January 2001 [Page 19]