Skip to main content

Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
RFC 4442

Revision differences

Document history

Date Rev. By Action
2018-12-20
03 (System)
Received changes through RFC Editor sync (changed abstract to 'TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios. TESLA is …
Received changes through RFC Editor sync (changed abstract to '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]')
2012-08-22
03 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2006-04-05
03 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-04-05
03 Amy Vezza [Note]: 'RFC 4442' added by Amy Vezza
2006-03-17
03 (System) RFC published
2006-01-20
03 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-01-12
03 Amy Vezza IESG state changed to Approved-announcement sent
2006-01-12
03 Amy Vezza IESG has approved the document
2006-01-12
03 Amy Vezza Closed "Approve" ballot
2006-01-12
03 Russ Housley State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley
2006-01-12
03 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2006-01-11
03 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-01-11
03 (System) New version available: draft-ietf-msec-bootstrapping-tesla-03.txt
2005-12-16
03 (System) Removed from agenda for telechat - 2005-12-15
2005-12-15
03 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2005-12-15
03 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-12-15
03 Michelle Cotton
IANA Comments:
Upon approval of this document we understand the IANA needs to assign 4 values.
It is not clear as to in which registries …
IANA Comments:
Upon approval of this document we understand the IANA needs to assign 4 values.
It is not clear as to in which registries these values need to go in.  The IANA Considerations section needs some clarification.
2005-12-15
03 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-12-15
03 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-12-15
03 Brian Carpenter
[Ballot discuss]
(Based on Gen-ART review by Elwyn Davies)

Some policy parameters appear to be under-specified, so interoperability is uncertain:

s4.2: Need to be more …
[Ballot discuss]
(Based on Gen-ART review by Elwyn Davies)

Some policy parameters appear to be under-specified, so interoperability is uncertain:

s4.2: Need to be more precise about how time values are carried (items 7 and 11).
One possibility is to refer to s6.6 of RFC3830 which gives three options for timestamp formats.

s4.2: I think it might be desirable to be more precise about how big items 8 and 9 are (2 byte or 4 byte integers maybe)

s4.2: Presumably Type 11 is optional, dependent on the sync method used.  Does anything need to be said about how it is decided whether this should be present/processed?  Is it a matter of policy to be determined OOB or it being present implies the use of 'type 2' synchronization?

IANA Considerations unclear

s6: The registries and defining documents into which the attributes are to be inserted need to be specified.
2005-12-15
03 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter
2005-12-15
03 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-12-15
03 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-12-14
03 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-12-14
03 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-12-14
03 Jon Peterson [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson
2005-12-14
03 Jon Peterson [Ballot comment]
The expansion of the acronyms SIP and SDP, and inclusion of corresponding references for those protocols, might be appropriate.
2005-12-14
03 Jon Peterson [Ballot Position Update] New position, Undefined, has been recorded for Jon Peterson by Jon Peterson
2005-12-14
03 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-12-12
03 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2005-12-12
03 Ted Hardie
[Ballot comment]
The document notes that NTP may be used as an out-of-band mechanism for synchronization, and it assigns this a SHOULD when piggybacking timestamp …
[Ballot comment]
The document notes that NTP may be used as an out-of-band mechanism for synchronization, and it assigns this a SHOULD when piggybacking timestamp information is not appropriate (as when the
media receiver is not the MIKEY initiator).  Is there any general set of characteristics for out-of-band mechanisms which would allow someone to know whether a mechanism might substitute for NTP in a specific environment?
2005-12-12
03 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2005-12-06
03 Scott Hollenbeck [Ballot comment]
The "IANA Considerations" section should explain which registry must be used to register the described parameters and values.
2005-12-06
03 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-11-28
03 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2005-11-28
03 Russ Housley Ballot has been issued by Russ Housley
2005-11-28
03 Russ Housley Created "Approve" ballot
2005-11-28
03 Russ Housley Placed on agenda for telechat - 2005-12-15 by Russ Housley
2005-11-28
03 Russ Housley State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley
2005-11-22
03 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2005-11-08
03 Amy Vezza Last call sent
2005-11-08
03 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-11-08
03 Russ Housley State Changes to Last Call Requested from AD Evaluation::AD Followup by Russ Housley
2005-11-08
03 Russ Housley Last Call was requested by Russ Housley
2005-11-08
03 (System) Ballot writeup text was added
2005-11-08
03 (System) Last call text was added
2005-11-08
03 (System) Ballot approval text was added
2005-10-19
03 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-10-19
02 (System) New version available: draft-ietf-msec-bootstrapping-tesla-02.txt
2005-07-31
03 Russ Housley State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Russ Housley
2005-05-26
03 Russ Housley Draft Added by Russ Housley in state Publication Requested
2005-05-24
01 (System) New version available: draft-ietf-msec-bootstrapping-tesla-01.txt
2005-01-18
00 (System) New version available: draft-ietf-msec-bootstrapping-tesla-00.txt