idnits 2.17.1 draft-ietf-msec-ipsec-composite-group-00.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 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 794. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 557, but not defined == Unused Reference: 'RFC2119' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'RFC2914' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC3171' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC3940' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'RFC4082' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'RFC4359' is defined on line 623, 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 3171 (Obsoleted by RFC 5771) -- 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: 5 errors (**), 0 flaws (~~), 15 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-00 5 Expires: May, 2006 November, 2006 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 Internet Society (2006). 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 62 2. Composite IPsec Group Architecture .................................5 63 2.1 Transport Mode Composite Group Distributor ......................6 64 2.2 Tunnel Mode Composite Group Distributor .........................6 65 2.3 Rationale for Multicast Destination IP Address and SPI Assignment7 66 3. Group Key Management Protocol Composite IPsec Group Requirements ...7 67 3.1 IPsec Security Association Identifier Assignment ................7 68 3.2 Group Receiver Composite IPsec Group Membership .................8 69 3.3 Group Speaker Composite IPsec Group Membership ..................8 71 5. IANA Considerations ................................................9 72 6. Security Considerations ............................................9 73 6.1 Security Issues Solved by Composite IPsec Groups ................9 74 6.2 Security Issues Not Solved by Composite IPsec Groups ............9 75 6.2.1 Outsider Attacks ...........................................10 76 6.2.2 Insider Attacks ............................................10 77 6.3 Implementation or Deployment Issues that Impact Security .......11 79 7. Acknowledgements ..................................................11 80 8. References ........................................................11 81 8.1 Normative References ...........................................11 82 8.2 Informative References .........................................12 83 APPENDIX A: Examples of Composite Cryptographic Group Use Cases ......15 84 Author's Address .....................................................18 85 Intellectual Property Statement ......................................19 86 Copyright Statement ..................................................19 87 Multicast IPsec Composite Cryptographic Groups 89 1. Introduction 91 In a basic IPsec cryptographic group there is a 1:1 relationship 92 between an IPsec group's data security association, a multicast 93 application, and a multicast IP address. All of the group members 94 share identical cryptographic capabilities and they abide by a common 95 security policy. IPsec subsystems that are compliant to the [Weis] 96 standard by definition support basic IPsec cryptographic groups. 97 For a small-scale cryptographic group, it is operationally feasible 98 to maintain a homogenous endpoint population. In contrast, large- 99 scale cryptographic groups may be heterogeneous in both their 100 cryptographic capabilities and/or their security policies. 102 o The differences in cryptographic capabilities can arise when 103 subsets of the group's membership are in transition, migrating from 104 one version of a cryptographic algorithm to its successor (e.g. 105 SHA-1 hash function to SHA-ng). It is unreasonable to expect that a 106 large-scale group membership should upgrade to new capabilities in 107 a flash cut operation. 109 o Heterogeneous security policies can occur when a cryptographic 110 group's membership straddles legal or security domain boundaries. 111 An example is a multi-national cryptographic group, for which some 112 endpoints reside in a country that enforces legislation that 113 specifies weaker cipher key strengths. 115 The above two requirements motivate the implementation and operation 116 of a "composite IPsec cryptographic group". A composite IPsec 117 cryptographic group is the union of two or more non-overlapping basic 118 IPsec cryptographic sub-groups. For sake of brevity, the terms 119 "Composite IPsec Group" and "Basic IPsec Subgroup" will be used in 120 subsequent text. The goal of a Composite IPsec Group is to 121 accommodate a large-scale group membership population that contains 122 heterogeneous capabilities, policies, or other attributes. Appendix A 123 enumerates additional use cases that can be satisfied by Composite 124 IPsec Groups. 126 A strong benefit of IPsec is that it applies its security processing 127 at the IP layer. Consequently, upper layer application programs can 128 execute securely without reprogramming or any awareness that IPsec 129 services are present. The additional benefit of a Composite IPsec 130 Group is that it shields the multicast application from the IP layer 131 complexity of the two or more Basic IPsec Subgroups. The application 132 multicasts its messages to what appear to be a single homogeneous 133 multicast group. 135 1.1 Scope 137 The IPsec extensions described in this document support IPsec 138 Security Associations that result in IPsec packets with IPv4 or IPv6 139 Multicast IPsec Composite Cryptographic Groups 141 multicast group addresses as the destination address. Both Any-Source 142 Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569, 143 RFC3376] group addresses are supported. 145 These extensions also support Security Associations with IPv4 146 Broadcast addresses that result in an IPv4 Broadcast packet, and IPv6 147 Anycast addresses [RFC2526] that result in an IPv6 Anycast packet. 148 These destination address types share many of the same 149 characteristics of multicast addresses because there may be multiple 150 receivers of a packet protected by IPsec. 152 The IPsec Architecture does not make requirements upon entities not 153 participating in IPsec (e.g., network devices between IPsec 154 endpoints). As such, these multicast extensions do not require 155 intermediate systems in a multicast enabled network to participate in 156 IPsec. In particular, no requirements are placed on the use of 157 multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast 158 admission protocols (e.g., IGMP [RFC3376]. 160 All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- 161 in-the-wire") are supported. 163 1.2 Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119. 169 The following key terms are used throughout this document. 171 Any-Source Multicast (ASM) 173 The Internet Protocol (IP) multicast service model as defined in 174 RFC 1112 [RFC1112]. In this model one or more senders source 175 packets to a single IP multicast address. When receivers join the 176 group, they receive all packets sent to that IP multicast address. 177 This is known as a (*,G) group. 179 Group Controller Key Server (GCKS) 181 A Group Key Management Protocol (GKMP) server that manages IPsec 182 state for a group. A GCKS authenticates and provides the IPsec SA 183 policy and keying material to GKMP group members. 185 Group Key Management Protocol (GKMP) 187 A key management protocol used by a GCKS to distribute IPsec 188 Security Association policy and keying material. A GKMP is used 189 when a group of IPsec devices require the same SAs. For example, 190 when an IPsec SA describes an IP multicast destination, the sender 191 and all receivers must have the group SA. 193 Multicast IPsec Composite Cryptographic Groups 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 244 subsystem configures one or more IPsec subsystems to reflect the 245 Composite IPsec Group's revised state. In addition, the GCKS 246 configures a supporting Composite Group Distributor component 247 Multicast IPsec Composite Cryptographic Groups 249 whenever a new Group Speaker endpoint joins the Composite IPsec 250 Group. The Composite Group Distributor handles the data flowing from 251 a multicast application's Group Speaker endpoint to the IPsec 252 subsystem. When the multicast application requests a message 253 transmission to the Composite IPsec Group's endpoints, the Composite 254 Group Distributor component transparently intercepts and replicates 255 that message for multicast delivery to each Basic IPsec Subgroup. 256 Sections 2.1 and 2.2 define the Composite Group Distributor's 257 architectural role for transport mode and tunnel mode IPsec security 258 associations. Section 3 provides the GKMP requirements for Composite 259 IPsec Group capability. 261 2.1 Transport Mode Composite Group Distributor 263 For a Composite IPsec Group transport mode security association, it 264 is the responsibility of the Composite Group Distributor to rewrite 265 each message copy's destination IP address before it is multicast to 266 the respective Basic IPsec Subgroup. The IPsec subsystem's SPD 267 traffic selectors then evaluate that message, and apply the Basic 268 IPsec Subgroup's security association transform. Since a single IPsec 269 subsystem supports the Group Speaker, that IPsec subsystem MUST 270 support all of the outbound security transforms required by all of 271 the Basic IPsec Subgroups that form the Composite IPsec Group. 272 Regardless of the Composite Group Distributor's underlying 273 implementation, it is a requirement that the two or more security 274 transforms applied by the IPsec subsystem to the multicast 275 application's replicated data streams MUST remain transparent to that 276 application's Group Speaker endpoint. Each Basic IPsec Subgroup MUST 277 be allocated a unique multicast destination IP address. Appendix B 278 provides non-normative guidance for the implementation of a Composite 279 Group Distributor supporting IPsec transport mode security 280 associations. 282 2.2 Tunnel Mode Composite Group Distributor 284 For a Composite IPsec Group tunnel mode security association, the 285 Composite Group Distributor component is simply the multicast routing 286 infrastructure residing on the network path between the Group Speaker 287 endpoint and two or more IPsec subsystems. Typically, the IPsec 288 subsystems are IPsec security gateways. In a tunnel mode 289 configuration, there is a parallel IPsec subsystem instance per Basic 290 IPsec Subgroup. Unlike transport mode, in tunnel mode the Composite 291 Group Distributor does not rewrite the destination IP multicast 292 address for each Basic IPsec Subgroup. Instead, each IPsec subsystem 293 SPD independently recognizes the message addressed to the Composite 294 IPsec Group destination IP address, and applies the IPsec tunnel mode 295 security transform for its respective Basic IPsec Subgroup. Each 296 IPsec subsystem MUST use a unique Security Parameter Index for their 297 security association instance. The GKMP is responsible for allocating 298 the SPI for each tunnel mode security association, so that they are 299 uniquely identified when the replicated messages are distributed to 300 the Composite IPsec Group. 302 Multicast IPsec Composite Cryptographic Groups 304 Note that in tunnel mode, there is one multicast distribution tree 305 representing the Composite IPsec Group rather than a multicast 306 distribution tree per Basic IPsec Subgroup. All of the message copies 307 are multicast to the Composite IPsec Group's multicast IP address. 308 Consequently, the Group Receiver IPsec subsystems use the SPI to de- 309 multiplex which one of the message replicas is addressed to its Basic 310 IPsec Subgroup. 312 2.3 Rationale for Multicast Destination IP Address and SPI Assignment 314 For Composite Groups in transport mode, each Basic IPsec Subgroup is 315 assigned a distinct multicast destination IP address. This assignment 316 policy assures that the Group Speaker IPsec subsystem's SPD packet 317 matching can direct a packet to the correct sub-group's transport 318 mode IPsec SA instance. In particular, the CGD must not only 319 replicate the transmitted packet for each Basic IPsec Subgroup, it 320 must also alter each copied packet's destination IP address so that 321 the packet will be matched by the SPD and then encrypted by the 322 respective IPsec SAD entry. 324 In a Composite Group with tunnel mode address preservation, the 325 address assignment policy is to keep the packet's original multicast 326 address, and use only the SPI to distinguish between the Basic IPsec 327 Subgroups. Each Basic IPsec Subgroup has a parallel Security Gateway 328 instance doing an IPsec tunnel mode SA encapsulation. There is no CGD 329 component in these Security Gateways, since the multicast capable 330 trusted network has already replicated the packet. Each such Security 331 Gateway SPD is configured by the GKM protocol to insert the same 332 outer IP header as its peer Security Gateways. However, the SPI 333 assigned to the IPsec SA at each of the Security Gateways must be 334 unique. This allows the Group Receivers to discriminate between the 335 sub-group specific packet arrivals sharing a common destination 336 multicast IP address. 338 In a Composite Group without tunnel mode address preservation, it is 339 feasible to use any assignment policy that maintains a unique 2-tuple 340 of {destination multicast IP address, SPI} across all of the Basic 341 IPsec subgroups. 343 3. Group Key Management Protocol Composite IPsec Group Requirements 345 A Group Key Management Protocol subsystem supporting Composite IPsec 346 Groups is responsible for configuring the Group Speaker's Composite 347 Group Distributor and one or more IPsec SPD/SAD to create and manage 348 a Composite IPsec Group membership. Those GKMP subsystems that choose 349 to implement the optional Composite IPsec Group capability MUST 350 support both Group Receivers and Group Speakers, as defined below in 351 section 3.2 and section 3.3 respectively. 353 3.1 IPsec Security Association Identifier Assignment 354 Multicast IPsec Composite Cryptographic Groups 356 Each Basic IPsec Subgroup MUST have a group data IPsec security 357 association identifier allocation from the GKMP subsystem that is 358 unique relative to all other security associations in the Composite 359 IPsec Group. For an any-source multicast group, the security 360 association identifier is the 2-tuple {destination multicast IP 361 address, Security Parameter Index}. If the Composite IPsec Group is 362 using Source-Specific Multicast, then the IPsec security association 363 identifier MUST be composite group-wide unique for the 3-tuple: 364 {source IP address, destination multicast IP address, Security 365 Parameter Index}. 366 3.2 Group Receiver Composite IPsec Group Membership 368 A Group Receiver endpoint acquires membership in only one Basic IPsec 369 Subgroup within a Composite IPsec Group. When a Group Receiver 370 endpoint requests to join the Composite IPsec Group, the registration 371 protocol exchange MUST select the Group Receiver's membership in one 372 of the Basic IPsec Subgroups. The Basic IPsec Subgroup selection can 373 be implicit (i.e. pre-configured at the GCKS) or explicitly 374 negotiated by registration protocol exchanges between the candidate 375 Group Receiver and the GCKS. The GKMP specification defines the 376 registration protocol exchange negotiation. When evaluating a 377 candidate Group Receiver's registration request, the GCKS MUST 378 enforce the authentication and membership authorization policies of 379 the Basic IPsec Subgroup that the candidate Group Receiver has 380 requested membership. 381 3.3 Group Speaker Composite IPsec Group Membership 383 When a Group Speaker endpoint registers with a GCKS to join a 384 Composite IPsec Group, the Group Speaker implicitly joins all of the 385 Basic IPsec Subgroups as a speaker in each subgroup. The GCKS sets up 386 the Composite IPsec Group such that when the multicast application 387 Group Speaker endpoint sends a single message to the Composite IPsec 388 Group, it is received once at each Group Receiver endpoint within the 389 two or more Basic IPsec Groups. The GCKS and GKMP is responsible for 390 the following actions: 392 o The GCKS MUST authenticate and authorize the candidate Group 393 Speaker endpoint before allowing it to become a Composite IPsec 394 Group Speaker. The speaker authorization is contingent on the 395 approval of both the Composite IPsec Group policy and the logical- 396 AND authorization of all of the Basic IPsec Group policies. 398 o For each Basic IPsec Group, the GCKS allocates a new group IPsec 399 security association instance representing the new Group Speaker. 400 The GCKS uses the GKMP to distribute and then activate that IPsec 401 security association's configuration in the IPsec subsystem SPD/SAD 402 of every Group Receiver endpoint within the subgroup. In addition, 403 the GCKS chooses one IPsec subsystem to be the Group Speaker's 404 representative in that Basic IPsec Group, and configures its 405 SPD/SAD for that role. 407 Multicast IPsec Composite Cryptographic Groups 409 o For an IPsec transport mode security association, the GCKS 410 explicitly directs the Group Speaker's Composite Group Distributor 411 to intercept and replicate the Group Speaker's data traffic before 412 multicasting it to each Basic IPsec Group. The trusted control 413 interface between the GCKS and Composite Group Distributor is 414 implementation specific and it is outside the scope of this 415 specification. 417 5. IANA Considerations 419 This document does not require any IANA action. 421 6. Security Considerations 423 This document describes a large-scale Composite IPsec Group 424 architecture. Consequently, it inherits all of the security 425 considerations previously discussed in [Weis] for Basic IPsec Groups. 426 The reader is encouraged to review those security considerations in 427 addition to those discussed herein for Composite IPsec Groups. 429 6.1 Security Issues Solved by Composite IPsec Groups 431 Composite IPsec Groups accommodate the natural heterogeneity often 432 found in large-scale cryptographic groups. Two common motivations for 433 Composite IPsec Groups are easing the migration to new cryptographic 434 algorithms and handling country-specific cryptographic policies. 435 Appendix A enumerates a variety of other potential use cases. 437 Regardless of the motive, the primary benefit of composite groups is 438 that a group multicast application can interact without change with a 439 single virtual homogeneous cryptographic group. The Composite Group 440 Distributor and its supporting IPsec subsystems transparently apply 441 the correct IPsec transforms at the IP layer for each sub-group. An 442 operational benefit of Composite IPsec Groups is that it centralizes 443 the security policy management for multiple group multicast 444 applications into a single Security Officer role. 446 In contrast, in the scenario without the Composite Group capability, 447 a group multicast application must be re-programmed and re-configured 448 to correctly interact with the two or more Basic IPsec Groups. 449 Alternatively, the group multicast application must be re-programmed 450 to support an application layer security service equivalent to that 451 offered by the IPsec subsystem at the network layer. In either case, 452 the group multicast application incurs complexity and cost that could 453 have been avoided. 455 6.2 Security Issues Not Solved by Composite IPsec Groups 457 Similar as is the case for Basic IPsec Groups, the security issues 458 not solved by a Composite IPsec Group divide into two categories: 460 Multicast IPsec Composite Cryptographic Groups 462 outsider attacks, and insider attacks. The discussion will focus on 463 the security issues that arise only in Composite IPsec Groups. 465 6.2.1 Outsider Attacks 467 A Composite IPsec Group using a weak cryptographic algorithm or key 468 strength in one of its Basic IPsec groups is vulnerable to an 469 Adversary that knows (or guesses) which sub-group uses that 470 algorithm. The Adversary can narrow its eavesdropping effort to only 471 the traffic sent to that sub-group and apply cryptoanalysis on that 472 sub-group's cipher-text. 474 The Composite Group Distributor can inadvertently leak the composite 475 group security policy to an Adversary that records the transmission 476 time of an IP packet, as each copy is encrypted and multicast for a 477 Basic IPsec Group. The Adversary could use that encryption processing 478 delay information to infer the cryptographic algorithm being applied 479 to a given Basic IPsec Group (e.g. AES encrypts at a faster rate than 480 triple-DES). The Composite Group Distributor can avoid this attack by 481 delaying each packet's transmission by a random dither. 483 If two Basic IPsec groups use the same encryption key but different 484 encryption algorithms for the same plain-text transmissions, then the 485 cipher-text may become vulnerable to differential analysis attacks. 486 This vulnerability exists only to the extent that comparing the 487 output of the encryption algorithms could disclose hints about the 488 plain text or the encryption key. Requiring the GKM protocol to 489 distribute a distinct encryption key for each Basic IPsec Group can 490 help mitigate this attack. Changing the keys more frequently is 491 another strategy. 493 6.2.2 Insider Attacks 495 Composite IPsec Groups are vulnerable to a registration time bid down 496 attack unless the GKM protocol has an accurate database describing 497 each group member's cryptographic capabilities. In the absence of GKM 498 enforcement at registration time, an insider Adversary could pretend 499 to support only a weak cryptographic algorithm. An accomplice to the 500 Adversary could eavesdrop and apply cryptoanalysis on the weakened 501 transmissions without the insider Adversary risking detection by 502 explicitly disclosing the key or plain text. To avoid this attack, a 503 Composite IPsec Group depends on the Group Owner designing a 504 membership authorization policy that forces each candidate Group 505 Receiver member to only join the Basic IPsec Group that implements 506 the strongest algorithms that their IPsec subsystem is known to 507 support. Special care must be taken when authorizing a Group Speaker, 508 as a group member in that role becomes a member of every Basic IPsec 509 Group. 511 A Composite Group Distributor under the control of an insider 512 Adversary could create a covert channel by altering the order in 513 which it multicast an IP packet to each Basic IP Group. An accomplice 514 Multicast IPsec Composite Cryptographic Groups 516 to the Adversary who observed a long sequence of IP packet multicasts 517 could assemble the covert message from a codebook. Each symbol would 518 be represented by a different sequence of Basic IPsec Group 519 transmissions. 521 6.3 Implementation or Deployment Issues that Impact Security 523 The most prominent barrier to a successful Composite IPsec Group 524 deployment is the complexity of designing a composite group security 525 policy. Factors that should be considered when designing such 526 policies include: 528 o For each Basic IPsec Group, the policy should delegate the 529 subordinate GCKS role to the group member with the highest 530 trustworthiness amongst all members of that sub-group. 532 o A Group Receiver identity should be an authorised member of only 533 one Basic IPsec Group and that sub-group should represent the 534 strongest cryptographic algorithm that the member is capable of 535 supporting. 537 o The Group Speaker role is endowed with a membership in every sub- 538 group, and therefore this role should be authorised for only the 539 group's most trustworthy members. 541 o The weakest Basic IPsec Group should be the focal point for 542 retirement efforts, with the goal of moving its membership to 543 better cryptographic algorithms. 545 o A host system implementing the Composite Group Distributor 546 component will necessarily incur substantially more encryption 547 processing overhead, in proportion to the number of Basic IPsec 548 Groups that form the Composite IPsec Group. Consequently, care 549 should be exercised to minimise the number of Basic IPsec Groups. 551 o The use of ESP padding, frequent key changes, and a separate key 552 for each IPsec SA can help mitigate traffic analysis attacks that 553 compare the cipher-texts sent to multiple Basic IPsec Groups. 555 7. Acknowledgements 557 [TBD] 559 8. References 561 8.1 Normative References 563 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 564 1112, August 1989. 566 Multicast IPsec Composite Cryptographic Groups 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Level", BCP 14, RFC 2119, March 1997. 571 [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on 572 Security Considerations", RFC 3552, July 2003. 574 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 575 Internet Protocol", RFC 4301, December 2005. 577 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 578 2005. 580 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 581 4303, December 2004. 583 [Weis] Weis B., Gross G., Ignjatic D., "Multicast Extensions to the 584 Security Architecture for the Internet", draft-ietf-msec-extensions- 585 03.txt, October 2006, work in progress. 587 8.2 Informative References 589 [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse 590 Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. 592 [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast 593 Addresses", RFC 2526, March 1999. 595 [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 596 September 2000. 598 [RFC3171] Albanni, Z., et. al., "IANA G uidelines fo r IPv4 599 Multic ast Address Assignments", RFC 3171, August 2001. 601 [RFC3376] Cain, B., et. al., "Internet Group Management Protocol, 602 Version 3", RFC 3376, October 2002. 604 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 605 Group Domain of Interpretation", RFC 3547, December 2002. 607 [RFC3569] Bhatta charyya, S., "An Ov erview of So urce-Specifi c 608 Multic ast (SSM)", RFC 3569, July 2003. 610 [RFC3940] Adamso n, B., et. a l., "Negative-a cknowledgmen t (NACK)- 611 Orient ed Reliable Multicast (N ORM) Protoco l", RFC 3940, November 612 2004. 614 [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant 615 Authentication (TESLA): Multicast Source Authentication Transform 616 Introduction", RFC 4082, June 2005. 618 Multicast IPsec Composite Cryptographic Groups 620 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 621 4306, December 2005. 623 [RFC4359] Weis., B., "The Use of RSA/SHA-1 Signatures within 624 Encapsulating Security Payload (ESP) and Authentication Header (AH)", 625 RFC 4359, January 2006. 627 [RFC3451] Luby, M., et al, "Layered Coding Transport (LCT) Building 628 Block", RFC3451, December 2002. 630 Multicast IPsec Composite Cryptographic Groups 631 Multicast IPsec Composite Cryptographic Groups 633 APPENDIX A: Examples of Composite Cryptographic Group Use Cases 635 The following is a non-exhaustive list that identifies other 636 representative use cases where a Composite Group could be applied: 638 - A group policy that allows the use of both IETF standard and 639 vendor-specific cryptographic algorithms. 641 - A group straddling both IP-v4 and IP-v6 endpoints. For a group 642 spanning IP-v4 and IP-v6, the Group Speaker endpoint's Node must be 643 dual stack capable. 645 - A single group using a Reliable Multicast Transport protocol (RTMP) 646 that has a heterogeneous deployment of error recovery algorithms 647 (e.g. Forward Error Correction codes) at its endpoint population. 648 Each RMTP version is configured as a sub-group at a distinct 649 multicast destination IP address. In this case, the application's 650 payload is replicated within the Group Speaker before being 651 distributed to each RMTP version-specific subsystem. The Group 652 Speaker endpoint's system must implement all of the RMTP sub-group 653 versions. 655 - There are multiple multicast routing domains supporting the IPsec 656 group, each routing domain imposing its own policy defined multicast 657 IP address. The Composite Group Distributor must alter the multicast 658 destination IP address for each copy of the multicast packet before 659 it is sent to its respective routing domain. 661 - A multicast application wherein the Composite Group is the union of 662 multiple source-specific IP multicast groups. For example, a multi- 663 homed Group Speaker might require this configuration. 665 In principal, each of the above examples could be decomposed into 666 multiple independent basic IPsec cryptographic groups. However, that 667 incurs a commensurate increase in the multicast application's 668 overhead to discover, join, and manage each of those groups. A 669 preferable solution is for the multicast application to join one 670 Composite Group 672 Figures A-1, A-2, and A-3 illustrate several representative composite 673 group use cases. 675 Multicast IPsec Composite Cryptographic Groups 677 +--------+------------+ 678 | | . 679 | Subgrp1 | 680 | ^ +-------+| 681 | | | Group || 682 | | |Speaker|| 683 | | +--+----+| 684 | | | | 685 | +------+-----V--+ | 686 +---------------+ | | Group Speaker | | +---------------+ 687 | Subgrp2, <------+Composite Group+------> Subgrp4, | 688 | No Speaker | | | Distributor | | | No Speaker | 689 +---------------+ | +------+------ + | +---------------+ 690 | | | 691 +---------|-----------+ 692 | 693 +------V--------+ 694 | Subgrp3, | 695 | No Speaker | 696 +---------------+ 698 Figure A-1: A simple Composite Group with a single Group Speaker 699 multicasting to 4 Basic IPsec Subgroups, each subgroup having a 700 different group security policy. The Group Speaker multicasts to all 701 four subgroups but it will receive its multicast traffic from only 702 from "Subgrp1". The Group Speaker's Composite Group Distributor (CGD) 703 replicates each of the Group Speaker's IP packets, transforms each 704 copied packet according to its respective Basic IPsec Subgroup's 705 security policy, and sends that copied packet to its subgroup. The 706 Composite Group's security policy specifies each Basic IPsec 707 Subgroup's membership authorization. 709 Multicast IPsec Composite Cryptographic Groups 711 +------+--------+ 712 | Subgrp1, CGD1 | . 713 | Speaker1 | 714 +------+--------+ 715 | 716 | 717 +---------------+ +------+--------+ +---------------+ 718 | Subgrp2, CGD2 +-----+ Satellite + ------+ Subgrp4, CGD4 | 719 | Speaker2 | | DVB network | | No Speaker | 720 +---------------+ +------+------ + +---------------+ 721 | 722 | 723 +------+--------+ 724 | Subgrp3, CGD3 | 725 | No Speaker | 726 +---------------+ 728 Figure A-2: A Composite Group containing 4 Basic IPsec Subgroups, 729 with each subgroup having its own S-GCKS. There are 5 LKH trees, one 730 for each subgroup managed by a S-GCKS and one LKH tree managed by the 731 primary GCKS for the set of S-GCKS. 733 Multicast IPsec Composite Cryptographic Groups 735 Figure A-3 illustrates a reliable multicast scenario using Layered 736 Coding Transport (LCT) as specified in RFC 3451 [RFC3451]. Each 737 subgroup corresponds to a LCT layer. Reliable content delivery and 738 streaming applications could leverage this type of configuration. 740 +------+--------+ 741 | Sub-group1, | . 742 | LCT layer1 | 743 +------A--------+ 744 | 745 | 746 +---------------+ +------+--------+ +---------------+ 747 | Sub-group2 <-----+ Multi-layered + ------> Sub-group 4 | 748 | LCT layer2 | | Reliable | | LCT layer4 | 749 +---------------+ | Multicast CGD | +---------------+ 750 +------+--------+ 751 | 752 | 753 +------V--------+ 754 | Sub-group3 | 755 | LCT layer3 | 756 +---------------+ 758 Figure A-3: 4 The LCT groups are organized as Basic IPsec Subgroups 759 managed by a centralized GCKS. 761 Author's Address 763 George Gross 764 IdentAware Security 765 82 Old Mountain Road 766 Lebanon, NJ 08833, USA 767 908-268-1629 768 gmgross@identaware.com 770 Haitham Cruickshank 771 Centre for Communications System Research (CCSR) 772 University of Surrey 773 Guildford, Surrey, GU2 7XH 774 UK 775 Email: h.cruickshank@surrey.ac.uk 776 Multicast IPsec Composite Cryptographic Groups 778 Intellectual Property Statement 780 The IETF takes no position regarding the validity or scope of any 781 Intellectual Property Rights or other rights that might be claimed 782 to pertain to the implementation or use of the technology 783 described in this document or the extent to which any license 784 under such rights might or might not be available; nor does it 785 represent that it has made any independent effort to identify any 786 such rights. Information on the procedures with respect to rights 787 in RFC documents can be found in BCP 78 and BCP 79. 789 Copies of IPR disclosures made to the IETF Secretariat and any 790 assurances of licenses to be made available, or the result of an 791 attempt made to obtain a general license or permission for the use 792 of such proprietary rights by implementers or users of this 793 specification can be obtained from the IETF on-line IPR repository 794 at http://www.ietf.org/ipr. 796 The IETF invites any interested party to bring to its attention any 797 copyrights, patents or patent applications, or other proprietary 798 rights that may cover technology that may be required to implement 799 this standard. Please address the information to the IETF at ietf- 800 ipr@ietf.org 802 Disclaimer of Validity 804 This document and the information contained herein are provided on an 805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 807 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 808 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 809 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 812 Copyright Statement 814 Copyright (C) The Internet Society (2006). 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.