Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
draft-ietf-msec-tesla-intro-04

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    msec mailing list <msec@ietf.org>, 
    msec chair <msec-chairs@tools.ietf.org>
Subject: Document Action: 'TESLA: Multicast Source 
         Authentication Transform Introduction' to Informational RFC 

The IESG has approved the following document:

- 'TESLA: Multicast Source Authentication Transform Introduction '
   <draft-ietf-msec-tesla-intro-05.txt> as an Informational RFC

This document is the product of the Multicast Security Working Group. 

The IESG contact persons are Russ Housley and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-intro-05.txt

Ballot Text

Technical Summary

  This document introduces TESLA, a secure source authentication
  mechanism for multicast or broadcast data streams.  This document
  provides an algorithmic description of the scheme for informational
  purposes, and in particular, it is intended to assist in writing
  specifications for protocols based on TESLA in different contexts.

  The main deterrents so far for a data authentication mechanism for
  multicast were the seemingly conflicting requirements: loss tolerance,
  high efficiency, no per-receiver state at the sender.  The problem is
  particularly hard in settings with high packet loss rates and where
  lost packets are not retransmitted, and where the receiver wants to
  authenticate each packet it receives.

  TESLA provides authentication of individual data packets, regardless
  of the packet loss rate.  In addition, TESLA features low overhead for
  both sender and receiver, and does not require per-receiver state at
  the sender. TESLA is secure as long as the sender and receiver are
  loosely time synchronized.

Working Group Summary

  The MSEC Working Group came to rough consensus on this document.

Protocol Quality

  This document was reviewed by Russ Housley for the IESG.

RFC Editor Note