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
      EXPIRES: September 2003                               March 2003

             MESP: A Multicast Encapsulating Security Payload
                     <draft-ietf-msec-mesp-00.txt> 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 security protocol framework for IP multicast data.
   MESP extends data-origin
   authentication using the IPsec Encapsulating Security Payload (ESP) protocol
   for multicast operation and supports source message authentication
   for multicast packets.
   protocol. The MESP offers three improvements to IPsec ESP
   for multicast operation.  First, it allows a mix of framework combines group-secrecy,
   group-authentication, group-
   authentication, and source-authentication transforms to be
   applied to in an MESP packet. Second, it extends ESP to authenticate
   messages sent by
   packet. MESP uses a member of the message authentication code for group using
   authentication to protect a digital signature signature, TESLA timed MAC, or
   hybrid MAC and signature
   other multicast source-authentication 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

1.0 Notational Conventions..........................................2
2.0 Introduction....................................................2
3.0
 2.1 Changes from the IPsec Specifications...........................3
 3.1 Changes from RFC 2401..........................................3
 3.2 Changes from RFC 2406..........................................4
4.0 Previous Version..............................3
 2.2 Overview.......................................................3
3.0 IP Multicast Security Functionalities...........................5
 4.1 Functionalities...........................3
 3.1 Composition of the Functionalities.............................6
 4.2 Functionalities.............................4
 3.2 MESP Security Association and Parameters.......................7
5.0 Database.............................5
4.0  MESP Packet Format.............................................7 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 Transforms................................................9 Authentication............................................8
 5.2 MESP Conformance Requirements.................................10 Denial-of-Service Protection..............................9
 5.3 MESP Signaling................................................11
   5.3.1 GDOI......................................................11
   5.3.2 GSAKMP....................................................11
   5.3.3 MIKEY.....................................................11 Encryption................................................9
6.0 Security Considerations........................................11
7.0 IANA Considerations............................................13 Considerations............................................10
7.0 Acknowledgements...............................................11
8.0 Acknowledgements...............................................13
9.0 Author's Address...............................................13
10.0 References....................................................14
 10.1 Address...............................................11
9.0 References.....................................................11
 9.1 Normative References.........................................14
 10.2 References..........................................11
 9.2 Informative References.......................................15 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

   Like the

   The IPsec Encapsulation Security Payload (ESP), MESP (ESP) 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 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].  Unlike ESP, MESP provides
   data origin  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 sources.  Thus, MESP is not
   ESP: MESP has a distinct protocol number from ESP.  MESP does extend
   ESP, groups, however, a MAC supports only "group
   authentication" and MESP includes the base IPsec ESP documents in its
   definition. not data-origin authentication [CP]. This I-D, therefore, assumes
   Internet-Draft document (I-D) defines a framework for ESP data-
   origin authentication that the reader is
   familiar with the "Security Architecture 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)"
   [RFC2406] [ESPBIS] RFCs. Section 3 describes MESP changes to the IPsec RFCs
   for IP multicast data security.

   Section 4
   reviews the functionalities of multicast group data-security transforms for use by a variety of IP multicast
   applications such as media streaming, process control, and reliable
   multicast applications.  Section 4 3 describes the problem of
   authenticating the source of IP multicast data, and it describes when 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 data-authentication key 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 shared
   by more than two IPsec endpoints. Section 4 describes the network
   configuration to prevent multiple senders.  Case (b) requires that
   each sender be trusted not to impersonate any other sender MESP
   framework in terms of the extensions 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 the ESP IV and features source message-
   authentication
   integrity-check-value fields. The three functionalities of the MESP
   framework are realized in cryptographic transforms that are secure
   for ASM various uses, and SSM environments. Section 5 describes recites the security considerations
   for each MESP extensions to transform.  Section 5 considers IP multicast risks,
   the IPsec Encapsulating
   Security Payload (ESP) protocol for source message authentication transforms that address a particular risk, and the other functionalities of Section 4. The design suitability
   of MESP
   emphasizes flexibility, simplicity a transform for various applications and maximal reuse of IPSec ESP.
   MESP preserves ESP functionality when environments.

