INTERNET DRAFT O. Paridaens <draft-paridaens-xcast-sec-framework-01.txt> D. Ooms B. Sales Alcatel November, 2000 Expires May, 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 as described in [16]. 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]. 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 [16]). 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]. A corresponding IETF WG may also probably be setup in the near future. 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 [16] 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 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 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. 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 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). 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 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 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 explicit multicast traffic. The discussion relates to the xcast encoding methods described in [16]. 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 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). 3.2.1 Xcast4 If AH is applied after the Xcast4 header has been placed in the IPv4 datagram, which corresponds to the common understanding of applying IPsec on the whole IP datagram once it has been built, the whole Xcast4 header is covered by AH. This gives the following resulting construction. [IP] [AH] [Xcast4] [app payload] As such, no modification can be brought to the Xcast4 fields by intermediate routers. IPsec defines the possibility to define IPv4 header options as mutable, hence providing a way to avoid calculating AH over such options. However, this only applies to header options, not to payloads carried within the IP datagram. Consequently, current IPsec implementations would be incompatible with the Xcast4 encoding described in [16]. It is also worth noting that intermediate routers must be able to skip the AH payload before getting to the routing information (ie the Xcast4 payload). Indeed, in normal situations (without AH), the Xcast4 payload will be located directly after the IP header. When AH has been applied, the Xcast4 payload is no longer located after the IP header but after the AH payload, which the router must skip to jump to reach the Xcast4 payload. Note that for currently implemented AH algorithms (MD5 and SHA1), the AH payload length is the same and fixed (24 bytes). Another scenario would be to apply Xcast4 after IPsec as described in the following construction. [IP] [Xcast4] [AH] [app payload] This would break the IP implementation model and would anyway not really make sense: the destination addresses must be provided before IPsec can be applied since the IPsec SA applied depends on the destination addresses. It would also require modifications to the IPsec implementation module itself (to ensure that the preceding Xcast4 payload does not bring trouble to the IPsec module). It can be noted that a solution to the above problem would be to separate the bitmap field from the Xcast4 payload and place the bitmap into a (mutable) IPv4 option. Whatever solution is finally adopted, it appears that anonymity cannot be provided if AH is being applied to the IP datagram. It would indeed require to also leave the list of addresses out of the AH coverage, which would leave no useful information in the Xcast4 payload to be covered by AH. Hence, if anonymity is required, AH should not be used (or at least AH should not protect the Xcast4 payload at all). 3.2.2 Xcast6 In the context of IPv6, [16] defines two new header extensions: the Routing extension and the Destination extension. The Routing extension must be flagged as mutable since the bitmap field in it changes on the way. It is worth noting that the extension option type and length subfields are covered by AH: only the option data subfield is considered as a stream of '00'H bytes. The use of AH together with anonymity is then possible since anonymity sets zero bytes into the list of destination addresses (hence the length is not changed). The receiver can still however determine the number of destinations. The Destination extension can be flagged non-mutable and covered by AH. In case of anonymity, the list of port numbers does not bring relevant information on destinations, except for the number of destinations. As in the case of Xcast4, it could be considered to separate the bitmap field and make it a (mutable) separate extension. This would enable to use AH to cover the (non-mutable) Routing extension containing the list of destination addresses. 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. 3.3.1 Xcast4 In the commonly understood IPsec model, the ESP payload is added after the IP header and "wraps" the IP data (e.g. TCP, UDP, ICMP, ...) being covered with ESP. The following construction illustrates this scenario. [IP] [ESP [Xcast4] [app payload] ] Hence, the IP header and any payload placed in front of the ESP payload is left unprotected (by ESP). Such a construction is not a valid solution. Because the list of destination IP addresses must be accessed by routers, the Xcast4 payload cannot logically be placed into the ESP "wrapped" data part (routers would need to go into the ESP payload to find routing information). Moreover, the Xcast4 payload may be simply unreadable to routers if ESP provides encryption. Another scenario would be to apply IPsec before Xcast4. The ESP payload would therefore not interact with the field (whether option or payload) containing the explicit multicast information since this latter would appear before the ESP payload, as illustrated in the schema below. [IP] [Xcast4] [ESP [app payload] ] However, this would somewhat break the IP implementation model for the same reasons given in 3.2.1. 3.3.2 Xcast6 In the context of IPv6, [16] defines two new header extensions: the HBHorRouting extension and the Destination extension. Since ESP does not cover the IPv6 header, there is no interaction betwen ESP and Xcast6. 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 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 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 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 Architectures", RFC 2627, June 1999. [7] Moyer et al, "Maintaining Balanced Key Trees for Secure Multicast", draft-irtf-smug-key-tree-balance00.txt, June 1999. [8] Harney et al, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997. [9] Harney et al, "Group Key Management Protocol (GKMP) 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. [16] Ooms et al, "Explicit Multicast (Xcast) Basic Specification", draft-ooms-xcast-basic-spec-00.txt, December 2000. Authors' Addresses Olivier Paridaens Alcatel Fr. Wellensplein, 1 B-2018 Antwerpen Belgium Phone : +32 (0)3 2409320 E-mail : Olivier.Paridaens@alcatel.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 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 document 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 developing 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."