One document matched: draft-gross-msec-ipsec-composite-group-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-20 11:32:02 |