3.0 IP Multicast Security Functionalities

   The security requirements for multicast source
   authentication have been discussed in [CP].
   In general, group security has different requirements and sender-based indexing of SAs are
   characteristics than pairwise security.  In particular, data-origin
   authentication using a MAC will not needed.
   Thus, the MESP packet structure is indistinguishable prevent one member from ESP for
   particular mixes
   impersonating another when a group of three or more members share
   the secure multicast functionalities.  As there symmetric authentication key.  There are three inter-dependent new
   functionalities for MESP, Section 5
   specifies their composition and ordering. needed to add data-origin authentication to ESP.

   a) Group Secrecy (GS)

   The three functionalities are realized in cryptographic transforms GS functionality is ESP confidentiality applied to a group . It
   ensures that transmitted data are secure for various uses and Section 6 recites 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 security
   considerations solution for each MESP transform.  Section 6 considers IP multicast risks, is the transforms that address a particular risk, and
   same as 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 solution for MESP.

3.0 Changes from the IPsec Specifications

   Although MESP has its own namespace, protocol number, and unicast confidentiality.  It is important
   to note, however, that some encryption transforms have special
   considerations when a
   distinct security protocol from ESP, key is shared among multiple senders.  An MESP reuses IPsec ESP's base
   specifications, RFC 2401
   encryption or authentication transform SHOULD describe any potential
   risks of multicast operation and RFC 2406.  This I-D assumes how those risks are averted.

   b) Group Authentication (GA)

   The GA functionality enables a group member to verify that
   the
   reader is familiar with these specifications, which are referenced received data originated from someone in the group and was not copied
   modified en-route 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 a non-group member.  Note that group
   authentication for IP
   multicast data. "Data origin authentication...is limited by itself does not identify the
   extent to which secrets used with source of 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,
   data.  For example, the
   most significant change introduced data might have been forged by MESP to IPsec ESP are methods
   to uniquely identify sources of IP packets to a multicast group. 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 following are SrA functionality enables a group member to verify that
   the specific changes introduced received data originated from the claimed source and was not
   modified en-route by MESP to RFC
   2401.

   1) MESP operates in both gateway (tunnel mode) and host (transport
   mode) environments without support for anyone (including other malicious group
   members). Unlike Group Authentication, SrA provides the IPsec Authentication
   Header protocol [Sections 3, 3.2 data-
   origin authentication function [RFC2401, ESPbis].  Source and 4.3, RFC2401].  MESP MAY be
   tunneled in an IPsec AH tunnel, but such operation is Data
   Authentication provides a much stronger security guarantee than
   Group Authentication in the realm that a particular group member can be
   identified as a source of IPsec a packet. Group 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 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 <destination IP address, security parameter index>
   pair; there Functionalities

   A secure multicast solution is no need likely to specify utilize all three of the protocol, which is always MESP
   [Section 4.4.3, RFC2401].

   4) MESP supports SA update for key refresh in addition
   basic functionalities. Due 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 diversity of the group
   controller/key server (GCKS) various
   application and deployment scenarios for a multicast group [Section 4.7, RFC
   2401].

   6) An MESP receiver MUST NOT share an SA among multiple senders 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
   multicast group "combined-mode" confidentiality/integrity operation is not used
   [Section 4.7, RFC 2401].

   Multicast groups having many senders might require that an SA be
   shared among all senders 3.3.2 of ESPBIS]. Combined modes of encryption and
   authentication are supported 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 ESP [ESPbis] but so are not considered
   in this version of MESP. Encryption first is an efficient ordering
   that allows the requirement for a receiver to support apply a large number of SAs for message authentication code
   (MAC) before it runs a group having more computationally-intensive decryption;
   fast authentication before decryption offers a large number better defense
   against bogus packets from a denial of senders.  For these and other reasons, service attack.  In MESP,
   therefore, the use of a wildcard
   source-address in an MESP SA is for further study.

