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

Network Working Group                                           S. Fries
Request for Comments: 4442                                 H. Tschofenig
Category: Standards Track                                        Siemens
                                                              March 2006

                             Bootstrapping
      Timed Efficient Stream Loss-Tolerant Authentication (TESLA)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.

Fries & Tschofenig          Standards Track                     [Page 1]
RFC 4442                  Bootstrapping TESLA                 March 2006

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. TESLA Parameter Overview ........................................4
   4. Parameter Encoding within MIKEY .................................6
      4.1. Security Policy (SP) Payload ...............................6
      4.2. TESLA Policy ...............................................7
      4.3. Time Synchronization .......................................8
      4.4. Key Data Transport within MIKEY's General
           Extension Payload .........................................10
   5. Security Considerations ........................................11
      5.1. Man-in-the-Middle Attack ..................................11
      5.2. Downgrading Attack ........................................12
      5.3. Denial of Service Attack ..................................12
      5.4. Replay Attack .............................................13
      5.5. Traffic Analysis ..........................................13
   6. IANA Considerations ............................................14
   7. Acknowledgements ...............................................15
   8. References .....................................................16
      8.1. Normative References ......................................16
      8.2. Informative References ....................................16

Fries & Tschofenig          Standards Track                     [Page 2]
RFC 4442                  Bootstrapping TESLA                 March 2006

1.  Introduction

   In many multicast, broadcast, and unicast communication scenarios, it
   is necessary to guarantee that a received message has been sent from
   a dedicated source and has not been altered in transit.  In unicast
   communication, commonly a pairwise security association exists that
   enables the validation of message integrity and data origin.  The
   approach in group-based communication is different, as here a key is
   normally shared between the members of a group and thus may not be
   used for data origin authentication.  As in some applications a
   dedicated identification of a sender is required, there exists the
   requirement to support data origin authentication also in multicast
   scenarios.  One of the methods supporting this is TESLA [RFC4082].
   TESLA provides source authentication in multicast scenarios by using
   MAC chaining.  It is based on loose time synchronization between the
   sender and the receivers.

   [RFC4383] describes extensions for SRTP [RFC3711] in order to support