TESLA
TESLA (Timed Efficient Stream Loss-tolerant Authentication), delayed-key-disclosure source authentication for multicast and broadcast streams
Within this page
TESLA RFCs (5)
RFC 6584: Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
Proposed Standard- V. Roca
- April 2012
- IETF publication
- Transport Area
Abstract
This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]
Abstract
This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. [STANDARDS-TRACK]
RFC 5776: Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
Experimental- V. Roca
- A. Francillon
- S. Faurite
- April 2010
- IETF publication
- Security Area
Abstract
This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community.
Abstract
This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community.
RFC 4442: Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
Proposed Standard- S. Fries
- H. Tschofenig
- March 2006
- IETF publication
- Security Area
Abstract
TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]
Abstract
TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized in TESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios where SRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms.
This document specifies payloads for the Multimedia Internet Keying (MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast. [STANDARDS-TRACK]
RFC 4383: The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
Proposed Standard- M. Baugher
- E. Carrara
- February 2006
- IETF publication
- Security Area
Abstract
This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]
Abstract
This memo describes the use of the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure Real-time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams. [STANDARDS-TRACK]
RFC 4082: Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction
Informational- A. Perrig
- D. Song
- R. Canetti
- J. D. Tygar
- B. Briscoe
- June 2005
- IETF publication
- Security Area
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. This memo provides information for the Internet community.
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. This memo provides information for the Internet community.
Subscribe to TESLA
Get notified when:
- RFC changes to status, obsoleted by, updates, updated by, or subseries.
- New RFC added to this subject or below
- The subject was merged into another.