idnits 2.17.00 (12 Aug 2021) /tmp/idnits21256/draft-irtf-smug-gsadef-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 259: '...ll multicast receivers are REQUIRED to...' RFC 2119 keyword, line 268: '... GSA: The sender MUST choose the time ...' RFC 2119 keyword, line 272: '...eceivers are NOT REQUIRED to track the...' RFC 2119 keyword, line 279: '...rs and receivers MUST support transpor...' RFC 2119 keyword, line 281: '... [KA98a]. They are NOT REQUIRED to support iterated tunneling....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 25, 1999) is 8298 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-ipsec-intragkm-00 -- Possible downref: Normative reference to a draft: ref. 'HCM98' ** Obsolete normative reference: RFC 2401 (ref. 'KA98a') (Obsoleted by RFC 4301) == Outdated reference: draft-ietf-idmr-igmp-v3 has been published as RFC 3376 -- Possible downref: Normative reference to a draft: ref. 'CCP99' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Indermohan Monga 2 INTERNET-DRAFT Thomas Hardjono 3 draft-irtf-smug-gsadef-00.txt Nortel Networks 4 February 25, 1999 Expires August 25, 1999 6 Group Security Association (GSA) Definition for IP Multicast 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document provides a definition of the Group Security 34 Association (GSA) for IP multicast, derived from the Security 35 Association (SA) definition for unicast. The document describes the 36 motivations of a GSA and other issues related to the GSA usage in 37 the context of the existing IPsec implementations. 39 1. Introduction 41 The current document delves into the issue of the use of IPsec 42 [KA98a] security associations (SA) in the context of IP multicast. 43 Unlike the traditional unicast IPsec, multicast groups can have one 44 or more senders, and one or more receivers. In the unicast IPsec, 45 the SA parameters are negotiated between the sender and the 46 receiver, where the receiver selects the Security Parameters Index 47 (SPI) that make-up the SA. 49 The concept of an IPsec Security Association cannot be easily mapped 50 without modifications to the multicast environment due the nature of 51 group-oriented communications. As an example, in the unicast case 52 it is the receiver that selects the SPI related to that instance of 53 communications. In multicast, however, there can be more than one 54 receiver, and hence arises the issue of who selects the SPI. 56 In the remainder of the document we present the concepts and 57 motivations underlying the current proposal for a GSA aimed at the 58 1-to-Many multicast. Other issues related to the 1-to-Many and 59 Many-to-Many multicast, and issues specific to a "Multicast IPsec" 60 (MIPsec) are also discussed. 62 2. Multicast Security Associations: Concept 64 The concept of multicast Security Associations was introduced in the 65 Security Architecture document of [KA98a] and further elucidated in 66 the group key management proposal of [HCM98]. The idea is that 67 unlike security associations for one-to-one unicast communications, 68 the security association for a collection of communicating entities 69 will be shared by more than two entities. Hence the notion of a 70 "Group" Security Association (GSA). In the current document we 71 focus on the unidirectional 1-to-Many (1-to-M) multicast 72 applications type, since it represents the simplest group 73 communications behavior. This does not preclude further 74 developments to address the Many-to-Many multicast application type. 76 In the current document we propose the design and composition of a 77 GSA that will make most use of the previous unicast Security 78 Association (SA) definition of [KA98a] for one-to-one 79 communications. The motivation behind this philosophy is to allow 80 the existing developments of IPsec to be employed for IP multicast 81 with minimum modification. 83 Unlike the security association in unicast communications where a 84 well-defined entity (eg. the receiver) selects some of the 85 parameters (eg. algorithm, security parameters index or SPI) that 86 make-up the security association, in multicast groups consisting of 87 multiple senders and receivers there is need for a single entity to 88 choose the parameters that make-up the group security association 89 (GSA). 91 In the current document we propose that the security parameter index 92 (SPI) of the GSA for a 1-to-Many multicast be selected by an entity 93 involved in the initial steps of the multicast group creation and 94 group key management. The SA parameters are either chosen by the 95 sender or are well known fixed properties of the group. For example, 96 a multicast group A.B.C.D started by a sender E.F.G.H might have 97 fixed security characteristics of 3DES encryption with MD5 98 authentication. 100 Two possible entities can be defined to select the SPI and/or the 101 group-key: 102 (a) The single sender in the 1-to-Many multicast 103 (b) A key-management entity, such as the Domain Key 104 Distributor (DKD) in [HCM98]. 105 Regardless of which entity selects the SPI and the group-key, one 106 fundamental issue that remains is the dissemination of the selected 107 parameters to the other members (receivers) of the multicast group. 109 Since the key-management entities involved in the group-key 110 management (GKM) protocol will be disseminating the group-key to the 111 group members, we relegate the task of disseminating the GSA to 112 these same entities, either through (or part of) the same GKM 113 protocol or through a different GSA distribution protocol executed 114 by these entities. 116 3. GSA for Multicast 118 The current work proposes a definition of a GSA based on the source 119 IP address. A GSA will be uniquely identified by the tuple (source 120 IP address, SPI and protocol). 122 This mirrors the tuple (destination IP address, SPI and protocol) 123 used to uniquely identify unicast SAs (USA). 125 There are a number motivating reasons for using the source IP 126 address in a GSA: 128 1. The current work seeks to address the demand today for IP 129 multicast, which in most cases (if not all) consists of the 1- 130 to-Many multicast. 132 2. Using the source IP address approach ensures that existing IPsec 133 implementations will not need to change their storage or access 134 mechanisms to their SA Database (SAD). 136 3. Some multicast routing protocols only admit the creation of 1- 137 to-Many multicast groups (eg. PIMv2), with a unidirectional 138 distribution tree towards the receivers at the leafs of the 139 tree. Assuming a 1-to-Many multicast routing protocol (eg. 140 PIMv2) is deployed, then source-authentication is provided as an 141 inherent part of a (GSA, group-key) pair. Since the underlying 142 1-to-M multicast routing protocol only admits a single sender as 143 part of its source access-control and since only the valid 144 single sender knows the group-key for that 1-to-Many multicast, 145 it follows that sender-authentication to the receivers is 146 achieved. Even if a dishonest receiver holding the group-key 147 attempts to send to the group, the multicast distribution tree 148 itself may not permit this. 150 4. The anti-replay features of IPsec can still be deployed. Since 151 there is only a single source per GSA, consistency and 152 monotonicity of the sequence number can be guaranteed. 154 Note, that, if a host is a sender for more than one 1-to-M multicast 155 groups, the sender needs to make sure that the SPI is different for 156 each GSA is uses. Note also, that the current approach to defining 157 the GSA solves some of the issues raised by [CCP99] (Section 6). 159 There are two general types of multicast: one-to-many and many-to- 160 many. The one-to-many multicast involves one sender sending data via 161 multicast to the members (receivers) of the group. The many-to-many 162 multicast group assumes that each member of the multicast group can 163 become a sender of data to the multicast group if it so chooses. The 164 two cases are discussed in the sections below in the context of the 165 GSA usage. 167 3.1 One-to-Many Multicast 169 Only one fixed sender sends multicast data using one GSA for the 170 group. The receivers in the multicast group save the (received) GSA 171 in the inbound SAD. On receiving an encrypted packet, the source IP 172 address, SPI and protocol from the packet are used to retrieve the 173 proper GSA from the inbound SAD to decrypt the packet. 175 3.2 Many-to-Many Multicast 177 The case of the Many-to-Many multicast is more complex since 178 multiple senders may exist and thus a mechanism to determine 179 (negotiate) the parameters among the multiple senders must be 180 employed. Unlike the 1-to-Many multicast, the Many-to-Many can 181 involve more than one sender, and in reality the number of active 182 receivers can even be less than the number of sender (ie. some 183 senders are not receivers). The current document places the issue of 184 Many-to-Many for later work. 186 Some points of consideration concern the behavior of the underlying 187 multicast routing protocol with respect to the current definition of 188 security associations for groups. 190 As mentioned above, some multicast routing protocols only admit the 191 creation of 1-to-Many multicast groups, with a unidirectional 192 distribution tree towards the receivers at the leafs of the tree. 193 With such multicast routing protocols, the creation of a M-to-M 194 multicast can be effected through the overlaying M of the 1-to-M 195 multicast. 197 If such is the case with the multicast routing protocol, then each 198 of the M layers (consisting of a 1-to-M multicast) can be served 199 with a separate GSA. In essence, each receiver must maintain M GSAs 200 (and M group-keys) corresponding to the M individual 201 sources/senders. Although at first this may appear to be a possible 202 overhead, there are some advantages of using M layers of the 1-to- 203 Many multicast. 205 The first advantage, as mentioned previously, is that source- 206 authentication is provided as an inherent part of a (GSA, group-key) 207 pair. 209 The second advantage, is that having M separate 1-to-Many multicasts 210 allows a receiver to choose particular sources from which it wishes 211 to hear. This selective reception of sources can be done by the 212 receiver simply opting not to join one (or several) 1-to-M 213 multicast, or it can be performed on a policy-basis by the local 214 administration. This approach also falls inline with the future 215 promise of IGMPv3 [CDT99] in which a host has the option of 216 specifying with sources of a multicast group it wishes to listen to, 217 through IGMPv3. 219 The third advantage, which ties into the first, is that the anti- 220 replay features of IPsec can still be deployed in each of the 1-to-M 221 multicast layers of the M-to-M multicast. 223 3.3 Dissemination of 1-to-Many GSAa 225 In the context of a 1-to-M multicast group, an important issue that 226 needs to be addressed is that of the dissemination of the GSA to the 227 M receivers in the group. 229 Assuming that the sender is already in possession of the GSA, one 230 possible mechanism to deliver the GSA to the M receivers is through 231 the same method as the group-key delivery. The motivation here is 232 that since the GKM protocol is already delivering a crucial piece of 233 information (the group-key) and is trusted to do so, then it makes 234 sense for the delivery of the GSA to be coupled to the delivery of 235 the group-key matching the GSA. 237 Note a GSA must be coupled with its respective group-key. Thus, 238 when a group-key is to be re-keyed, a new SPI must be created, and 239 thus a new GSA. Hence, in the current work we propose the delivery 240 of the group-key and its GSA as a single unit. 242 3.4 GSA Parameters 244 This sections discusses certain unicast SA parameters [KA98a] which 245 have a direct bearing on MIPsec. 247 - IPsec Protocol Mode: 248 The IP security architecture describes two different types of 249 IPsec SAs: tunnel and transport. A transport mode SA is used to 250 securely communicate between two hosts. A tunnel mode SA is used 251 to protect communication between two security gateways or between 252 a security gateway and a host. Since members of a multicast group 253 are assumed to be end-hosts, we propose that GSAs be defined for 254 transport mode only. Note that this decision does not prevent 255 multicast traffic being tunneled over a set of unicast IPSec SAs. 256 Furthermore, this does not preclude the possibility of a gateway 257 entity in itself becoming an "end-host" of a multicast group. 259 - Anti-replay window: All multicast receivers are REQUIRED to 260 implement this window. 262 - AH Authentication algorithm, keys, ESP Encryption algorithm, 263 authentication algorithm, keys etc: Unlike IPSec SAs, these 264 parameters are not negotiated but generated by the sender(s) of 265 the multicast group or a DKD entity [HCM98] and propagated to the 266 multicast receivers using GKM protocol. 268 - Lifetime of GSA: The sender MUST choose the time interval the GSAs 269 are valid, whether they be time based or kilobyte based. The 270 sender is responsible for taking the appropriate action, either 271 creating a new GSA or terminating the existing GSA, when the 272 existing GSA expires. The receivers are NOT REQUIRED to track the 273 lifetime of the GSA. The GSA lifetime must be constrained by the 274 validity of the senders certificate, if that is provided in the 275 GSA. 277 3.5 Combining GSAs 279 Multicast senders and receivers MUST support transport adjacency of 280 GSAs as described in Section 4.3 of IPsec Security Architecture 281 [KA98a]. They are NOT REQUIRED to support iterated tunneling. 283 4. Security Association Database 285 The concept of GSAs integrates seamlessly with the SAD concept 286 described in the IPSec Security Architecture document[KA98a]. Since 287 GSAs have the same number of unique parameters which are of 288 same/similar type, GSAs can be stored/accessed from the same SAD 289 meant for unicast IPSec SAs. This reduces the complexity of 290 multicast security implementation in the client. 292 5. References 294 [HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key 295 Management Protocol", Internet Draft, July 1998. 296 draft-ietf-ipsec-intragkm-00.txt 298 [KA98a] S. Kent and R. Atkinson, "Security Architecture for the 299 Internet Protocol", IETF, RFC 2401, 1998. 301 [CDT99] B. Cain, S. Deering and A. Thyagarajan, "Internet Group 302 Management Protocol, Version 3", Internet Draft, February 1999. 303 draft-ietf-idmr-igmp-v3-01.txt 305 [CCP99] R. Canetti, P-C. Cheng, D. Pendarakis, J.R. Rao, P.Rohatgi 306 and D. Saha, "An Architecture for Secure Internet Multicast". 307 Internet Draft, February 1999. draft-irtf-smug-sec-mcast-arch-00.txt 309 6. Author Addresses 311 Indermohan Monga 312 Email: imonga@baynetworks.com 314 Thomas Hardjono 315 Email: thardjono@baynetworks.com 317 Nortel Networks 318 3 Federal Street, Bl3-03 319 Billerica, MA 01821, USA 320 Tel: +1-978-916-4538 322 -------------------------------------------------------------------------