draft-ietf-msec-ipsec-composite-group-00.txt   draft-ietf-msec-ipsec-composite-group-01.txt 
Internet Engineering Task Force George Gross (IdentAware) Internet Engineering Task Force George Gross (IdentAware)
INTERNET-DRAFT (experimental track) H. Cruickshank INTERNET-DRAFT (experimental track) H. Cruickshank
(CCSR, U. of Surrey) (CCSR, U. of Surrey)
draft-ietf-msec-ipsec-composite-group-00 draft-ietf-msec-ipsec-composite-group-01
Expires: May, 2006 November, 2006 Expires: August, 2007 February, 2007
Multicast IP Security Composite Cryptographic Groups Multicast IP Security Composite Cryptographic Groups
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
skipping to change at page 2, line ? skipping to change at page 1, line 36
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Multicast IP Security extension architecture [Weis] implicitly The Multicast IP Security extension architecture [Weis] implicitly
assumes a basic group endpoint population that shares homogeneous assumes a basic group endpoint population that shares homogeneous
cryptographic capabilities and security policies. In practice, large- cryptographic capabilities and security policies. In practice, large-
scale cryptographic groups may contain a heterogeneous endpoint scale cryptographic groups may contain a heterogeneous endpoint
population that can not be accommodated by that basic multicast IPsec population that can not be accommodated by that basic multicast IPsec
architecture. For example, some endpoints may not have been upgraded architecture. For example, some endpoints may not have been upgraded
to handle the successor algorithm for one that is being retired (e.g. to handle the successor algorithm for one that is being retired (e.g.
skipping to change at page 2, line ? skipping to change at page 2, line 12
to transparently interact with the single logical group that is to transparently interact with the single logical group that is
formed by the union of one or more basic cryptographic groups. formed by the union of one or more basic cryptographic groups.
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
Table of Contents Table of Contents
1. Introduction .......................................................3 1. Introduction .......................................................3
1.1 Scope ...........................................................3 1.1 Scope ...........................................................3
1.2 Terminology .....................................................4 1.2 Terminology .....................................................4
2. Composite IPsec Group Architecture .................................5 2. Composite IPsec Group Architecture .................................5
2.1 Transport Mode Composite Group Distributor ......................6 2.1 Transport Mode Composite Group Distributor ......................6
2.2 Tunnel Mode Composite Group Distributor .........................6 2.2 Tunnel Mode Composite Group Distributor .........................6
2.3 Rationale for Multicast Destination IP Address and SPI Assignment7 2.3 Rationale for Multicast Destination IP Address and SPI Assignment7
3. Group Key Management Protocol Composite IPsec Group Requirements ...7 3. Group Key Management Protocol Composite IPsec Group Requirements ...7
3.1 IPsec Security Association Identifier Assignment ................7 3.1 IPsec Security Association Identifier Assignment................8
3.2 Group Receiver Composite IPsec Group Membership .................8 3.2 Group Receiver Composite IPsec Group Membership .................8
3.3 Group Speaker Composite IPsec Group Membership ..................8 3.3 Group Speaker Composite IPsec Group Membership ..................8
5. IANA Considerations ................................................9 5. IANA Considerations ................................................9
6. Security Considerations ............................................9 6. Security Considerations ............................................9
6.1 Security Issues Solved by Composite IPsec Groups ................9 6.1 Security Issues Solved by Composite IPsec Groups ................9
6.2 Security Issues Not Solved by Composite IPsec Groups ............9 6.2 Security Issues Not Solved by Composite IPsec Groups ............9
6.2.1 Outsider Attacks ...........................................10 6.2.1 Outsider Attacks ...........................................10
6.2.2 Insider Attacks ............................................10 6.2.2 Insider Attacks ............................................10
6.3 Implementation or Deployment Issues that Impact Security .......11 6.3 Implementation or Deployment Issues that Impact Security .......11
7. Acknowledgements ..................................................11 7. Acknowledgements ..................................................11
8. References ........................................................11 8. References ........................................................11
8.1 Normative References ...........................................11 8.1 Normative References ...........................................11
8.2 Informative References .........................................12 8.2 Informative References .........................................12
APPENDIX A: Examples of Composite Cryptographic Group Use Cases ......15 APPENDIX A: Examples of Composite Cryptographic Group Use Cases ......15
Author's Address .....................................................18 Author's Address .....................................................18
Intellectual Property Statement ......................................19 Intellectual Property Statement ......................................19
Copyright Statement ..................................................19 Copyright Statement ..................................................19
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
1. Introduction 1. Introduction
In a basic IPsec cryptographic group there is a 1:1 relationship In a basic IPsec cryptographic group there is a 1:1 relationship
between an IPsec group's data security association, a multicast between an IPsec group's data security association, a multicast
application, and a multicast IP address. All of the group members application, and a multicast IP address. All of the group members
share identical cryptographic capabilities and they abide by a common share identical cryptographic capabilities and they abide by a common
security policy. IPsec subsystems that are compliant to the [Weis] security policy. IPsec subsystems [RFC4301] [RFC4302] [RFC4303] that
standard by definition support basic IPsec cryptographic groups. are compliant to the [Weis] standard by definition support basic
IPsec cryptographic groups.
For a small-scale cryptographic group, it is operationally feasible For a small-scale cryptographic group, it is operationally feasible
to maintain a homogenous endpoint population. In contrast, large- to maintain a homogenous endpoint population. In contrast, large-
scale cryptographic groups may be heterogeneous in both their scale cryptographic groups may be heterogeneous in both their
cryptographic capabilities and/or their security policies. cryptographic capabilities and/or their security policies.
o The differences in cryptographic capabilities can arise when o The differences in cryptographic capabilities can arise when
subsets of the group's membership are in transition, migrating from subsets of the group's membership are in transition, migrating from
one version of a cryptographic algorithm to its successor (e.g. 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 SHA-1 hash function to SHA-ng). It is unreasonable to expect that a
large-scale group membership should upgrade to new capabilities in large-scale group membership should upgrade to new capabilities in
skipping to change at page 3, line 54 skipping to change at page 4, line 5
at the IP layer. Consequently, upper layer application programs can at the IP layer. Consequently, upper layer application programs can
execute securely without reprogramming or any awareness that IPsec execute securely without reprogramming or any awareness that IPsec
services are present. The additional benefit of a Composite IPsec services are present. The additional benefit of a Composite IPsec
Group is that it shields the multicast application from the IP layer Group is that it shields the multicast application from the IP layer
complexity of the two or more Basic IPsec Subgroups. The application complexity of the two or more Basic IPsec Subgroups. The application
multicasts its messages to what appear to be a single homogeneous multicasts its messages to what appear to be a single homogeneous
multicast group. multicast group.
1.1 Scope 1.1 Scope
The IPsec extensions described in this document support IPsec
Security Associations that result in IPsec packets with IPv4 or IPv6
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
The IPsec extensions described in this document support IPsec
Security Associations that result in IPsec packets with IPv4 or IPv6
multicast group addresses as the destination address. Both Any-Source multicast group addresses as the destination address. Both Any-Source
Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569, Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569,
RFC3376] group addresses are supported. RFC3376] group addresses are supported.
These extensions also support Security Associations with IPv4 These extensions also support Security Associations with IPv4
Broadcast addresses that result in an IPv4 Broadcast packet, and IPv6 Broadcast addresses that result in an IPv4 Broadcast packet, and IPv6
Anycast addresses [RFC2526] that result in an IPv6 Anycast packet. Anycast addresses [RFC2526] that result in an IPv6 Anycast packet.
These destination address types share many of the same These destination address types share many of the same
characteristics of multicast addresses because there may be multiple characteristics of multicast addresses because there may be multiple
receivers of a packet protected by IPsec. receivers of a packet protected by IPsec.
skipping to change at page 4, line 55 skipping to change at page 5, line 4
A Group Key Management Protocol (GKMP) server that manages IPsec A Group Key Management Protocol (GKMP) server that manages IPsec
state for a group. A GCKS authenticates and provides the IPsec SA state for a group. A GCKS authenticates and provides the IPsec SA
policy and keying material to GKMP group members. policy and keying material to GKMP group members.
Group Key Management Protocol (GKMP) Group Key Management Protocol (GKMP)
A key management protocol used by a GCKS to distribute IPsec A key management protocol used by a GCKS to distribute IPsec
Security Association policy and keying material. A GKMP is used Security Association policy and keying material. A GKMP is used
when a group of IPsec devices require the same SAs. For example, 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.
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
when an IPsec SA describes an IP multicast destination, the sender
and all receivers must have the group SA.
GKMP Subsystem GKMP Subsystem
A subsystem in an IPsec device implementing a Group Key Management A subsystem in an IPsec device implementing a Group Key Management
Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec
subsystem on the IPsec device. subsystem on the IPsec device.
Group Member Group Member
An IPsec device that belongs to a group. A Group Member is An IPsec device that belongs to a group. A Group Member is
authorized to be a Group Speaker and/or a Group Receiver. authorized to be a Group Speaker and/or a Group Receiver.
skipping to change at page 5, line 56 skipping to change at page 6, line 4
implementations when encapsulating IP multicast packets such that implementations when encapsulating IP multicast packets such that
they remain IP multicast packets. This mode is necessary in order they remain IP multicast packets. This mode is necessary in order
for IP multicast routing to correctly route IP multicast packets for IP multicast routing to correctly route IP multicast packets
that are protected by IPsec. that are protected by IPsec.
2. Composite IPsec Group Architecture 2. Composite IPsec Group Architecture
The GCKS and the Group Members must support a Group Key Management The GCKS and the Group Members must support a Group Key Management
Protocol (GKMP) that can negotiate a Composite IPsec Group's Protocol (GKMP) that can negotiate a Composite IPsec Group's
membership join or leave operation. The group key management membership join or leave operation. The group key management
Multicast IPsec Composite Cryptographic Groups
subsystem configures one or more IPsec subsystems to reflect the subsystem configures one or more IPsec subsystems to reflect the
Composite IPsec Group's revised state. In addition, the GCKS Composite IPsec Group's revised state. In addition, the GCKS
configures a supporting Composite Group Distributor component configures a supporting Composite Group Distributor component
Multicast IPsec Composite Cryptographic Groups
whenever a new Group Speaker endpoint joins the Composite IPsec whenever a new Group Speaker endpoint joins the Composite IPsec
Group. The Composite Group Distributor handles the data flowing from Group. The Composite Group Distributor handles the data flowing from
a multicast application's Group Speaker endpoint to the IPsec a multicast application's Group Speaker endpoint to the IPsec
subsystem. When the multicast application requests a message subsystem. When the multicast application requests a message
transmission to the Composite IPsec Group's endpoints, the Composite transmission to the Composite IPsec Group's endpoints, the Composite
Group Distributor component transparently intercepts and replicates Group Distributor component transparently intercepts and replicates
that message for multicast delivery to each Basic IPsec Subgroup. that message for multicast delivery to each Basic IPsec Subgroup.
Sections 2.1 and 2.2 define the Composite Group Distributor's Sections 2.1 and 2.2 define the Composite Group Distributor's
architectural role for transport mode and tunnel mode IPsec security architectural role for transport mode and tunnel mode IPsec security
associations. Section 3 provides the GKMP requirements for Composite associations. Section 3 provides the GKMP requirements for Composite
skipping to change at page 6, line 55 skipping to change at page 7, line 4
subsystems are IPsec security gateways. In a tunnel mode subsystems are IPsec security gateways. In a tunnel mode
configuration, there is a parallel IPsec subsystem instance per Basic configuration, there is a parallel IPsec subsystem instance per Basic
IPsec Subgroup. Unlike transport mode, in tunnel mode the Composite IPsec Subgroup. Unlike transport mode, in tunnel mode the Composite
Group Distributor does not rewrite the destination IP multicast Group Distributor does not rewrite the destination IP multicast
address for each Basic IPsec Subgroup. Instead, each IPsec subsystem address for each Basic IPsec Subgroup. Instead, each IPsec subsystem
SPD independently recognizes the message addressed to the Composite SPD independently recognizes the message addressed to the Composite
IPsec Group destination IP address, and applies the IPsec tunnel mode IPsec Group destination IP address, and applies the IPsec tunnel mode
security transform for its respective Basic IPsec Subgroup. Each security transform for its respective Basic IPsec Subgroup. Each
IPsec subsystem MUST use a unique Security Parameter Index for their IPsec subsystem MUST use a unique Security Parameter Index for their
security association instance. The GKMP is responsible for allocating security association instance. The GKMP is responsible for allocating
Multicast IPsec Composite Cryptographic Groups
the SPI for each tunnel mode security association, so that they are the SPI for each tunnel mode security association, so that they are
uniquely identified when the replicated messages are distributed to uniquely identified when the replicated messages are distributed to
the Composite IPsec Group. the Composite IPsec Group.
Multicast IPsec Composite Cryptographic Groups
Note that in tunnel mode, there is one multicast distribution tree Note that in tunnel mode, there is one multicast distribution tree
representing the Composite IPsec Group rather than a multicast representing the Composite IPsec Group rather than a multicast
distribution tree per Basic IPsec Subgroup. All of the message copies distribution tree per Basic IPsec Subgroup. All of the message copies
are multicast to the Composite IPsec Group's multicast IP address. are multicast to the Composite IPsec Group's multicast IP address.
Consequently, the Group Receiver IPsec subsystems use the SPI to de- Consequently, the Group Receiver IPsec subsystems use the SPI to de-
multiplex which one of the message replicas is addressed to its Basic multiplex which one of the message replicas is addressed to its Basic
IPsec Subgroup. IPsec Subgroup.
2.3 Rationale for Multicast Destination IP Address and SPI Assignment 2.3 Rationale for Multicast Destination IP Address and SPI Assignment
skipping to change at page 7, line 56 skipping to change at page 8, line 5
3. Group Key Management Protocol Composite IPsec Group Requirements 3. Group Key Management Protocol Composite IPsec Group Requirements
A Group Key Management Protocol subsystem supporting Composite IPsec A Group Key Management Protocol subsystem supporting Composite IPsec
Groups is responsible for configuring the Group Speaker's Composite Groups is responsible for configuring the Group Speaker's Composite
Group Distributor and one or more IPsec SPD/SAD to create and manage Group Distributor and one or more IPsec SPD/SAD to create and manage
a Composite IPsec Group membership. Those GKMP subsystems that choose a Composite IPsec Group membership. Those GKMP subsystems that choose
to implement the optional Composite IPsec Group capability MUST to implement the optional Composite IPsec Group capability MUST
support both Group Receivers and Group Speakers, as defined below in support both Group Receivers and Group Speakers, as defined below in
section 3.2 and section 3.3 respectively. section 3.2 and section 3.3 respectively.
3.1 IPsec Security Association Identifier Assignment
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
3.1 IPsec Security Association Identifier Assignment
Each Basic IPsec Subgroup MUST have a group data IPsec security Each Basic IPsec Subgroup MUST have a group data IPsec security
association identifier allocation from the GKMP subsystem that is association identifier allocation from the GKMP subsystem that is
unique relative to all other security associations in the Composite unique relative to all other security associations in the Composite
IPsec Group. For an any-source multicast group, the security IPsec Group. For an any-source multicast group, the security
association identifier is the 2-tuple {destination multicast IP association identifier is the 2-tuple {destination multicast IP
address, Security Parameter Index}. If the Composite IPsec Group is address, Security Parameter Index}. If the Composite IPsec Group is
using Source-Specific Multicast, then the IPsec security association using Source-Specific Multicast, then the IPsec security association
identifier MUST be composite group-wide unique for the 3-tuple: identifier MUST be composite group-wide unique for the 3-tuple:
{source IP address, destination multicast IP address, Security {source IP address, destination multicast IP address, Security
Parameter Index}. Parameter Index}.
skipping to change at page 8, line 54 skipping to change at page 9, line 4
Group Speaker. The speaker authorization is contingent on the Group Speaker. The speaker authorization is contingent on the
approval of both the Composite IPsec Group policy and the logical- approval of both the Composite IPsec Group policy and the logical-
AND authorization of all of the Basic IPsec Group policies. AND authorization of all of the Basic IPsec Group policies.
o For each Basic IPsec Group, the GCKS allocates a new group IPsec o For each Basic IPsec Group, the GCKS allocates a new group IPsec
security association instance representing the new Group Speaker. security association instance representing the new Group Speaker.
The GCKS uses the GKMP to distribute and then activate that IPsec The GCKS uses the GKMP to distribute and then activate that IPsec
security association's configuration in the IPsec subsystem SPD/SAD security association's configuration in the IPsec subsystem SPD/SAD
of every Group Receiver endpoint within the subgroup. In addition, of every Group Receiver endpoint within the subgroup. In addition,
the GCKS chooses one IPsec subsystem to be the Group Speaker's 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.
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
representative in that Basic IPsec Group, and configures its
SPD/SAD for that role.
o For an IPsec transport mode security association, the GCKS o For an IPsec transport mode security association, the GCKS
explicitly directs the Group Speaker's Composite Group Distributor explicitly directs the Group Speaker's Composite Group Distributor
to intercept and replicate the Group Speaker's data traffic before to intercept and replicate the Group Speaker's data traffic before
multicasting it to each Basic IPsec Group. The trusted control multicasting it to each Basic IPsec Group. The trusted control
interface between the GCKS and Composite Group Distributor is interface between the GCKS and Composite Group Distributor is
implementation specific and it is outside the scope of this implementation specific and it is outside the scope of this
specification. specification.
5. IANA Considerations 5. IANA Considerations
skipping to change at page 9, line 55 skipping to change at page 10, line 5
a group multicast application must be re-programmed and re-configured a group multicast application must be re-programmed and re-configured
to correctly interact with the two or more Basic IPsec Groups. to correctly interact with the two or more Basic IPsec Groups.
Alternatively, the group multicast application must be re-programmed Alternatively, the group multicast application must be re-programmed
to support an application layer security service equivalent to that to support an application layer security service equivalent to that
offered by the IPsec subsystem at the network layer. In either case, offered by the IPsec subsystem at the network layer. In either case,
the group multicast application incurs complexity and cost that could the group multicast application incurs complexity and cost that could
have been avoided. have been avoided.
6.2 Security Issues Not Solved by Composite IPsec Groups 6.2 Security Issues Not Solved by Composite IPsec Groups
Similar as is the case for Basic IPsec Groups, the security issues
not solved by a Composite IPsec Group divide into two categories:
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
Similar as is the case for Basic IPsec Groups, the security issues
not solved by a Composite IPsec Group divide into two categories:
outsider attacks, and insider attacks. The discussion will focus on outsider attacks, and insider attacks. The discussion will focus on
the security issues that arise only in Composite IPsec Groups. the security issues that arise only in Composite IPsec Groups.
6.2.1 Outsider Attacks 6.2.1 Outsider Attacks
A Composite IPsec Group using a weak cryptographic algorithm or key A Composite IPsec Group using a weak cryptographic algorithm or key
strength in one of its Basic IPsec groups is vulnerable to an strength in one of its Basic IPsec groups is vulnerable to an
Adversary that knows (or guesses) which sub-group uses that Adversary that knows (or guesses) which sub-group uses that
algorithm. The Adversary can narrow its eavesdropping effort to only algorithm. The Adversary can narrow its eavesdropping effort to only
the traffic sent to that sub-group and apply cryptoanalysis on that the traffic sent to that sub-group and apply cryptoanalysis on that
skipping to change at page 10, line 56 skipping to change at page 11, line 5
transmissions without the insider Adversary risking detection by transmissions without the insider Adversary risking detection by
explicitly disclosing the key or plain text. To avoid this attack, a explicitly disclosing the key or plain text. To avoid this attack, a
Composite IPsec Group depends on the Group Owner designing a Composite IPsec Group depends on the Group Owner designing a
membership authorization policy that forces each candidate Group membership authorization policy that forces each candidate Group
Receiver member to only join the Basic IPsec Group that implements Receiver member to only join the Basic IPsec Group that implements
the strongest algorithms that their IPsec subsystem is known to the strongest algorithms that their IPsec subsystem is known to
support. Special care must be taken when authorizing a Group Speaker, support. Special care must be taken when authorizing a Group Speaker,
as a group member in that role becomes a member of every Basic IPsec as a group member in that role becomes a member of every Basic IPsec
Group. Group.
Multicast IPsec Composite Cryptographic Groups
A Composite Group Distributor under the control of an insider A Composite Group Distributor under the control of an insider
Adversary could create a covert channel by altering the order in Adversary could create a covert channel by altering the order in
which it multicast an IP packet to each Basic IP Group. An accomplice which it multicast an IP packet to each Basic IP Group. An accomplice
Multicast IPsec Composite Cryptographic Groups
to the Adversary who observed a long sequence of IP packet multicasts to the Adversary who observed a long sequence of IP packet multicasts
could assemble the covert message from a codebook. Each symbol would could assemble the covert message from a codebook. Each symbol would
be represented by a different sequence of Basic IPsec Group be represented by a different sequence of Basic IPsec Group
transmissions. transmissions.
6.3 Implementation or Deployment Issues that Impact Security 6.3 Implementation or Deployment Issues that Impact Security
The most prominent barrier to a successful Composite IPsec Group The most prominent barrier to a successful Composite IPsec Group
deployment is the complexity of designing a composite group security deployment is the complexity of designing a composite group security
policy. Factors that should be considered when designing such policy. Factors that should be considered when designing such
skipping to change at page 11, line 53 skipping to change at page 12, line 5
compare the cipher-texts sent to multiple Basic IPsec Groups. compare the cipher-texts sent to multiple Basic IPsec Groups.
7. Acknowledgements 7. Acknowledgements
[TBD] [TBD]
8. References 8. References
8.1 Normative References 8.1 Normative References
Multicast IPsec Composite Cryptographic Groups
[RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC
1112, August 1989. 1112, August 1989.
Multicast IPsec Composite Cryptographic Groups
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on
Security Considerations", RFC 3552, July 2003. Security Considerations", RFC 3552, July 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
skipping to change at page 12, line 34 skipping to change at page 12, line 37
03.txt, October 2006, work in progress. 03.txt, October 2006, work in progress.
8.2 Informative References 8.2 Informative References
[RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse
Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999. 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, [RFC3376] Cain, B., et. al., "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002. Version 3", RFC 3376, October 2002.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, December 2002. Group Domain of Interpretation", RFC 3547, December 2002.
[RFC3569] Bhatta charyya, S., "An Ov erview of So urce-Specifi c [RFC3569] Bhatta charyya, S., "An Ov erview of So urce-Specifi c
Multic ast (SSM)", RFC 3569, July 2003. Multic ast (SSM)", RFC 3569, July 2003.
[RFC3940] Adamso n, B., et. a l., "Negative-a cknowledgmen t (NACK)- [RFC3940] Adamso n, B., et. a l., "Negative-a cknowledgmen t (NACK)-
Orient ed Reliable Multicast (N ORM) Protoco l", RFC 3940, November Orient ed Reliable Multicast (N ORM) Protoco l", RFC 3940, November
2004. 2004.
[RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication Transform Authentication (TESLA): Multicast Source Authentication Transform
Introduction", RFC 4082, June 2005. Introduction", RFC 4082, June 2005.
Multicast IPsec Composite Cryptographic Groups
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005. 4306, December 2005.
Multicast IPsec Composite Cryptographic Groups
[RFC4359] Weis., B., "The Use of RSA/SHA-1 Signatures within [RFC4359] Weis., B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication Header (AH)", Encapsulating Security Payload (ESP) and Authentication Header (AH)",
RFC 4359, January 2006. RFC 4359, January 2006.
[RFC3451] Luby, M., et al, "Layered Coding Transport (LCT) Building [RFC3451] Luby, M., et al, "Layered Coding Transport (LCT) Building
Block", RFC3451, December 2002. Block", RFC3451, December 2002.
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
Multicast IPsec Composite Cryptographic Groups Multicast IPsec Composite Cryptographic Groups
APPENDIX A: Examples of Composite Cryptographic Group Use Cases APPENDIX A: Examples of Composite Cryptographic Group Use Cases
The following is a non-exhaustive list that identifies other The following is a non-exhaustive list that identifies other
representative use cases where a Composite Group could be applied: representative use cases where a Composite Group could be applied:
- A group policy that allows the use of both IETF standard and - A group policy that allows the use of both IETF standard and
vendor-specific cryptographic algorithms. vendor-specific cryptographic algorithms.
skipping to change at page 19, line 28 skipping to change at page 19, line 29
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 33 change blocks. 
42 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/