Network L. Dondeti, Ed.
Internet-Draft QUALCOMM, Inc.
Intended status: Standards Track R. Canetti
Expires: January 8, 2008 IBM Research
July 7, 2007
The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
in IPsec
draft-dondeti-msec-ipsec-tesla-02
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 January 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies the use of Timed Efficient Stream Loss-
tolerant Authentication (TESLA) -- a source authentication mechanism
for multicast or broadcast data streams -- with IPsec ESP. In
addition to the source authentication using TESLA, group
authentication of the ESP packet can be provided using a shared
symmetric group key. Thus, the proposed extension to ESP combines
Dondeti & Canetti Expires January 8, 2008 [Page 1]
Internet-Draft IPsec TESLA July 2007
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 the TESLA work. Mark Baugher, Ran Canetti, Pau-Chen
Cheng and Pankaj Rohatgi were the original contributors to the
multicast ESP transform design.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Notes on IPsec ESP and TESLA . . . . . . . . . . . . . . . . . 4
4. IPsec ESP Packet Format with TESLA . . . . . . . . . . . . . . 4
4.1. On the IPsec ICV in TESLA Protected ESP packets . . . . . 6
5. Cryptographic Algorithms for IPsec ESP with TESLA . . . . . . 7
6. Sender Processing of TESLA Protected Packets . . . . . . . . . 7
7. Receiver Processing of TESLA Protected Packets . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Dondeti & Canetti Expires January 8, 2008 [Page 2]
Internet-Draft IPsec TESLA July 2007
1. Introduction
The IPsec Encapsulation Security Payload (ESP) [RFC4303] transform
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 (SA). A Message Authentication Code (MAC) based on a
symmetric key is the common means to provide data origin
authentication for pairwise IPsec SAs. However, for secure groups
such as IP multicast groups, a MAC supports only "group
authentication" and not data origin authentication. This document
specifies a ESP data origin authentication transform based on TESLA
for source authentication of data sent to groups of receivers.
The description of the TESLA protocol itself is available in RFC 4082
[RFC4082]. The TESLA authentication itself is protected from DoS
attacks by an external authentication transform using a symmetric-key
based MAC. Thus senders first source authenticate a packet and then
protect it with group authentication. 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 following the TESLA procedures.
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): Group Secrecy ensures that transmitted data is
accessible only to group members. This is often used as the means
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 group secrecy is the same as the
solution for two party confidential communication.
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 or HMAC.
Dondeti & Canetti Expires January 8, 2008 [Page 3]
Internet-Draft IPsec TESLA July 2007
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 group members). Unlike Group Authentication, SrA
provides the IPsec data origin authentication function. SrA
provides a much stronger security guarantee than GA in that a
particular group member can be identified as a source of a packet.
3. Notes on IPsec ESP and TESLA
IPsec ESP provides confidentiality, integrity protection, replay
protection and traffic flow confidentiality. Integrity protection
may be provided using symmetric keys or digital signatures [RFC4359].
For unicast communication, integrity protection using either
mechanism provides data origin authentication. In case of multicast
or group communication, symmetric-key based integrity protection
supports group authentication only. For source authentication of
multicast streams, the sender may sign every packet [RFC4359], use
TESLA or another source authentication mechanism.
TESLA uses symmetric key chain commitment, delayed disclosure of a
key from the key chain, and loose time synchronization between the
sender's and the receivers' clocks to support source and data origin
authentication. The delayed disclosure of keys from the key chain
implies that the receivers must buffer packets until the
authentication can be verified. To avoid denial of service attacks
taking advantage of this buffering requirement, TESLA protected
packets may be further protected using group authentication of
packets. That limits any such denial of service attacks to from
members of the secure group.
TESLA receivers may be bootstrapped using a digitally signed
broadcast message containing the commitment to a key chain, local
time, disclosure delay and other TESLA parameters from the sender or
via individual registration processes with the sender. Bootstrapping
of TESLA is out of scope for this document. The key management
protocol that establishes the IPsec SA can be used for bootstrapping
TESLA at the receivers.
4. IPsec ESP Packet Format with TESLA
In the following we first describe the TESLA authentication fields,
followed by a depiction of where the those fields fit in an IPsec ESP
packet. Figure 2 also shows the coverage of encryption (when the
encryption algorithm is non-NULL), IPsec integrity protection (IPsec
ICV), and the TESLA MAC.
Dondeti & Canetti Expires January 8, 2008 [Page 4]
Internet-Draft IPsec TESLA July 2007
The TESLA Authentication Fields are as follows:
o Id i of K_i (OPTIONAL) -- The 32-bit Id of the key used to compute
the TESLA-MAC of the current packet: Within the TESLA tag, the Id
i of K_i MAY be sent with the MAC of the message M computed using
K_i. 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.
o Disclosed Key K_(i-d) -- Variable length disclosed key is
MANDATORY and is used to authenticate previous packets from
earlier time intervals.
o TESLA MAC (K'_i, M): Variable length, MANDATORY. TESLA MAC is
computed using the key K'_i (derived from K_i) [RFC4082], which is
disclosed in a subsequent packet (in the Disclosed Key field).
The MAC coverage is shown in Figure 2.
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: TESLA Authentication Fields.
TESLA authentication fields are added to IPsec ESP packets as shown
in Figure 2.
Dondeti & Canetti Expires January 8, 2008 [Page 5]
Internet-Draft IPsec TESLA July 2007
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 | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I
T | IV (optional) |^ P
E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| s
S | Rest of Payload Data (variable) |E e
L ~ ~N c
A | |C
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R I
M | | TFC Padding * (optional, variable) |Y C
A +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+P V
C | | Padding (0-255 bytes) |T |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v | | Pad Length | Next Header |v |
--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
~ TESLA Authentication Fields (variable) ~ v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
~ Integrity Check Value-ICV (variable) ~
+---------------------------------------------------------------+
Figure 2: IPsec ESP Packet Format with TESLA MAC and IPsec ICV
In the figure,
o The label "Encyrpt" indicates the coverage of IPsec encryption.
It is the same as that described in the IPsec ESP specification
[RFC4303].
o The label "IPsec ICV" indicates IPsec ESP's ICV coverage. Whether
the ICV is present and its coverage of the fields of the IPsec
packet is as specified in the ESP specification.
o The label "TESLA MAC" indicates the TESLA MAC coverage. The TESLA
MAC protects the IPsec ESP packet starting with the Sequence
number and ending with the Next Header field.
4.1. On the IPsec ICV in TESLA Protected ESP packets
IPsec ESP mandates the presence of an Integrity Check Value (ICV),
except when combined mode algorithms are used to protect the packet
and the ICV is part of the combined mode algorithm. In case of CCM,
the ICV is encrypted and only parseable at the receiver after
Dondeti & Canetti Expires January 8, 2008 [Page 6]
Internet-Draft IPsec TESLA July 2007
decryption. With TESLA protection of a packet, technically an ICV is
not required for integrity protection of the packet. However, as
noted above, a symmetric-key based ICV has the advantage of
protecting against some DoS attacks on TESLA, so ICV is REQUIRED to
be present in ESP-TESLA.
5. Cryptographic Algorithms for IPsec ESP with TESLA
TESLA needs a PRF algorithm to derive keys in the key chain. TESLA
PRF algorithm is specified through the key management protocol that
distributes the ESP SA.
The TESLA MAC algorithm is also specified through the key management
protocol. There is no reason for this algorithm to be different from
the IPsec ICV algorithm. When the TESLA MAC algorithm is not
explicitly specified, the receivers are REQUIRED to use the IPsec ICV
algorithm to compute the TESLA MAC algorithm.
In the single sender group communication, all encryption algorithms
that are appropriate for unicast communication are also suitable for
secure group communication. In the multi-sender communication case,
the counter mode algorithms must be used as specified in .
[I-D.weis-esp-group-counter-cipher]
6. Sender Processing of TESLA Protected Packets
In addition to the steps in [RFC4303], the sender follows the steps
below for TESLA protected packets:
o The sender determines the current TESLA time interval i. The
sender may include the time interval i in the message.
o It then includes the TESLA Key, K_(i-d), where d is the TESLA
disclosure delay.
o Next, it computes the TESLA MAC over the IPsec ESP packet,
starting at the Sequence Number field and ending with the Next
Header field, using the TESLA Key K_i. That key itself SHALL NOT
be disclosed until the TESLA interval i+d.
o The sender includes all the TESLA Authentication Fields after the
Next Header field of the ESP packet and proceeds to compute the
IPsec ICV over the entire ESP packet excluding the ICV field
itself.
Dondeti & Canetti Expires January 8, 2008 [Page 7]
Internet-Draft IPsec TESLA July 2007
7. Receiver Processing of TESLA Protected Packets
Receiver processing of TESLA packets contains the following steps.
Note that the symmetric key MAC or the group MAC verification is
similar to the MAC verification process specified in Section 3.4.4 of
[RFC4303]. We limit the specification below for TESLA MAC
verification.
o When a receiver receives an ESP packet with TESLA fields, it must
first check to see that the time interval of the message does not
violate the security conditions for the keys used. The message is
buffered, and the receiver attempts to authenticate any messages
which are authenticated using K_(i-d), i.e., messages received
with the index i-d.
o 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.
o When the receiver receives a TESLA protected ESP packet, it first
needs to verify whether the packet is safe, which is to verify
that the key used to compute the MAC of the packet was still
secret upon packet arrival. For the verification, 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. The "safe
packet test" is explained in detail in Section 3.5 of [RFC4082].
o Once the receiver has determined i, it checks K_(i-d) against the
most recently stored key, K_c. If i-d=c then the receiver does
nothing. Otherwise it 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 buffered 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). If K_(i-d) is not authentic,
the receiver discards the received message. If the MAC
verification on any individual buffered packet fails, the receiver
discards that buffered packet.
o Note, that if i-d < c the packet would have been unsafe and
discarded before this step.
o After the TESLA MAC has been verified, the receiver updates the
replay window.
Dondeti & Canetti Expires January 8, 2008 [Page 8]
Internet-Draft IPsec TESLA July 2007
8. Security Considerations
This document specifies the use of a source authentication scheme
TESLA with IPsec ESP. TESLA provides source authentication using a
symmetric key MAC but relies on loose time synchronization and
delayed MAC key disclosure. The scheme is safe as long as receivers
can estimate an upper bound on the sender's time and accept packets
only if there is a local assurance that the sender has not revealed
the MAC key used to authenticate the received packet. To that end,
the security considerations in [RFC4082] apply.
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. TESLA-ESP
addresses this problem by augmenting the IPsec ICV with the TESLA MAC
protection. Source authentication schemes leave multicast receivers
vulnerable to DoS attacks if the receiver is duped into performing
computationally-expensive validation of bogus packets or buffering of
bogus packets. An IPsec ICV is RECOMMENDED to accompany the TESLA
MAC so as to limit the effectiveness of bogus packets sent by non-
group members.
Unfortunately, group members are still capable of sending packets
with a valid external-authenticating MAC and invalid TESLA MAC, i.e.,
any group member can launch a DoS attack. In this case, the IPsec
ICV verification will succeed only to have the TESLA MAC verification
to fail.
The new transform includes the ESP sequence number in the TESLA MAC
to protect against a replay attack by a group member. When the TESLA
MAC is used, however, the ESP receiver MUST validate both the
authentication tags before updating the ESP replay window.
9. IANA Considerations
IANA considerations associated with this work will appear in future
version of this document.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Dondeti & Canetti Expires January 8, 2008 [Page 9]
Internet-Draft IPsec TESLA July 2007
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
10.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.
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within
Encapsulating Security Payload (ESP) and Authentication
Header (AH)", RFC 4359, January 2006.
[I-D.weis-esp-group-counter-cipher]
McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic",
draft-weis-esp-group-counter-cipher-00 (work in progress),
October 2006.
Authors' Addresses
Lakshminath Dondeti (editor)
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Dondeti & Canetti Expires January 8, 2008 [Page 10]
Internet-Draft IPsec TESLA July 2007
Ran Canetti
IBM Research
30 Saw Mill River Rd
Hawthorne, NY
USA
Phone:
Email: canetti@watson.ibm.com
Dondeti & Canetti Expires January 8, 2008 [Page 11]
Internet-Draft IPsec TESLA July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dondeti & Canetti Expires January 8, 2008 [Page 12]