draft-ietf-msec-mesp-00.txt   draft-ietf-msec-mesp-01.txt 
Internet Engineering Task Force Mark Baugher (Cisco Systems) Internet Engineering Task Force Mark Baugher (Cisco Systems)
MSEC Working Group Ran Canetti (IBM Watson) MSEC Working Group Ran Canetti (IBM Watson)
INTERNET-DRAFT Pau-Chen Cheng (IBM Watson) INTERNET-DRAFT Pau-Chen Cheng (IBM Watson)
EXPIRES: April 25, 2003 Pankaj Rohatgi (IBM Watson) Pankaj Rohatgi (IBM Watson)
October 25, 2002 EXPIRES: September 2003 March 2003
MESP: Multicast Encapsulating Security Payload MESP: A Multicast Framework for the IPsec ESP
<draft-ietf-msec-mesp-00.txt> <draft-ietf-msec-mesp-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
material or cite them other than as "work in progress". material or 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/lid-abstracts.txt http://www.ietf.org/ietf/lid-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
Abstract Abstract
Multicast ESP (MESP) is a security protocol for IP multicast data. Multicast ESP (MESP) is a framework for multicast data-origin
MESP extends the IPsec Encapsulating Security Payload (ESP) protocol authentication using the IPsec Encapsulating Security Payload (ESP)
for multicast operation and supports source message authentication protocol. The MESP framework combines group-secrecy, group-
for multicast packets. MESP offers three improvements to IPsec ESP authentication, and source-authentication transforms in an ESP
for multicast operation. First, it allows a mix of group-secrecy, packet. MESP uses a message authentication code for group
group-authentication, and source-authentication transforms to be authentication to protect a digital signature, TESLA timed MAC, or
applied to an MESP packet. Second, it extends ESP to authenticate other multicast source-authentication transform.
messages sent by a member of the group using a digital signature or
hybrid MAC and signature transform. And third, MESP identifies a
security association (SA) using the IP address of the source in
addition to the destination address and SPI.
TABLE OF CONTENTS TABLE OF CONTENTS
1.0 Notational Conventions..........................................2 1.0 Notational Conventions..........................................2
2.0 Introduction....................................................2 2.0 Introduction....................................................2
3.0 Changes from the IPsec Specifications...........................3 2.1 Changes from the Previous Version..............................3
3.1 Changes from RFC 2401..........................................3 2.2 Overview.......................................................3
3.2 Changes from RFC 2406..........................................4 3.0 IP Multicast Security Functionalities...........................3
4.0 IP Multicast Security Functionalities...........................5 3.1 Composition of the Functionalities.............................4
4.1 Composition of the Functionalities.............................6 3.2 MESP Security Association Database.............................5
4.2 MESP Security Association and Parameters.......................7 4.0 MESP Packet Format.............................................5
5.0 MESP Packet Format.............................................7 4.1 MESP Transforms................................................7
5.1 MESP Transforms................................................9 4.1.1 Group Secrecy..............................................7
5.2 MESP Conformance Requirements.................................10 4.1.2 Internal Authentication....................................7
5.3 MESP Signaling................................................11 4.1.3 External Authentication....................................7
5.3.1 GDOI......................................................11 4.2 MESP Signaling.................................................7
5.3.2 GSAKMP....................................................11 4.2.1 GDOI.......................................................7
5.3.3 MIKEY.....................................................11 4.2.2 GSAKMP.....................................................8
6.0 Security Considerations........................................11 4.2.3 MIKEY......................................................8
7.0 IANA Considerations............................................13 5.0 Security Considerations.........................................8
8.0 Acknowledgements...............................................13 5.1 MESP Authentication............................................8
9.0 Author's Address...............................................13 5.2 MESP Denial-of-Service Protection..............................9
10.0 References....................................................14 5.3 MESP Encryption................................................9
10.1 Normative References.........................................14 6.0 IANA Considerations............................................10
10.2 Informative References.......................................15 7.0 Acknowledgements...............................................11
8.0 Author's Address...............................................11
9.0 References.....................................................11
9.1 Normative References..........................................11
9.2 Informative References........................................12
1.0 Notational Conventions 1.0 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The terminology conforms to [RFC2828]. The terminology conforms to [RFC2828].
2.0 Introduction 2.0 Introduction
Like the IPsec Encapsulation Security Payload (ESP), MESP provides a The IPsec Encapsulation Security Payload (ESP) provides a set of
set of security services that include access control, connectionless security services that include data origin authentication, which
integrity, data origin authentication, rejection of replayed enables an IPsec receiver to validate that a received packet
packets, confidentiality (encryption), and limited traffic-flow originated from a peer-sender in a pairwise security association
confidentiality [Section 3.1, RFC2401]. Unlike ESP, MESP provides [Section 3.1, RFC2401]. A Message Authentication Code (MAC), such
data origin authentication for multicast sources. Thus, MESP is not as the hash-based message authentication code [RFC2104, RFC2404]
ESP: MESP has a distinct protocol number from ESP. MESP does extend (HMAC), is the common means to provide data-origin authentication
ESP, however, and MESP includes the base IPsec ESP documents in its for pairwise IPsec security associations. For secure groups such as
definition. This I-D, therefore, assumes that the reader is IP multicast groups, however, a MAC supports only "group
familiar with the "Security Architecture for Internet Protocol" authentication" and not data-origin authentication [CP]. This
[RFC2401] and the "IP Encapsulating Security Payload (ESP)" Internet-Draft document (I-D) defines a framework for ESP data-
[RFC2406] RFCs. Section 3 describes MESP changes to the IPsec RFCs origin authentication that is suitable for IP multicast groups of
for IP multicast data security. ESP receivers.
Section 4 reviews the functionalities of multicast data-security
transforms for use by a variety of IP multicast applications such as
media streaming, process control, and reliable multicast
applications. Section 4 describes the problem of authenticating the
source of IP multicast data, and it describes the requirement for an
IP multicast security association (SA) to support both "Any Source
Multicast" (ASM) and "Source Specific Multicast" (SSM) groups [SSM,
IGMPV3]. IPsec ESP is suitable for IP multicast groups that are (a)
restricted to a single sender or (b) where all senders use a single
group controller/key server. Case (a) relies upon the network
configuration to prevent multiple senders. Case (b) requires that
each sender be trusted not to impersonate any other sender and that
all receivers accept parameters from within a single security
domain. For cases where such restrictions do not hold, however, this
proposed standards-track I-D RECOMMENDS use of MESP, which
complements IGMPv3 source pruning and features source message-
authentication for ASM and SSM environments.
Section 5 describes the MESP extensions to the IPsec Encapsulating
Security Payload (ESP) protocol for source message authentication
and the other functionalities of Section 4. The design of MESP
emphasizes flexibility, simplicity and maximal reuse of IPSec ESP.
MESP preserves ESP functionality when multicast source
authentication and sender-based indexing of SAs are not needed.
Thus, the MESP packet structure is indistinguishable from ESP for
particular mixes of the secure multicast functionalities. As there
are three inter-dependent functionalities for MESP, Section 5
specifies their composition and ordering.
The three functionalities are realized in cryptographic transforms
that are secure for various uses and Section 6 recites the security
considerations for each MESP transform. Section 6 considers IP
multicast risks, the transforms that address a particular risk, and
the suitability of a transform for various applications and
environments.
MESP has its own namespace, and Section 7 identifies Internet
Assigned Names and Number (IANA) requirements for MESP.
3.0 Changes from the IPsec Specifications
Although MESP has its own namespace, protocol number, and is a
distinct security protocol from ESP, MESP reuses IPsec ESP's base
specifications, RFC 2401 and RFC 2406. This I-D assumes that the
reader is familiar with these specifications, which are referenced
and not copied by MESP. The changes to RFC 2401 and RFC 2406 are
listed in this section.
3.1 Changes from RFC 2401
MESP extends IPsec ESP to feature data-origin authentication for IP
multicast data. "Data origin authentication...is limited by the
extent to which secrets used with the authentication algorithm...are
shared among multiple possible sources" [Section 4.6, RFC 2401]. In
an IP multicast group, symmetric encryption and authentication keys
are shared among multiple potential sources thereby making data-
origin authentication using symmetric keys impossible. Thus, the
most significant change introduced by MESP to IPsec ESP are methods
to uniquely identify sources of IP packets to a multicast group.
The following are the specific changes introduced by MESP to RFC
2401.
1) MESP operates in both gateway (tunnel mode) and host (transport
mode) environments without support for the IPsec Authentication
Header protocol [Sections 3, 3.2 and 4.3, RFC2401]. MESP MAY be
tunneled in an IPsec AH tunnel, but such operation is in the realm
of IPsec and outside the scope of MESP.
2) An MESP destination-address selector MUST always be an IPv4 or
IPv6 multicast address [Section 4.4.2, RFC2401].
3) An MESP security association database (SAD) entry MUST be
identified by the <destination IP address, security parameter index>
pair; there is no need to specify the protocol, which is always MESP
[Section 4.4.3, RFC2401].
4) MESP supports SA update for key refresh in addition to SA
replacement, and IKE is not the default, automated key mangement
protocol for MESP [Section 4.6.2, RFC2401].
5) MESP receivers do not allocate the security parameter index
(SPI), which MAY be allocated by the sender or by the group
controller/key server (GCKS) for a multicast group [Section 4.7, RFC
2401].
6) An MESP receiver MUST NOT share an SA among multiple senders to a
multicast group [Section 4.7, RFC 2401].
Multicast groups having many senders might require that an SA be
shared among all senders in the group. This sharing would obviate
IPsec-style replay protection unless an MESP SA were re-defined to
allow a replay list to be dynamically created for each observed
sender. This seems onerous but so is the requirement for a receiver
to support a large number of SAs for a group having a large number
of senders. For these and other reasons, the use of a wildcard
source-address in an MESP SA is for further study.
3.2 Changes from RFC 2406
Some MESP changes to RFC 2406 are also listed above for RFC 2401;
these are included in this section for the sake of completeness.
1) MESP uses protocol number xxxx and not 50 [Section 2, RFC2406].
2) An MESP SPI is selected by the sender or by the group
controller/key server (GCKS) [Section 2.1, RFC 2406].
3) MESP does not support use of AH for IP multicast packets [Section 2.1 Changes from the Previous Version
3.1, RFC2406].
4) MESP REQUIRES some form of message authentication; NULL This version is not a protocol, unlike the previous version, but is
authentication [Section 3.2.2, RFC2406] is supported only under a transform framework for ESP and realizes all of its functions
certain circumstances that are defined in Section 4.1, below. within the ESP protocol. MESP now imposes an additional structure
and usage on IPsec ESP Initialization Vector (IV) and Integrity
Check Value (ICV) fields [ESPbis].
5) MESP refers to ESP authentication as the "external A smaller change that appears in this version of MESP is the
authentication," which MUST be a hash-based message authentication requirement that TESLA authentication be protected by external
code [RFC2104, RFC2404] and which MUST NOT be a digital signature authentication transform such as a MAC.
[Section 3.4.4, RFC2406].
6) MESP has a different set of conformance requirements than IPsec 2.2 Overview
ESP [Section 3.5, RFC2406]. Section 5.2 lists MESP conformance
requirements.
MESP conformance subsumes IPsec ESP conformance for authentication This I-D assumes that the reader is familiar with the "Security
but not for encryption (see Section 5.2). MESP, however, classifies Architecture for Internet Protocol" [RFC2401] and the "IP
ESP message authentication as "group authentication" and ESP message Encapsulating Security Payload (ESP)" [ESPBIS] RFCs. Section 3
confidentiality (encryption) as "group secrecy." The following reviews the functionalities of group data-security transforms for
section defines these functionalities. applications such as media streaming, process control, and reliable
multicast applications. Section 3 describes the problem of
authenticating the source when the data-authentication key is shared
by more than two IPsec endpoints. Section 4 describes the MESP
framework in terms of the extensions and use of the ESP IV and
integrity-check-value fields. The three functionalities of the MESP
framework are realized in cryptographic transforms that are secure
for various uses, and Section 5 recites the security considerations
for each MESP transform. Section 5 considers IP multicast risks,
the transforms that address a particular risk, and the suitability
of a transform for various applications and environments.
4.0 IP Multicast Security Functionalities 3.0 IP Multicast Security Functionalities
The security requirements for multicast have been discussed in [CP]. The security requirements for multicast have been discussed in [CP].
In particular, these reference documents identify three different In general, group security has different requirements and
functionalities that must be part of any complete solution. characteristics than pairwise security. In particular, data-origin
authentication using a MAC will not prevent one member from
impersonating another when a group of three or more members share
the symmetric authentication key. There are three new
functionalities needed to add data-origin authentication to ESP.
a) Group Secrecy (GS) a) Group Secrecy (GS)
The GS functionality ensures that the transmitted data is accessible The GS functionality is ESP confidentiality applied to a group . It
only to group members (i.e. two or more hosts in possession of a ensures that transmitted data are accessible only to group members
shared symmetric key). This can also be viewed as a way to enforce (i.e. two or more hosts in possession of a shared symmetric key).
access control. A typical realization is to encrypt data using a key This can also be viewed as a way to enforce access control. A
known only to group members. Essentially, the solution for multicast typical realization of GS is to encrypt data using a key known only
is the same as the solution for unicast confidentiality. It is to group members. Essentially, the solution for multicast is the
important to note, however, that some encryption transforms have same as the solution for unicast confidentiality. It is important
special considerations when a key is shared among multiple senders. to note, however, that some encryption transforms have special
An MESP encryption or authentication transform SHOULD describe the considerations when a key is shared among multiple senders. An MESP
potential risks of multicast operation and how those risks are encryption or authentication transform SHOULD describe any potential
averted. risks of multicast operation and how those risks are averted.
b) Group Authentication (GA). b) Group Authentication (GA)
The GA functionality ensures that any group member can verify that The GA functionality enables a group member to verify that
the received data originated from someone in the group. Note that the received data originated from someone in the group and was not
group authentication by itself does not identify the source of the modified en-route by a non-group member. Note that group
data; for example, the data might have been forged by any malicious authentication by itself does not identify the source of the
data. For example, the data might have been forged by any malicious
group member. GA can be efficiently realized using standard shared group member. GA can be efficiently realized using standard shared
key authentication mechanisms such as Message Authentication Codes key authentication mechanisms such as Message Authentication Codes
(MACs), e.g., CBC-MAC, HMAC, or UMAC. IPsec ESP authentication (MACs), e.g., CBC-MAC, HMAC, or UMAC.
using a hash-based message authentication code (HMAC) is strictly
GA.
c) Source and Data Authentication (SrA). c) Source and Data Authentication (SrA)
The SrA functionality ensures that any group member can verify that The SrA functionality enables a group member to verify that
the received data originated from the claimed source and was not the received data originated from the claimed source and was not
modified en-route by anyone (including other malicious group modified en-route by anyone (including other malicious group
members). Source and Data Authentication provides a much stronger members). Unlike Group Authentication, SrA provides the IPsec data-
security guarantee than the Group Authentication functionality. origin authentication function [RFC2401, ESPbis]. Source and Data
Realizing source authentication requires stronger cryptographic Authentication provides a much stronger security guarantee than
techniques such as digital signatures, stream signatures [GR], flow Group Authentication in that a particular group member can be
signatures [WL], hybrid signatures [R], timed MACs, e.g. TESLA identified as a source of a packet. Group and multicast source
[TESLA, Ch,PCTS],asymmetric MACs [CGIMNP], etc. authentication requires stronger cryptographic techniques such as
digital signatures, stream signatures [GR], flow signatures [WL],
hybrid signatures [R], timed MACs, e.g. TESLA [TESLA,
Ch,PCTS],asymmetric MACs [CGIMNP], etc.
4.1 Composition of the Functionalities 3.1 Composition of the Functionalities
A secure multicast solution is likely to utilize all three of the A secure multicast solution is likely to utilize all three of the
basic functionalities. Due to the diversity of the various basic functionalities. Due to the diversity of the various
application and deployment scenarios for multicast, several issues application and deployment scenarios for multicast, several issues
arise with respect to the composition and ordering of these arise with respect to the composition and ordering of these
functionalities. functionalities.
In ESP, encryption precedes authentication when both are present [p. In ESP, encryption precedes authentication when both are applied and
11, RFC2406]. This is an efficient ordering that allows the receiver a "combined-mode" confidentiality/integrity operation is not used
to apply a message authentication code (MAC) before it runs a more [Section 3.3.2 of ESPBIS]. Combined modes of encryption and
computationally-intensive decryption; fast authentication before authentication are supported in ESP [ESPbis] but are not considered
encryption offers a better defense against invalid packets in a in this version of MESP. Encryption first is an efficient ordering
denial of service attack. In MESP, therefore, the group secrecy (GS) that allows the receiver to apply a message authentication code
transforms MUST precede group authentication (GA). Krawczyk has (MAC) before it runs a more computationally-intensive decryption;
shown that it is more secure to authenticate encrypted data rather fast authentication before decryption offers a better defense
than encrypt authenticated data [K], but this ordering does not against bogus packets from a denial of service attack. In MESP,
provide non-repudiation. therefore, the group secrecy (GS) transform MUST precede group
authentication (GA) when GS is used. In other words, the sender
A digital signature over the plaintext packet payload, however, applies GS prior to GA and the receiver applies GA prior to GS.
provides both message source authentication and non-repudiation. Krawczyk has shown that it is more secure to authenticate encrypted
Digital signatures offer the simplest method for multicast source data rather than encrypt authenticated data [K], but this ordering
authentication (SrA) but are computationally expensive and does not provide non-repudiation. The latter is usually not needed
impractical for high-rate packet flows. Given the relatively high or even desirable for IPsec applications.
cost of signature verification, a digital signature leaves the
receiver highly vulnerable to denial of service attack when an
attacker succeeds in getting the receiver to perform signature
validation of bad packets.
MESP protects a digitally-signed packet by applying a message
authentication code to it after signing it. MESP calls this MAC
"external authentication" and applies it in an identical fashion to
ESP. The digital signature is called "internal authentication,"
which the sender applies to the packet payload before the MAC.
Thus, MAC authentication is applied first by the receiver. If the
attacker is not a member of the group, or otherwise has not obtained
the group key, the MAC will fail before the receiver incurs the
burden of a signature validation.
Thus, the digital signature is an internal-authentication transform MESP uses the same ordering for SrA: SrA MUST follow GS. Digital
that MUST be applied first at the sender and last at the receiver. signatures offer the simplest method for multicast source
MAC-based Group authentication is an external-authentication authentication (SrA) but are computationally expensive, greatly
transform that MUST be applied last at the sender and first at the expand the packet size and impractical for many, if not most, packet
receiver. As in ESP, encryption (GS) is applied before external flows. Given the relatively high cost of signature verification, a
authentication (GA). Other SrA transforms MAY be applied as internal digital signature leaves the receiver vulnerable to denial of
or external authentication depending on the particular transform; service attack when an attacker succeeds in getting the receiver to
TESLA, for example is an external authentication transform that perform signature validation of bad packets.
obviates the use of a MAC (see Section 5.0).
4.2 MESP Security Association and Parameters MESP partially protects the receiver from denial-of-service attacks
from bogus digitally-signed packets by applying a MAC to the packet
after signing it. MESP calls this MAC "external authentication" and
applies it in an identical fashion to ESP. The digital signature is
called "internal authentication," which the sender applies to the
packet payload before the MAC. MAC authentication, therefore, is
applied first by the receiver. If the attacker is not a member of
the group, or otherwise has not obtained the group key, the MAC will
fail before the receiver incurs the burden of a signature
validation.
The three secure-multicast functionalities are realized in an MSEC SrA transforms such as TESLA timed-MAC can be more efficient than
security association (SA), which is an extension of an IPsec SA digital signatures for many applications. But like a digital
[Section 4.4.3, RFC 2401]. MESP uses all of the SA "policy" signature, it is REQUIRED that TESLA and other SrA transforms use
parameters for IPsec ESP with the exception of the AH parameters as internal authentication in MESP and be protected by an external-
noted in Section 3, above. Any ESP encryption transform [p.10 authentication MAC. Thus, a digital signature or TESLA MAC MUST be
RFC2407] MAY be used for MESP for the group-secrecy functionality. applied prior to GA at the sender and after GA at the receiver.
MESP also supports NULL encryption (NULL GS). The ESP authentication MAC-based GA is an external-authentication transform that MUST be
algorithm is the MESP GA transform, which must be an HMAC [RFC2404]. applied last at the sender and first at the receiver. As in ESP,
NULL GA authentication is supported for MESP when a MAC-based SrA encryption (GS) is applied before any authentication and is
transform is used in its place. NULL GA authentication MUST NOT be optional.
used with an SrA digital signature or with a NULL SrA transform.
Thus, SrA is the single MESP addition to the IPsec SA database (SAD) 3.2 MESP Security Association Database
parameters of RFC 2401. The SrA parameter consists of a named group
source-authentication transform and a set of parameters that are
unique to that particular transform.
An MESP SA is also identified differently from an IPsec SA. An MESP The MESP framework applies up to three transforms to a multicast ESP
SA is identified by the triple <s, g, SPI> where "s" is the source packet in the order described above: Group Secrecy (GS) is OPTIONAL,
IP address of the sender, "g" is the destination IP multicast Source Authentication (SrA) SHOULD be applied next, and Group
address, and "SPI" is the security parameter index that MAY be Authentication (GA) SHOULD be applied last. The IPsec SAD MUST be
assigned by the sender or by a third party entity such as a GCKS. extended to store the additional transform information if MESP is to
This SA identification method allows any sender, s, to multicast be supported.
group, g, to select an SPI without coordination with other senders
to g. This method also allows a GCKS to operate on an <s, g> basis
with no need to mandate a common controller for all senders to g.
As discussed above in Section 3.1, use of a wildcard value for s is
for further study.
5.0 MESP Packet Format There are no changes to ESP SA lookup beyond what is specified for
multicast SAs in the IPsec specifications [AHbis, ESPbis].
The MESP packet is identical to an ESP packet in situations where no 4.0 MESP Packet Format
internal authentication is applied. As with ESP, MESP MAY operate The ESP Packet format is illustrated in Figure 4-1:
in either tunnel mode from an MESP host or security gateway, or it
MAY operate in transport mode at an MESP host only.
As in ESP, the transport-mode MESP packet header appears between the * Internal Authentication Parameters (variable). The length and
IP header and the upper-layer protocol header (e.g. the transport contents of this field are defined by the SrA transform. Certain
header). The IP header carries the MESP protocol number that is internal authentication transforms have a zero length SrA Transform
designated in the IANA Considerations section of this I-D. Parameters fields (Section 5.1).
As in ESP, the tunnel-mode MESP packet header appears after the * Internal Authentication Tag (Variable). The length and contents
encapsulating IP header and before the encapsulated IP packet. The of this field are defined by the internal authentication transform.
encapsulating IP header carries the MESP protocol number that is Certain SrA transforms have a zero length Internal Authentication
designated in the IANA Considerations section of this I-D. Tag field.
Figure 5-1: MESP Format. Figure 4-1: MESP Transforms in an ESP Packet
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | ^ | Security Parameters Index (SPI) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number |^ | | Sequence Number |^ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || | ~ IV (variable & optional) ~ | |
~ IV (if any) ~| | +---------------------------------------------------------------+ | |
| || | ~ Internal Authentication Parameters (variable & optional) ~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || ^ | ~ Data (variable) ~^ I E
~ Internal Authentication Parameters (if any) ~| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E N X
| |I E E ~ ~ Padding (0-255 bytes) |N T T
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+N N X +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C | |
| |T C T | | Pad Length | Next Header |v v |
~ Data (variable) ~| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|...............................................................|v | | ~ Internal Authentication Tag (variable) ~ v
| Internal Authentication Tag (variable) | | | +---------------------------------------------------------------+
| | | | ~ Integrity Check Value (variable) ~
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Padding (0-255 bytes) | | |
~ ~ | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ External Authentication Data (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MESP Packet format is illustrated in Figure 5-1. As in the ESP Encryption (ENC), when applied, covers the ESP data, padding and
packet format, the MESP packet starts with a 32-bit Security next header fields. Internal Authentication (INT) covers the ESP
Parameter Index (SPI) field followed by a 32-bit sequence number sequence number through the next header field, inclusive. External
field. Unlike, ESP, the IP address of the packet sender together authentication (EXT) covers the entire ESP packet except for the
with the SPI and the destination IP address uniquely identify a Integrity Check Value (ICV) field.
Security Association (SA) and associated keying material.
As in an ESP packet, the sequence number field is followed by an
optional IV field. In cases where the MESP does not use internal
authentication, the structure of the encrypted data field is
identical to that of the ESP packet. In cases where the MESP uses
internal authentication, the encrypted data consists of the
following fields:
* Internal Transform Parameters (variable). The length and contents
of this field are defined by the SrA transform. Certain internal
authentication transforms have a zero length SrA Transform
Parameters fields (Section 5.1).
* Internal Authentication Tag (Variable). The length and contents
of this field are defined by the internal authentication transform.
Certain SrA transforms have a zero length Internal Authentication
Tag field.
A sender of an MESP packet MAY use an internal-authentication A sender MAY use an encryption-transform (ENC) as done in any other
transform (INT). When INT is applied to the packet, its output (if ESP packet.
any) is placed in the Internal Authentication Tag. Section 5.1
identifies the INT transforms, which the sender MUST perform prior
to the encryption transform.
A sender of an MESP packet MAY use an encryption-transform (ENC). As When INT is applied to the packet, its output (if any) is placed in
in an ESP packet, the encrypted payload (ENC in Figure 5-1) ends the Internal Authentication Tag. Section 4.1 identifies the INT
with variable amount (0-255 bytes) of padding followed by the pad transforms, which the sender MUST perform prior to the encryption
length and next header fields. The next header field still refers to transform.
the next protocol header (e.g. transport header) in the actual data.
Section 5.1 identifies the ENC transforms, which the sender MUST
perform prior to the external authentication transform.
A sender of an MESP packet MAY use an external-authentication A sender of an MESP packet SHOULD use an external-authentication
transform (EXT). Section 5.1 identifies the EXT transforms, which transform (EXT). Section 4.1 identifies the EXT transforms, which
the sender MUST perform last (and the receiver performs first). the sender MUST perform last (and the receiver performs first).
Thus the sender performs the MESP transforms in the order of INT, The sender MUST perform the MESP transforms in the order of ENC,
ENC, and EXT while the receiver performs them in the order of EXT, INT, and EXT while the receiver MUST perform them in the order of
ENC and INT. EXT, INT and ENC.
5.1 MESP Transforms 4.1 MESP Transforms
Table 5.1-1 lists the MESP transforms and any dependencies that are This version of MESP defines a minimal number of transforms. In the
associated with their application. As noted above, MESP REQUIRES future, new transforms MAY be added through the publication of an
that a MAC external authentication be used in conjunction with an Internet RFC. The transforms of the MESP framework are listed below
internal-authenticating digital signature. This restriction reduces and classified according to MESP type.
the effectiveness of a denial of service attack by a non-group
member (i.e. by an MESP entity that does not hold the symmetric
authentication key). The RSA-SHA1 [PKCS1] internal authentication
MUST have a zero-length Internal Transform Parameters field; the
signed RSA appendix is placed in the Internal Authentication Tag.
The size of the security of the RSA signature is of course
determined by the size of the RSA key, which MUST be long enough to
suffice for the duration of the ESP session (see Security
Considerations). This version of MESP does not consider key sizes or
other digital signature transforms. A future version of this I-D
will consider the issue of digital signature key sizes for MESP
sessions and the use of ECDSA as an alternative transform.
TABLE 5.1-1: Pre-defined MESP Transforms 4.1.1 Group Secrecy
+-----------------+----------------------+---------------+
| Transform Class | Transform Identifier | Dependencies |
+-----------------+----------------------+---------------+
| | RSA-SHA1 | HMAC-SHA1 EXT |
| INT +----------------------+---------------+
| | NULL | None |
+-----------------+----------------------+---------------+
| ENC | Any ESP encryption | None |
| | transform [RFC2407] | |
+-----------------+----------------------+---------------+
| | HMAC-SHA1 | None |
| EXT +----------------------+---------------+
| | TESLA | No INT |
+-----------------+----------------------+---------------+
As indicated in Table 5.1-1, MESP MAY use any ESP encryption MESP supports 3DES, AES-CBC, and AES-CTR.
transform that is defined in RFC 2407. New MESP encryption
transforms SHOULD be specified in an Internet RFC.
As shown in Table 5.1-1, HMAC-SHA1 [RFC2404] is the only pre-defined 4.1.2 Internal Authentication
MESP MAC and is REQUIRED when internal authentication is used. In
addition to HMAC-SHA1, TESLA MAY be applied when no internal-
authentication transform applies to an MESP packet.
The Table 5.1-1 transforms are mutually exclusive by class: There MESP internal authentication is either RSA-SHA1 or TESLA.
MAY be at most one INT, ENC or EXT transform applied to an MESP
packet.
5.2 MESP Conformance Requirements 4.1.3 External Authentication
TABLE 5.2-1: Default and Mandatory MESP Transforms MESP external authentication uses HMAC-SHA1.
+-----------------+----------------------+
| Transform Class | Transform Identifier |
+-----------------+----------------------+
| INT | RSA-SHA1 |
+-----------------+----------------------+
| ENC | 3DES-CBC [RFC2451] |
+-----------------+----------------------+
| EXT | HMAC-SHA1 |
+-----------------+----------------------+
5.3 MESP Signaling 4.2 MESP Signaling
MESP parameters are signaled through a key management protocol or MESP parameters are signaled through a key management protocol or
interface such as GDOI, GSAKMP, GKMP, or SDP. interface such as GDOI, GSAKMP, GKMP, or SDP.
5.3.1 GDOI 4.2.1 GDOI
GDOI MUST signal an MESP session using PROTO_MSEC_MESP as defined in GDOI MUST signal use of the MESP framework using PROTO_ESP_MESP with
the IANA Section of this I-D. PROTO_MSEC_MESP has the same TEK the TRANSFORM ID set to the MESP transform ID value (see IANA
protocol-specific payload as PROTO_IPSEC_ESP [Section 5.4.1, GDOI]. Section below). MESP extends the RFC 2407 attributes ["IPsec
MESP replaces the RFC 2407 attributes in the TEK payload with the Security Association Attributes," IANA] with the three new classes,
following attributes. "ENC_Transform, "INT_Transform," and "EXT_Transform" (see IANA
Section below).
class value type The ENC Transform MUST be one of the transforms from 4.1.1.
----------------------------------------- Additional ENC transforms MAY be added to this suite through the
INT Transform 1 B publication of an Internet RFC.
EXT Transform 2 B
Encapsulation Mode 3 B
SA Life Type 4 B
SA Life Duration 5 V
Signature PubKey 6 V
The INT Transform MAY be NULL, which has the value 1. When the EXT The INT Transform MUST be non-null and MUST be one of the values
Transform is HMAC-SHA1, the INT Transform MAY be RSA-SHA1, which has from 4.1.2. Additional INT transforms MAY be added to this suite
the value 2. through the publication of an Internet RFC.
The EXT Transform MAY be HMAC-SHA1, which has the value 1, or it MAY The EXT Transform MUST be one of the transforms from 4.1.3.
be TESLA, which has the value 2 when the INT Transform is NULL. Additional EXT transforms MAY be added to this suite through the
publication of an Internet RFC.
The Encapsulation Mode MAY be 1 for transport mode or 2 for tunnel The IANA Considerations section of this document describes value
mode. assignments for the EXT, INT and ENC attributes.
SA Life Type and Life Duration are as defined in RFC 2407. Life The SA Life Type and Life Duration as defined in RFC 2407 [RFC2407,
Type and Duration apply to all keys used for the session, including IANA] apply to all keys used for the session, including the
the Signature PubKey, which MUST NOT be sent if the INT Transform is Signature PubKey, which MUST NOT be sent if the INT Transform is not
not a digital signature algorithm. The length of the encoding is a digital signature algorithm. The length of the encoding is
determined by INT. {Editor: Need to define the Signature PubKey determined by INT. {Editor: Need to define the Signature PubKey
format and should make it a GDOI KD payload item instead.} format and should make it a GDOI KD payload item instead.}
5.3.2 GSAKMP 4.2.2 GSAKMP
TBD TBD
5.3.3 MIKEY 4.2.3 MIKEY
TBD TBD
6.0 Security Considerations 5.0 Security Considerations
MESP provides a set of security services that include access
control, data origin authentication, rejection of replayed packets,
confidentiality (encryption), limited traffic-flow confidentiality
and connectionless integrity. With its default transforms, MESP
services support a datagram environment where each IP packet is
cryptographically independent of other IP packets and can be
decrypted, authenticated, and integrity checked when delayed,
reordered, or when other packets from the flow are lost. Some
packet loss, delay and reordering are unavoidable on IP networks
through normal operation as well as a result of attack from an
interloper who has gained access to the packet flow.
IP multicast packets are vulnerable to snooping and tampering, MESP is a framework for IPsec ESP authentication and encryption
particularly on shared-media networks such as local area networks; transforms to support IP multicast delivery. IPsec ESP provides
the MESP group secrecy function (see Section 4) controls access to access control, rejection of replayed packets, confidentiality
packet data and provides confidentiality to data exchanged among (encryption), limited traffic-flow confidentiality and
group members. Even encrypted packets carry IP headers in plaintext, connectionless integrity. ESP supports a datagram environment where
however, and some environments might consider the source, each IP packet is cryptographically independent of other IP packets
destination, packet length and other packet-header information to be and can be decrypted, authenticated, and integrity checked when
worthy of protection from unauthorized parties; MESP features the delayed, reordered, or when other packets from the flow are lost.
IPsec tunnel mode of operation to encrypt the entire IP multicast ESP provides rejection of replayed packets for pairwise security
packet and thereby provide some traffic-flow confidentiality though associations and for multicast security associations under certain
the encapsulating IP packet unavoidably reveals some information circumstances [ESPbis]. MESP has the same replay mechanism for the
about the tunnel endpoints (MESP implementations could alter the single-sender case; the multi-sender case is for further study. ESP
encapsulated packet length to further thwart traffic analysis by an provides data origin authentication for pairwise security
attacker). associations using symmetric message authentication codes, which are
not sufficient for group security applications where more than two
members share a symmetric key.
An attacker that has access to the flow of IP multicast packets can 5.1 MESP Authentication
"replay" the packets by capturing and resending the packets in an
effort to disrupt the IP multicast session through a "denial of
service" attack. MESP features the IPsec ESP replay counter to
detect replayed IP packets (or packets duplicated during routine
operation). Unlike IPsec, there is no provision in MESP for a
receiver to disable replay protection through signaling since MESP
sends to multiple receivers. Like IPsec ESP, however, key
management MAY choose to configure group senders and receivers to
neither set nor read the MESP packet sequence number though proper
use of the replay counter is RECOMMENDED by MESP. If more than one
sender shares an MESP security association (SA), however, then the
IPSec-defined replay protection mechanism will not work. Thus, the
current version of MESP mandates that an MESP SA MUST NOT be shared
by multiple senders. It is for future study to determine whether
SA-sharing is needed in MESP.
The MESP replay counter is vulnerable to tampering if the integrity The MESP framework for ESP provides data-origin authentication
of the IP packet that contains the counter is not protected. MESP services to multicast ESP packets. Secure groups, such as secure
REQUIRES message integrity for MESP packets through one of two multicast groups, cannot use a symmetric-key MAC to uniquely
mechanisms. The first mechanism uses HMAC-SHA1 integrity with a identify the sender; any group member that is in possession of the
symmetric authentication key. Unlike unicast IP packets, the MAC group authentication key is capable of replacing the source address
cannot authenticate the source of the packet for a multicast group of the packet with that of another group member and applying the
where multiple members share the symmetric authentication key. symmetric key to authenticate the packet. To uniquely identify a
sender among a group of members, digital signature, public key
encryption, or specialized source-authentication techniques such as
timed MACs are needed. This version of MESP defines a general ESP
packet structure for accommodating a digital signature or TESLA
timed MAC.
Thus, a rogue member of the group has all the keying material needed 5.2 MESP Denial-of-Service Protection
to impersonate a sender of the group if that attacker is able to
inject packets into the network using that sender's IP address. The As discussed above, a group member cannot authenticate the source of
second MESP mechanism augments the MAC with a digital signature over the packet for a multicast group where multiple members share the
the packet data to uniquely identify the sender of the packet. MAC key. Thus, a rogue member of the group has all the keying
material needed to impersonate a sender of the group if that
attacker is able to inject packets into the network using that
sender's IP address. The MESP framework addresses this problem by
augmenting the MAC with an "internal authentication" transform,
which MAY be an RSA-SHA1 digital signature or a TESLA timed MAC.
Digital signatures leave multicast receivers vulnerable to denial- Digital signatures leave multicast receivers vulnerable to denial-
of-service attack that the receiver attempts to validate through of-service attack if the receiver is duped into performing
computationally-expensive signature validation. MESP mandates that computationally-expensive signature validation of bogus packets. An
HMAC-SHA1 message authentication MUST accompany a digital signature external message authentication SHOULD accompany a digital signature
so as to limit the effectiveness of forging digitally signed packets so as to limit the effectiveness of bogus digitally signed packets
by non-group members. by non-group members. TESLA is also vulnerable to a denial of
service attack if the receiver is duped into storing bogus packets
awaiting MAC verification. An external message authentication
transform SHOULD accompany a TESLA authentication transform so as to
limit the effectiveness of bogus TESLA packets by non-group members.
Unfortunately, group members are still capable of sending packets Unfortunately, group members are still capable of sending packets
with a valid MAC and invalid digital signature, i.e. a group member with a valid external-authenticating MAC and invalid digital
can launch a DoS attack on the group using invalid digital signature, i.e. a group member can launch a DoS attack on the group
signatures. When this threat is an application concern, MESP using invalid digital signatures. And group members are still
supports multicast source authentication using hybrid MAC/digital capable of sending packets with a valid external-authentication MAC
signature and Timed MAC schemes, such as TESLA, to mitigate attacks but an invalid TESLA MAC. In both the TESLA and digital-signature
by group members upon the group. TESLA source authentication can cases, the external authentication will succeed only to have the
uniquely identify the source in a manner that amortizes the cost of internal authentication fail. MESP includes the ESP sequence number
a single digital signature over a very long chain of packets in the internal authentication to protect against a replay attack by
[TESLA]. a group member. When the RECOMMENDED external authentication code
is use, however, the ESP receiver MUST validate both the internal
authentication as well as the external authentication before
updating the ESP replay window.
7.0 IANA Considerations The value of MESP authentication transforms is to enable the
receiver to greatly reduce the effect of an attack by non-group
members, to reduce the effects of a denial of service attack by a
group member, to detect an attack by a group member, and to support
the integration of multicast source-authentication transforms into
IPsec ESP for data-origin authentication.
MESP uses protocol number xxxx. Both of these values MUST be 5.3 MESP Encryption
registered with IANA.
GDOI uses PROTO_MSEC_MESP, which has the value xxxx. Within The value of MESP encryption is to validate individual encryption
PROTO_MSEC_ESP, GDOI signals the INT Transform with the number 1, transforms for multicast operation. It is possible that a
the EXT transform with the number 2, the Encapsulation Mode with the particular cipher and mode are suitable for pairwise security
value 3, SA Life Type with 4, SA Life Duration with 5, and Signature associations but not for multicast security associations, such as
PubKey with the value 6. Within the INT Transform, GDOI reserves one where multiple senders share the key. For example, a stream or
the number 1 for the NULL digital signature and 2 for RSA-SHA1. hybrid stream/block cipher has special risks of keystream reuse when
Within the EXT transform, GDOI reserves the number 1 for HMAC-SHA1 its key is shared by multiple senders. Although IPsec encryption
and the number 2 for TESLA. Within Encapsulation Mode, GDOI transforms are generally suitable for multicast operation, many have
reserves 1 for transport mode and 2 for tunnel mode. The values not been evaluated, tested or used in IP multicast environments.
MUST be registered with IANA. This I-D has considered the suitability of several IPsec ESP
encryption transforms for inclusion in the MESP framework. It is
RECOMMENDED that all future IPsec encryption transforms be analyzed
as to their security for multicast and group security as well as for
pairwise security.
8.0 Acknowledgements 6.0 IANA Considerations
The authors wish to thank Brian Weis and Scott Fluhrer, who This I-D extends the RFC 2407 attributes for IPsec ESP,
identified some problems in a previous version of the draft. PROTO_IPSEC_ESP [RFC2407]. Within PROTO_IPSEC_ESP, MESP reserves the
transform identifier value 13 [See IANA, "IPSEC ESP Transform
Identifiers"]. MESP also adds new type/length/value attributes to
RFC 2407. For the MESP transform ID security association
attributes, the ENC Transform has type number 11, the INT transform
has type number 12, and the EXT transform has type number 13 [see
IANA, "Security Association Attributes"].
9.0 Author's Address class value type
-----------------------------------------
ENC-Transform 11 B
INT-Transform 12 B
EXT-Transform 13 B
The ENC-Transform has the following values.
name value
---- -----
Reserved 0
3DES 1
AES-CBC 2
AES-CTR 3
The INT-Transform has the following values.
name value
---- -----
Reserved 0
RSA-SHA 1
TESLA 2
The EXT-Transform has the following values.
name value
---- -----
Reserved 0
HMAC-SHA1 1
7.0 Acknowledgements
The authors wish to thank Scott Fluhrer, Thomas Hardjono, Steve Kent
and Brian Weis for their thoughtful comments and suggestions.
8.0 Author's Address
Mark Baugher
Cisco Systems, Inc.
5510 SW Orchid Street
Portland, Oregon
mbaugher@cisco.com
+1-503-245-4543
Ran Canetti Ran Canetti
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
30 Saw Mill River Road 30 Saw Mill River Road
Hawthorne, NY 10598, USA Hawthorne, NY 10598, USA
canetti@watson.ibm.com canetti@watson.ibm.com
Tel: +1-914-784-6692 Tel: +1-914-784-6692
Pau-Chen Cheng Pau-Chen Cheng
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
skipping to change at page 14, line 21 skipping to change at page 11, line 40
pau@watson.ibm.com pau@watson.ibm.com
Tel: +1-914-784-6692 Tel: +1-914-784-6692
Pankaj Rohatgi Pankaj Rohatgi
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
30 Saw Mill River Road 30 Saw Mill River Road
Hawthorne, NY 10598, USA Hawthorne, NY 10598, USA
rohatgi@watson.ibm.com rohatgi@watson.ibm.com
Tel: +1-914-784-6692 Tel: +1-914-784-6692
Mark Baugher 9.0 References
Cisco Systems, Inc.
5510 SW Orchid Street
Portland, Oregon
mbaugher@cisco.com
+1-503-245-4543
10.0 References 9.1 Normative References
10.1 Normative References [AHBIS] S. Kent, IP Authentication Header (AH), IETF, Work in
Progress, March 2003, http://www.ietf.org/internet-drafts/draft-
ietf-ipsec-rfc2402bis-02.txt
[ESPBIS] S. Kent, IP Encapsulated Security Payload (ESP), IETF, Work
in Progress, March 2003, http://www.ietf.org/internet-drafts/draft-
ietf-ipsec-esp-v3-04.txt.
[GDOI] M. Baugher, H. Harjono, H. Harney, B. Weis, The Group Domain [GDOI] M. Baugher, H. Harjono, H. Harney, B. Weis, The Group Domain
of Interpretation, IETF, Work in Progress, October 2002, of Interpretation, IETF, Work in Progress, October 2002,
http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-06.txt. http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-06.txt.
[GSAKMP] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light, IETF, [GSAKMP] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light, IETF,
Work in Progress, July 2002, http://www.ietf.org/internet- Work in Progress, July 2002, http://www.ietf.org/internet-
drafts/draft-ietf-msec-gsakmp-light-sec-01.txt drafts/draft-ietf-msec-gsakmp-light-sec-01.txt
[IANA] http://www.iana.org/assignments/isakmp-registry
[MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Normann, [MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Normann,
MIKEY: Multimedia Internet KEYing, IETF, Work in Progress, September MIKEY: Multimedia Internet KEYing, IETF, Work in Progress, September
2002, http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey- 2002, http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-
04.txt 04.txt
[PKCS1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, [PKCS1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories,
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf, June 2002. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf, June 2002.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing
for Message Authentication, Internet Request for Comments 2104, for Message Authentication, Internet Request for Comments 2104,
IETF, November 1997, ftp://ftp.rfc-editor.org/in-notes/rfc2104.txt. IETF, November 1997, ftp://ftp.rfc-editor.org/in-notes/rfc2104.txt.
[RFC2401] S.Kent, R.Atkinson, Security Architecture for the Internet [RFC2401] S.Kent, R.Atkinson, Security Architecture for the Internet
Protocol, Internet Request for Comments 2401, IETF, November 1998, Protocol, Internet Request for Comments 2401, IETF, November 1998,
http://www.ietf.org/rfc/tfc2401.txt. http://www.ietf.org/rfc/tfc2401.txt.
[RFC2404] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP [RFC2404] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP
and AH, Internet Request for Comments 2404, IETF, November 1998, and AH, Internet Request for Comments 2404, IETF, November 1998,
http://www.ietf.org/rfc/rfc2404.txt. http://www.ietf.org/rfc/rfc2404.txt.
[RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload
(ESP), Internet Request for Comments 2406, IETF, November 1998,
http://www.ietf.org/rfc/rfc2406.txt.
[RFC2407] D. Piper, The Internet IP Security Domain of [RFC2407] D. Piper, The Internet IP Security Domain of
Interpretation for ISAKMP, Internet Request for Comments 2407, IETF, Interpretation for ISAKMP, Internet Request for Comments 2407, IETF,
November 1998, http://www.ietf.org/rfc/rfc2407.txt. November 1998, http://www.ietf.org/rfc/rfc2407.txt.
[RFC2451] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", Internet Request For Comments 2451, IETF, November Algorithms", Internet Request For Comments 2451, IETF, November
1998, ftp://ftp.rfc-editor.org/in-notes/rfc2451.txt. 1998, ftp://ftp.rfc-editor.org/in-notes/rfc2451.txt.
[RFC3376] B.Cain, S.Deering, B.Fenner, I. Kouvelas, A. Thyagarajan, [RFC3376] B.Cain, S.Deering, B.Fenner, I. Kouvelas, A. Thyagarajan,
Internet Group Management Protocol, Version 3, Internet Request for Internet Group Management Protocol, Version 3, Internet Request for
Comments 3376, IETF, October 2002, Comments 3376, IETF, October 2002,
http://www.ietf.org/rfc/rfc3376.txt. http://www.ietf.org/rfc/rfc3376.txt.
[SSM]H.Holbrook, B.Cain, Source Specific Multicast for IP, [SSM]H.Holbrook, B.Cain, Source Specific Multicast for IP,
http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-00.txt, Work http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-00.txt, Work
in Progress in Progress
[TESLA] [TESLA]
10.2 Informative References 9.2 Informative References
[CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, B. [CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, B.
Pinkas, "Multicast Security: A Taxonomy and Efficient Pinkas, "Multicast Security: A Taxonomy and Efficient
Authentication", INFOCOM '99. Authentication", INFOCOM '99.
[CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security [CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security
issues",draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998. issues",draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998.
[Ch] S. Cheung, An Efficient Message Authentication Scheme for [Ch] S. Cheung, An Efficient Message Authentication Scheme for
Link State Routing, Proceedings of the 13th Annual Computer Link State Routing, Proceedings of the 13th Annual Computer
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/