Internet Engineering Task Force George Gross (IdentAware) INTERNET-DRAFT draft-gross-msec-ipsec-composite-group-00 Expires: December, 2006 June, 2006 Multicast IP Security Composite Cryptographic Groups Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Multicast IP Security extension architecture [Weis] implicitly assumes a basic group endpoint population that shares homogeneous cryptographic capabilities and security policies. In practice, large- scale cryptographic groups may contain a heterogeneous endpoint population that can not be accommodated by that basic multicast IPsec architecture. For example, some endpoints may not have been upgraded to handle the successor algorithm for one that is being retired (e.g. SHA1 transition to SHA-ng). This document defines the "composite cryptographic group" IP security architecture capability. A composite cryptographic group allows multicast IPsec applications to transparently interact with the single logical group that is formed by the union of one or more basic cryptographic groups. Multicast IPsec Composite Cryptographic Groups June, 2006 Table of Contents 1. Introduction .......................................................3 1.1 Scope ...........................................................3 1.2 Terminology .....................................................4 2. Composite IPsec Group Architecture .................................5 2.1 Transport Mode Composite Group Distributor ......................6 2.2 Tunnel Mode Composite Group Distributor .........................6 3. Group Key Management Protocol Composite IPsec Group Requirements ...7 3.1 IPsec Security Association Identifier Assignment ................7 3.2 Group Receiver Composite IPsec Group Membership .................7 3.3 Group Speaker Composite IPsec Group Membership ..................7 5. IANA Considerations ................................................8 6. Security Considerations ............................................8 7. Acknowledgements ...................................................8 8. References .........................................................8 8.1 Normative References ............................................8 8.2 Informative References ..........................................9 Appendix A _ Examples of Composite Cryptographic Group Use Cases .....10 Author's Address .....................................................11 Intellectual Property Statement ......................................12 Copyright Statement ..................................................12 Gross Expires December, 2006 [Page 2] Multicast IPsec Composite Cryptographic Groups June, 2006 1. Introduction In a basic IPsec cryptographic group there is a 1:1 relationship between an IPsec group's data security association, a multicast application, and a multicast IP address. All of the group members share identical cryptographic capabilities and they abide by a common security policy. IPsec subsystems that are compliant to the [Weis] standard by definition support basic IPsec cryptographic groups. For a small-scale cryptographic group, it is operationally feasible to maintain a homogenous endpoint population. In contrast, large- scale cryptographic groups may be heterogeneous in both their cryptographic capabilities and/or their security policies. o The differences in cryptographic capabilities can arise when subsets of the group's membership are in transition, migrating from one version of a cryptographic algorithm to its successor (e.g. SHA-1 hash function to SHA-ng). It is unreasonable to expect that a large-scale group membership should upgrade to new capabilities in a flash cut operation. o Heterogeneous security policies can occur when a cryptographic group's membership straddles legal or security domain boundaries. An example is a multi-national cryptographic group, for which some endpoints reside in a country that enforces legislation that specifies weaker cipher key strengths. The above two requirements motivate the implementation and operation of a "composite IPsec cryptographic group". A composite IPsec cryptographic group is the union of two or more non-overlapping basic IPsec cryptographic sub-groups. For sake of brevity, the terms "Composite IPsec Group" and "Basic IPsec Subgroup" will be used in subsequent text. The goal of a Composite IPsec Group is to accommodate a large-scale group membership population that contains heterogeneous capabilities, policies, or other attributes. Appendix A enumerates additional use cases that can be satisfied by Composite IPsec Groups. A strong benefit of IPsec is that it applies its security processing at the IP layer. Consequently, upper layer application programs can execute securely without reprogramming or any awareness that IPsec services are present. The additional benefit of a Composite IPsec Group is that it shields the multicast application from the IP layer complexity of the two or more Basic IPsec Subgroups. The application multicasts its messages to what appear to be a single homogeneous multicast group. 1.1 Scope The IPsec extensions described in this document support IPsec Security Associations that result in IPsec packets with IPv4 or IPv6 Gross Expires December, 2006 [Page 3] Multicast IPsec Composite Cryptographic Groups June, 2006 multicast group addresses as the destination address. Both Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569, RFC3376] group addresses are supported. These extensions also support Security Associations with IPv4 Broadcast addresses that result in an IPv4 Broadcast packet, and IPv6 Anycast addresses [RFC2526] that result in an IPv6 Anycast packet. These destination address types share many of the same characteristics of multicast addresses because there may be multiple receivers of a packet protected by IPsec. The IPsec Architecture does not make requirements upon entities not participating in IPsec (e.g., network devices between IPsec endpoints). As such, these multicast extensions do not require intermediate systems in a multicast enabled network to participate in IPsec. In particular, no requirements are placed on the use of multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast admission protocols (e.g., IGMP [RFC3376]. All implementation models of IPsec (e.g., "bump-in-the-stack", "bump- in-the-wire") are supported. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The following key terms are used throughout this document. Any-Source Multicast (ASM) The Internet Protocol (IP) multicast service model as defined in RFC 1112 [RFC1112]. In this model one or more senders source packets to a single IP multicast address. When receivers join the group, they receive all packets sent to that IP multicast address. This is known as a (*,G) group. Group Controller Key Server (GCKS) A Group Key Management Protocol (GKMP) server that manages IPsec state for a group. A GCKS authenticates and provides the IPsec SA policy and keying material to GKMP group members. Group Key Management Protocol (GKMP) A key management protocol used by a GCKS to distribute IPsec Security Association policy and keying material. A GKMP is used when a group of IPsec devices require the same SAs. For example, when an IPsec SA describes an IP multicast destination, the sender and all receivers must have the group SA. Gross Expires December, 2006 [Page 4] Multicast IPsec Composite Cryptographic Groups June, 2006 GKMP Subsystem A subsystem in an IPsec device implementing a Group Key Management Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec subsystem on the IPsec device. Group Member An IPsec device that belongs to a group. A Group Member is authorized to be a Group Speaker and/or a Group Receiver. Group Owner An administrative entity that chooses the policy for a group. Group Security Association (GSA) A collection of IPsec Security Associations (SAs) and GKMP Subsystem SAs necessary for a Group Member to receive key updates. A GSA describes the working policy for a group. Group Receiver A Group Member that is authorized to receive packets sent to a group by a Group Speaker. Group Speaker A Group Member that is authorized to send packets to a group. Source-Specific Multicast (SSM) The Internet Protocol (IP) multicast service model as defined in RFC 3569 [RFC3569]. In this model, each combination of a sender and an IP multicast address is considered a group. This is known as an (S,G) group. Tunnel Mode with Address Preservation A type of IPsec tunnel mode used by security gateway implementations when encapsulating IP multicast packets such that they remain IP multicast packets. This mode is necessary in order for IP multicast routing to correctly route IP multicast packets that are protected by IPsec. 2. Composite IPsec Group Architecture The GCKS and the Group Members must support a Group Key Management Protocol (GKMP) that can negotiate a Composite IPsec Group's membership join or leave operation. The group key management subsystem configures one or more IPsec subsystems to reflect the Composite IPsec Group's revised state. In addition, the GCKS configures a supporting Composite Group Distributor component Gross Expires December, 2006 [Page 5] Multicast IPsec Composite Cryptographic Groups June, 2006 whenever a new Group Speaker endpoint joins the Composite IPsec Group. The Composite Group Distributor handles the data flowing from a multicast application's Group Speaker endpoint to the IPsec subsystem. When the multicast application requests a message transmission to the Composite IPsec Group's endpoints, the Composite Group Distributor component transparently intercepts and replicates that message for multicast delivery to each Basic IPsec Subgroup. Sections 2.1 and 2.2 define the Composite Group Distributor's architectural role for transport mode and tunnel mode IPsec security associations. Section 3 provides the GKMP requirements for Composite IPsec Group capability. 2.1 Transport Mode Composite Group Distributor For a Composite IPsec Group transport mode security association, it is the responsibility of the Composite Group Distributor to rewrite each message copy's destination IP address before it is multicast to the respective Basic IPsec Subgroup. The IPsec subsystem's SPD traffic selectors then evaluate that message, and apply the Basic IPsec Subgroup's security association transform. Since a single IPsec subsystem supports the Group Speaker, that IPsec subsystem MUST support all of the outbound security transforms required by all of the Basic IPsec Subgroups that form the Composite IPsec Group. Regardless of the Composite Group Distributor's underlying implementation, it is a requirement that the two or more security transforms applied by the IPsec subsystem to the multicast application's replicated data streams MUST remain transparent to that application's Group Speaker endpoint. Each Basic IPsec Subgroup MUST be allocated a unique multicast destination IP address. Appendix B provides non-normative guidance for the implementation of a Composite Group Distributor supporting IPsec transport mode security associations. 2.2 Tunnel Mode Composite Group Distributor For a Composite IPsec Group tunnel mode security association, the Composite Group Distributor component is simply the multicast routing infrastructure residing on the network path between the Group Speaker endpoint and two or more IPsec subsystems. Typically, the IPsec subsystems are IPsec security gateways. In a tunnel mode configuration, there is a parallel IPsec subsystem instance per Basic IPsec Subgroup. Unlike transport mode, in tunnel mode the Composite Group Distributor does not rewrite the destination IP multicast address for each Basic IPsec Subgroup. Instead, each IPsec subsystem SPD independently recognizes the message addressed to the Composite IPsec Group destination IP address, and applies the IPsec tunnel mode security transform for its respective Basic IPsec Subgroup. Each IPsec subsystem MUST use a unique Security Parameter Index for their security association instance. The GKMP is responsible for allocating the SPI for each tunnel mode security association, so that they are uniquely identified when the replicated messages are distributed to the Composite IPsec Group. Gross Expires December, 2006 [Page 6] Multicast IPsec Composite Cryptographic Groups June, 2006 Note that in tunnel mode, there is one multicast distribution tree representing the Composite IPsec Group rather than a multicast distribution tree per Basic IPsec Subgroup. All of the message copies are multicast to the Composite IPsec Group's multicast IP address. Consequently, the Group Receiver IPsec subsystems use the SPI to de- multiplex which one of the message replicas are addressed to its Basic IPsec Subgroup. 3. Group Key Management Protocol Composite IPsec Group Requirements A Group Key Management Protocol subsystem supporting Composite IPsec Groups is responsible for configuring the Group Speaker's Composite Group Distributor and one or more IPsec SPD/SAD to create and manage a Composite IPsec Group membership. Those GKMP subsystems that choose to implement the optional Composite IPsec Group capability MUST support both Group Receivers and Group Speakers, as defined below in section 3.2 and section 3.3 respectively. 3.1 IPsec Security Association Identifier Assignment Each Basic IPsec Subgroup MUST have a group data IPsec security association identifier allocation from the GKMP subsystem that is unique relative to all other security associations in the Composite IPsec Group. For an any-source multicast group, the security association identifier is the 2-tuple {destination multicast IP address, Security Parameter Index}. If the Composite IPsec Group is using Source-Specific Multicast, then the IPsec security association identifier MUST be composite group-wide unique for the 3-tuple: {source IP address, destination multicast IP address, Security Parameter Index}. 3.2 Group Receiver Composite IPsec Group Membership A Group Receiver endpoint acquires membership in only one Basic IPsec Subgroup within a Composite IPsec Group. When a Group Receiver endpoint requests to join the Composite IPsec Group, the registration protocol exchange MUST select the Group Receiver's membership in one of the Basic IPsec Subgroups. The Basic IPsec Subgroup selection can be implicit (i.e. pre-configured at the GCKS) or explicitly negotiated by registration protocol exchanges between the candidate Group Receiver and the GCKS. The GKMP specification defines the registration protocol exchange negotiation. When evaluating a candidate Group Receiver's registration request, the GCKS MUST enforce the authentication and membership authorization policies of the Basic IPsec Subgroup that the candidate Group Receiver has requested membership. 3.3 Group Speaker Composite IPsec Group Membership When a Group Speaker endpoint registers with a GCKS to join a Composite IPsec Group, the Group Speaker implicitly joins all of the Basic IPsec Subgroups as a speaker in each subgroup. The GCKS sets up the Composite IPsec Group such that when the multicast application Gross Expires December, 2006 [Page 7] Multicast IPsec Composite Cryptographic Groups June, 2006 Group Speaker endpoint sends a single message to the Composite IPsec Group, it is received once at each Group Receiver endpoint within the two or more Basic IPsec Groups. The GCKS and GKMP is responsible for the following actions: o The GCKS MUST authenticate and authorize the candidate Group Speaker endpoint before allowing it to become a Composite IPsec Group Speaker. The speaker authorization is contingent on the approval of both the Composite IPsec Group policy and the logical- AND authorization of all of the Basic IPsec Group policies. o For each Basic IPsec Group, the GCKS allocates a new group IPsec security association instance representing the new Group Speaker. The GCKS uses the GKMP to distribute and then activate that IPsec security association's configuration in the IPsec subsystem SPD/SAD of every Group Receiver endpoint within the subgroup. In addition, the GCKS chooses one IPsec subsystem to be the Group Speaker's representative in that Basic IPsec Group, and configures its SPD/SAD for that role. o For an IPsec transport mode security association, the GCKS explicitly directs the Group Speaker's Composite Group Distributor to intercept and replicate the Group Speaker's data traffic before multicasting it to each Basic IPsec Group. The trusted control interface between the GCKS and Composite Group Distributor is implementation specific and it is outside the scope of this specification. 5. IANA Considerations This document does not require any IANA action. 6. Security Considerations This document describes architecture for securing group network traffic using IPsec. As such, security considerations are found throughout this document. 7. Acknowledgements [TBD] 8. References 8.1 Normative References [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, August 1989. Gross Expires December, 2006 [Page 8] Multicast IPsec Composite Cryptographic Groups June, 2006 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2004. [Weis] Weis B., Gross G., Ignjatic D., "Multicast Extensions to the Security Architecture for the Internet", draft-ietf-msec-extensions- 01.txt, February 2006, work in progress. 8.2 Informative References [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000. [RFC3171] Albanni, Z., et. al., "IANA G uidelines fo r IPv4 Multic ast Address Assignments", RFC 3171, August 2001. [RFC3376] Cain, B., et. al., "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, December 2002. [RFC3569] Bhatta charyya, S., "An Ov erview of So urce-Specifi c Multic ast (SSM)", RFC 3569, July 2003. [RFC3940] Adamso n, B., et. a l., "Negative-a cknowledgmen t (NACK)- Orient ed Reliable Multicast (N ORM) Protoco l", RFC 3940, November 2004. [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. Gross Expires December, 2006 [Page 9] Multicast IPsec Composite Cryptographic Groups June, 2006 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4359] Weis., B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006. [ZLLY03] Zhang, X., et. al., "Protocol Design for Scalable and Reliable Group Rekeying", IEEE/ACM Transactions on Networking (TON), Volume 11, Issue 6, December 2003. See http://www.cs.utexas.edu/users/lam/Vita/Cpapers/ZLLY01.pdf. Appendix A _ Examples of Composite Cryptographic Group Use Cases The following is a non-exhaustive list that identifies other representative use cases where a Composite Group could be applied: - A group policy that allows the use of both IETF standard and vendor-specific cryptographic algorithms. - A group straddling both IP-v4 and IP-v6 endpoints. For a group spanning IP-v4 and IP-v6, the Group Speaker endpoint's Node must be dual stack capable. - A single group using a Reliable Multicast Transport protocol (RTMP) that has a heterogeneous deployment of error recovery algorithms (e.g. Forward Error Correction codes) at its endpoint population. Each RMTP version is configured as a sub-group at a distinct multicast destination IP address. In this case, the application's payload is replicated within the Group Speaker before being distributed to each RMTP version-specific subsystem. The Group Speaker endpoint's system must implement all of the RMTP sub-group versions. - There are multiple multicast routing domains supporting the IPsec group, each routing domain imposing its own policy defined multicast IP address. The Composite Group Distributor must alter the multicast destination IP address for each copy of the multicast packet before it is sent to its respective routing domain. - A multicast application wherein the Composite Group is the union of multiple source-specific IP multicast groups. For example, a multi- homed Group Speaker might require this configuration. In principal, each of the above examples could be decomposed into multiple independent basic IPsec cryptographic groups. However, that incurs a commensurate increase in the multicast application's overhead to discover, join, and manage each of those groups. A preferable solution is for the multicast application to join one Composite Group Gross Expires December, 2006 [Page 10] Multicast IPsec Composite Cryptographic Groups June, 2006 Author's Address George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833 908-268-1629 gmgross@identaware.com Gross Expires December, 2006 [Page 11] Multicast IPsec Composite Cryptographic Groups June, 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Gross Expires December, 2006 [Page 12]