3.2 Changes from RFC 2406

   Some MESP changes group secrecy (GS) transform MUST precede group
   authentication (GA) when GS is used.  In other words, the sender
   applies GS prior to RFC 2406 are also listed above for RFC 2401;
   these are included in 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 section ordering
   does not provide non-repudiation. The latter is usually not needed
   or even desirable for the sake of completeness.

   1) IPsec applications.

   MESP uses protocol number xxxx and not 50 [Section 2, RFC2406].

   2) An MESP SPI is selected by the sender or by same ordering for SrA: SrA MUST follow GS. Digital
   signatures offer the group
   controller/key server (GCKS) [Section 2.1, RFC 2406].

   3) MESP does not support use of AH simplest method for IP multicast packets [Section
   3.1, RFC2406].

   4) MESP REQUIRES some form of message authentication; NULL source
   authentication [Section 3.2.2, RFC2406] is supported only under
   certain circumstances that (SrA) but are defined in Section 4.1, below.

   5) MESP refers to ESP authentication as computationally expensive, greatly
   expand the "external
   authentication," which MUST be a hash-based message authentication
   code [RFC2104, RFC2404] packet size and which MUST NOT be impractical for many, if not most, packet
   flows.  Given the relatively high cost of signature verification, a
   digital signature
   [Section 3.4.4, RFC2406].

   6) MESP has a different set leaves the receiver vulnerable to denial 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
   service attack when an attacker succeeds 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 getting the transmitted data is accessible
   only receiver to group members (i.e. two or more hosts in possession
   perform signature validation 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 bad packets.

   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 partially protects the received data originated receiver 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
   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 denial-of-service attacks
   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 bogus 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
   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
   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 packets by applying a MAC to the packet
   after signing it.  MESP Packet format is illustrated in Figure 5-1.  As calls this MAC "external authentication" and
   applies it in an identical fashion to ESP.  The digital signature is
   called "internal authentication," which the ESP
   packet format, sender applies to the MESP
   packet starts with a 32-bit Security
   Parameter Index (SPI) field followed payload before the MAC.  MAC authentication, therefore, is
   applied first by a 32-bit sequence number
   field. Unlike, ESP, the IP address receiver.  If the attacker is not a member of
   the packet sender together
   with group, or otherwise has not obtained the SPI and group key, the destination IP address uniquely identify MAC will
   fail before the receiver incurs the burden of a
   Security Association (SA) 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 associated keying material.

   As other SrA transforms use
   internal authentication in MESP and be protected by an ESP packet, external-
   authentication MAC.  Thus, a digital signature or TESLA MAC MUST be
   applied prior to GA at the sequence number field sender and after GA at the receiver.
   MAC-based GA is followed by an
   optional IV field. In cases where 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 does not use internal
   authentication, Security Association Database

   The MESP framework applies up to three transforms to a multicast ESP
   packet in the structure of 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 encrypted data field additional transform information if MESP is
   identical to that of the
   be supported.

   There are no changes to ESP packet. In cases where SA lookup beyond what is specified for
   multicast SAs in the IPsec specifications [AHbis, ESPbis].

4.0  MESP uses
   internal authentication, the encrypted data consists of the
   following fields: Packet Format
   The ESP Packet format is illustrated in Figure 4-1:

   * Internal Transform 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.

   A sender of an

             Figure 4-1: MESP packet MAY use an internal-authentication
   transform (INT). When INT is applied to the packet, its output (if
   any) is placed 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 Tag.  Section 5.1
   identifies (INT) covers the INT transforms, which ESP
   sequence number through the sender MUST perform prior
   to next header field, inclusive. External
   authentication (EXT) covers the encryption transform. entire ESP packet except for the
   Integrity Check Value (ICV) field.

   A sender of an MESP packet MAY use an encryption-transform (ENC). As (ENC) as done in an any other
   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 packet.

   When INT is applied to
   the next protocol header (e.g. transport header) the packet, its output (if any) is placed in
   the actual data. Internal Authentication Tag.  Section 5.1 4.1 identifies the ENC INT
   transforms, which the sender MUST perform prior to the external authentication encryption
   transform.

   A sender of an MESP packet MAY SHOULD use an external-authentication
   transform (EXT).  Section 5.1 4.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
   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 sender 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 perform 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 the order of ENC,
   INT, and EXT while the receiver MUST perform them in Table 5.1-1, HMAC-SHA1 [RFC2404] is the only pre-defined
   MESP MAC order of
   EXT, INT and is REQUIRED when internal authentication is used. ENC.

4.1 MESP Transforms

   This version of MESP defines a minimal number of transforms.  In
   addition to HMAC-SHA1, TESLA the
   future, new transforms MAY be applied when no internal-
   authentication transform applies to added through the publication of an MESP packet.
   Internet RFC.  The Table 5.1-1 transforms of the MESP framework are mutually exclusive by class: There
   MAY be at most one INT, ENC or EXT transform applied listed below
   and classified according to an MESP
   packet.

5.2 type.

4.1.1 Group Secrecy

   MESP Conformance Requirements

   TABLE 5.2-1: Default supports 3DES, AES-CBC, and Mandatory AES-CTR.

4.1.2 Internal Authentication

   MESP Transforms
      +-----------------+----------------------+
      | Transform Class | Transform Identifier |
      +-----------------+----------------------+
      |      INT        | internal authentication is either RSA-SHA1             |
      +-----------------+----------------------+
      |      ENC        | 3DES-CBC [RFC2451]   |
      +-----------------+----------------------+
      |      EXT        | HMAC-SHA1            |
      +-----------------+----------------------+

5.3 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.

5.3.1

4.2.1 GDOI

   GDOI MUST signal an use of the MESP session framework using PROTO_MSEC_MESP as defined in PROTO_ESP_MESP with
   the TRANSFORM ID set to the MESP transform ID value (see 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]. below).  MESP replaces extends the RFC 2407 attributes in the TEK payload ["IPsec
   Security Association Attributes," IANA] 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 three new classes,
   "ENC_Transform, "INT_Transform," and "EXT_Transform" (see IANA
   Section below).

   The INT ENC Transform MAY MUST be NULL, which has one of the value 1.  When transforms from 4.1.1.
   Additional ENC transforms MAY be added to this suite through the EXT
   publication of an Internet RFC.

   The INT Transform is HMAC-SHA1, MUST be non-null and MUST be one of the values
   from 4.1.2. Additional INT Transform transforms MAY be RSA-SHA1, which has added to this suite
   through the value 2. publication of an Internet RFC.

   The EXT Transform MAY MUST be HMAC-SHA1, which has one of the value 1, or it transforms from 4.1.3.
   Additional EXT transforms MAY be TESLA, which has added to this suite through the
   publication of an Internet RFC.

   The IANA Considerations section of this document describes value 2 when
   assignments for the EXT, INT Transform is NULL. and ENC attributes.

   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 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.}

