One document matched: draft-irtf-smug-sec-mcast-arch-00.txt
INTERNET-DRAFT R. Canetti, P-C. Cheng,
draft-irtf-smug-sec-mcast-arch-00.txt D. Pendarakis, J.R. Rao,
P.Rohatgi and D. Saha
IBM
Expires August 1999 February, 1999
An Architecture for Secure Internet Multicast
<draft-irtf-smug-sec-mcast-arch-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 to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Canetti et. al. [Page 1]
INTERNET DRAFT February 1999
ABSTRACT
This document proposes an architecture for secure IP multicast.
It identifies the basic components and their functionalities,
and specifies how these components interact with each other and
with the surrounding systems.
The main design principles followed in developing this architecture are
simplicity, flexibility, ease of incorporation within existing systems.
In particular, the design attempts to mimic the IPSec architecture, and
to re-use existing IPSec mechanisms wherever possible.
The proposed architecture is able to accommodate many of the existing
proposals for multicast key management. In this draft, we concentrate
on the architectural building blocks required to enable a group member
(either a receiver or a sender of data) to use secure IP multicast.
Design of the group controller(s) is left to future documents.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Security Requirements from Multicast Communication. . . . . . 3
3. Design Goals and Guidelines . . . . . . . . . . . . . . . . . 4
4. Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Architectural Block Diagram . . . . . . . . . . . . . . . 5
4.2 Architecture Overview . . . . . . . . . . . . . . . . . . 7
5. Design Guidelines for MIKE. . . . . . . . . . . . . . . . . . 11
5.1 Requirements of MIKE. . . . . . . . . . . . . . . . . . . 11
5.2 Architectural Block Diagram of MIKE . . . . . . . . . . . 12
5.3 An Example Group Key Management Module. . . . . . . . . . 12
5.4 Architectural Block Diagram of MKMM . . . . . . . . . . . 14
6. Issues for use of IKE and IPSEC . . . . . . . . . . . . . . 15
6.1 Use of IKE. . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Identifications of Multicast Security Associations. . . . 15
6.3 SPI Assignment. . . . . . . . . . . . . . . . . . . . . . 15
6.4 Sequence Number Handling and Replay-Prevention. . . . . . 16
7. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Authors Addresses . . . . . . . . . . . . . . . . . . . . . 17
Canetti et. al. [Page 2]
INTERNET DRAFT February 1999
1. Introduction
This document proposes a basic architecture for a secure IP multicast
standard. It identifies the basic components and their
functionalities, and specifies how these components interact with
each other and with the surrounding systems. We start with a brief
overview of the security requirements for multicast communication.
We then describe some basic design principles followed here.
Next, we sketch and motivate the overall design. We also suggest
design principles for two main modules: key management and source
authentication. Finally, some issues for discussion and related
work are presented.
Given the large variance in the characteristics and security
requirements of different multicast applications, it is unlikely
that a single solution will be adequate for handling all possible
applications (see [CP,Q]). Still, we believe that the architecture
described here is flexible and general enough to serve as
a common ground for most future solutions.
Following the rationale of the IPSec architecture [KEN98c],
this document goes beyond making the minimum specifications
required for interoperability. It sketches the internal
design required of a secure multicast protocol. Such a detailed
specification is needed since the overall security of the system
often depends on the correct internal operation of all the
components.
The current version of this document does not fully specify the
internal structure of all the modules. These will be described in
subsequent documents.
Canetti et. al. [Page 3]
INTERNET DRAFT February 1999
2. Security requirements from multicast communication
We briefly sketch the salient security requirements. A more detailed
discussion appears in [CP].
(a) Group membership control and confidentiality: This means
making sure that the group communication
is accessible only to legitimate group members. This document
concentrates on a "flat" access control structure; that is, all
the group communication is accessible to all group members.
Hierarchical group membership (as in, say, [HM]) is not addressed
here, and can be added at a later stage.
Group membership control is usually implemented
by having a group key shared by all group members. All group data
communication is encrypted via symmetric encryption using this key.
The architecture proposed here follows this approach.
For many applications, group membership is likely to vary over time.
It is often required that members leaving a group lose access to future
group communication. It
is also sometimes required that members joining a group will not gain
access to group communication that occurred before they joined.
Note that in order to implement access control it must be possible to
authenticate the identity of potential group members. This can be done
using public-key certificates of potential members.
(b) Group data authentication: This refers to the process by which a
group member is able to verify that the group communication originated
from a source within the group. Here the recipient of the communication
is not generally able to authenticate the individual source but is able
to verify that the communication originated with some member of the
group.
We follow the usual approach of implementing group data authentication
using a dedicated key shared among all group members. All the
communicated data is authenticated via Message Authentication Codes,
using the common key.
(c) Individual source authentication: This refers to the process by
which group members are able to verify the identity of the sender of
data to the group. The problem of source authentication in multicast
is inherently different from the source authentication problem for
point-to-point connections since single MAC based solutions (such as
those used in IPSec) are not applicable here. (see [CP] for a survey
of techniques for achieving this goal).
Other security concerns, like non-repudiability and anonymity, are
not addressed here, and will be determined by the specific
implementation.
Canetti et. al. [Page 4]
INTERNET DRAFT February 1999
3. Design Goals and Guidelines
Our main design goals are simplicity, flexibility, ease of
incorporation within existing systems. To achieve these goals,
we follow the guidelines listed here:
(a) Make the design independent from the underlying routing mechanism.
The architecture does not interfere with the routing mechanism of
the data. Data packets may be routed via any multicast or unicast
routing. For sake of simplicity and
modularity of design, we recommend that the key management mechanism
assume reliable communication. Yet, no specific mechanism for
obtaining reliability is specified. Any reliable multicast or
unicast mechanism (e.g., TCP) can be used.
(b) Mimic the IPSec architecture and design as much as possible.
As in IPSEC, we separate the modules that handle data from those that
handle key management. Functions such as the generation, distribution
and update of cryptographic keys are encapsulated in a key management
module. In addition, the key management module is placed in the
"application layer" of the communication, and outside the OS kernel.
This facilitates application specific operations, such as multiplexing
of data for different users and certificate verification. The data
handling part lies mostly in the IP layer, using IPSec modules. (Yet,
we introduce an additional level of data handling, in the interest of
source authentication. See details in the sequel.)
(c) Use existing components wherever possible.
Specifically, we use IPSec's ESP and AH protocols for encrypting and
authenticating data. The ESP protocol [KEN98a] is used for
exchanging encrypted and authenticated multicast data.
If confidentiality is not an issue or if additional
authentication beyond what is provided by the ESP authentication
mechanism is required (such as authentication of the IP header)
then the AH protocol can also be used.
Since IPSec was mostly designed for unicast, there are a few
issues that arise when the ESP/AH protocols are used for
multicast data. We discuss some of these issues in Section 6.
Multicast-specific packet transformations may be introduced
in the future.
(d) Minimize modifications of the OS kernel.
The current architecture is structured so that the new multicast
security specific components are kept in the application space and
the IPSec components that are currently in the OS kernel can be used
Canetti et. al. [Page 5]
INTERNET DRAFT February 1999
for multicast security without modification. It is expected that with
time, some of the multicast specific components may be moved to the
kernel and IPSec components already in the kernel would be modified
to better support multicast.
(e) Flexibility in the choice of cryptographic algorithms and key
management schemes.
By re-using the IPSec design for data transport, we retain the
flexibility of using any data encryption and authentication
algorithm which can be supported by IPSec.
The new components introduced in this document, namely the
Multicast Internet Key Exchange Module (MIKE) and the Source
Authentication Module (SAM) provide frameworks which are
flexible enough to support most group key management and
source authentication schemes.
4. Architecture
This section presents the architecture. We start with a block diagram,
and continue to describe the functionalities of the various components,
and the data flows.
4.1 Architectural Block Diagram
There are two types of entities involved in Secure Multicast, namely
the group members which participate in the Secure Multicast
communications and the controller(s) which manage keys for the group
or parts of the group and enforce access control. The architecture of
the controller(s) depends on the group access control and key
management mechanism and is expected to vary widely. Therefore we
concentrate on the architecture of a group member where uniformity
is desirable and is achievable.
The architecture separates between control and data plane functions.
The primary responsibility of control plane functions is to manage
group membership and enforce access control privileges. Data plane
functions handle multicast data distribution and cryptographic
operations such as encryption, decryption, digital signature
generation and signature verification.
Canetti et. al. [Page 6]
INTERNET DRAFT February 1999
The block diagram of a secure multicast host is shown below.
CONTROL PLANE * DATA PLANE
*
------------------------------------------------
| |
| CLIENT APPLICATION |
| |
------------------------------------------------
/\ * /\
|| * ||
Control || join/leave * Data || send/receive
API || * API ||
|| * ||
\/ * ||
-------------------------- * ||
| | * ||
| MULTICAST INTERNET | * ||
| KEY EXCHANGE MODULE | * ||
| ( M I K E ) | * ||
-------------------------- * \/
/\ | * --------------------
|| V * | |
|| --------------------- * | SENDER AUTHEN. |
|| | MULTICAST SECURITY |---->| MODULE |
|| | ASSOCIATION | * | ( S A M ) |
|| | ( M S A ) | * --------------------
|| --------------------- * /\
|| | * || User Space
===================|===============*===========================
|| | * || Kernel
|| | * \/
|| | * ------------------
|| ------------------>| IPSec |
|| * | (AH + ESP) |
\/ * ------------------
* /\
Secure Multicast Key * ||
Management Flows * \/
*
* Secure Multicast Data
* Flow
Figure 1: Block diagram of secure multicast framework
Canetti et. al. [Page 7]
INTERNET DRAFT February 1999
4.2. Architecture Overview
We describe the architecture of a member of a secure
multicast group. The member could either be a data recipient or a
data sender or both. From the application's perspective, the secure
multicast framework provides a simple API for using secure
multicast. This API is logically partitioned into the Data API
which deals with sending and receiving multicast data securely
and the Control API which deals with the process of leaving and
joining a secure multicast group and the associated access control
and key update functions.
4.2.1 Architectural Components
The major architectural components of the Secure Multicast Framework
are:
(a) MIKE - Multicast Internet Key Exchange.
This module is responsible for key management and
implements the Control API which permits applications to join and
leave secure multicast groups. This module resides in the
application layer, outside the OS kernel. It interacts with the
MIKE modules of the group controller(s), and generates and
maintains a Multicast Security Association (MSA) that contains:
(i) Group keys for encryption/decryption and authentication of
data (via the AH/ESP modules).
(ii) Signing/Verification keys for source authentication of data
by the SAM module, described below.
(iii) Other information regarding the connection, as in an IPSec SA.
In order to make a MIKE specification complete, the MIKE
modules within the group controller(s) need to be specified.
See more discussion on the design of MIKE in section 5.
An additional functionality of MIKE is periodic updates of the MSA,
whenever group keys or keys used by SAM are changed.
Canetti et. al. [Page 8]
INTERNET DRAFT February 1999
(b) IPSec modules: AH/ESP.
These are the IPSec modules that reside in the OS kernel
and deal with encryption/decryption and authentication of data
packets. These modules provide Encryption/Decryption and Group
Authentication of incoming or outgoing Multicast Data. Data is
encrypted with the group key by the sender(s) and decrypted using
the same key by receivers. The ESP header remains as defined in the
unicast case; the protocol header preceding the ESP header will
contain the value 50 in its Protocol (IPv4) or Next Header (IPv6,
Extension) field and its destination IP address will be the IP
multicast group address, a class D address. Thus, the packet will
be forwarded to all members of the group by routers supporting
multicast delivery. ESP can be used in conjunction with the ESP
authentication option (more on authentication below). In principle,
ESP for multicast traffic can be used either in transport or tunnel
mode, although transport mode is clearly more adequate in an
environment where most participating members are end hosts.
For multicast data authentication different techniques will be used
depending on whether group or individual sender authentication is
desired. For group authentication, the protocol designed for
unicast IP security, namely the IP Authentication Header (AH)
[KEN98b] and/or the authentication option within ESP are sufficient.
All members share a common, symmetric authentication key which is
administered by the group controller and which is used to generate
the message authentication code (MAC). The AH header remains as defined
in the unicast case; the protocol header preceding the ESP header
will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6,
Extension) field and its destination IP address will be the IP
multicast group address, a class D address. The SPI value is
selected, as for ESP, by the controller.
(c) SAM - Source Authentication Module.
This module is responsible for the transformations that enable
authenticating the source of received data and possibly for
replay protection. Scalable source authentication would typically
involve operations that span more than a single packet, both for
outgoing and incoming data. (UDP frames are good candidates for a
basic unit for authentication.) Thus, it seems reasonable to place
this component in a higher layer in the protocol stack, specifically in
the application layer above UDP. Another advantage of placing SAM
in the application layer is that this way the OS kernel need not
be immediately changed.
The internal structure of the SAM depends to a large extent on the
source authentication mechanism used. Two basic
source authentication mechanisms exist. One is authentication by public
key signatures which may be applied on a group of packets via a variety
of mechanisms (see [CP]). The other is authentication via symmetric
authentication with multiple keys [CGJPMN].
Canetti et. al. [Page 9]
INTERNET DRAFT February 1999
An additional potential functionality of SAM is to provide replay
protection for data, in case that the IPSEC replay protection mechanism
is turned off because of multiple sender problems. (See Section 6.)
We defer further design details of SAM to future documents.
4.2.2 Data and Control Flows
Typical operation of the system proceeds as follows:
Remark:
Here we assume that the data is sent/received via reliable or
unreliable IP multicast. However, the security mechanism
described here can be used even when the data is being routed via
point-to-point connections, such as TCP.
The member initiates a secure multicast session by invoking the join
operation in the Control API which is implemented by MIKE. This enables
the member to register in the group as a sender or a receiver or both.
Subsequently, the member is able to send and receive datagrams securely
to the multicast group using the send/receive functions of the Data API.
All group key management, data encryption/decryption and group/source
authentication functions are managed by the secure multicast framework
and are transparent to the member. If at some later point in time the
member decides to leave the secure multicast group then this is done by
invoking the leave operation in the Control API. This action eventually
results in the termination of the member's ability to securely
send/receive messages to the group.
We now outline the data and control flows in more detail.
(a) Control Flows:
- Client Join: The application invokes MIKE to join a multicast group.
At a minimum, the application must identify the group that it wishes to
join and provide information as to the authentication required (e.g.,
whether or not source authentication is required and if so, the
sources it will trust).
MIKE then performs the process of registering with the group
controller(s), sets up a Multicast Security Association (MSA), invokes
a standard registration mechanism for the underlying IP multicast group
and enables the ESP/AH and SAM modules to start processing data.
The registration process will inevitably include communication with
the group controller(s) and this communication will require mechanisms
for authentication of the parties as well as confidentiality of the
information exchanged. This communication, its authentication and
encryption mechanisms should be dealt with within the MIKE module.
Canetti et. al. [Page 10]
INTERNET DRAFT February 1999
At the end of the join process, a Multicast Security Association
(MSA) needs to be set up. (See Section 4.2.1 for the proposed contents
of the MSA.) The relevant information from the MSA is then pushed to
the ESP/AH and SAM modules.
- Key update: Key updates messages are internal MIKE messages and are
not part of the high-level architecture. These messages are
authenticated and encrypted separately, as specified in MIKE. A special
class of key update messages consist of member expulsion messages in
which the controller expels the member from the group. The
expulsion process is dependent on the specifics of the Key Management
Protocol, but should result in the member being cryptographically unable
to send/receive messages from the secure multicast group. In this case
MIKE module should treat an expulsion message like a member leave
request without the need to contact the controller(s).
- Client Leave: First MIKE is invoked to de-register with the group
controller(s). Next the Multicast Security Association is deleted
(or marked stale). Finally, the host executes the standard
procedure for leaving the underlying IP multicast group.
(b) Data Flows
- Sending of data: If source authentication is not needed, then data
is transmitted directly via UDP (or a reliable multicast layer) and
the IPSec module in the IP layer, with the IP multicast group in the
destination address.
If source authentication is needed then the data is first
transferred to the SAM. There the data is processed for source
verification. (The keys for performing these operations are
obtained from the MSA.) Next, the data is directed to the AH/ESP
transformations in the kernel. These transformations are executed
with the group keys that appear in the MSA. Finally the data packets
are sent on the channel in the standard way.
- Receipt of data: Incoming data packets are first being processed by
IPSec's AH/ESP transformations in the kernel. There the data is
decrypted and group authentication is verified. Next, the data stream
is processed by the SAM and source identity is authenticated, if
needed. Finally, the data is handed to the calling application.
Canetti et. al. [Page 11]
INTERNET DRAFT February 1999
5. Design Guidelines For MIKE
Although the design of MIKE deserves a separate document, we proceed
to suggest some requirements for MIKE, describe an architectural
framework that will allow MIKE to meet these requirements and yet
be flexible enough to accommodate a variety of group key management
techniques. This framework provides an interface for plugging in
different group key management modules into MIKE. Next we suggest
some design principles for one such pluggable group key management
module which we call the Multicast Key Management Module (MKMM).
5.1 Requirements of MIKE
(a) MIKE should support the simple scenario where there is only a
single group controller that communicates with all group members.
More complex environments where intermediate servers facilitate the
communication may also be supported.
(b) MIKE should support having a set of keys (for symmetric encryption
and authentication) shared among all group members. In addition,
MIKE will help in forwarding the public verification keys of the
group controller and of senders in the group, to support source
authentication by group members. (Note that these verification keys
may be different from the long-term certificates of these parties.)
(c) MIKE will be placed in the application layer of the
communication, and outside the OS kernel.
(d) MIKE should be flexible enough to accommodate any reasonable
multicast group key management solution.
Canetti et. al. [Page 12]
INTERNET DRAFT February 1999
5.2 Architectural Block Diagram of MIKE
Control API /\ join/leave
||
\/
----------------------------------------------
| /\ |
| MULTICAST INTERNET || KEY EXCHANGE MODULE |
| || |
| || |
| \/ |
| ------------------------------ |
| | KEY MANAGEMENT TECHNIQUE | |
| | SELECTOR | |
| ------------------------------ |
| /\ |
|========//=====================================|
| // GROUP KEY AND MSA MANAGEMENT |-
| \/ FRAMEWORK | |
=============================================== | GROUP
| GROUP | | GROUP | | GROUP | | KEY MGMT
| KEY MGMT | | KEY MGMT | | KEY MGMT | | MODULE
| MODULE | | MODULE | ..... | MODULE | | INITIATED
| # 1 | | #2 | | #N | | MSA CONTROL
---------- ----------- ---------- | FLOWS
/\ V
|| ----------
|| | M S A |
|| ----------
||
\/
Secure Multicast Key
Management Flows
Figure 2: Block diagram of MIKE
5.3 An example Group Key Management Module.
This section suggests a group key management modules that can
be plugged into MIKE. We call this suggested module as the Multicast
Key Management Module (MKMM).
The main design criterion for MKMM are similar to those for
Secure Multicast Framework, i.e., simplicity and the re-use of
existing solutions and standards such as IPSEC and IKE
Canetti et. al. [Page 13]
INTERNET DRAFT February 1999
where possible. This module uses IPSEC to set-up secure channels
for all point-to-point between the host and the controller(s).
Of course, other solutions that provide secure channels (e.g.,
SSL or proprietary communication protocols) can be used instead.
(a) Point-to-point communication between a group member and the
controller (say, for group registration and de-registration) will
be secured via a standard IPSec connection established by IKE. This
connection will provide confidentiality as well as authentication of
the information exchanged. In particular, the group keys and additional
information will be transmitted as DATA in the secure connection. The
IPSec SA between a group member and a controller will be short-lived,
and will generally NOT last throughout the lifetime of the multicast
group.
(b) Key update messages will be transmitted from the group controller
to the members using an abstract transportation mechanism, called
"Reliable Multicast Shim" (RMS). This abstract mechanism provides
reliable multicast, in the sense that any message transmitted via
the RMS is guaranteed to reach all group members.
The RMS abstraction can then be implemented via any available
reliable multicast mechanism, or alternatively via point-to-point
reliable communication (TCP).
(c) Key update messages sent by the controller will have a special
format. In particular, they will be authenticated using public-key
signatures that are verifiable using a public key that is handed to
the members at registration time. MKMM will implement its own
signature verification mechanism.
Canetti et. al. [Page 14]
INTERNET DRAFT February 1999
5.4 Architectural Block Diagram of Multicast Key Management Module
(MKMM).
The following is the architectural block diagram of MKMM.
-----------------------------------------------|
| MULTICAST INTERNET KEY EXCHANGE MODULE |
|===============================================|
| GROUP KEY AND MSA MANAGEMENT |-
| FRAMEWORK | |
=============================================== | GROUP
| | | KEY MGMT
| MULTICAST | | MODULE
| KEY MANAGEMENT | | INITIATED
| MODULE | | MSA CONTROL
| | | FLOWS
|-------------------------- | V
| RELIABLE MULTICAST | | --------
| SHIM | | | M S A |
|-------------------------- | --------
| RELIABLE MULTICAST | |
| EMULATION USING | |
| RMTP OR PGM | |
| OR HOME GROWN REL. MCAST | |
| OR POINT-TO-POINT TCP | |
--------------------------------------
/\ /\
|| ||
|| User Space ||
=========================================||=================
|| Kernel Space ||
|| ||
|| ||
\/ \/
Mulitcastable Key -------------------
Management Flows | I P S E C |
(incl. Key Updates | AH/ESP |
-------------------
/\
Point-to-Point Flows ||
Required for Secure Multicast ||
Key Management (e.g., between ||
member and controller).\/
Figure 3: Structure of Multicast Key Management Module.
Canetti et. al. [Page 15]
INTERNET DRAFT February 1999
6. Issues related to the use of IKE and IPSEC
In this section we discuss some issues and apparent problems related
to the use of the IPSEC components (IKE, AH, ESP) in a secure
multicast protocol. Some of these issues appear to have satisfactory
solutions. Other issues are brought up for further discussion.
6.1 Use of IKE
It is clear that group key management is very different from
key management for point-to-point communications and therefore
the Internet Key Exchange Protocol (IKE) cannot be re-used for
group key management. However, it is proposed that the key
exchange module for multicast (which we call MIKE, for the Multicast
Internet Key Exchange module) should use IKE whenever it
needs to establish point-to-point security associations between
entities.
Similarly, the problem of source authentication for multicast
requires a different solution than the approach used in IPSec.
We also propose that the Source Authentication Module (SAM) in
this framework use existing standards such as standards for
digital signatures and certification wherever possible.
6.2 Identification of Multicast Security Associations
In the Internet Protocol, a Security Association (SA) is uniquely
identified by the combination of the destination address, Security
Parameter Index (SPI) and the protocol used (e.g., AH, ESP).
As stated in the Security Architecture for the Internet Protocol
document [KEN98c], the destination address can be either unicast
or multicast; the definition of an SA remains the same.
6.3 SPI Assignment
In unicast SAs, in order to avoid potential conflicts of SPI values,
receivers are responsible for assignment of the SPI. Since in the
multicast case there are multiple destinations, all within the same
multicast destination address, such an approach is impractical since
it would require coordination by all receivers. Selection by the
sender would also be problematic, especially in the case of multiple
group senders.
Within our framework, a reasonable solution to the problem is to
utilize the benefits of the centralized controller by requiring that
the group controller selects the SPI for each multicast group and
communicates it to members, senders and receivers during
registration. Selection by the controller guarantees that the SA is
uniquely identified by the combination of the SPI value, the multicast
group address and the protocol.
Canetti et. al. [Page 16]
INTERNET DRAFT February 1999
As stated in [KEN98c], multiple senders to a multicast group MAY use a
single Security Association (and hence Security Parameter Index) for
all traffic to that group. In that case, the receiver only knows that
the message came from a system knowing the security association data
for that multicast group. Multicast traffic MAY also use a separate
Security Association (and hence SPI) for each sender to the multicast
group, in which case source authentication can also be provided via
IPSEC. The assignment of SA's to senders can be done by the group
controller.
6.4 Sequence Number Handling and Replay-Prevention
According to the latest ESP and AH drafts, both ESP and AH headers
contain a mandatory, monotonically increasing, sequence number field
intended to provide anti-replay protection. Processing of the sequence
number is at the discretion of the receiver, but the sender MUST
always transmit it. The sender's and receiver's counters have to be
initialized to 0 when the SA is established and the first packet of
that SA will have a sequence number of 1.
In the case of multiple senders using the same security association
(and hence the same SPI value) consistency and monotonicity of the
sequence number cannot be guaranteed. Hence, as stated in the latest
ESP draft, anti-replay service SHOULD NOT be used in a multi-sender
environment that employs a single SA. Multicast security
implementations should thus ensure that receivers do not
perform sequence number processing and verification.
We see two possible solutions to provide anti-replay protection:
(1) Using multiple SAs, one for each sender. (All these SAs
may be part of a single MSA.)
(2) Putting anti-replay protection in some higher level module such
as SAM. This solution requires application-layer framing of
multicast messages.
Further work and debate is needed to decide which solution is best
for the first implementations of secure multicast.
6.5 Allowing IPSEC processing of multicast packets
Some current implementations of the IP protocol stack will
discard any IP packet with a class D destination address
and a "protocol" field that is not UDP. Such implementations
need to be changed to support IP-multicast packets protected
by IPSEC.
Canetti et. al. [Page 17]
INTERNET DRAFT February 1999
7. Related work
Several recent works suggest mechanisms for IP multicast
[HCD,HM,HCM,HD]. (See also the mini-survey in [CP].) Typically,
these works concentrate on the key management module (MIKE, in our
terminology). Most of these suggest a design that can be
incorporated within the architecture proposed here either
as a pluggable group key management module under MIKE or
in some cases even as a version of MKMM (such as the schemes
based on [WHA].) An exception is the [HCD1] design that calls for a
hierarchy of group keys for data encryption.
The notion of Multicast Security Association (MSA) is addressed in
the IPSec architecture document [KEN98c] and in [HCM], with
roughly the same functionality. (Here we introduce the additional
functionality of use by SAM.)
8. References:
[CGIMNP] Canetti R., J. Garay, G. Itkis, D. Micciancio, M. Naor,
B. Pinkas, "Multicast Security: A Taxonomy and Efficient
Authentication", to be presented at INFOCOM '99.
[CP] R. Canetti, B. Pinkas, "A taxonomy of multicast security issues",
draft-canetti-secure-multicast-taxonomy-01.txt, Nov. 1998.
[HCD] Hardjono T., Cain B., Doraswamy N., "A Framework for Group Key
Management for Multicast Security", internet draft
draft-ietf-ipsec-gkmframework-00.txt, July 1998.
[HCM] Hardjono T., Cain B., Monga N., "Intra-Domain Group Key
Management Protocol", internet draft,
draft-ietf-ipsec-intragkm-00.txt, November 1998.
[HM] Harney, H., C. Muckenhirn, "Group Key Management Protocol
(GKMP) Architecture", RFC 2094, July 1997.
[KEN98a] Stephen Kent, Randall Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft draft-ietf-ipsec-esp-v2-06.txt, July
1998.
[KEN98b] Stephen Kent, Randall Atkinson, "IP Authentication
Header", Internet Draft draft-ietf-ipsec-auth-header-07.txt, July
1998.
[KEN98c] Stephen Kent, Randall Atkinson, "Security Architecture for
the Internet Protocol", Internet Draft draft-ietf-ipsec-arch-sec-07.txt,
July 1998.
Canetti et. al. [Page 18]
INTERNET DRAFT February 1999
[Quinn] Bob Quinn, "IP Multicast Applications: Challenges and
Solutions", draft-quinn-multicast-apps-00.txt, Nov 1998.
[WHA], D.M. Wallner, E. J. Harder, R. C. Agee, Key Management for
Multicast: Issues and Architectures, , internet draft
draft-wallner-key-arch-01.txt, September 1998.
9. Authors Addresses
Ran Canetti
EMail: canetti@watson.ibm.com
Pau-Chen Cheng
EMail: pau@watson.ibm.com
Dimitris Pendarakis
EMail: dimitris@watson.ibm.com
J.R. Rao
EMail: jrrao@watson.ibm.com
Pankaj Rohatgi
EMail: rohatgi@watson.ibm.com
Debanjan Saha
EMail: debanjan@us.ibm.com
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10598, USA
Tel: +1-914-784-6692
Canetti et. al. [Page 18]
Expires August 1999
| PAFTECH AB 2003-2026 | 2026-04-22 23:28:07 |