idnits 2.17.1 draft-ietf-msec-ipsec-composite-group-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 786. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 793. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 799. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 3) being 70 lines == It seems as if not all pages are separated by form feeds - found 1 form feeds but 19 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Weis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 560, but not defined == Unused Reference: 'RFC2119' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC3940' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC4082' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC4359' is defined on line 620, but no explicit reference was found in the text -- No information found for draft-ietf-msec-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Weis' -- Obsolete informational reference (is this intentional?): RFC 2362 (Obsoleted by RFC 4601, RFC 5059) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3451 (Obsoleted by RFC 5651) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force George Gross (IdentAware) 2 INTERNET-DRAFT (experimental track) H. Cruickshank 3 (CCSR, U. of Surrey) 4 draft-ietf-msec-ipsec-composite-group-01 5 Expires: August, 2007 February, 2007 7 Multicast IP Security Composite Cryptographic Groups 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). 37 Abstract 39 The Multicast IP Security extension architecture [Weis] implicitly 40 assumes a basic group endpoint population that shares homogeneous 41 cryptographic capabilities and security policies. In practice, large- 42 scale cryptographic groups may contain a heterogeneous endpoint 43 population that can not be accommodated by that basic multicast IPsec 44 architecture. For example, some endpoints may not have been upgraded 45 to handle the successor algorithm for one that is being retired (e.g. 46 SHA1 transition to SHA-ng). Group deployments that span multiple 47 legal jurisdictions may have a different security policy in each 48 jurisdiction (e.g. key strength). This document defines the 49 "composite cryptographic group" IP security architecture capability. 50 A composite cryptographic group allows multicast IPsec applications 51 to transparently interact with the single logical group that is 52 formed by the union of one or more basic cryptographic groups. 54 Multicast IPsec Composite Cryptographic Groups 56 Table of Contents 58 1. Introduction.......................................................3 59 1.1 Scope...........................................................3 60 1.2 Terminology.....................................................4 61 2. Composite IPsec Group Architecture.................................5 62 2.1 Transport Mode Composite Group Distributor......................6 63 2.2 Tunnel Mode Composite Group Distributor.........................6 64 2.3 Rationale for Multicast Destination IP Address and SPI Assignment7 65 3. Group Key Management Protocol Composite IPsec Group Requirements...7 66 3.1 IPsec Security Association Identifier Assignment................8 67 3.2 Group Receiver Composite IPsec Group Membership.................8 68 3.3 Group Speaker Composite IPsec Group Membership..................8 69 5. IANA Considerations................................................9 70 6. Security Considerations............................................9 71 6.1 Security Issues Solved by Composite IPsec Groups................9 72 6.2 Security Issues Not Solved by Composite IPsec Groups............9 73 6.2.1 Outsider Attacks...........................................10 74 6.2.2 Insider Attacks............................................10 75 6.3 Implementation or Deployment Issues that Impact Security.......11 76 7. Acknowledgements..................................................11 77 8. References........................................................11 78 8.1 Normative References...........................................11 79 8.2 Informative References.........................................12 80 APPENDIX A: Examples of Composite Cryptographic Group Use Cases......15 81 Author's Address.....................................................18 82 Intellectual Property Statement......................................19 83 Copyright Statement..................................................19 85 Multicast IPsec Composite Cryptographic Groups 87 1. Introduction 89 In a basic IPsec cryptographic group there is a 1:1 relationship 90 between an IPsec group's data security association, a multicast 91 application, and a multicast IP address. All of the group members 92 share identical cryptographic capabilities and they abide by a common 93 security policy. IPsec subsystems [RFC4301] [RFC4302] [RFC4303] that 94 are compliant to the [Weis] standard by definition support basic 95 IPsec cryptographic groups. 96 For a small-scale cryptographic group, it is operationally feasible 97 to maintain a homogenous endpoint population. In contrast, large- 98 scale cryptographic groups may be heterogeneous in both their 99 cryptographic capabilities and/or their security policies. 101 o The differences in cryptographic capabilities can arise when 102 subsets of the group's membership are in transition, migrating from 103 one version of a cryptographic algorithm to its successor (e.g. 104 SHA-1 hash function to SHA-ng). It is unreasonable to expect that a 105 large-scale group membership should upgrade to new capabilities in 106 a flash cut operation. 108 o Heterogeneous security policies can occur when a cryptographic 109 group's membership straddles legal or security domain boundaries. 110 An example is a multi-national cryptographic group, for which some 111 endpoints reside in a country that enforces legislation that 112 specifies weaker cipher key strengths. 114 The above two requirements motivate the implementation and operation 115 of a "composite IPsec cryptographic group". A composite IPsec 116 cryptographic group is the union of two or more non-overlapping basic 117 IPsec cryptographic sub-groups. For sake of brevity, the terms 118 "Composite IPsec Group" and "Basic IPsec Subgroup" will be used in 119 subsequent text. The goal of a Composite IPsec Group is to 120 accommodate a large-scale group membership population that contains 121 heterogeneous capabilities, policies, or other attributes. Appendix A 122 enumerates additional use cases that can be satisfied by Composite 123 IPsec Groups. 125 A strong benefit of IPsec is that it applies its security processing 126 at the IP layer. Consequently, upper layer application programs can 127 execute securely without reprogramming or any awareness that IPsec 128 services are present. The additional benefit of a Composite IPsec 129 Group is that it shields the multicast application from the IP layer 130 complexity of the two or more Basic IPsec Subgroups. The application 131 multicasts its messages to what appear to be a single homogeneous 132 multicast group. 134 1.1 Scope 136 Multicast IPsec Composite Cryptographic Groups 138 The IPsec extensions described in this document support IPsec 139 Security Associations that result in IPsec packets with IPv4 or IPv6 140 multicast group addresses as the destination address. Both Any-Source 141 Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569, 142 RFC3376] group addresses are supported. 144 These extensions also support Security Associations with IPv4 145 Broadcast addresses that result in an IPv4 Broadcast packet, and IPv6 146 Anycast addresses [RFC2526] that result in an IPv6 Anycast packet. 147 These destination address types share many of the same 148 characteristics of multicast addresses because there may be multiple 149 receivers of a packet protected by IPsec. 151 The IPsec Architecture does not make requirements upon entities not 152 participating in IPsec (e.g., network devices between IPsec 153 endpoints). As such, these multicast extensions do not require 154 intermediate systems in a multicast enabled network to participate in 155 IPsec. In particular, no requirements are placed on the use of 156 multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast 157 admission protocols (e.g., IGMP [RFC3376]. 159 All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- 160 in-the-wire") are supported. 162 1.2 Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119. 168 The following key terms are used throughout this document. 170 Any-Source Multicast (ASM) 172 The Internet Protocol (IP) multicast service model as defined in 173 RFC 1112 [RFC1112]. In this model one or more senders source 174 packets to a single IP multicast address. When receivers join the 175 group, they receive all packets sent to that IP multicast address. 176 This is known as a (*,G) group. 178 Group Controller Key Server (GCKS) 180 A Group Key Management Protocol (GKMP) server that manages IPsec 181 state for a group. A GCKS authenticates and provides the IPsec SA 182 policy and keying material to GKMP group members. 184 Group Key Management Protocol (GKMP) 186 A key management protocol used by a GCKS to distribute IPsec 187 Security Association policy and keying material. A GKMP is used 188 when a group of IPsec devices require the same SAs. For example, 190 Multicast IPsec Composite Cryptographic Groups 192 when an IPsec SA describes an IP multicast destination, the sender 193 and all receivers must have the group SA. 195 GKMP Subsystem 197 A subsystem in an IPsec device implementing a Group Key Management 198 Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec 199 subsystem on the IPsec device. 201 Group Member 202 An IPsec device that belongs to a group. A Group Member is 203 authorized to be a Group Speaker and/or a Group Receiver. 205 Group Owner 207 An administrative entity that chooses the policy for a group. 209 Group Security Association (GSA) 211 A collection of IPsec Security Associations (SAs) and GKMP 212 Subsystem SAs necessary for a Group Member to receive key updates. 213 A GSA describes the working policy for a group. 215 Group Receiver 217 A Group Member that is authorized to receive packets sent to a 218 group by a Group Speaker. 220 Group Speaker 222 A Group Member that is authorized to send packets to a group. 224 Source-Specific Multicast (SSM) 226 The Internet Protocol (IP) multicast service model as defined in 227 RFC 3569 [RFC3569]. In this model, each combination of a sender 228 and an IP multicast address is considered a group. This is known 229 as an (S,G) group. 231 Tunnel Mode with Address Preservation 233 A type of IPsec tunnel mode used by security gateway 234 implementations when encapsulating IP multicast packets such that 235 they remain IP multicast packets. This mode is necessary in order 236 for IP multicast routing to correctly route IP multicast packets 237 that are protected by IPsec. 239 2. Composite IPsec Group Architecture 241 The GCKS and the Group Members must support a Group Key Management 242 Protocol (GKMP) that can negotiate a Composite IPsec Group's 243 membership join or leave operation. The group key management 245 Multicast IPsec Composite Cryptographic Groups 247 subsystem configures one or more IPsec subsystems to reflect the 248 Composite IPsec Group's revised state. In addition, the GCKS 249 configures a supporting Composite Group Distributor component 250 whenever a new Group Speaker endpoint joins the Composite IPsec 251 Group. The Composite Group Distributor handles the data flowing from 252 a multicast application's Group Speaker endpoint to the IPsec 253 subsystem. When the multicast application requests a message 254 transmission to the Composite IPsec Group's endpoints, the Composite 255 Group Distributor component transparently intercepts and replicates 256 that message for multicast delivery to each Basic IPsec Subgroup. 257 Sections 2.1 and 2.2 define the Composite Group Distributor's 258 architectural role for transport mode and tunnel mode IPsec security 259 associations. Section 3 provides the GKMP requirements for Composite 260 IPsec Group capability. 262 2.1 Transport Mode Composite Group Distributor 264 For a Composite IPsec Group transport mode security association, it 265 is the responsibility of the Composite Group Distributor to rewrite 266 each message copy's destination IP address before it is multicast to 267 the respective Basic IPsec Subgroup. The IPsec subsystem's SPD 268 traffic selectors then evaluate that message, and apply the Basic 269 IPsec Subgroup's security association transform. Since a single IPsec 270 subsystem supports the Group Speaker, that IPsec subsystem MUST 271 support all of the outbound security transforms required by all of 272 the Basic IPsec Subgroups that form the Composite IPsec Group. 273 Regardless of the Composite Group Distributor's underlying 274 implementation, it is a requirement that the two or more security 275 transforms applied by the IPsec subsystem to the multicast 276 application's replicated data streams MUST remain transparent to that 277 application's Group Speaker endpoint. Each Basic IPsec Subgroup MUST 278 be allocated a unique multicast destination IP address. Appendix B 279 provides non-normative guidance for the implementation of a Composite 280 Group Distributor supporting IPsec transport mode security 281 associations. 283 2.2 Tunnel Mode Composite Group Distributor 285 For a Composite IPsec Group tunnel mode security association, the 286 Composite Group Distributor component is simply the multicast routing 287 infrastructure residing on the network path between the Group Speaker 288 endpoint and two or more IPsec subsystems. Typically, the IPsec 289 subsystems are IPsec security gateways. In a tunnel mode 290 configuration, there is a parallel IPsec subsystem instance per Basic 291 IPsec Subgroup. Unlike transport mode, in tunnel mode the Composite 292 Group Distributor does not rewrite the destination IP multicast 293 address for each Basic IPsec Subgroup. Instead, each IPsec subsystem 294 SPD independently recognizes the message addressed to the Composite 295 IPsec Group destination IP address, and applies the IPsec tunnel mode 296 security transform for its respective Basic IPsec Subgroup. Each 297 IPsec subsystem MUST use a unique Security Parameter Index for their 298 security association instance. The GKMP is responsible for allocating 300 Multicast IPsec Composite Cryptographic Groups 302 the SPI for each tunnel mode security association, so that they are 303 uniquely identified when the replicated messages are distributed to 304 the Composite IPsec Group. 306 Note that in tunnel mode, there is one multicast distribution tree 307 representing the Composite IPsec Group rather than a multicast 308 distribution tree per Basic IPsec Subgroup. All of the message copies 309 are multicast to the Composite IPsec Group's multicast IP address. 310 Consequently, the Group Receiver IPsec subsystems use the SPI to de- 311 multiplex which one of the message replicas is addressed to its Basic 312 IPsec Subgroup. 314 2.3 Rationale for Multicast Destination IP Address and SPI Assignment 316 For Composite Groups in transport mode, each Basic IPsec Subgroup is 317 assigned a distinct multicast destination IP address. This assignment 318 policy assures that the Group Speaker IPsec subsystem's SPD packet 319 matching can direct a packet to the correct sub-group's transport 320 mode IPsec SA instance. In particular, the CGD must not only 321 replicate the transmitted packet for each Basic IPsec Subgroup, it 322 must also alter each copied packet's destination IP address so that 323 the packet will be matched by the SPD and then encrypted by the 324 respective IPsec SAD entry. 326 In a Composite Group with tunnel mode address preservation, the 327 address assignment policy is to keep the packet's original multicast 328 address, and use only the SPI to distinguish between the Basic IPsec 329 Subgroups. Each Basic IPsec Subgroup has a parallel Security Gateway 330 instance doing an IPsec tunnel mode SA encapsulation. There is no CGD 331 component in these Security Gateways, since the multicast capable 332 trusted network has already replicated the packet. Each such Security 333 Gateway SPD is configured by the GKM protocol to insert the same 334 outer IP header as its peer Security Gateways. However, the SPI 335 assigned to the IPsec SA at each of the Security Gateways must be 336 unique. This allows the Group Receivers to discriminate between the 337 sub-group specific packet arrivals sharing a common destination 338 multicast IP address. 340 In a Composite Group without tunnel mode address preservation, it is 341 feasible to use any assignment policy that maintains a unique 2-tuple 342 of {destination multicast IP address, SPI} across all of the Basic 343 IPsec subgroups. 345 3. Group Key Management Protocol Composite IPsec Group Requirements 347 A Group Key Management Protocol subsystem supporting Composite IPsec 348 Groups is responsible for configuring the Group Speaker's Composite 349 Group Distributor and one or more IPsec SPD/SAD to create and manage 350 a Composite IPsec Group membership. Those GKMP subsystems that choose 351 to implement the optional Composite IPsec Group capability MUST 352 support both Group Receivers and Group Speakers, as defined below in 353 section 3.2 and section 3.3 respectively. 355 Multicast IPsec Composite Cryptographic Groups 357 3.1 IPsec Security Association Identifier Assignment 359 Each Basic IPsec Subgroup MUST have a group data IPsec security 360 association identifier allocation from the GKMP subsystem that is 361 unique relative to all other security associations in the Composite 362 IPsec Group. For an any-source multicast group, the security 363 association identifier is the 2-tuple {destination multicast IP 364 address, Security Parameter Index}. If the Composite IPsec Group is 365 using Source-Specific Multicast, then the IPsec security association 366 identifier MUST be composite group-wide unique for the 3-tuple: 367 {source IP address, destination multicast IP address, Security 368 Parameter Index}. 369 3.2 Group Receiver Composite IPsec Group Membership 371 A Group Receiver endpoint acquires membership in only one Basic IPsec 372 Subgroup within a Composite IPsec Group. When a Group Receiver 373 endpoint requests to join the Composite IPsec Group, the registration 374 protocol exchange MUST select the Group Receiver's membership in one 375 of the Basic IPsec Subgroups. The Basic IPsec Subgroup selection can 376 be implicit (i.e. pre-configured at the GCKS) or explicitly 377 negotiated by registration protocol exchanges between the candidate 378 Group Receiver and the GCKS. The GKMP specification defines the 379 registration protocol exchange negotiation. When evaluating a 380 candidate Group Receiver's registration request, the GCKS MUST 381 enforce the authentication and membership authorization policies of 382 the Basic IPsec Subgroup that the candidate Group Receiver has 383 requested membership. 384 3.3 Group Speaker Composite IPsec Group Membership 386 When a Group Speaker endpoint registers with a GCKS to join a 387 Composite IPsec Group, the Group Speaker implicitly joins all of the 388 Basic IPsec Subgroups as a speaker in each subgroup. The GCKS sets up 389 the Composite IPsec Group such that when the multicast application 390 Group Speaker endpoint sends a single message to the Composite IPsec 391 Group, it is received once at each Group Receiver endpoint within the 392 two or more Basic IPsec Groups. The GCKS and GKMP is responsible for 393 the following actions: 395 o The GCKS MUST authenticate and authorize the candidate Group 396 Speaker endpoint before allowing it to become a Composite IPsec 397 Group Speaker. The speaker authorization is contingent on the 398 approval of both the Composite IPsec Group policy and the logical- 399 AND authorization of all of the Basic IPsec Group policies. 401 o For each Basic IPsec Group, the GCKS allocates a new group IPsec 402 security association instance representing the new Group Speaker. 403 The GCKS uses the GKMP to distribute and then activate that IPsec 404 security association's configuration in the IPsec subsystem SPD/SAD 405 of every Group Receiver endpoint within the subgroup. In addition, 406 the GCKS chooses one IPsec subsystem to be the Group Speaker's 408 Multicast IPsec Composite Cryptographic Groups 410 representative in that Basic IPsec Group, and configures its 411 SPD/SAD for that role. 413 o For an IPsec transport mode security association, the GCKS 414 explicitly directs the Group Speaker's Composite Group Distributor 415 to intercept and replicate the Group Speaker's data traffic before 416 multicasting it to each Basic IPsec Group. The trusted control 417 interface between the GCKS and Composite Group Distributor is 418 implementation specific and it is outside the scope of this 419 specification. 421 5. IANA Considerations 423 This document does not require any IANA action. 425 6. Security Considerations 427 This document describes a large-scale Composite IPsec Group 428 architecture. Consequently, it inherits all of the security 429 considerations previously discussed in [Weis] for Basic IPsec Groups. 430 The reader is encouraged to review those security considerations in 431 addition to those discussed herein for Composite IPsec Groups. 433 6.1 Security Issues Solved by Composite IPsec Groups 435 Composite IPsec Groups accommodate the natural heterogeneity often 436 found in large-scale cryptographic groups. Two common motivations for 437 Composite IPsec Groups are easing the migration to new cryptographic 438 algorithms and handling country-specific cryptographic policies. 439 Appendix A enumerates a variety of other potential use cases. 441 Regardless of the motive, the primary benefit of composite groups is 442 that a group multicast application can interact without change with a 443 single virtual homogeneous cryptographic group. The Composite Group 444 Distributor and its supporting IPsec subsystems transparently apply 445 the correct IPsec transforms at the IP layer for each sub-group. An 446 operational benefit of Composite IPsec Groups is that it centralizes 447 the security policy management for multiple group multicast 448 applications into a single Security Officer role. 450 In contrast, in the scenario without the Composite Group capability, 451 a group multicast application must be re-programmed and re-configured 452 to correctly interact with the two or more Basic IPsec Groups. 453 Alternatively, the group multicast application must be re-programmed 454 to support an application layer security service equivalent to that 455 offered by the IPsec subsystem at the network layer. In either case, 456 the group multicast application incurs complexity and cost that could 457 have been avoided. 459 6.2 Security Issues Not Solved by Composite IPsec Groups 461 Multicast IPsec Composite Cryptographic Groups 463 Similar as is the case for Basic IPsec Groups, the security issues 464 not solved by a Composite IPsec Group divide into two categories: 465 outsider attacks, and insider attacks. The discussion will focus on 466 the security issues that arise only in Composite IPsec Groups. 468 6.2.1 Outsider Attacks 470 A Composite IPsec Group using a weak cryptographic algorithm or key 471 strength in one of its Basic IPsec groups is vulnerable to an 472 Adversary that knows (or guesses) which sub-group uses that 473 algorithm. The Adversary can narrow its eavesdropping effort to only 474 the traffic sent to that sub-group and apply cryptoanalysis on that 475 sub-group's cipher-text. 477 The Composite Group Distributor can inadvertently leak the composite 478 group security policy to an Adversary that records the transmission 479 time of an IP packet, as each copy is encrypted and multicast for a 480 Basic IPsec Group. The Adversary could use that encryption processing 481 delay information to infer the cryptographic algorithm being applied 482 to a given Basic IPsec Group (e.g. AES encrypts at a faster rate than 483 triple-DES). The Composite Group Distributor can avoid this attack by 484 delaying each packet's transmission by a random dither. 486 If two Basic IPsec groups use the same encryption key but different 487 encryption algorithms for the same plain-text transmissions, then the 488 cipher-text may become vulnerable to differential analysis attacks. 489 This vulnerability exists only to the extent that comparing the 490 output of the encryption algorithms could disclose hints about the 491 plain text or the encryption key. Requiring the GKM protocol to 492 distribute a distinct encryption key for each Basic IPsec Group can 493 help mitigate this attack. Changing the keys more frequently is 494 another strategy. 496 6.2.2 Insider Attacks 498 Composite IPsec Groups are vulnerable to a registration time bid down 499 attack unless the GKM protocol has an accurate database describing 500 each group member's cryptographic capabilities. In the absence of GKM 501 enforcement at registration time, an insider Adversary could pretend 502 to support only a weak cryptographic algorithm. An accomplice to the 503 Adversary could eavesdrop and apply cryptoanalysis on the weakened 504 transmissions without the insider Adversary risking detection by 505 explicitly disclosing the key or plain text. To avoid this attack, a 506 Composite IPsec Group depends on the Group Owner designing a 507 membership authorization policy that forces each candidate Group 508 Receiver member to only join the Basic IPsec Group that implements 509 the strongest algorithms that their IPsec subsystem is known to 510 support. Special care must be taken when authorizing a Group Speaker, 511 as a group member in that role becomes a member of every Basic IPsec 512 Group. 514 Multicast IPsec Composite Cryptographic Groups 516 A Composite Group Distributor under the control of an insider 517 Adversary could create a covert channel by altering the order in 518 which it multicast an IP packet to each Basic IP Group. An accomplice 519 to the Adversary who observed a long sequence of IP packet multicasts 520 could assemble the covert message from a codebook. Each symbol would 521 be represented by a different sequence of Basic IPsec Group 522 transmissions. 524 6.3 Implementation or Deployment Issues that Impact Security 526 The most prominent barrier to a successful Composite IPsec Group 527 deployment is the complexity of designing a composite group security 528 policy. Factors that should be considered when designing such 529 policies include: 531 o For each Basic IPsec Group, the policy should delegate the 532 subordinate GCKS role to the group member with the highest 533 trustworthiness amongst all members of that sub-group. 535 o A Group Receiver identity should be an authorised member of only 536 one Basic IPsec Group and that sub-group should represent the 537 strongest cryptographic algorithm that the member is capable of 538 supporting. 540 o The Group Speaker role is endowed with a membership in every sub- 541 group, and therefore this role should be authorised for only the 542 group's most trustworthy members. 544 o The weakest Basic IPsec Group should be the focal point for 545 retirement efforts, with the goal of moving its membership to 546 better cryptographic algorithms. 548 o A host system implementing the Composite Group Distributor 549 component will necessarily incur substantially more encryption 550 processing overhead, in proportion to the number of Basic IPsec 551 Groups that form the Composite IPsec Group. Consequently, care 552 should be exercised to minimise the number of Basic IPsec Groups. 554 o The use of ESP padding, frequent key changes, and a separate key 555 for each IPsec SA can help mitigate traffic analysis attacks that 556 compare the cipher-texts sent to multiple Basic IPsec Groups. 558 7. Acknowledgements 560 [TBD] 562 8. References 564 8.1 Normative References 566 Multicast IPsec Composite Cryptographic Groups 568 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 569 1112, August 1989. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Level", BCP 14, RFC 2119, March 1997. 574 [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on 575 Security Considerations", RFC 3552, July 2003. 577 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 578 Internet Protocol", RFC 4301, December 2005. 580 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 581 2005. 583 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 584 4303, December 2004. 586 [Weis] Weis B., Gross G., Ignjatic D., "Multicast Extensions to the 587 Security Architecture for the Internet", draft-ietf-msec-extensions- 588 03.txt, October 2006, work in progress. 590 8.2 Informative References 592 [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse 593 Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. 595 [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast 596 Addresses", RFC 2526, March 1999. 598 [RFC3376] Cain, B., et. al., "Internet Group Management Protocol, 599 Version 3", RFC 3376, October 2002. 601 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 602 Group Domain of Interpretation", RFC 3547, December 2002. 604 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 605 Multicast (SSM)", RFC 3569, July 2003. 607 [RFC3940] Adamson, B., et. al., "Negative-acknowledgment (NACK)- 608 Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 609 2004. 611 [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant 612 Authentication (TESLA): Multicast Source Authentication Transform 613 Introduction", RFC 4082, June 2005. 615 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 616 4306, December 2005. 618 Multicast IPsec Composite Cryptographic Groups 620 [RFC4359] Weis., B., "The Use of RSA/SHA-1 Signatures within 621 Encapsulating Security Payload (ESP) and Authentication Header (AH)", 622 RFC 4359, January 2006. 624 [RFC3451] Luby, M., et al, "Layered Coding Transport (LCT) Building 625 Block", RFC3451, December 2002. 627 Multicast IPsec Composite Cryptographic Groups 629 Multicast IPsec Composite Cryptographic Groups 631 APPENDIX A: Examples of Composite Cryptographic Group Use Cases 633 The following is a non-exhaustive list that identifies other 634 representative use cases where a Composite Group could be applied: 636 - A group policy that allows the use of both IETF standard and 637 vendor-specific cryptographic algorithms. 639 - A group straddling both IP-v4 and IP-v6 endpoints. For a group 640 spanning IP-v4 and IP-v6, the Group Speaker endpoint's Node must be 641 dual stack capable. 643 - A single group using a Reliable Multicast Transport protocol (RTMP) 644 that has a heterogeneous deployment of error recovery algorithms 645 (e.g. Forward Error Correction codes) at its endpoint population. 646 Each RMTP version is configured as a sub-group at a distinct 647 multicast destination IP address. In this case, the application's 648 payload is replicated within the Group Speaker before being 649 distributed to each RMTP version-specific subsystem. The Group 650 Speaker endpoint's system must implement all of the RMTP sub-group 651 versions. 653 - There are multiple multicast routing domains supporting the IPsec 654 group, each routing domain imposing its own policy defined multicast 655 IP address. The Composite Group Distributor must alter the multicast 656 destination IP address for each copy of the multicast packet before 657 it is sent to its respective routing domain. 659 - A multicast application wherein the Composite Group is the union of 660 multiple source-specific IP multicast groups. For example, a multi- 661 homed Group Speaker might require this configuration. 663 In principal, each of the above examples could be decomposed into 664 multiple independent basic IPsec cryptographic groups. However, that 665 incurs a commensurate increase in the multicast application's 666 overhead to discover, join, and manage each of those groups. A 667 preferable solution is for the multicast application to join one 668 Composite Group 670 Figures A-1, A-2, and A-3 illustrate several representative composite 671 group use cases. 673 Multicast IPsec Composite Cryptographic Groups 675 +--------+------------+ 676 | | . 677 | Subgrp1 | 678 | ^ +-------+| 679 | | | Group || 680 | | |Speaker|| 681 | | +--+----+| 682 | | | | 683 | +------+-----V--+ | 684 +---------------+ | | Group Speaker | | +---------------+ 685 | Subgrp2, <------+Composite Group+------> Subgrp4, | 686 | No Speaker | | | Distributor | | | No Speaker | 687 +---------------+ | +------+------ + | +---------------+ 688 | | | 689 +---------|-----------+ 690 | 691 +------V--------+ 692 | Subgrp3, | 693 | No Speaker | 694 +---------------+ 696 Figure A-1: A simple Composite Group with a single Group Speaker 697 multicasting to 4 Basic IPsec Subgroups, each subgroup having a 698 different group security policy. The Group Speaker multicasts to all 699 four subgroups but it will receive its multicast traffic from only 700 from "Subgrp1". The Group Speaker's Composite Group Distributor (CGD) 701 replicates each of the Group Speaker's IP packets, transforms each 702 copied packet according to its respective Basic IPsec Subgroup's 703 security policy, and sends that copied packet to its subgroup. The 704 Composite Group's security policy specifies each Basic IPsec 705 Subgroup's membership authorization. 707 Multicast IPsec Composite Cryptographic Groups 709 +------+--------+ 710 | Subgrp1, CGD1 | . 711 | Speaker1 | 712 +------+--------+ 713 | 714 | 715 +---------------+ +------+--------+ +---------------+ 716 | Subgrp2, CGD2 +-----+ Satellite + ------+ Subgrp4, CGD4 | 717 | Speaker2 | | DVB network | | No Speaker | 718 +---------------+ +------+------ + +---------------+ 719 | 720 | 721 +------+--------+ 722 | Subgrp3, CGD3 | 723 | No Speaker | 724 +---------------+ 726 Figure A-2: A Composite Group containing 4 Basic IPsec Subgroups, 727 with each subgroup having its own S-GCKS. There are 5 LKH trees, one 728 for each subgroup managed by a S-GCKS and one LKH tree managed by the 729 primary GCKS for the set of S-GCKS. 731 Multicast IPsec Composite Cryptographic Groups 733 Figure A-3 illustrates a reliable multicast scenario using Layered 734 Coding Transport (LCT) as specified in RFC 3451 [RFC3451]. Each 735 subgroup corresponds to a LCT layer. Reliable content delivery and 736 streaming applications could leverage this type of configuration. 738 +------+--------+ 739 | Sub-group1, | . 740 | LCT layer1 | 741 +------A--------+ 742 | 743 | 744 +---------------+ +------+--------+ +---------------+ 745 | Sub-group2 <-----+ Multi-layered + ------> Sub-group 4 | 746 | LCT layer2 | | Reliable | | LCT layer4 | 747 +---------------+ | Multicast CGD | +---------------+ 748 +------+--------+ 749 | 750 | 751 +------V--------+ 752 | Sub-group3 | 753 | LCT layer3 | 754 +---------------+ 756 Figure A-3: 4 The LCT groups are organized as Basic IPsec Subgroups 757 managed by a centralized GCKS. 759 Author's Address 761 George Gross 762 IdentAware Security 763 82 Old Mountain Road 764 Lebanon, NJ 08833, USA 765 908-268-1629 766 gmgross@identaware.com 768 Haitham Cruickshank 769 Centre for Communications System Research (CCSR) 770 University of Surrey 771 Guildford, Surrey, GU2 7XH 772 UK 773 Email: h.cruickshank@surrey.ac.uk 775 Multicast IPsec Composite Cryptographic Groups 777 Intellectual Property Statement 779 The IETF takes no position regarding the validity or scope of any 780 Intellectual Property Rights or other rights that might be claimed 781 to pertain to the implementation or use of the technology 782 described in this document or the extent to which any license 783 under such rights might or might not be available; nor does it 784 represent that it has made any independent effort to identify any 785 such rights. Information on the procedures with respect to rights 786 in RFC documents can be found in BCP 78 and BCP 79. 788 Copies of IPR disclosures made to the IETF Secretariat and any 789 assurances of licenses to be made available, or the result of an 790 attempt made to obtain a general license or permission for the use 791 of such proprietary rights by implementers or users of this 792 specification can be obtained from the IETF on-line IPR repository 793 at http://www.ietf.org/ipr. 795 The IETF invites any interested party to bring to its attention any 796 copyrights, patents or patent applications, or other proprietary 797 rights that may cover technology that may be required to implement 798 this standard. Please address the information to the IETF at ietf- 799 ipr@ietf.org. 801 Disclaimer of Validity 803 This document and the information contained herein are provided on an 804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 806 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 807 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 808 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 809 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 810 PARTICULAR PURPOSE. 812 Copyright Statement 814 Copyright (C) The IETF Trust (2007). This document is subject 815 to the rights, licenses and restrictions contained in BCP 78, and 816 except as set forth therein, the authors retain all their rights. 818 Acknowledgement 820 Funding for the RFC Editor function is currently provided by the 821 Internet Society.