5.3.2

4.2.2 GSAKMP

   TBD

5.3.3

4.2.3 MIKEY

   TBD

6.0

5.0 Security Considerations

   MESP provides is a set of security services that include framework for IPsec ESP authentication and encryption
   transforms to support IP multicast delivery.  IPsec ESP provides
   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  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.  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
   ESP 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 rejection 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 pairwise security
   associations 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 for multicast security association (SA), however, then associations under certain
   circumstances [ESPbis].  MESP has the
   IPSec-defined same replay protection mechanism will not work.  Thus, for the
   current version of
   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 mandates that an Authentication

   The MESP SA MUST NOT be shared
   by multiple senders.  It is framework for future study ESP provides data-origin authentication
   services to multicast ESP packets.  Secure groups, such as secure
   multicast groups, cannot use a symmetric-key MAC to determine whether
   SA-sharing uniquely
   identify the sender; any group member that is needed in MESP.

   The MESP replay counter possession of the
   group authentication key is vulnerable to tampering if capable of replacing the integrity source address
   of the IP packet with that contains of another group member and applying the counter is not protected.
   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
   REQUIRES message integrity defines a general ESP
   packet structure for accommodating a digital signature or TESLA
   timed MAC.

5.2 MESP packets through one of two
   mechanisms.  The first mechanism uses HMAC-SHA1 integrity with Denial-of-Service Protection

   As discussed above, a
   symmetric authentication key.  Unlike unicast IP packets, the MAC group member cannot authenticate the source of
   the packet for a multicast group where multiple members share the symmetric authentication
   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
   second MESP mechanism augments framework addresses this problem by
   augmenting the MAC with a an "internal authentication" transform,
   which MAY be an RSA-SHA1 digital signature over
   the packet data to uniquely identify the sender of the packet. or a TESLA timed MAC.
   Digital signatures leave multicast receivers vulnerable to denial-
   of-service attack that if the receiver attempts to validate through is duped into performing
   computationally-expensive signature validation.  MESP mandates that
   HMAC-SHA1 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 MUST
   transform SHOULD accompany a digital signature TESLA authentication transform so as to
   limit the effectiveness of forging digitally signed 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 this threat 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 application concern, 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
   supports Encryption

   The value of MESP encryption is to validate individual encryption
   transforms for multicast source authentication using hybrid MAC/digital
   signature operation.  It is possible that a
   particular cipher and Timed MAC schemes, mode are suitable for pairwise security
   associations but not for multicast security associations, such as TESLA, to mitigate attacks
   by group members upon
   one where multiple senders share the group. TESLA source authentication can
   uniquely identify 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 source suitability of several IPsec ESP
   encryption transforms for inclusion in a manner the MESP framework.  It is
   RECOMMENDED that amortizes the cost of
   a single digital signature over a very long chain of packets
   [TESLA].

