INTERNET DRAFT A. Van Moffaert O. Paridaens Alcatel December, 2001 Expires June, 2002 Security issues in Protocol Independent Multicast - Sparse Mode (PIM-SM). 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 points out a number of security issues in PIM-SM. Table of Contents 1. Introduction 2. Terminology 3. Security Issues in PIM-SM 3.1 Authentication of Link-local Messages 3.2 Authentication of Unicast Messages 3.3 Authentication of Bootstrap Messages 4. Key exchange mechanism for multi-party Security Associations 5. Security Considerations 6. Conclusions Van Moffaert Expires June 2002 [Page 1] Internet Draft draft-annelies-00.txt December 2001 1. Introduction Protocol Independent Multicast - Sparse Mode (PIM-SM) is described in the draft [PIM-SM]. In the latest version of this draft the authors elaborated the section with security considerations. That section contains an overview of possible attacks that are based on forged PIM control messages and describes optional and recommended authentication mechanisms. IPsec AH is recommended for message authentication and additionally a number of other non-cryptographic authentication mechanisms are described. The multi-party aspect of PIM-SM control messages introduces however special problems to apply IPsec AH and/or to set up the required Security Associations (SAs). These problems are not (completely) addressed in the internet draft [PIM-SM]. Secondly authentication of Bootstrap messages (BSMs) is not treated in [PIM-SM] nor in [PIM- BSR]. This document discusses these issues and proposes possible solutions. 2. Terminology The terminology of [PIM-SM], [PIM-BSR], [AH], [ESP], [IKE] and [ISAKMP] applies to this document. 3. Security Issues in PIM-SM The draft [PIM-SM] recommends the use of IPsec AH in transport mode to authenticate PIM-SM messages and the anti-replay option SHOULD be enabled. We keep the structure of section 6.3 of [PIM-SM]. 3.1 Authentication of Link-local Messages The link-local PIM messages are Hello, Join/Prune and Assert messages and are all sent with IP destination address 224.0.0.13 the all-PIM- routers group. In [PIM-SM] a single IPsec SA is used for authentication of all link-local messages on a link. They further state that the anti-replay option provided by IPsec SHOULD be enabled. This anti-replay mechanism runs however into trouble when more than one sender uses the same SA. The anti-replay mechanism provided by IPsec is based on a sequence number and a sliding window at the receiver side. The originating IPsec entity includes a sequence number in the IPsec AH. At the other side of the connection the receiver uses an anti-replay window. The "right" edge of the window represents the highest validated sequence number value received on this SA. Packets that contain a sequence number lower than the "left" edge of the window are rejected. Packets falling Van Moffaert Expires June 2002 [Page 2] Internet Draft draft-annelies-00.txt December 2001 within the window are checked against a list of received packets within the window. Packets with a sequence number that has been received before are also discarded. When a packet is received with a higher sequence number than the "right" edge of the window then the window is advanced so that the "right" edge coincides afterwards with that new highest received sequence number value. The combination of such a sequence number-based anti-replay mechanism with a situation with multiple senders per SA causes problems resulting into legitimate packets being dropped. Different senders will each use their own sequence number counter and hence sequence number collisions will occur. Furthermore, sequence number counters from different senders are likely to differ by an amount higher than the window used in the anti-replay mechanism of the receiver which also leads to legitimate packets being discarded. The situation described above where more than one PIM entity sends packets to the same address on a link is very common. More precisely, it occurs whenever more than two PIM routers are present on a shared subnet. The problem does not occur if the IPsec anti-replay option is disabled but then one looses all protection against replay attacks. The only solution that protects against message replay and that does not require any changes to IPsec AH is to use a different SA for each sender, i.e., to use a SA per (sender, group) pair. We see two other solutions that would however require modifications to the IPsec protocol. The first is to replace the sequence number by a timestamp. This would bring in the problem of clock synchronization between the different entities. This seems however feasible for IGMP since all entities belong to the same subnet. Secondly the clocks should have a sufficient fine granularity to avoid having two messages (from different senders) with the same timestamp. A second solution that also requires a modification to the IPsec protocol is the use of one SA per group address but possibly more than one anti-replay window per SA. Receivers should then keep track of a separate sequence number window and a separate list of received packet in that window per (SA, sender) pair. Note that this option works with IPsec AH but should not be used with Ipsec ESP authentication. Since the authentication value in ESP does not protect the source IP address, an old packet could be replayed with another (possibly spoofed) source IP address. A problem that remains however is how to set up these SAs since IKE the standard protocol to set up IPsec SAs is essentially peer-to-peer and cannot be used to set up SAs between a sender and multiple Van Moffaert Expires June 2002 [Page 3] Internet Draft draft-annelies-00.txt December 2001 receivers. One possibility is to manually set up the PIM SAs on a shared subnet through a secured channel between the network administrator and the PIM routers. This is a solution that works today and does not require any new key exchange protocol. It is however not very practical nor scalable. In section 4 we therefore propose a new key exchange mechanism based on [GDOI] to set up SAs between more than 2 parties. 3.2 Authentication of Unicast Messages PIM unicast messages are the Register and Register-Stop messages exchanged between the Designated Router (DR) of a multicast source and the Rendez-vous Point (RP) of the domain. To authenticate unicast PIM messages standard IPsec AH can be used as described in [PIM-SM] section 6.3.2. Standard IKE could be used to set up SAs in an automated fashion. In [PIN-SM] the authors assume manual configuration of IPsec SAs. They do not preclude automatic SA configuration if this is supported by a protocol. Using IKE rather than manual configuration could simplify the task of the network administrator. IKE phase 1 authentication could be done using a pre-shared secret, certainly in PIM domains that are under a single administrative control. This pre-shared secret is only used in IKE phase 1 and it must only be updated after a much longer time than IPsec authentication keys. 3.3 Authentication of Bootstrap Messages PIM bootstrap messages are created by an elected Bootstrap Router (BSR). They are sent with TTL = 1 to the all PIM routers multicast address 224.0.0.13 and are then flooded hop-by-hop throughout the domain. They contain information that allows routers to map multicast group addresses to RPs. Bootstrap information is stored in all PIM routers. It is important for PIM routers to know that a Bootstrap message was indeed created by the legal BSR and that it was not changed on its path. With the symmetric authentication option provided by IPsec only hop-by-hop authentication can be achieved. This means that a router that receives a Bootstrap message only knows that it came from an authenticated PIM router in the domain but it can make no distinction between ordinary PIM routers and the BSR. Furthermore, the relaying mechanism in which each intermediate router forwards the Bootstrap message as the payload of a new IP packet with TTL = 1 and the router's own IP address as source address, precludes end-to-end authentication at the IP level. Van Moffaert Expires June 2002 [Page 4] Internet Draft draft-annelies-00.txt December 2001 The only way to distinguish between an authorized sender (the BSR) and authorized receivers that should be able to check the validity of a message without being able to produce valid messages themselves (the PIM routers), is via a digital signature mechanism. Due to the hop-by-hop mechanism the most natural level to include such a signature would be the PIM level. In that case the bootstrap message including the signature is relayed hop-by-hop as payload of hop-by- hop created IP packets. This requires a modification of the PIM bootstrap specification. Apart from a digital signature extension for Bootstrap messages, a keying mechanism is also needed to make sure that all PIM routers have a valid copy of the public key of the BSR which can be updated regularly or when necessary. All candidate BSRs in a domain could share an RSA key pair (SKbsr,PKbsr) as is e.g. suggested in [SKMP]. The public key PKbsr could be manually configured in every PIM router and the key pair (PKbsr,SKbsr) in every C-BSR or the key pair could be periodically updated by a domain key distributor and then communicated to the relevant entities (as is described in [SKMP]). The draft [SKMP] proposes such a key management mechanism, however as part of IPsec AH. We think however that it should be done at the PIM rather than at the IP level. First, IPsec AH does not provide the possibility to use digital signatures for authentication but secondly and more importantly, a new IP packet is created in every router that relays the Bootstrap message. The digital signature authentication should hence be done at the PIM level such that the signature produced by the BSR is part of the IP payload and is hence flooded together with the Bootstrap message. 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.1 above 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 a PIM context every PIM router Van Moffaert Expires June 2002 [Page 5] Internet Draft draft-annelies-00.txt December 2001 authenticates to this central control entity via standard IKE phase 1 (peer-to-peer). This could be done using a preshared secret, certainly when all entities are under the same administrative control. Note that this preshared secret is a different one for every PIM entity. Every PIM entity shares its own secrets with the GCKS in a peer-to-peer relation. The PIM router initiates the second step by identifying the group it wants to join to the GCKS. This is done via an extended ISAKMP Identification payload. The group address is for a PIM router typically the all PIM routers group, 224.0.0.13 to which PIM link-local messages are sent. The GCKS then pushes the existing IPsec SAs for that group (including security protocol, crypto algorithms, parameters etc) together with the present value of the sequence number. Note that since the SA has already been used before the new PIM router joined, the joining PIM router needs to know the current value of the sequence number. This phase 2 SA (called category 3 in [GDOI]) is used to authenticate link-local PIM 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. For every SA the current value of the sequence number is included in the message of the GCKS. In the first data packet it receives, the new member must accept any value that is larger than the received sequence number value and then update its counter accordingly. 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. The GCKS then pushes the new SA to the requesting entity (to e.g. the PIM router) 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 PIM 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 Van Moffaert Expires June 2002 [Page 6] Internet Draft draft-annelies-00.txt December 2001 that a seperate SA is created per (sender,group) pair rather than per group. As explained in section 3.1 this is done to avoid modifications to IPsec. 5. Security Considerations This whole memo is about security considerations. 6. Conclusions We discussed in this report some security issues that are not addressed in [PIM-SM]. First the anti-replay mechanism provided by IPsec and recommended in [PIM-SM] can run into problems when it is applied to PIM messages due to the multi-party aspect of some of these messages. We explained how this can be avoided without changing IPsec. Secondly we noted that IKE cannot be used to set up SAs that are shared by more than 2 parties and we proposed a key exchange mechanism based on GDOI that can be used to automatically set up multi-party SAs. References [PIM-SM]B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specifi- cation (Revised)", draft-ietf-pim-sm-v2-new-03.text, July 2001. [PIM-BSR]B. Fenner, M. Handley, R. Kermode, D. Thaler, "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr- 01.txt, July 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 Van Moffaert Expires June 2002 [Page 7] Internet Draft draft-annelies-00.txt December 2001 of Interpretation", draft-ietf-msec-gdoi-01.txt, July 2001 [SKMP] T. Hardjono, B. Cain, "Simple Key Management Protocol", draft- ietf-pim-simplekmp-01.txt, Februari 2000 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 June 2002 [Page 8]