INTERNET DRAFT A. Van Moffaert O. Paridaens Alcatel February, 2002 Expires August, 2002 Security issues in Internet Group Management Protocol version 3 (IGMPv3). Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 discusses security aspects in IGMPv3 the protocol used by hosts and routers to communicate their multicast group membership. A number of security issues are identified for which a possible solution is proposed. Table of Contents 1. Introduction 2. Terminology 3. Security Issues in IGMPv3 3.1 Authentication of Genral Query and Reort Messages 3.2 Authentication of Group- and Group-and-Source-Specific Queries 4. Key exchange mechanism for multi-party security association 5. Security Considerations Van Moffaert Expires August 2002 [Page 1] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 6. Conclusions Changes with respect to version .00 Some minor corrections were made in section 4 with respect to sequence numbers in GDOI. 1. Introduction Internet Group Management Protocol version 3 (IGMPv3) is described in [IGMPv3]. IGMP is the protocol used by IPv4 systems to report their IP multicast membership to neighboring multicast routers. The standard document [IGMPv3] has a section with security consideration which consists of a part on IPsec Authentication Header (IPsec AH) to authenticate IGMPv3 messages and a part (the larger part) that describes the ramifications of forged messages of each type. The multi-party aspect of IGMPv3 control messages introduces however problems to apply IPsec AH and/or to set up the required Security Associations (SAs). These problems are not addressed in the internet draft [IGMPv3]. This document discusses these issues and proposes possible solutions. Section 3 discusses the different possibilitites and encountered problems to use Ipsec AH to authenticate IGMP messages. These messages are often sent to more than one receiver and more than one sender can send messages to the same group address. A decision has to be made whether all messages sent to the same group will be protected by a single SA or whether multiple SAs will be used per group. Section 3 discusses the possibility of one SA per group and that of one SA per group and per sender i.e. per (group, sender) pair. Section 4 addresses the problems to set up SAs automatically when these SAs must be shared between more than two parties. IKE the standard protocol to set up SAs in an automatic fashion is essentially a peer-to-peer protocol that does not support the set up of a SA between more than two parties. One solution is to configure the necessary SAs manually but this is neither practical nor scalable. Section 4 proposes a way to automatically set up multi- party SAs. The proposed mechanism builds further on Group Domain of Interpretation (GDOI) a group key management protocol proposed in [GDOI]. 2. Terminology The terminology of [IGMPv3], [AH], [ESP], [IKE], [ISAKMP] and [GDOI] Van Moffaert Expires August 2002 [Page 2] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 applies to this document. 3. Security Issues in IGMPv3 In this section we discuss the IPsec related part of the security section in [IGMPv3], we outline the problems we see with the combination of IGMPv3, IPsec and IKE as they exist today to authenticate IGMP messages and we propose possible solutions. In the draft [IGMPv3] confidentiality is not mentioned. Although in most cases confidentiality will not be needed for IGMP messages, encryption of report messages could be used to protect user's identities and user membership information on the local subnet. 3.1 Authentication of General Query and Report Messages In section 9 of [IGMPv3] the authors advise to use IPsec AH to authenticate messages that are sent to the IP addresses 224.0.0.1 and 224.0.0.22, i.e. General Query and Report messages. It is further stated that there are 2 options, symmetric key authentication or digital signature authentication. For digital signature authentication [IGMPv3] simply mentions that an appropriate key management standard should be developed. Let us note here that for symmetric authentication also IPsec ESP with authentication could be used. 3.1.1 Digital signature authentication It should be noted that IPsec AH does not support digital signatures, regardless whether an appropriate key management standard (i.e. a PKI) is available or not. Since IGMPv3 messages are restricted to local subnets it should be possible to manually configure on each entity the public keys of all other entities on the subnet. However there is some protocol required to implement the digital signature mechanism. This could either be an extension to IPsec or it could be incorporated in the IGMPv3 protocol but it exists for the moment in neither. Hence authentication of General Query and Report messages via digital signatures is a theoretical option but it needs an extension of the IGMPv3 protocol or of IPsec to be of practical use. 3.1.2 Symmetric authentication Apart from digital signatures [IGMPv3] mentions symmetric authentication with a single key per LAN or a key for each group. Van Moffaert Expires August 2002 [Page 3] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 However the document does not specify how this should be worked out at the level of IPsec Security Associations (SAs) nor at that of key management. With symmetric authentication mechanisms there is no knowledge difference between senders and receivers. In other words, an entity that is able to check the valitidy of a received message is also able to create valid messages itself. This means that all participating IGMP entities must trust each other. An IGMP host that receives a Query message with a valid authentication value cannot know e.g. whether this Query really came from the Querier or from another host impersonating the Querier. Since IGMP messages are bound to local subnets, manual configuration of SAs including cryptographic keys, is probably the easiest option although it is not very practical on large or dynamically changing subnets. IKE the standard protocol to set up (peer-to-peer) IPsec SAs in an automated fashion, cannot be used for multi-party communication. General Query messages are e.g. typically multi-party messages since they are sent to all IGMP hosts on the subnet. In section 4 we propose a mechanism to automatically set up multi- party SAs but we will first examine the possibility to use IPsec AH with manually configured SAs. 3.1.2.1 One security association per group IPsec SAs are identified by the triplet SPI (an SA identifier), protocol (e.g. IPsec AH) and destination IP address. Hence, messages sent to different groups (i.e. to different IP destination addresses) cannot be secured using the same security association. When the SAs are configured manually on all the IGMP hosts and routers there can be a single key for the LAN or a different key (and possibly a different authentication algorithm) for each group (both are mentioned in the IGMP document [IGMPv3] without however referring to SAs). IPsec has an optional replay prevention mechanism based on sequence numbers. When this replay prevention mechanism is used, the IPsec peers keep track of a sequence number window per SA. Incoming packets with a sequence number that has been received before or with a sequence number that falls out of the window are discarded. When multiple senders use the same SA, this replay mechanism runs into problems. Every sender keeps track of its own sequence number counter but sequence numbers of different senders are not correlated. Hence, it is possible that different sources use the same sequence number or use sequence numbers that do not fall in the same window. In both cases the receiver will discard valid packets. As this replay Van Moffaert Expires August 2002 [Page 4] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 mechanism is optional in IPsec, it could be disabled to avoid these problems however then the security level is doubtful as there is then no protection against packet replay. Using one SA per group is therefore dissuaded from for groups with more than one sender. In the next subsection we consider the possibility to use a separate SA per (sender,group) pair. 3.1.2.2 One security association per group and per sender To avoid the problems with the replay prevention mechanism explained above, a network manager can configure a SA per group and per sender. In this case a different sequence number window is kept for every sender. This leads of course to a lot more SAs to be configured (e.g. IGMP routers will have one incoming SA for every IGMP host on the subnet) but it is the only possibility that does not require modifications to IPsec. 3.2 Authentication of Group- and Group-and-Source-Specific Queries Authentication of Group- and Group-and-Source-Specific Queries is not mentioned in [IGMPv3] although it is explained how forged Group- and Group-and-Source-Specific Queries can be used to mount a DoS attack. Group- and Group-and-Source specific Queries are sent with the multicast group address as IP destination address. Since a SA is identified by the destination IP address (among others) and since a network manager can in general not a priori know which groups the hosts will join, manual configuration of SAs is in most cases quasi impossible for authentication of Group- and Group-and-Source-specific Queries. On the other hand, since Group- and Group-and-Source- specific Queries are sent to all hosts on the subnet that joined that Group, i.e. to multiple receivers, also IKE cannot be used to establish the SAs. Hence, a new key exchange protocol suited to set up multiparty SAs, is needed. In section 4 we propose a possible solution which is inspired by the work done in the MSEC working group of the IETF (see [GDOI]). 3.3 Privacy Privacy concerns are not mentioned in the draft [IGMPv3]. IPsec ESP with encryption with a SA per group and per sender could be used to hide membership information from other hosts on the subnet. Every host on the subnet reports its group memberships in IGMP Report messages sent to the IGMP routers group address 224.0.0.22. To hide Van Moffaert Expires August 2002 [Page 5] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 this information from other hosts on the subnet, Ipsec ESP with encryption could be used to protect the Report messages. In this case there would be a separate SA (and key) per host. This SA is shared between the host (as outgoing SA) and the IGMP routers on the subnet. For the IGMP routers it is an incoming SA. Note that since Current- State Records are sent in response to Group- or Group-and-Source- Specific Queries, membership info could be deduced by observing the source IP addresses of responses to Group- and Group-and-Source- Specific Queries. These IP addresses stay in the clear also when ESP with encryption is used. However, Report messages are not sent immediately after a Query is received but rather when a certain timer expires. Hence, the information revealed by the source IP address of Report messages is very limited when ESP with encryption is used. The same problems as for IPsec AH SAs remain to set up the IPsec ESP SA. 4. Key exchange mechanism for multi-party security associations Group Domain of Interpretation (GDOI) described in the draft [GDOI]) is a group security association management protocol that was developed in the context of the IRTF GSEC and IETF MSEC working group to protect multicast data traffic in large dynamic groups. The GDOI draft does not completely match the needs described in section 3 but a subset of the specification can be used to add new receivers to existing groups and to push an existing SA to a new receiver. What lacks --for our purposes-- in GDOI is the possibility for an entity to join a group as a sender. The mechanism described in the rest of this section to set up multi-party IPsec SAs is based on GDOI but we propose some extensions to allow entities to join an existing group as a sender. GDOI assumes the existence of a central control entity, the Group Controller and Key Server (GCKS). In an IGMPv3 context every IGMP entity authenticates to this central control entity via standard IKE phase 1 (peer-to-peer). This could be done using a preshared secret since all entities are on the same subnet. Note that this preshared secret is a different one for every IGMP entity. Every IGMP entity shares its own secret with the GCKS in a peer-to-peer relation. The IGMP entity initiates the second step by identifying the group it wants to join(as a receiver) to the GCKS. This is done via an extended ISAKMP Identification payload. Group addresses are for an IGMP host typically the all system multicast address 224.0.0.1 to which General Queries are sent and the IP addresses of the multicast groups the host wants to join since to the latter addresses the Group(-and-Source)-Specific Queries are sent. For an IGMP router it is e.g. the all IGMPv3 routers group 224.0.0.22 to which Report messages are sent. The GCKS then pushes the existing IPsec SAs for Van Moffaert Expires August 2002 [Page 6] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 those groups (including security protocol, crypto algorithms, parameters etc). This phase 2 SA (called category 3 in [GDOI]) is used to authenticate (and possibly encrypt) IGMPv3 control messages. As in standard IKE, the second step is performed under the protection of the previously established IKE phase 1 SA. We propose the following modifications to GDOI. When an entity initiates a phase 2 or category 3 (in [GDOI] terminology) negotiation, it specifies apart from the group it wants to join also whether it wants to join that group as a sender or as a receiver. If it is as a sender then a new IPsec SA has to be created. To a new receiver, the GCKS pushes all existing SAs for that group address using the mechanism of GDOI. When an entity announces itself as a new sender for a multicast group address, the GCKS creates a new SA for the combination (sender, multicast address). To this end, the GCKS chooses an SPI value that did not exist yet for that group address and fixes the security protocol, cryptographic algorithms, parameters etc according to a pre-configured security policy. We propose that such a policy is determined based on group address and e.g. port number or protocol carried above IP. This should allow different policies for different classes of messages that are sent to the same destination IP address. Group-Specific IGMP Queries can e.g. have a different policy than multicast data messages that are sent to the same group address. The GCKS then pushes the new SA to the requesting entity (to e.g. the IGMPv3 router or host) and to all possible other entities that are registered as receivers at the GCKS for this group address. Note that the GCKS must keep track of group membership. The mechanism described here is of course not restricted to IGMPv3 control messages but could be used to set up multi-party IPsec SAs to protect any type of message that is sent to multiple receivers. Note that a seperate SA is created per (sender,group) pair rather than per group. As explained in section 3 this is done to avoid problems with the anti-replay mechanism of IPsec without modifications to IPsec. 5. Security Considerations This whole memo is about security considerations. 6. Conclusions The draft [IGMPv3] recommends to use IPsec AH to authenticate IGMPv3 messages but further details are omitted. In this document we Van Moffaert Expires August 2002 [Page 7] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 explained how the anti-replay mechanism of IPsec AH can run into troubles when it is applied to IGMP messages due to the multi-party aspect of IGMP messages. We explained how these problems can be avoided without changing the IPsec protocol. Secondly we noted that IKE cannot be used to automatically set up SAs that are shared by more than two parties. We further explained why a mechanism to set up SAs in an automated fashion (rather than manually configure them) is important to secure IGMP messages. Finally GDOI was taken as the starting point of a proposed mechanism to automatically set up multi-party SAs. References [IGMPv3]B. Cain, B. Fenner, I. Kouvelas, A. Thyagarajan, "Internet Group Management Protocol, Version 3", draft-ietf-idmr-igmp-v3-07.txt, March 2001. [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange" , RFC2409, November 1998. [ISAKMP]D. Maughan, M Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC2408, November 1998. [AH] S. Kent, R. Atkinson, "IP Authentication Header (AH)", RFC2402, November 1998. [ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [GDOI] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group Domain of Interpretation", draft-ietf-msec-gdoi-01.txt, July 2001 Authors' Addresses Annelies Van Moffaert Alcatel Fr. Wellesplein 1, 2018 Antwerp, Belgium E-mail: annelies.van_moffaert@alcatel.be Olivier Paridaens Alcatel Fr. Wellesplein 1, 2018 Antwerp, Belgium E-mail: olivier.paridaens@alcatel.be Van Moffaert Expires August 2002 [Page 8] Internet Draftdraft-irtf-gsec-igmpv3-security-issues-01.txtFebruary 2002 Van Moffaert Expires August 2002 [Page 9]