Internet Engineering Task Force Mark Baugher (Cisco Systems)
MSEC Working Group Ran Canetti (IBM Watson)
INTERNET-DRAFT Pau-Chen Cheng (IBM Watson)
Pankaj Rohatgi (IBM Watson)
EXPIRES: September 2003 March 2003
MESP: A Multicast Framework for the IPsec ESP
<draft-ietf-msec-mesp-01.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 framework for multicast data-origin
authentication using the IPsec Encapsulating Security Payload (ESP)
protocol. The MESP framework combines group-secrecy, group-
authentication, and source-authentication transforms in an ESP
packet. MESP uses a message authentication code for group
authentication to protect a digital signature, TESLA timed MAC, or
other multicast source-authentication transform.
INTERNET-DRAFT Multicast ESP March 2003
TABLE OF CONTENTS
1.0 Notational Conventions..........................................2
2.0 Introduction....................................................2
2.1 Changes from the Previous Version..............................3
2.2 Overview.......................................................3
3.0 IP Multicast Security Functionalities...........................3
3.1 Composition of the Functionalities.............................4
3.2 MESP Security Association Database.............................5
4.0 MESP Packet Format.............................................5
4.1 MESP Transforms................................................7
4.1.1 Group Secrecy..............................................7
4.1.2 Internal Authentication....................................7
4.1.3 External Authentication....................................7
4.2 MESP Signaling.................................................7
4.2.1 GDOI.......................................................7
4.2.2 GSAKMP.....................................................8
4.2.3 MIKEY......................................................8
5.0 Security Considerations.........................................8
5.1 MESP Authentication............................................8
5.2 MESP Denial-of-Service Protection..............................9
5.3 MESP Encryption................................................9
6.0 IANA Considerations............................................10
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
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
The IPsec Encapsulation Security Payload (ESP) provides a set of
security services that include data origin authentication, which
enables an IPsec receiver to validate that a received packet
originated from a peer-sender in a pairwise security association
[Section 3.1, RFC2401]. A Message Authentication Code (MAC), such
as the hash-based message authentication code [RFC2104, RFC2404]
(HMAC), is the common means to provide data-origin authentication
for pairwise IPsec security associations. For secure groups such as
IP multicast groups, however, a MAC supports only "group
authentication" and not data-origin authentication [CP]. This
Internet-Draft document (I-D) defines a framework for ESP data-
Baugher, Canetti, Cheng, Rohatgi [Page 2]
INTERNET-DRAFT Multicast ESP March 2003
origin authentication that is suitable for IP multicast groups of
ESP receivers.
2.1 Changes from the Previous Version
This version is not a protocol, unlike the previous version, but is
a transform framework for ESP and realizes all of its functions
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].
A smaller change that appears in this version of MESP is the
requirement that TESLA authentication be protected by external
authentication transform such as a MAC.
2.2 Overview
This I-D assumes that the reader is familiar with the "Security
Architecture for Internet Protocol" [RFC2401] and the "IP
Encapsulating Security Payload (ESP)" [ESPBIS] RFCs. Section 3
reviews the functionalities of group data-security transforms for
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.
3.0 IP Multicast Security Functionalities
The security requirements for multicast have been discussed in [CP].
In general, group security has different requirements and
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)
The GS functionality is ESP confidentiality applied to a group . It
ensures that transmitted data are 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 of GS is to encrypt data using a key known only
to group members. Essentially, the solution for multicast is the
Baugher, Canetti, Cheng, Rohatgi [Page 3]
INTERNET-DRAFT Multicast ESP March 2003
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 any potential
risks of multicast operation and how those risks are averted.
b) Group Authentication (GA)
The GA functionality enables a group member to verify that
the received data originated from someone in the group and was not
modified en-route by a non-group member. 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
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.
c) Source and Data Authentication (SrA)
The SrA functionality enables a group member to verify that
the received data originated from the claimed source and was not
modified en-route by anyone (including other malicious group
members). Unlike Group Authentication, SrA provides the IPsec data-
origin authentication function [RFC2401, ESPbis]. Source and Data
Authentication provides a much stronger security guarantee than
Group Authentication in that a particular group member can be
identified as a source of a packet. Group and multicast 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.
3.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 applied and
a "combined-mode" confidentiality/integrity operation is not used
[Section 3.3.2 of ESPBIS]. Combined modes of encryption and
authentication are supported in ESP [ESPbis] but are not considered
in this version of MESP. Encryption first 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 decryption offers a better defense
against bogus packets from a denial of service attack. In MESP,
therefore, the group secrecy (GS) transform MUST precede group
authentication (GA) when GS is used. In other words, the sender
Baugher, Canetti, Cheng, Rohatgi [Page 4]
INTERNET-DRAFT Multicast ESP March 2003
applies GS prior to GA and the receiver applies GA prior to GS.
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. The latter is usually not needed
or even desirable for IPsec applications.
MESP uses the same ordering for SrA: SrA MUST follow GS. Digital
signatures offer the simplest method for multicast source
authentication (SrA) but are computationally expensive, greatly
expand the packet size and impractical for many, if not most, packet
flows. Given the relatively high cost of signature verification, a
digital signature leaves the receiver vulnerable to denial of
service attack when an attacker succeeds in getting the receiver to
perform signature validation of bad packets.
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.
SrA transforms such as TESLA timed-MAC can be more efficient than
digital signatures for many applications. But like a digital
signature, it is REQUIRED that TESLA and other SrA transforms use
internal authentication in MESP and be protected by an external-
authentication MAC. Thus, a digital signature or TESLA MAC MUST be
applied prior to GA at the sender and after GA at the receiver.
MAC-based GA 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 any authentication and is
optional.
3.2 MESP Security Association Database
The MESP framework applies up to three transforms to a multicast ESP
packet in the order described above: Group Secrecy (GS) is OPTIONAL,
Source Authentication (SrA) SHOULD be applied next, and Group
Authentication (GA) SHOULD be applied last. The IPsec SAD MUST be
extended to store the additional transform information if MESP is to
be supported.
There are no changes to ESP SA lookup beyond what is specified for
multicast SAs in the IPsec specifications [AHbis, ESPbis].
4.0 MESP Packet Format
Baugher, Canetti, Cheng, Rohatgi [Page 5]
INTERNET-DRAFT Multicast ESP March 2003
The ESP Packet format is illustrated in Figure 4-1:
* Internal Authentication 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.
Figure 4-1: MESP Transforms in an ESP Packet
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 (variable & optional) ~ | |
+---------------------------------------------------------------+ | |
~ Internal Authentication Parameters (variable & optional) ~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
~ Data (variable) ~^ I E
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E N X
~ ~ Padding (0-255 bytes) |N T T
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C | |
| | Pad Length | Next Header |v v |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Internal Authentication Tag (variable) ~ v
+---------------------------------------------------------------+
~ Integrity Check Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encryption (ENC), when applied, covers the ESP data, padding and
next header fields. Internal Authentication (INT) covers the ESP
sequence number through the next header field, inclusive. External
authentication (EXT) covers the entire ESP packet except for the
Integrity Check Value (ICV) field.
A sender MAY use an encryption-transform (ENC) as done in any other
ESP packet.
When INT is applied to the packet, its output (if any) is placed in
the Internal Authentication Tag. Section 4.1 identifies the INT
transforms, which the sender MUST perform prior to the encryption
transform.
Baugher, Canetti, Cheng, Rohatgi [Page 6]
INTERNET-DRAFT Multicast ESP March 2003
A sender of an MESP packet SHOULD use an external-authentication
transform (EXT). Section 4.1 identifies the EXT transforms, which
the sender MUST perform last (and the receiver performs first).
The sender MUST perform the MESP transforms in the order of ENC,
INT, and EXT while the receiver MUST perform them in the order of
EXT, INT and ENC.
4.1 MESP Transforms
This version of MESP defines a minimal number of transforms. In the
future, new transforms MAY be added through the publication of an
Internet RFC. The transforms of the MESP framework are listed below
and classified according to MESP type.
4.1.1 Group Secrecy
MESP supports 3DES, AES-CBC, and AES-CTR.
4.1.2 Internal Authentication
MESP internal authentication is either RSA-SHA1 or TESLA.
4.1.3 External Authentication
MESP external authentication uses HMAC-SHA1.
4.2 MESP Signaling
MESP parameters are signaled through a key management protocol or
interface such as GDOI, GSAKMP, GKMP, or SDP.
4.2.1 GDOI
GDOI MUST signal use of the MESP framework using PROTO_ESP_MESP with
the TRANSFORM ID set to the MESP transform ID value (see IANA
Section below). MESP extends the RFC 2407 attributes ["IPsec
Security Association Attributes," IANA] with the three new classes,
"ENC_Transform, "INT_Transform," and "EXT_Transform" (see IANA
Section below).
The ENC Transform MUST be one of the transforms from 4.1.1.
Additional ENC transforms MAY be added to this suite through the
publication of an Internet RFC.
The INT Transform MUST be non-null and MUST be one of the values
from 4.1.2. Additional INT transforms MAY be added to this suite
through the publication of an Internet RFC.
Baugher, Canetti, Cheng, Rohatgi [Page 7]
INTERNET-DRAFT Multicast ESP March 2003
The EXT Transform MUST be one of the transforms from 4.1.3.
Additional EXT transforms MAY be added to this suite through the
publication of an Internet RFC.
The IANA Considerations section of this document describes value
assignments for the EXT, INT and ENC attributes.
The SA Life Type and Life Duration as defined in RFC 2407 [RFC2407,
IANA] 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.}
4.2.2 GSAKMP
TBD
4.2.3 MIKEY
TBD
5.0 Security Considerations
MESP is a framework for IPsec ESP authentication and encryption
transforms to support IP multicast delivery. IPsec ESP provides
access control, rejection of replayed packets, confidentiality
(encryption), limited traffic-flow confidentiality and
connectionless integrity. ESP supports 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.
ESP provides rejection of replayed packets for pairwise security
associations and for multicast security associations under certain
circumstances [ESPbis]. MESP has the same replay mechanism for the
single-sender case; the multi-sender case is for further study. ESP
provides data origin authentication for pairwise security
associations using symmetric message authentication codes, which are
not sufficient for group security applications where more than two
members share a symmetric key.
5.1 MESP Authentication
The MESP framework for ESP provides data-origin authentication
services to multicast ESP packets. Secure groups, such as secure
multicast groups, cannot use a symmetric-key MAC to uniquely
identify the sender; any group member that is in possession of the
group authentication key is capable of replacing the source address
of the packet with that of another group member and applying the
symmetric key to authenticate the packet. To uniquely identify a
sender among a group of members, digital signature, public key
Baugher, Canetti, Cheng, Rohatgi [Page 8]
INTERNET-DRAFT Multicast ESP March 2003
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.
5.2 MESP Denial-of-Service Protection
As discussed above, a group member cannot authenticate the source of
the packet for a multicast group where multiple members share the
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-
of-service attack if the receiver is duped into performing
computationally-expensive signature validation of bogus packets. An
external message authentication SHOULD accompany a digital signature
so as to limit the effectiveness of bogus digitally signed packets
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
with a valid external-authenticating MAC and invalid digital
signature, i.e. a group member can launch a DoS attack on the group
using invalid digital signatures. And group members are still
capable of sending packets with a valid external-authentication MAC
but an invalid TESLA MAC. In both the TESLA and digital-signature
cases, the external authentication will succeed only to have the
internal authentication fail. MESP includes the ESP sequence number
in the internal authentication to protect against a replay attack by
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.
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.
5.3 MESP Encryption
The value of MESP encryption is to validate individual encryption
transforms for multicast operation. It is possible that a
Baugher, Canetti, Cheng, Rohatgi [Page 9]
INTERNET-DRAFT Multicast ESP March 2003
particular cipher and mode are suitable for pairwise security
associations but not for multicast security associations, such as
one where multiple senders share the key. For example, a stream or
hybrid stream/block cipher has special risks of keystream reuse when
its key is shared by multiple senders. Although IPsec encryption
transforms are generally suitable for multicast operation, many have
not been evaluated, tested or used in IP multicast environments.
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.
6.0 IANA Considerations
This I-D extends the RFC 2407 attributes for IPsec ESP,
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"].
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
Baugher, Canetti, Cheng, Rohatgi [Page 10]
INTERNET-DRAFT Multicast ESP March 2003
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
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10598, USA
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
9.0 References
9.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
of Interpretation, IETF, Work in Progress, October 2002,
http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-06.txt.
Baugher, Canetti, Cheng, Rohatgi [Page 11]
INTERNET-DRAFT Multicast ESP March 2003
[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
[IANA] http://www.iana.org/assignments/isakmp-registry
[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.
[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.
[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]
9.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.
Baugher, Canetti, Cheng, Rohatgi [Page 12]
INTERNET-DRAFT Multicast ESP March 2003
[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.
[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 13]