7.0 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

   MESP uses protocol number xxxx.  Both of these values MUST be
   registered with IANA.

   GDOI uses PROTO_MSEC_MESP, which has

   This I-D extends the value xxxx. RFC 2407 attributes for IPsec ESP,
   PROTO_IPSEC_ESP [RFC2407]. Within
   PROTO_MSEC_ESP, GDOI signals PROTO_IPSEC_ESP, MESP reserves the INT
   transform identifier value 13 [See IANA, "IPSEC ESP Transform with the number 1,
   Identifiers"].  MESP also adds new type/length/value attributes to
   RFC 2407.  For the EXT MESP transform with ID security association
   attributes, the ENC Transform has type 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 11, the INT Transform, GDOI reserves
   the transform
   has type number 1 for the NULL digital signature 12, and 2 for RSA-SHA1.
   Within the EXT transform, GDOI reserves the transform has type number 1 for HMAC-SHA1
   and 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 number following values.
         name                value
         ----                -----
         Reserved              0
         3DES                  1
         AES-CBC               2 for TESLA.  Within Encapsulation Mode, GDOI
   reserves
         AES-CTR               3

   The INT-Transform has the following values.
         name                value
         ----                -----
         Reserved              0
         RSA-SHA               1 for transport mode and
         TESLA                 2 for tunnel mode.

   The values
   MUST be registered with IANA.

8.0 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 Scott Fluhrer, who
   identified some problems in a previous version of the draft.

9.0 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

   Mark Baugher
   Cisco Systems, Inc.
   5510 SW Orchid Street
   Portland, Oregon
   mbaugher@cisco.com
   +1-503-245-4543

10.0

9.0 References

10.1

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.

   [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.

   [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

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.

   [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.