Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
RFC 4082

 
Document Type RFC - Informational (June 2005; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4082 (Informational)
Telechat date
Responsible AD Russ Housley
Send notices to <canetti@watson.ibm.com>, <thardjono@verisign.com>

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                          A. Perrig
Request for Comments: 4082                                       D. Song
Category: Informational                       Carnegie Mellon University
                                                              R. Canetti
                                                                     IBM
                                                             J. D. Tygar
                                      University of California, Berkeley
                                                              B. Briscoe
                                                                      BT
                                                               June 2005

     Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
         Multicast Source Authentication Transform Introduction

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document introduces Timed Efficient Stream Loss-tolerant
   Authentication (TESLA).  TESLA allows all receivers to check the
   integrity and authenticate the source of each packet in multicast or
   broadcast data streams.  TESLA requires no trust between receivers,
   uses low-cost operations per packet at both sender and receiver, can
   tolerate any level of loss without retransmissions, and requires no
   per-receiver state at the sender.  TESLA can protect receivers
   against denial of service attacks in certain circumstances.  Each
   receiver must be loosely time-synchronized with the source in order
   to verify messages, but otherwise receivers do not have to send any
   messages.  TESLA alone cannot support non-repudiation of the data
   source to third parties.

   This informational document is intended to assist in writing
   standardizable and secure specifications for protocols based on TESLA
   in different contexts.

Perrig, et al.               Informational                      [Page 1]
RFC 4082                   TESLA Introduction                  June 2005

Table of Contents

   1. Introduction ....................................................2
      1.1. Notation ...................................................3
   2. Functionality ...................................................4
      2.1. Threat Model and Security Guarantee ........................5
      2.2. Assumptions ................................................5
   3. The Basic TESLA Protocol ........................................6
      3.1. Protocol Sketch ............................................6
      3.2. Sender Setup ...............................................7
      3.3. Bootstrapping Receivers ....................................8
           3.3.1. Time Synchronization ................................9
      3.4. Broadcasting Authenticated Messages .......................10
      3.5. Authentication at Receiver ................................11
      3.6. Determining the Key Disclosure Delay ......................12
      3.7. Denial of Service Protection ..............................13
           3.7.1. Additional Group Authentication ....................14
           3.7.2. Not Re-using Keys ..................................15
           3.7.3. Sender Buffering ...................................17
      3.8. Some Extensions ...........................................17
   4. Layer Placement ................................................17
   5. Security Considerations ........................................18
   6. Acknowledgements ...............................................19
   7. Informative References .........................................19

1.  Introduction

   In multicast, a single packet can reach millions of receivers.
   Unfortunately, this introduces the danger that an attacker can
   potentially also reach millions of receivers with a malicious packet.
   Through source authentication, receivers can ensure that a received
   multicast packet originates from the correct source.  In these
   respects, a multicast is equivalent to a broadcast to a superset of
   the multicast receivers.

   In unicast communication, we can achieve data authentication through
   a simple mechanism: the sender and the receiver share a secret key to
   compute a message authentication code (MAC) of all communicated data.
   When a message with a correct MAC arrives, the receiver is assured
   that the sender generated that message.  Standard mechanisms achieve
   unicast authentication this way; for example, TLS or IPsec [1,2].

   Symmetric MAC authentication is not secure in a broadcast setting.
   Consider a sender that broadcasts authentic data to mutually
Show full document text