Internet Research Task Force Ran Canetti (IBM Watson)
INTERNET-DRAFT Pankaj Rohatgi (IBM Watson)
June 2000 Pau-Chen Cheng (IBM Watson)
Multicast Data Security Transformations:
Requirements, Considerations, and Proposed Design
<draft-irtf-smug-data-transforms-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.
Abstract
In the framework document <draft-irtf-smug-framework-00.txt>,
the Secure Multicast Group (SMuG) has identified three functionalities
that deal with security transformations for the multicasted
data. These are data encryption, source authentication, and group
authentication. This document expands on the issues to be taken
into consideration when designing transforms that realize these
functionalities. These issues include the order of applying the
transforms, their placement in the communication layers, possible
aggregation of several functionalities in a single transform, and
the relationships with other protocols (such as reliable multicast
protocols). Next a specific design is proposed, that attempts to meet
the requirements of prominent application in a simple yet flexible way.
Canetti Rohatgi Cheng 1
Contents:
1. Introduction.................................................. 3
2. Data security transforms...................................... 4
2.1 The functionalities ....................................... 4
2.2 Considerations ............................................ 5
3. The proposed design .......................................... 7
4. Possible usage patterns ...................................... 10
5. References.................................................... 12
Canetti Rohatgi Cheng 2
1. Introduction
A security solution for IP multicast consists of three main components:
a component that sets the security policy of the group (typically set by
the group controller), a component that handles the interaction between
group members and the group controller(s) (and in particular guarantees
secure dissemination and update of policy and cryptographic keys to the
group members), and a component that applies actual cryptographic
transforms to the data in order to implement the security policy.
See more details in the SMuG framework document [HCBD].
This document concentrates on the design and placement of the
cryptographic transforms applied to the multicasted data. It starts
with a short review of the functionalities for multicast security data
transforms. Next it reviews the issues related to the ordering, placement
and aggregation of these functionalities.
This includes integration of the transforms with each other,
with the current IP multicast model, with reliable multicast protocols,
and with the secure multicast framework.
Next a specific design for the security data transforms is proposed.
The design emphasizes flexibility, simplicity and maximal reuse of
IPSec protocols (in particular, ESP [KA]). It allows providing security
either in the IP layer or in the application/transport layer.
It also allows for easy incorporation within the reliable multicast
protocols that are being designed in the Reliable Multicast Transport
(RMT) working group.
The design is quite simple. It consists of two ESP-like transforms,
MESP (for Multicast ESP) which is an IP layer transform and AMESP
which is an application/transport layer transform:
* MESP is an extension of ESP,
in a sense that for certain choice of parameters, MESP is identical
to ESP. In particular, MESP can keep the same IANA protocol number as
ESP (namely, protocol 50). This also means that the existing ESP
transform can be used to provide limited support for secure multicast.
* AMESP is similar to MESP, but works in the application/transport layer.
Each one of these transforms is capable of providing full security
for the data (encryption, group and source authentication)
independently of the other. Furthermore, in general a secure
multicast protocol-suite will apply *both* transforms to the
data. It is up to the security policy (set by the application) to
specify which cryptographic algorithms, if any, are invoked in each
transform.
Canetti Rohatgi Cheng 3
This design allows for increased flexibility in the ordering and
layer placement of the three basic functionalities. Using different
sets of policy parameters, a system can do all the cryptographic
transforms in the application layer, all in the network layer, or
some in the application and some in the network layer. In addition,
AMESP can be used in conjunction with a transport-layer reliable
multicast transform, to obtain a single transform that guarantees
both reliability and security. See more details in Section 4.
A remark on terminology: we make a distinction between the term
functionality (or, "functional building block" in the terminology of
[HCBD]) and the term "security transform". The former refers to a
cryptographic functionality (e.g., encryption, source authentication,
or group authentication). The latter refers to an actual transform
that is being carried out on the data (e.g., ESP or AH). In particular,
a single transform can provide more than one functionality.
2. Data security transforms: Issues and considerations.
2.1 The functionalities
The security requirements for multicast have been discussed and
enumerated in the SMuG Framework document [HCBD] and also in
[CP]. In particular, these reference documents identify three
different functionalities that must be part of any complete solution.
The functionalities for multicast security data transforms
are:
a) Group Secrecy (GS).
The group secrecy functionality ensures that the transmitted data
is accessible only to group members. 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
confidentiality in unicast.
b) Group Authentication (GA).
This 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 could have been forged by any malicious
group member. It can be efficiently realized using standard shared
key authentication mechanisms such as Message Authentication Codes
(MACs), e.g., CBC-MAC or HMAC.
Canetti Rohatgi Cheng 4
c) Source and Data Authentication (SrA). This 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 [Ch,PCTS], asymmetric MACs [CGIMNP], etc.
2.2 Considerations regarding ordering, layer placement and aggregation
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 layering of these functionalities (i.e., in which layer of the
networking stack each functionality should be applied to the data),
ordering of application of the functionalities and use of composite
transforms that aggregate more than one functionality. These issues
are listed below.
1. Should transforms include only a single functionality or should
transforms combine several functionalities for common usage scenarios?
For example ESP provides both encryption and group authentication.
2. Potential for interactions between security transforms and Reliable
Multicast protocols:
A. Reliable multicast protocols based on Forward Error Correction
(FEC) techniques require source authentication to be done below or
together with the reliability transform. This is because these
reliability solutions are very susceptible to denial-of-service
attacks based on a small number of forged packets.
B. Other multicast reliability mechanisms are based on
having intermediary network entities (e.g., "repair nodes")
retransmit lost packets. Since the reliability mechanism resides
above the network layer, a network layer encryption
transform would interfere with the retransmission mechanism unless
the intermediary entities have access to the group key and decrypt
and re-encrypt data.
C. On the other hand, the Source Authentication functionality
can be realized much more efficiently over Reliable Multicast than
over plain IP-Multicast. This means that the choice of a data
transform could depend on whether reliable multicast is provided.
Canetti Rohatgi Cheng 5
3. Should all transforms be applied at the same level in the networking
stack, either application or network layer or should there be
flexibility in applying different transforms at different layers?
The main advantage of a flexible approach is that it may allow the
re-use of existing IPSec components directly, and may facilitate
the transition from application-layer transforms to
network-layer transforms without changing the overall design.
However, the flexibility to apply different transforms in different
layers would complicate both the design and the security analysis.
For example, the end-points of the connections in different layers
are different entities (e.g., host vs. application).
4. More considerations regarding placing transforms at different
layers of the stack.
Arguments in favor of application level transforms:
- Supports application -level group membership granularity.
- Faster to implement and deploy, requires no kernel modifications.
- Less efficient, especially in multiple group members per host
scenarios.
- some source authentication transforms are more efficient when
applied at the application layer above some form of reliable
multicast transport.
Arguments in favor of network level transforms:
- Supports host-level group membership granularity.
- more efficient, especially in multiple group members/host
scenarios.
- Does not require modification of current multicast applications;
if done right, secure multicast should be transparent to
current multicast applications.
5. In scenarios where more than one functionality is used,
the order of application of the functionalities could be important.
- Source authentication should ideally be done before encryption.
Two reasons are:
-- For the purpose of non-repudiation, it is a good cryptographic
practice to apply source authentication before any encryption.
If a source authenticates encrypted data, then for non-repudiation
purposes there may be ambiguity regarding the cleartext, since
every different key potentially yields a different cleartext.
( To mitigate this problem the source could also authenticate the
key. This may not be trivial since one has to make sure that
authenticating the key does not leak any information on the key.)
-- Encrypted data may get decrypted and re-encrypted by a different
key at gateways between different domains, e.g., in Iolus or
because of legal restrictions on permissible encryption
schemes. Therefore in this scenario source authentication
information should be applied before encryption.
Canetti Rohatgi Cheng 6
- To minimize impact of denial-of-service attacks, it is usually
best to have group authentication transformation performed last,
i.e., checked first.
In summary, it seems best not to mandate an order. For example,
GA[GS[SrA[M]]] may be preferable in some scenarios, and SrA[GS[M]]
may be more appropriate in other scenarios.
REMARK: Order of transform application and the level (in the network
stack) they are applied are related. Order of application can only
move down the stack.
3. The proposed design
3.1 Network layer transform: MESP
The Network layer transform (MESP) is intended to be an extension of
the ESP transform in IPSec, in that the encryption algorithm of the
ESP is overloaded to perform both encryption and source
authentication. Also, the authentication algorithm of ESP can be
replaced by algorithms that guarantee source authentication (such
as timed MACs algorithms). Thus the MESP packet is identical to an
ESP packet in situations where no source authentication is done in
the network layer.
Canetti Rohatgi Cheng 7
Figure 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) | Ext.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth
| Sequence Number | cov.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ |
| IV (if any) | | |
~ ~ | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | ---
| Source ID | | ^ | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |
| Multicast Session ID | | | | |
~ ~ | I | |
| | | n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t. | |
| Internal Authentication SEQ # | | A | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | u | |
| Reserved | Data and Option Length | | t | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | h. | |
| Transform-specific options (variable) | P co | |
| + | a ve | |
~ Data (variable) ~ y ra | |
| | l ge | |
| | o v | |
|...............................................................| a --- | |
| Internal Authentication Tag (variable) | d | |
| | | |Conf
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |Cov.
| | Padding (0-255 bytes) | | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |
| | Pad Length | Next Header | v v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- ---
| External Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Canetti Rohatgi Cheng 8
The MESP Packet format is illustrated in Figure 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. As in IPSec, the SPI together with the destination address
uniquely identify a Security Association (SA) and associated
keying material. The main difference between the unicast and
multicast case is that the destination address in this case is a
multicast address. It is also expected that each sender in a
multicast group would be assigned a different SPI, so that each
source can manage its own sequence number.
As in an ESP packet, the sequence number field is followed by an
optional IV field, plus a variable-length field of encrypted data. In
cases where the MESP does not involve any internal authentication, the
structure of the encrypted data field is identical to that of the ESP
packet. In case that the MESP involves internal authentication,
the encrypted data consists of the following fields:
* Internal Authentication Sequence Number (4 bytes).
This sequence number is potentially different than the ESP sequence
number. (In particular, it can be source-specific.) Note that
the Internal Authentication Sequence Number authenticated both by
the internal authentication and by the external authentication
transforms, whereas the ESP sequence number is authenticated only
by the external authentication transform.
* Reserved (2 Bytes)
* Data and Options Length (2 Bytes)
This field contains the combined length of the transform-specific
options and of the data. It does NOT contain the length of the
Internal Authentication Tag.
* Transform-specific Options and Data (Variable)
This field contains optional parameters that may be required by
specific transforms, together with the data payload. For maximum
flexibility, this document does not mandate any particular structure
for this field; it is left to the designers of specific internal
authentication transforms to come up with the most appropriate
structure for this field.
* Internal Authentication Tag (Variable)
As in an ESP packet, the encrypted payload 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 in the actual data. The format of the internal authenticating
data will be described in greater detail later.
As in ESP, the encrypted data is followed by the external
authentication data or tag, which provides either group or source
authentication (depending on the algorithm used) for the SPI, SEQ
Number and encrypted data. If the current authentication
algorithms of ESP are used then the the external authentication
data provides only group authentication. If appropriate algorithms
are used (such as timed MACs) then the external authentication may
provide also source authentication.
Canetti Rohatgi Cheng 9
3.1.1 Internal Authentication transform format.
We now describe the internal authentication transform format in
greater detail. The internal authentication transform prepends a
fixed size internal authentication header together with transform
specific options, to the data to be authenticated and appends a
variable sized internal authentication tag at the end of the
data. The internal authentication tag authenticates both the
header, options and the data. The internal authentication header
consists of of a 32-bit Source ID field, followed by a TBD sized
Multicast Session ID field, followed by a 32-bit Internal
Authentication Sequence Number field followed by a 16-bit reserved
field (currently mandated to be all 0 bits) followed by a 16 bit
Data and Options Length field. The function of each of these fields
is as follows.
Source ID: This is a 32 bit quantity which identifies the source. The
source identifier could be independent of the particular SPI that is
assigned to the source for the particular multicast session.
Multicast Session ID: This identifier uniquely specifies the
current multicast session in which the source is
participating. This field is intended to prevent out-of-context
substitution attacks wherein source authenticated data from a
particular source in one multicast session is replayed by an
attacker in another session. The size of this field is TBD.
Internal Authentication SEQ number: This sequence number is with
respect to the stream/flow of internal authenticated data from the
source in the current multicast session. In general this may not
be related to the ESP sequence number which may be only group
authenticated.
Reserved field. This 16-bit field which is currently set to 0's is
reserved for future extensions.
Data and Options Length field. This 16-bit field must contain the
length of the data (in bytes) that is authenticated using the internal
authentication algorithm. Since both the length of the
authenticated data and the internal authentication tag are
variable sized this field is to be used to determine the beginning
of the internal authentication tag.
3.2 Application layer transform: AMESP
The structure of the AMESP mimics the structure of MESP. The only
difference is that the next header field in not meaningful and is
mandated to be set to all 0's. Other fields are meant to be
functionally equivalent.
Canetti Rohatgi Cheng 10
4. Possible usage patterns
To exemplify the usability of the above design, we briefly mention
some potential usage patterns.
(1) AMESP with encryption, source and group authentication, null
MESP.
Here all the security is applied in the transport/application layer,
and no network layer mechanisms are deployed. This mode requires no
kernel modifications and can be used even in groups where hosts do not
have IPSec deployed.
(2) AMESP with source authentication, MESP with encryption and group
authentication.
Here source authentication is applied in the transport/application
layer, and encryption and group authentication are applied in the
network layer. This mode requires no kernel modifications and can be
used wherever IPSec is deployed.
(3) Null AMESP, MESP with encryption, source and group authentication.
Here all the security is applied in the network layer. This mode
requires some kernel changes (adding a transform in the ESP format),
but has the advantage that security is transparent to
applications. However, this mode is incompatible with
retransmission-based reliable multicast, unless all the
retransmission points become group members.
(4) AMESP used in conjunction with a reliable multicast transform.
When a secure multicast protocol is used in conjunction with a
transport-layer reliable multicast protocol, it is possible to use
AMESP to obtain reliable multicast transport-layer transform that
provides both security and reliability. Such a transform would have
a dedicated security field, and its processing can proceed roughly
as follows. (The description corresponds to the processing of an
outgoing packet. Processing of an incoming packet is analogous.)
a. Apply a first-pass of the reliability transform, with the security
field "zeroed out". Obtain a packet (or frame) denoted P.
b. Feed P (as data) to AMESP.
c. Use the fields of the generated packet (in AMESP format) to
modify P as follows: - Replace the data field of P with the
encrypted payload of AMESP. - Fill the security field in the
header of P with: -- The header information of AMESP, including
the SPI, the sequence number and IV. -- The external
authentication tag of AMESP. The obtained modified packet, P', is
the result of the combined transform.
Canetti Rohatgi Cheng 11
The combined transform has the advantage that the security
algorithms are applied to the data *after* the reliability
algorithms, and are still done at the transport layer (and
potentially outside of the kernel). Furthermore, there is only one
transport-layer multicast header. This can potentially be useful
when one needs to provide, at the transport layer, source
authentication of individual data packets.
5. 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.
[HCBD] T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore,
"Secure IP Multicast: Problem areas, Framework, and Building Blocks",
Internet Draft draft-irtf-smug-framework-00.txt, October 1999.
[KA] Stephen Kent, Randall Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft draft-ietf-ipsec-esp-v2-06.txt, July
1998.
[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 Authenticatio". 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.
Canetti Rohatgi Cheng 12
Authors Addresses
Ran Canetti
EMail: canetti@watson.ibm.com
Pau-Chen Cheng
EMail: pau@watson.ibm.com
Pankaj Rohatgi
EMail: rohatgi@watson.ibm.com
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY 10598, USA
Tel: +1-914-784-6692
Canetti Rohatgi Cheng 13
Datatracker
Report a datatracker bug
draft-irtf-smug-data-transforms-00
None
| Document | Document type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Authors |
Ran Canetti
,
Pankaj Rohatgi
,
Pau-Chen Cheng
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats |