datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

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

Document type: RFC - Informational (June 2005)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4082 (Informational)
Responsible AD: Russ Housley
Send notices to: <canetti@watson.ibm.com>, <thardjono@verisign.com>

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

[include full document text]