Network L. Dondeti, Ed.
Internet-Draft QUALCOMM, Inc.
Expires: December 22, 2006 R. Canetti
IBM Research
June 20, 2006
The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
in IPsec
draft-dondeti-msec-ipsec-tesla-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies Timed Efficient Stream Loss-tolerant
Authentication (TESLA), a secure source authentication mechanism for
multicast or broadcast data streams. RFC 4082 introduces and
describes TESLA in detail, and this document specifies the format of
the TESLA authentication field as it is used with IPsec ESP. In
addition to the source authentication using TESLA there may be a
Dondeti & Canetti Expires December 22, 2006 [Page 1]
Internet-Draft IPsec TESLA June 2006
message authentication code for group authentication to protect
against DoS attacks. The proposed addition to ESP combines group-
secrecy, group-authentication, and source-authentication transforms
in an ESP packet.
Contributors
Adrian Perrig, Ran Canetti, and Bram Whillock were the original
contributors of this work (see draft-ietf-msec-tesla-spec-00). Mark
Baugher, Ran Canetti, Pau-Chen Cheng and Pankaj Rohatgi were the
original contributors of the multicast ESP work.
Editor's note
This version of the draft is the result of a quick and dirty job of
merging the old draft-ietf-msec-tesla-spec-00 and the MESP work. Ran
was not given a chance to review the I-D before submission, due to
time constraints. Any errors and omissions are due to the Editor's
hasty work. Please send comments to msec@securemulticast.org so we
can promptly revise the document before the Montreal meeting in July
2006.
Dondeti & Canetti Expires December 22, 2006 [Page 2]
Internet-Draft IPsec TESLA June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. TESLA Specification . . . . . . . . . . . . . . . . . . . . . 5
3.1. Sender Setup . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Receiver Bootstrapping . . . . . . . . . . . . . . . . . . 6
3.2.1. Bootstrapping Parameters . . . . . . . . . . . . . . . 6
3.2.2. Direct Time Synchronization . . . . . . . . . . . . . 7
3.2.3. Set-up using a multicast key management protocol . . . 10
3.3. Layer Placement . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Interface Specification . . . . . . . . . . . . . . . 10
3.3.2. Sending Authenticated Data . . . . . . . . . . . . . . 12
4. IPsec ESP Packet Format with TESLA . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.1. IPsec ESP Authentication for Group Communication . . . . . 15
5.2. Denial-of-Service Protection . . . . . . . . . . . . . . . 15
5.3. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Dondeti & Canetti Expires December 22, 2006 [Page 3]
Internet-Draft IPsec TESLA June 2006
1. Introduction
The IPsec Encapsulation Security Payload (ESP) provides a set of
security services that include data origin authentication, which
enables an IPsec receiver to validate that a received packet
originated from a peer-sender in a pairwise security association. A
Message Authentication Code (MAC) based on a symmetric key is the
common means to provide data-origin authentication for pairwise IPsec
security associations. For secure groups such as IP multicast
groups, however, a MAC supports only "group authentication" and not
data-origin authentication. This document defines a framework for
ESP data-origin authentication that is suitable for IP multicast
groups of ESP receivers.
First we specify the format of the TESLA source authentication data
as an external authentication transform within the IPsec ESP protocol
[RFC4303]. It specifies the cryptographic operations and message
formats. The description of the TESLA protocol is in RFC 4082
[RFC4082].
The TESLA authentication itself is protected by external
authentication transform using a symmetric-key based MAC. Thus
senders first source authenticate a packet and then protect it with
group authentication, the latter protects against external DoS
attacks on the source authentication scheme. The receivers verify
the external MAC to rule out any attacks from parties outside of the
secure group and then proceed to verify that the message originated
from the claimed source.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, the following terms are defined and used in this
document:
Group Secrecy (GS): The GS functionality is ESP confidentiality
applied to a group . It ensures that transmitted data are
accessible only to group members (i.e. two or more hosts in
possession of a shared symmetric key). This can also be viewed as
a way to enforce access control. A typical realization of GS is
to encrypt data using a key known only to group members.
Essentially, the solution for multicast is the 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
Dondeti & Canetti Expires December 22, 2006 [Page 4]
Internet-Draft IPsec TESLA June 2006
IPsec ESP encryption or authentication transform SHOULD describe
any potential risks of multicast operation and how those risks are
averted.
Group Authentication (GA): The GA functionality enables a group
member to verify that the received data originated from someone in
the group and was not modified en-route by a non-group member.
Note that group authentication by itself does not identify the
source of the data. For example, the data might have been forged
by any malicious group member. GA can be efficiently realized
using standard shared key authentication mechanisms such as
Message Authentication Codes (MACs), e.g., CBC-MAC, HMAC, or UMAC.
Source and Data Authentication (SrA): The SrA functionality enables a
group member to verify that the received data originated from the
claimed source and was not modified en-route by anyone (including
other malicious group members). Unlike Group Authentication, SrA
provides the IPsec data-origin authentication function [RFC2401,
ESPbis]. Source and Data Authentication provides a much stronger
security guarantee than Group Authentication in that a particular
group member can be identified as a source of a packet. Group and
multicast source authentication requires stronger cryptographic
techniques such as digital signatures, stream signatures [GR],
flow signatures [WL], hybrid signatures [R], timed MACs, e.g.
TESLA [TESLA, Ch,PCTS],asymmetric MACs [CGIMNP], etc.
3. TESLA Specification
3.1. Sender Setup
The sender chooses a time interval duration T_int. Practical values
for T_int vary from 100 milliseconds to 1 second.
The sender estimates an upper bound on the round-trip-time (RTT).
More specifically, this RTT is the propagation delay of a unicast
packet from the receiver to the sender, plus the propagation delay of
a broadcast packet from the sender to the receiver. Based on the
RTT, the sender chooses a key disclosure delay d, where d denotes a
number of time intervals, such that d > ceil(RTT/T_int).
The sender picks the starting time of time interval zero, which we
denote with T_0. The starting time of time interval i is thus T_0 +
i * T_int.
Next, the sender pre-computes the one-way key chain. Each key of the
one-way key chain is active in one time interval, for example, key
K_i is active in time interval i. The sender always uses the active
Dondeti & Canetti Expires December 22, 2006 [Page 5]
Internet-Draft IPsec TESLA June 2006
key to compute the MAC of a packet it sends. The sender discloses
the keys with a delay of d time intervals, so it discloses key K_i-d
in time interval i.
To generate the one-way key chain, the sender chooses the length of
the chain N. In future versions, we will define extensions which
allow the sender to switch key chains, but for now we assume that N
is large enough such that the key chain is long enough for the
duration of the broadcast. The sender randomly selects the last key
of the one-way key chain K_N. The random choice of K_N is critical,
since the security of TESLA relies on the fact that an attacker
cannot guess K_N. Simply using a hash of the current time, process
id, port number, etc. is thus not sufficient, and we suggest using
hardware-based random number generators, or operating system provided
random number generators such as /dev/random or /dev/urandom on some
UNIX systems. The bit length of K_N is a global parameter, and needs
to match the output length of the pseudo-random function F that
generates the one-way key chain (see the companion draft for more
details on how the PRF F is used to generate the one-way chain and
the PRF F' is used to derive the MAC key [1]).
The sender uses a pseudo-random function F with target-collision
resistance to generate the previous elements of the chain. We
suggest using HMAC-MD5 for this purpose [17,18], where the output is
truncated to the bit length of the key. If the key length is larger
than 128 bits, we suggest using HMAC-SHA-1; the 160 bit size should
be sufficient for all practical purposes.
Jakobsson [19], and Coppersmith and Jakobsson [20] present a storage
and computation efficient mechanism for one-way chains. For a chain
of length N, storage is about log(N) elements, and the computation
overhead to reconstruct each element is also about log(N).
The companion document draft-msec-tesla-intro-01.txt [1] has more
information on the one-way key chain.
3.2. Receiver Bootstrapping
TESLA requires that the sender and the receiver be at least loosely
time synchronized such that the receiver MUST know an upper bound on
the sender's clock. The receiver MUST also receive authentic
parameters for initiating the TESLA session. Authentication is
achieved with a digital signature such as RSA or DSA.
3.2.1. Bootstrapping Parameters
In order to bootstrap, the receiver must receive the following
authenticated information (Note that the Cryptographic Type Assigned
Dondeti & Canetti Expires December 22, 2006 [Page 6]
Internet-Draft IPsec TESLA June 2006
Number (CTAN) is a 16-bit integer describing the type of
authentication used to generate the signature Sig. CTAN is described
in Appendix A.):
. The id j of a specific time interval I_j.
. An NTP timestamp TI_j describing the beginning of that time
interval.
. An NTP timestamp T_int describing the interval duration.
. A PRF CTAN describing the function that will be used to
calculate the keychain (F).
. A PRF CTAN describing the function that will be used to derive
the MAC key from the keychain (F').
. The key disclosure interval d (unit is intervals).
. A bit I telling whether or not the optional id field will be in
the TESLA authentication tag.
. An Encryption CTAN representing the type of key to be used.
. A disclosed key K_i (i < j - d).
. The id n of the final key in this key chain, K_n.
. The interval d_n of the last key chain element.
The Network Time Protocol (NTP) timestamp is described in RFC 958 and
is a 64 bit integer which can represent time with precision of .2
nanoseconds. It is noted that this format will overflow in year
2030, TESLA will agree with any format changes in NTP to accomodate
this problem.
3.2.2. Direct Time Synchronization
In direct time synchronization, the receiver will synchronize its
clock with the sender by determining an upper bound on the sender's
clock. The protocol is very simple, and suffices for the loose time
synchronization required by TESLA.
The receiver sends an initial time synchronization request to the
sender. This time synchronization request will contain only a random
nonce N_r to later ensure that data received from the sender is
authentic. The receiver will then record the time T_s at which the
nonce was sent. Figure 1 describes the format of the nonce. The
Dondeti & Canetti Expires December 22, 2006 [Page 7]
Internet-Draft IPsec TESLA June 2006
size of the nonce is a multiple of 8 bits, and the sender can deduce
the nonce size from the size of the request packet.
Once N_r has been received, the sender responds with the bootstrap
ping parameters as well as the following time synchronization
parameters:
. An NTP timestamp T_sig describing when the data was signed.
. An Authentication CTAN S_sig describing the signature type.
. A bit F, allowing for an optional formatting of the signature
to include a public certificate chain.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Nr (nonce) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Time synchronization request format
. The signature Sig, used to authenticate the parameters.
Dondeti & Canetti Expires December 22, 2006 [Page 8]
Internet-Draft IPsec TESLA June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of certs | PCAN of certs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Certificate 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| Certificate 1 |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Certificate 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| Certificate 2 |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Signature(variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Optional Signature Format
Sig is a signature of the bootstrapping parameters, the time
synchronization parameters (excluding Sig), and N_r. The receiver
can authenticate the data by appending its nonce to the parameter
and use this data to verify the signature. This method assumes
that the receiver has an authentic public key of the sender, for
example using a public-key infrastructure, so the receiver has a
list of authentic public root key certificates of the certificate
authorities, and the sender sends along its certificate signed by
a certificate authority.
Once a receiver has received both sets of parameters, it records the
time at which he received the parameters, T_r. The maximum clock off
set is d_t = T_r - T_s. The receiver can now easily compute an upper
bound on the sender's current time t_s, using it's current local time
t_r as follows: t_s = t_r - T_r + T_s. If d_t is larger than a
certain threshold, the receiver may repeat time synchronization.
TESLA will return the data in the form of a Signature Tag, which has
the format described in Figure 3. If so required TESLA will include
a certificate chain for authentication via RSA or another public
certificate algorithm. If the bit F is set, then the optional format
described by 2 is used. The PCAN is a Public Certificate Assigned
Number describing what format the certificates are in.
Dondeti & Canetti Expires December 22, 2006 [Page 9]
Internet-Draft IPsec TESLA June 2006
3.2.3. Set-up using a multicast key management protocol
Another way to set-up the parameters of the TESLA transform at the
receiver is to obtain these parameters in the Security Association
provided by the multicast key management protocol in use (e.g.,
GDOI). This way of setting the parameters will be further described
in future versions of this draft.
3.3. Layer Placement
This document assumes TESLA to be implemented as a standalone
library, which could reside either in the network, transport, or
application layer. However, incorporating TESLA within IPsec ESP
implies usage in the network layer.
TESLA relies upon timing of packets, that is, TESLA requires knowing
the arrival time of incoming packets. TESLA SHOULD NOT be deployed
on top of a protocol or layer which will aggressively buffer packets
and hides the true packet arrival time, e.g. TCP.
3.3.1. Interface Specification
The following describes the interface which the TESLA library will
export for the above methods of bootstrapping.
3.3.1.1. Time Synchronization request
TESLA will accept a nonce and write a time synchronization request
tag (TSRT) to a user specified buffer which must be of required
length. The nonce must have significant random properties (non-
trivial and of certain length). The implementer must provide
adequate space to write the TSRT.
Dondeti & Canetti Expires December 22, 2006 [Page 10]
Internet-Draft IPsec TESLA June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id j of time interval I_j (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TI_j (NTP timestamp) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ T_int (NTP timedif) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KeyChain PRF type(F) | MAC PRF type(F') |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| d (intervals) | Key type(HMAC function) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
| |
~ K_i(variable length) ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id n of K_n (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval of n, d_n (intervals) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Time of signature T_sig (NTP timestamp) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature type | Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved(0) | |
+-+-+-+-+-+-+-+-+ Signature(variable length) ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Signature Tag format
Dondeti & Canetti Expires December 22, 2006 [Page 11]
Internet-Draft IPsec TESLA June 2006
3.3.1.2. Authentic Parameters
TESLA will accept the time synchronization request, which has the
format described in Figure 1, and write the signature tag to a user
specified buffer. It is assumed that the signature tag will be sent
to the receiver immediately following the creation of the signature.
Significant delay would result in too large a bound for d_t and
possible synchronization failure.
3.3.2. Sending Authenticated Data
When the sender sends an authenticated message to all receivers, it
adds a TESLA authentication tag to attach to the message. With the
authentication tag, a receiver MAY be able to verify or disrepute
previously received messages.
TESLA will be used as the external authentication transform in the
IPsec ESP protocol. (Recall that IPsec ESP determines exactly which
fields are covered under the TESLA authentication.) The format of
the TESLA authentication tag is shown in Figure 4. Here M denotes
the data in the fields covered by the external authentication in
IPsec ESP. Within the TESLA tag, the Id i of K_i is always sent with
the MAC of the message M computed using K_i. The last disclosed key
K_(i-d) can be used to authenticate previous messages.
When a receiver receives the tag, he must first check to see that the
time of the message does not violate the security conditions for the
keys used. M is buffered, and he attempts to authenticate any
messages which relied upon K_(i-d).
If i is not included in the message, the receiver determines i by the
time the packet was received and the maximum time displacement from
the server. With this time it then can determine the sender's
current interval i.
When the receiver receives an IPsec ESP packet with external
authentication done using TESLA, it first needs to verify whether the
packet is safe, which is to check that the key used to compute the
MAC of the packet was still secret upon packet arrival. For this,
the receiver computes an upper bound on the sender's clock, and
checks that the MAC key is still secret (based on the key disclosure
schedule). If the packet is safe, the receiver buffers the packet.
Once the receiver has determined i, either directly or by the
sender's time, it checks K_(i-d) against the most recently stored
key, K_c. If i-d=c then the receiver does nothing. Otherwise he
applies the PRF (i-d)-c times to K_(i-d) which should yield K_c. If
K_(i-d) is authentic, the receiver uses it to authenticate all
Dondeti & Canetti Expires December 22, 2006 [Page 12]
Internet-Draft IPsec TESLA June 2006
messages which used keys in the range K_(c+1) .. K_(i-d) as the MAC
key. Finally the receiver replaces K_c with K_(i-d). Note, that if
i-d < c, the packet would have been unsafe and discarded before this
step.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Id i of K_i(optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_(i-d) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K_i, M) ~
| |
~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Authentication Tag format. (This is the external
authentication tag of IPsec ESP with TESLA.)
A message in this interval may be authentic or tainted. Dealing with
tainted messages is left to the implementor. It is possible that the
sender and receiver have fallen out of sync, in which case it is
RECOMMENDED that they resynchronize times. If i is not included in
the message to the receiver and the two have fallen out of sync, the
receiver will not correctly compute i, and failure will occur when
attempting to authenticate the key.
4. IPsec ESP Packet Format with TESLA
Dondeti & Canetti Expires December 22, 2006 [Page 13]
Internet-Draft IPsec TESLA June 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Sequence Number |^ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
~ IV (variable & optional) ~| |
+---------------------------------------------------------------+| |
~ Internal Authentication Parameters (variable & optional) ~| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
^~ Data (variable) ~I E
E+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+N X
N~ ~ Padding (0-255 bytes) |T T
C+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
V| | Pad Length | Next Header |v |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Internal Authentication Tag (variable) ~ v
+---------------------------------------------------------------+
~ Integrity Check Value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPsec ESP Packet Format with External and Internal
Authentication
Encryption (ENC), when applied, covers the ESP data, padding and next
header fields. Internal Authentication (INT) covers the ESP sequence
number through the next header field, inclusive. External
authentication (EXT) covers the entire ESP packet except for the
Integrity Check Value (ICV) field.
A sender MAY use an encryption-transform (ENC) as done in any other
ESP packet.
When INT is applied to the packet, its output (if any) is placed in
the Internal Authentication Tag. Section 4.1 identifies the INT
transforms, which the sender MUST perform prior to the encryption
transform.
A sender of an IPsec ESP packet for multicast or group communication
SHOULD use an external-authentication transform (EXT). Section 4.1
identifies the EXT transforms, which the sender MUST perform last
(and the receiver performs first).
The sender MUST perform the IPsec ESP transforms for multicast or
Dondeti & Canetti Expires December 22, 2006 [Page 14]
Internet-Draft IPsec TESLA June 2006
group communication in the order of ENC, INT, and EXT while the
receiver MUST perform them in the order of EXT, INT and ENC.
5. Security Considerations
For a formal proof of the security of TESLA, please see [6]. An
analysis of the robustness of TESLA to denial-of-service attacks
along with countermeasures is described in [5].
This document extends IPsec ESP authentication and encryption
transforms to support IP multicast delivery. IPsec ESP provides
access control, rejection of replayed packets, confidentiality
(encryption), limited traffic-flow confidentiality and connectionless
integrity. ESP supports a datagram environment where each IP packet
is cryptographically independent of other IP packets and can be
decrypted, authenticated, and integrity checked when delayed,
reordered, or when other packets from the flow are lost. ESP
provides rejection of replayed packets for pairwise security
associations and for multicast security associations under certain
circumstances [ESPbis]. IPsec ESP for multicast support has the same
replay mechanism for the single-sender case; the multi-sender case is
for further study. ESP provides data origin authentication for
pairwise security associations using symmetric message authentication
codes, which are not sufficient for group security applications where
more than two members share a symmetric key.
5.1. IPsec ESP Authentication for Group Communication
This document describes data-origin authentication services to
multicast ESP packets. Secure groups, such as secure multicast
groups, cannot use a symmetric-key MAC to uniquely identify the
sender; any group member that is in possession of the group
authentication key is capable of replacing the source address of the
packet with that of another group member and applying the symmetric
key to authenticate the packet. To uniquely identify a sender among
a group of members, digital signature, public key encryption, or
specialized source-authentication techniques such as timed MACs are
needed. We define a general ESP packet structure for accommodating a
digital signature or TESLA timed MAC.
5.2. Denial-of-Service Protection
As discussed above, a group member cannot authenticate the source of
the packet for a multicast group where multiple members share the MAC
key. Thus, a rogue member of the group has all the keying material
needed to impersonate a sender of the group if that attacker is able
to inject packets into the network using that sender's IP address.
Dondeti & Canetti Expires December 22, 2006 [Page 15]
Internet-Draft IPsec TESLA June 2006
The modified ESP framework addresses this problem by augmenting the
MAC with an "internal authentication" transform, which MAY be an RSA-
SHA1 digital signature or a TESLA timed MAC. Digital signatures
leave multicast receivers vulnerable to denial- of-service attack if
the receiver is duped into performing computationally-expensive
signature validation of bogus packets. An external message
authentication SHOULD accompany a digital signature so as to limit
the effectiveness of bogus digitally signed packets by non-group
members. TESLA is also vulnerable to a denial of service attack if
the receiver is duped into storing bogus packets awaiting MAC
verification. An external message authentication transform SHOULD
accompany a TESLA authentication transform so as to limit the
effectiveness of bogus TESLA packets by non-group members.
Unfortunately, group members are still capable of sending packets
with a valid external-authenticating MAC and invalid digital
signature, i.e. a group member can launch a DoS attack on the group
using invalid digital signatures. And group members are still
capable of sending packets with a valid external-authentication MAC
but an invalid TESLA MAC. In both the TESLA and digital-signature
cases, the external authentication will succeed only to have the
internal authentication fail. The new transform includes the ESP
sequence number in the internal authentication to protect against a
replay attack by a group member. When the RECOMMENDED external
authentication code is use, however, the ESP receiver MUST validate
both the internal authentication as well as the external
authentication before updating the ESP replay window.
The value of the external MAC authentication transforms is to enable
the receiver to greatly reduce the effect of an attack by non-group
members, to reduce the effects of a denial of service attack by a
group member, to detect an attack by a group member, and to support
the integration of multicast source-authentication transforms into
IPsec ESP for data-origin authentication.
5.3. Encryption
The value of encryption in the modified ESP transform is to validate
individual encryption transforms for multicast operation. It is
possible that a particular cipher and mode are suitable for pairwise
security associations but not for multicast security associations,
such as one where multiple senders share the key. For example, a
stream or hybrid stream/block cipher has special risks of keystream
reuse when its key is shared by multiple senders. Although IPsec
encryption transforms are generally suitable for multicast operation,
many have not been evaluated, tested or used in IP multicast
environments. This I-D has considered the suitability of several
IPsec ESP encryption transforms for inclusion in the modified
Dondeti & Canetti Expires December 22, 2006 [Page 16]
Internet-Draft IPsec TESLA June 2006
framework. It is RECOMMENDED that all future IPsec encryption
transforms be analyzed as to their security for multicast and group
security as well as for pairwise security.
6. IANA Considerations
IANA considerations associated with this work will appear in future
version of this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
7.2. Informative References
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Briscoe, "Timed Efficient Stream Loss-Tolerant
Authentication (TESLA): Multicast Source Authentication
Transform Introduction", RFC 4082, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Dondeti & Canetti Expires December 22, 2006 [Page 17]
Internet-Draft IPsec TESLA June 2006
Authors' Addresses
Lakshminath Dondeti (editor)
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Ran Canetti
IBM Research
30 Saw Mill River Rd
Hawthorne, NY
USA
Phone:
Email: canetti@watson.ibm.com
Dondeti & Canetti Expires December 22, 2006 [Page 18]
Internet-Draft IPsec TESLA June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dondeti & Canetti Expires December 22, 2006 [Page 19]