TESLA: Multicast Source Authentication Transform Specification
draft-ietf-msec-tesla-spec-00
Document | Type |
Expired Internet-Draft
(msec WG)
Expired & archived
|
|
---|---|---|---|
Authors | Ran Canetti , Adrian Perrig , Bram Whillock | ||
Last updated | 2015-10-14 (Latest revision 2002-10-30) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Expired (IESG: Dead::Revised I-D Needed) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Russ Housley | ||
Send notices to | <thardjono@verisign.com> |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Data authentication is an important component for many applications, for example audio and video Internet broadcasts, or data distribution by satellite. This document specifies TESLA, a secure source authen tication mechanism for multicast or broadcast data streams. The com panion draft draft-msec-tesla-intro-01.txt [1] introduces and describes TESLA in detail, this document specifies the format of the TESLA authentication field as it is used within the MESP header [2]. The main deterrents so far for a data authentication mechanism for multicast were seemingly conflicting requirements: tolerance to packet loss, low per-packet overhead, low computation overhead, scal ability, no per-receiver state at the sender. The problem is particu larly 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 multicast source 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.
Authors
Ran Canetti
Adrian Perrig
Bram Whillock
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)