[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

      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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/