Internet Engineering Task Force Mark Baugher (Cisco Systems)
MSEC Working Group Ran Canetti (IBM Watson)
INTERNET-DRAFT Pau-Chen Cheng (IBM Watson)
EXPIRES: April 25, 2003 Pankaj Rohatgi (IBM Watson)
October 25, 2002
MESP: Multicast Encapsulating Security Payload
<draft-ietf-msec-mesp-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Multicast ESP (MESP) is a security protocol for IP multicast data.
MESP extends the IPsec Encapsulating Security Payload (ESP) protocol
for multicast operation and supports source message authentication
for multicast packets. MESP offers three improvements to IPsec ESP
for multicast operation. First, it allows a mix of group-secrecy,
group-authentication, and source-authentication transforms to be
applied to an MESP packet. Second, it extends ESP to authenticate
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.
INTERNET-DRAFT Multicast ESP October 25, 2002
TABLE OF CONTENTS
1.0 Notational Conventions..........................................2
2.0 Introduction....................................................2
3.0 Changes from the IPsec Specifications...........................3
3.1 Changes from RFC 2401..........................................3
3.2 Changes from RFC 2406..........................................4
4.0 IP Multicast Security Functionalities...........................5
4.1 Composition of the Functionalities.............................6
4.2 MESP Security Association and Parameters.......................7
5.0 MESP Packet Format.............................................7
5.1 MESP Transforms................................................9
5.2 MESP Conformance Requirements.................................10
5.3 MESP Signaling................................................11
5.3.1 GDOI......................................................11
5.3.2 GSAKMP....................................................11
5.3.3 MIKEY.....................................................11
6.0 Security Considerations........................................11
7.0 IANA Considerations............................................13
8.0 Acknowledgements...............................................13
9.0 Author's Address...............................................13
10.0 References....................................................14
10.1 Normative References.........................................14
10.2 Informative References.......................................15
1.0 Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terminology conforms to [RFC2828].
2.0 Introduction
Like the IPsec Encapsulation Security Payload (ESP), MESP provides a
set of security services that include access control, connectionless
integrity, data origin authentication, rejection of replayed
packets, confidentiality (encryption), and limited traffic-flow
confidentiality [Section 3.1, RFC2401]. Unlike ESP, MESP provides
data origin authentication for multicast sources. Thus, MESP is not
ESP: MESP has a distinct protocol number from ESP. MESP does extend
ESP, however, and MESP includes the base IPsec ESP documents in its
definition. This I-D, therefore, assumes that the reader is
familiar with the "Security Architecture for Internet Protocol"
[RFC2401] and the "IP Encapsulating Security Payload (ESP)"
[RFC2406] RFCs. Section 3 describes MESP changes to the IPsec RFCs
for IP multicast data security.
Section 4 reviews the functionalities of multicast data-security
transforms for use by a variety of IP multicast applications such as
Baugher, Canetti, Cheng, Rohatgi [Page 2]
INTERNET-DRAFT Multicast ESP October 25, 2002
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
Baugher, Canetti, Cheng, Rohatgi [Page 3]
INTERNET-DRAFT Multicast ESP October 25, 2002
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].
Baugher, Canetti, Cheng, Rohatgi [Page 4]
INTERNET-DRAFT Multicast ESP October 25, 2002
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
3.1, RFC2406].
4) MESP REQUIRES some form of message authentication; NULL
authentication [Section 3.2.2, RFC2406] is supported only under
certain circumstances that are defined in Section 4.1, below.
5) MESP refers to ESP authentication as the "external
authentication," which MUST be a hash-based message authentication
code [RFC2104, RFC2404] and which MUST NOT be a digital signature
[Section 3.4.4, RFC2406].
6) MESP has a different set of conformance requirements than IPsec
ESP [Section 3.5, RFC2406]. Section 5.2 lists MESP conformance
requirements.
MESP conformance subsumes IPsec ESP conformance for authentication
but not for encryption (see Section 5.2). MESP, however, classifies
ESP message authentication as "group authentication" and ESP message
confidentiality (encryption) as "group secrecy." The following
section defines these functionalities.
4.0 IP Multicast Security Functionalities
The security requirements for multicast have been discussed in [CP].
In particular, these reference documents identify three different
functionalities that must be part of any complete solution.
a) Group Secrecy (GS)
The GS functionality ensures that the transmitted data is accessible
only to group members (i.e. two or more hosts in possession of a
shared symmetric key). This can also be viewed as a way to enforce
access control. A typical realization is to encrypt data using a key
known only to group members. Essentially, the solution for multicast
is the same as the solution for unicast confidentiality. It is
important to note, however, that some encryption transforms have
special considerations when a key is shared among multiple senders.
An MESP encryption or authentication transform SHOULD describe the
potential risks of multicast operation and how those risks are
averted.
b) Group Authentication (GA).
The GA functionality ensures that any group member can verify that
the received data originated from someone in the group. Note that
group authentication by itself does not identify the source of the
data; for example, the data might have been forged by any malicious
Baugher, Canetti, Cheng, Rohatgi [Page 5]
INTERNET-DRAFT Multicast ESP October 25, 2002
group member. GA can be efficiently realized using standard shared
key authentication mechanisms such as Message Authentication Codes
(MACs), e.g., CBC-MAC, HMAC, or UMAC. IPsec ESP authentication
using a hash-based message authentication code (HMAC) is strictly
GA.
c) Source and Data Authentication (SrA).
The SrA functionality ensures that any group member can verify that
the received data originated from the claimed source and was not
modified en-route by anyone (including other malicious group
members). Source and Data Authentication provides a much stronger
security guarantee than the Group Authentication functionality.
Realizing source 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
A secure multicast solution is likely to utilize all three of the
basic functionalities. Due to the diversity of the various
application and deployment scenarios for multicast, several issues
arise with respect to the composition and ordering of these
functionalities.
In ESP, encryption precedes authentication when both are present [p.
11, RFC2406]. This is an efficient ordering that allows the receiver
to apply a message authentication code (MAC) before it runs a more
computationally-intensive decryption; fast authentication before
encryption offers a better defense against invalid packets in a
denial of service attack. In MESP, therefore, the group secrecy (GS)
transforms MUST precede group authentication (GA). Krawczyk has
shown that it is more secure to authenticate encrypted data rather
than encrypt authenticated data [K], but this ordering does not
provide non-repudiation.
A digital signature over the plaintext packet payload, however,
provides both message source authentication and non-repudiation.
Digital signatures offer the simplest method for multicast source
authentication (SrA) but are computationally expensive and
impractical for high-rate packet flows. Given the relatively high
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,"
Baugher, Canetti, Cheng, Rohatgi [Page 6]
INTERNET-DRAFT Multicast ESP October 25, 2002
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
that MUST be applied first at the sender and last at the receiver.
MAC-based Group authentication is an external-authentication
transform that MUST be applied last at the sender and first at the
receiver. As in ESP, encryption (GS) is applied before external
authentication (GA). Other SrA transforms MAY be applied as internal
or external authentication depending on the particular transform;
TESLA, for example is an external authentication transform that
obviates the use of a MAC (see Section 5.0).
4.2 MESP Security Association and Parameters
The three secure-multicast functionalities are realized in an MSEC
security association (SA), which is an extension of an IPsec SA
[Section 4.4.3, RFC 2401]. MESP uses all of the SA "policy"
parameters for IPsec ESP with the exception of the AH parameters as
noted in Section 3, above. Any ESP encryption transform [p.10
RFC2407] MAY be used for MESP for the group-secrecy functionality.
MESP also supports NULL encryption (NULL GS). The ESP authentication
algorithm is the MESP GA transform, which must be an HMAC [RFC2404].
NULL GA authentication is supported for MESP when a MAC-based SrA
transform is used in its place. NULL GA authentication MUST NOT be
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)
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
SA is identified by the triple <s, g, SPI> where "s" is the source
IP address of the sender, "g" is the destination IP multicast
address, and "SPI" is the security parameter index that MAY be
assigned by the sender or by a third party entity such as a GCKS.
This SA identification method allows any sender, s, to multicast
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
The MESP packet is identical to an ESP packet in situations where no
internal authentication is applied. As with ESP, MESP MAY operate
Baugher, Canetti, Cheng, Rohatgi [Page 7]
INTERNET-DRAFT Multicast ESP October 25, 2002
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
IP header and the upper-layer protocol header (e.g. the transport
header). The IP header carries the MESP protocol number that is
designated in the IANA Considerations section of this I-D.
As in ESP, the tunnel-mode MESP packet header appears after the
encapsulating IP header and before the encapsulated IP packet. The
encapsulating IP header carries the MESP protocol number that is
designated in the IANA Considerations section of this I-D.
Figure 5-1: MESP Format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number |^ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ IV (if any) ~| |
| || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || ^ |
~ Internal Authentication Parameters (if any) ~| | |
| |I E E
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+N N X
| |T C T
~ Data (variable) ~| | |
|...............................................................|v | |
| Internal Authentication Tag (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
packet format, the MESP packet starts with a 32-bit Security
Parameter Index (SPI) field followed by a 32-bit sequence number
field. Unlike, ESP, the IP address of the packet sender together
Baugher, Canetti, Cheng, Rohatgi [Page 8]
INTERNET-DRAFT Multicast ESP October 25, 2002
with the SPI and the destination IP address uniquely identify a
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
transform (INT). When INT is applied to the packet, its output (if
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
in an ESP packet, the encrypted payload (ENC in Figure 5-1) ends
with variable amount (0-255 bytes) of padding followed by the pad
length and next header fields. The next header field still refers to
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
transform (EXT). Section 5.1 identifies the EXT transforms, which
the sender MUST perform last (and the receiver performs first).
Thus the sender performs the MESP transforms in the order of INT,
ENC, and EXT while the receiver performs them in the order of EXT,
ENC and INT.
5.1 MESP Transforms
Table 5.1-1 lists the MESP transforms and any dependencies that are
associated with their application. As noted above, MESP REQUIRES
that a MAC external authentication be used in conjunction with an
internal-authenticating digital signature. This restriction reduces
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
Baugher, Canetti, Cheng, Rohatgi [Page 9]
INTERNET-DRAFT Multicast ESP October 25, 2002
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
+-----------------+----------------------+---------------+
| 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
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
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
MAY be at most one INT, ENC or EXT transform applied to an MESP
packet.
5.2 MESP Conformance Requirements
TABLE 5.2-1: Default and Mandatory MESP Transforms
+-----------------+----------------------+
| Transform Class | Transform Identifier |
+-----------------+----------------------+
| INT | RSA-SHA1 |
+-----------------+----------------------+
| ENC | 3DES-CBC [RFC2451] |
+-----------------+----------------------+
| EXT | HMAC-SHA1 |
+-----------------+----------------------+
Baugher, Canetti, Cheng, Rohatgi [Page 10]
INTERNET-DRAFT Multicast ESP October 25, 2002
5.3 MESP Signaling
MESP parameters are signaled through a key management protocol or
interface such as GDOI, GSAKMP, GKMP, or SDP.
5.3.1 GDOI
GDOI MUST signal an MESP session using PROTO_MSEC_MESP as defined in
the IANA Section of this I-D. PROTO_MSEC_MESP has the same TEK
protocol-specific payload as PROTO_IPSEC_ESP [Section 5.4.1, GDOI].
MESP replaces the RFC 2407 attributes in the TEK payload with the
following attributes.
class value type
-----------------------------------------
INT Transform 1 B
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
Transform is HMAC-SHA1, the INT Transform MAY be RSA-SHA1, which has
the value 2.
The EXT Transform MAY be HMAC-SHA1, which has the value 1, or it MAY
be TESLA, which has the value 2 when the INT Transform is NULL.
The Encapsulation Mode MAY be 1 for transport mode or 2 for tunnel
mode.
SA Life Type and Life Duration are as defined in RFC 2407. Life
Type and Duration apply to all keys used for the session, including
the Signature PubKey, which MUST NOT be sent if the INT Transform is
not a digital signature algorithm. The length of the encoding is
determined by INT. {Editor: Need to define the Signature PubKey
format and should make it a GDOI KD payload item instead.}
5.3.2 GSAKMP
TBD
5.3.3 MIKEY
TBD
6.0 Security Considerations
Baugher, Canetti, Cheng, Rohatgi [Page 11]
INTERNET-DRAFT Multicast ESP October 25, 2002
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,
particularly on shared-media networks such as local area networks;
the MESP group secrecy function (see Section 4) controls access to
packet data and provides confidentiality to data exchanged among
group members. Even encrypted packets carry IP headers in plaintext,
however, and some environments might consider the source,
destination, packet length and other packet-header information to be
worthy of protection from unauthorized parties; MESP features the
IPsec tunnel mode of operation to encrypt the entire IP multicast
packet and thereby provide some traffic-flow confidentiality though
the encapsulating IP packet unavoidably reveals some information
about the tunnel endpoints (MESP implementations could alter the
encapsulated packet length to further thwart traffic analysis by an
attacker).
An attacker that has access to the flow of IP multicast packets can
"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
of the IP packet that contains the counter is not protected. MESP
REQUIRES message integrity for MESP packets through one of two
mechanisms. The first mechanism uses HMAC-SHA1 integrity with a
symmetric authentication key. Unlike unicast IP packets, the MAC
cannot authenticate the source of the packet for a multicast group
where multiple members share the symmetric authentication key.
Baugher, Canetti, Cheng, Rohatgi [Page 12]
INTERNET-DRAFT Multicast ESP October 25, 2002
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
second MESP mechanism augments the MAC with a digital signature over
the packet data to uniquely identify the sender of the packet.
Digital signatures leave multicast receivers vulnerable to denial-
of-service attack that the receiver attempts to validate through
computationally-expensive signature validation. MESP mandates that
HMAC-SHA1 message authentication MUST accompany a digital signature
so as to limit the effectiveness of forging digitally signed packets
by non-group members.
Unfortunately, group members are still capable of sending packets
with a valid MAC and invalid digital signature, i.e. a group member
can launch a DoS attack on the group using invalid digital
signatures. When this threat is an application concern, MESP
supports multicast source authentication using hybrid MAC/digital
signature and Timed MAC schemes, such as TESLA, to mitigate attacks
by group members upon the group. TESLA source authentication can
uniquely identify the source in a manner that amortizes the cost of
a single digital signature over a very long chain of packets
[TESLA].
7.0 IANA Considerations
MESP uses protocol number xxxx. Both of these values MUST be
registered with IANA.
GDOI uses PROTO_MSEC_MESP, which has the value xxxx. Within
PROTO_MSEC_ESP, GDOI signals the INT Transform with the number 1,
the EXT transform with the number 2, the Encapsulation Mode with the
value 3, SA Life Type with 4, SA Life Duration with 5, and Signature
PubKey with the value 6. Within the INT Transform, GDOI reserves
the number 1 for the NULL digital signature and 2 for RSA-SHA1.
Within the EXT transform, GDOI reserves the number 1 for HMAC-SHA1
and the number 2 for TESLA. Within Encapsulation Mode, GDOI
reserves 1 for transport mode and 2 for tunnel mode. The values
MUST be registered with IANA.
8.0 Acknowledgements
The authors wish to thank Brian Weis and Scott Fluhrer, who
identified some problems in a previous version of the draft.
9.0 Author's Address
Ran Canetti
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10598, USA
Baugher, Canetti, Cheng, Rohatgi [Page 13]
INTERNET-DRAFT Multicast ESP October 25, 2002
canetti@watson.ibm.com
Tel: +1-914-784-6692
Pau-Chen Cheng
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10598, USA
pau@watson.ibm.com
Tel: +1-914-784-6692
Pankaj Rohatgi
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10598, USA
rohatgi@watson.ibm.com
Tel: +1-914-784-6692
Mark Baugher
Cisco Systems, Inc.
5510 SW Orchid Street
Portland, Oregon
mbaugher@cisco.com
+1-503-245-4543
10.0 References
10.1 Normative References
[GDOI] M. Baugher, H. Harjono, H. Harney, B. Weis, The Group Domain
of Interpretation, IETF, Work in Progress, October 2002,
http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-06.txt.
[GSAKMP] H. Harney, A. Schuett, A. Colegrove, GSAKMP Light, IETF,
Work in Progress, July 2002, http://www.ietf.org/internet-
drafts/draft-ietf-msec-gsakmp-light-sec-01.txt
[MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Normann,
MIKEY: Multimedia Internet KEYing, IETF, Work in Progress, September
2002, http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-
04.txt
[PKCS1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories,
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf, June 2002.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing
for Message Authentication, Internet Request for Comments 2104,
IETF, November 1997, ftp://ftp.rfc-editor.org/in-notes/rfc2104.txt.
[RFC2401] S.Kent, R.Atkinson, Security Architecture for the Internet
Protocol, Internet Request for Comments 2401, IETF, November 1998,
http://www.ietf.org/rfc/tfc2401.txt.
Baugher, Canetti, Cheng, Rohatgi [Page 14]
INTERNET-DRAFT Multicast ESP October 25, 2002
[RFC2404] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP
and AH, Internet Request for Comments 2404, IETF, November 1998,
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
Interpretation for ISAKMP, Internet Request for Comments 2407, IETF,
November 1998, http://www.ietf.org/rfc/rfc2407.txt.
[RFC2451] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", Internet Request For Comments 2451, IETF, November
1998, ftp://ftp.rfc-editor.org/in-notes/rfc2451.txt.
[RFC3376] B.Cain, S.Deering, B.Fenner, I. Kouvelas, A. Thyagarajan,
Internet Group Management Protocol, Version 3, Internet Request for
Comments 3376, IETF, October 2002,
http://www.ietf.org/rfc/rfc3376.txt.
[SSM]H.Holbrook, B.Cain, Source Specific Multicast for IP,
http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-00.txt, Work
in Progress
[TESLA]
10.2 Informative References
[CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor, B.
Pinkas, "Multicast Security: A Taxonomy and Efficient
Authentication", INFOCOM '99.
[CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security
issues",draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998.
[Ch] S. Cheung, An Efficient Message Authentication Scheme for
Link State Routing, Proceedings of the 13th Annual Computer
Security Applications Conference, San Diego, December 8-12, 1997,
pp.90-98.
[GR] R. Gennaro, P. Rohatgi, "How to Sign Digital Streams", Advances
in Cryptology - Crypto '97, Springer-Verlag LNCS 1294, pp. 180-197,
1997.
[K] H. Krawczyk, The order of encryption and authentication for
protecting communications (or: How secure is SSL?). In J. Kilian,
editor, CRYPTO 2001.
Baugher, Canetti, Cheng, Rohatgi [Page 15]
INTERNET-DRAFT Multicast ESP October 25, 2002
[PCTS] A. Perrig, R. Canetti, D. Tygar, D. Song, Efficient
Authentication and Signature of Multicast Streams over Lossy
Channels, IEEE Symposium on Security and Privacy, Oakland, CA, May
2000.
[R] P. Rohatgi, A Compact and Fast Signature Scheme for Multicast
Packet Authentication, In 6th ACM Computer and Communications
Security Conference (CCS) , Nov 1999.
[WL] C. K. Wong and S. S. Lam, Digital Signatures for Flows and
Multicasts, IEEE ICNP '98. See also University of Texas at Austin,
Computer Science Technical report TR 98-15.
Baugher, Canetti, Cheng, Rohatgi [Page 16]