datatracker.ietf.org
Sign in
Version 5.12.0.p2, 2015-03-02
Report a bug

The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
RFC 4383

Document type: RFC - Proposed Standard (February 2006; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4383 (Proposed Standard)
Responsible AD: Russ Housley
Send notices to: canetti@watson.ibm.com, ldondeti@qualcomm.com

Network Working Group                                         M. Baugher
Request for Comments: 4383                                         Cisco
Category: Standards Track                                     E. Carrara
                                           Royal Institute of Technology
                                                           February 2006

 The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
           in the Secure Real-time Transport Protocol (SRTP)

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

   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.

Baugher & Carrara           Standards Track                     [Page 1]
RFC 4383                       TESLA-SRTP                  February 2006

Table of Contents

   1. Introduction ....................................................2
      1.1. Notational Conventions .....................................3
   2. SRTP ............................................................3
   3. TESLA ...........................................................4
   4. Usage of TESLA within SRTP ......................................5
      4.1. The TESLA Extension ........................................5
      4.2. SRTP Packet Format .........................................6
      4.3. Extension of the SRTP Cryptographic Context ................7
      4.4. SRTP Processing ............................................8
           4.4.1. Sender Processing ...................................9
           4.4.2. Receiver Processing .................................9
      4.5. SRTCP Packet Format .......................................11
      4.6. TESLA MAC .................................................13
      4.7. PRFs ......................................................13
   5. TESLA Bootstrapping and Cleanup ................................14
   6. SRTP TESLA Default Parameters ..................................14
   7. Security Considerations ........................................15
   8. Acknowledgements ...............................................16
   9. References .....................................................17
      9.1. Normative References ......................................17
      9.2. Informative References ....................................17

1.  Introduction

   Multicast and broadcast communications introduce some new security
   challenges compared to unicast communication.  Many multicast and
   broadcast applications need "data origin authentication" (DOA), or
   "source authentication", in order to guarantee that a received
   message had originated from a given source, and was not manipulated
   during the transmission.  In unicast communication, a pairwise
   security association between one sender and one receiver can provide
   data origin authentication using symmetric-key cryptography (such as
   a message authentication code, MAC).  When the communication is
   strictly pairwise, the sender and receiver agree upon a key that is
   known only to them.

   In groups, however, a key is shared among more than two members, and
   this symmetric-key approach does not guarantee data origin
   authentication.  When there is a group security association [RFC4046]
   instead of a pairwise security association, any of the members can
   alter the packet and impersonate any other member.  The MAC in this
   case only guarantees that the packet was not manipulated by an
   attacker outside the group (and hence not in possession of the group
   key), and that the packet was sent by a source within the group.

Baugher & Carrara           Standards Track                     [Page 2]
RFC 4383                       TESLA-SRTP                  February 2006

   Some applications cannot tolerate source ambiguity and need to
   identify the true sender from any other group member.  A common way
   to solve the problem is by use of asymmetric cryptography, such as
   digital signatures.  This method, unfortunately, suffers from high
   overhead in terms of time (to sign and verify) and bandwidth (to
   convey the signature in the packet).

[include full document text]