doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc4383.txt b/doc/rfc/rfc4383.txt
new file mode 100644
index 0000000..c01fb35
--- /dev/null
+++ b/doc/rfc/rfc4383.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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).
+
+   Several schemes have been proposed to provide efficient data origin
+   authentication in multicast and broadcast scenarios.  The Timed
+   Efficient Stream Loss-tolerant Authentication (TESLA) is one such
+   scheme.
+
+   This memo specifies TESLA authentication for SRTP.  SRTP TESLA can
+   provide data origin authentication to RTP applications that use group
+   security associations (such as multicast RTP applications) so long as
+   receivers abide by the TESLA security invariants [RFC4082].
+
+1.1.  Notational Conventions
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   This specification assumes that the reader is familiar with both SRTP
+   and TESLA.  Few of their details are explained in this document, and
+   the reader can find them in their respective specifications,
+   [RFC3711] and [RFC4082].  This specification uses the same
+   definitions as TESLA for common terms and assumes that the reader is
+   familiar with the TESLA algorithms and protocols [RFC4082].
+
+2.  SRTP
+
+   The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
+   of RTP, which can provide confidentiality, message authentication,
+   and replay protection to the RTP traffic and to the RTP control
+   protocol, the Real-time Transport Control Protocol (RTCP).  Note that
+   the term "SRTP" may often be used to indicate SRTCP as well.
+
+   SRTP is a framework that allows new security functions and new
+   transforms to be added.  SRTP currently does not define any mechanism
+   to provide data origin authentication for group security
+   associations.  Fortunately, it is straightforward to add TESLA to the
+   SRTP cryptographic framework.
+
+   The TESLA extension to SRTP is defined in this specification, which
+   assumes that the reader is familiar with the SRTP specification
+   [RFC3711], its packet structure, and its processing rules.  TESLA is
+
+
+
+
+Baugher & Carrara           Standards Track                     [Page 3]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+   an alternative message-authentication algorithm that authenticates
+   messages from the source when a key is shared among two or more
+   receivers.
+
+3.  TESLA
+
+   TESLA provides delayed per-packet data authentication and is
+   specified in [RFC4082].
+
+   In addition to its SRTP data-packet definition given here, TESLA
+   needs an initial synchronization protocol and initial bootstrapping
+   procedure.  The synchronization protocol allows the sender and the
+   receiver to compare their clocks and determine an upper bound of the
+   difference.  The synchronization protocol is outside the scope of
+   this document.
+
+   TESLA also requires an initial bootstrapping procedure to exchange
+   needed parameters and the initial commitment to the key chain
+   [RFC4082].  For SRTP, it is assumed that the bootstrapping is
+   performed out-of-band, possibly using the key management protocol
+   that is exchanging the security parameters for SRTP, e.g., [RFC3547,
+   RFC3830].  Initial bootstrapping of TESLA is outside the scope of
+   this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                     [Page 4]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+4.  Usage of TESLA within SRTP
+
+   The present specification is an extension to the SRTP specification
+   [RFC3711] and describes the use of TESLA with only a single key chain
+   and delayed-authentication [RFC4082].
+
+4.1.  The TESLA Extension
+
+   TESLA is an OPTIONAL authentication transform for SRTP.  When used,
+   TESLA adds the fields shown in Figure 1 per-packet.  The fields added
+   by TESLA are called "TESLA authentication extensions," whereas
+   "authentication tag" or "integrity protection tag" indicate the
+   normal SRTP integrity protection tag, when the SRTP master key is
+   shared by more than two endpoints [RFC3711].
+
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              i                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                         Disclosed Key                         ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                           TESLA MAC                           ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 1.  The "TESLA authentication extension".
+
+   i: 32 bit, MANDATORY
+      Identifier of the time interval i, corresponding to the key K_i,
+      which is used to calculate the TESLA MAC of the current packet
+      (and other packets sent in the current time interval i).
+
+   Disclosed Key: variable length, MANDATORY
+      The disclosed key (K_(i-d)), which can be used to authenticate
+      previous packets from earlier time intervals [RFC4082].  A
+      Section 4.3 parameter establishes the size of this field.
+
+   TESLA MAC (Message Authentication Code): variable length, MANDATORY
+      The MAC computed using the key K'_i (derived from K_i)
+      [RFC4082], which is disclosed in a subsequent packet (in the
+      Disclosed Key field).  The MAC coverage is defined in Section
+      4.6.  A Section 4.3 parameter establishes the size of this
+      field.
+
+
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                     [Page 5]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+4.2.  SRTP Packet Format
+
+   Figure 2 illustrates the format of the SRTP packet when TESLA is
+   applied.  When applied to RTP, the TESLA authentication extension
+   SHALL be inserted before the (optional) SRTP MKI and (recommended)
+   authentication tag (SRTP MAC).
+
+     0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
+  |V=2|P|X|  CC   |M|     PT      |       sequence number         | | |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+  |                           timestamp                           | | |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+  |           synchronization source (SSRC) identifier            | | |
+  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
+  |            contributing source (CSRC) identifiers             | | |
+  |                               ....                            | | |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+  |                   RTP extension (OPTIONAL)                    | | |
++>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| |                          payload  ...                         | | |
+| |                               +-------------------------------+ | |
+| |                               | RTP padding   | RTP pad count | | |
++>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |
+| |                            i                                  | | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                      Disclosed Key                            ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                          TESLA MAC                            ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+
+| ~                            MKI                                ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                            MAC                                ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+|                                                                   | |
++- Encrypted Portion                 TESLA Authenticated Portion ---+ |
+                                                                      |
+                                             Authenticated Portion ---+
+
+   Figure 2.  The format of the SRTP packet when TESLA is applied.
+
+   As in SRTP, the "Encrypted Portion" of an SRTP packet consists of the
+   encryption of the RTP payload (including RTP padding when present) of
+   the equivalent RTP packet.
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                     [Page 6]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+   The "Authenticated Portion" of an SRTP packet consists of the RTP
+   header, the Encrypted Portion of the SRTP packet, and the TESLA
+   authentication extension.  Note that the definition is extended from
+   [RFC3711] by the inclusion of the TESLA authentication extension.
+
+   The "TESLA Authenticated Portion" of an SRTP packet consists of the
+   RTP header and the Encrypted Portion of the SRTP packet.  As shown in
+   Figure 2, the SRTP MAC covers up to the MKI field but does not
+   include the MKI.  It is necessary for packet integrity that the
+   SRTP-TESLA MAC tag be covered by the SRTP integrity check.  SRTP does
+   not cover the MKI field (because it does not need to be covered for
+   SRTP packet integrity).  In order to make the two tags (SRTP-TESLA
+   MAC and SRTP-MAC) contiguous, we would need to redefine the SRTP
+   specification to include the MKI in SRTP-MAC coverage.  This change
+   is impossible, so the MKI field separates the TESLA MAC from the SRTP
+   MAC in the packet layout of Figure 2.  This change to the packet
+   format presents no problem to an implementation that supports the new
+   SRTP-TESLA authentication transform.
+
+   The lengths of the Disclosed Key and TESLA MAC fields are Section 4.3
+   parameters.  As in SRTP, fields that follow the packet payload are
+   not necessarily aligned on 32-bit boundaries.
+
+4.3.  Extension of the SRTP Cryptographic Context
+
+   When TESLA is used, the definition of cryptographic context in
+   Section 3.2 of SRTP SHALL include the following extensions.
+
+   Transform-Dependent Parameters
+
+     1.  an identifier for the PRF (TESLA PRF), implementing the one-way
+         function F(x) in TESLA (to derive the keys in the chain), and
+         the one-way function F'(x) in TESLA (to derive the keys for the
+         TESLA MAC, from the keys in the chain), e.g., to indicate
+         HMAC-SHA1.  See Section 6 for the default value.
+
+     2.  a non-negative integer, n_p, determining the length of the F
+         output; i.e., the length of the keys in the chain (that is also
+         the key disclosed in an SRTP packet).  See Section 6 for the
+         default value.
+
+     3.  a non-negative integer, n_f, determining the length of the
+         output of F', i.e., of the key for the TESLA MAC.  See Section
+         6 for the default value.
+
+     4.  an identifier for the TESLA MAC that accepts the output of
+         F'(x) as its key, e.g., to indicate HMAC-SHA1.  See Section 6
+         for the default value.
+
+
+
+Baugher & Carrara           Standards Track                     [Page 7]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+     5.  a non-negative integer, n_m, determining the length of the
+         output of the TESLA MAC.  See Section 6 for the default value.
+
+     6.  the beginning of the session T_0.
+
+     7.  the interval duration T_int (in msec).
+
+     8.  the key disclosure delay d (in number of intervals).
+
+     9.  the upper bound D_t (in sec) on the lag of the receiver clock
+         relative to the sender clock (this quantity has to be
+         calculated by the peers out-of-band).
+
+     10. a non-negative integer, n_c, determining the length of the key
+         chain, K_0...K_n-1 of [RFC4082] (see also Section 6 of this
+         document), which is determined based upon the expected duration
+         of the stream.
+
+     11. the initial key of the chain to which the sender has committed
+         himself.
+
+   F(x) is used to compute a keychain of keys in SRTP TESLA, as defined
+   in Section 6.  Also according to TESLA, F'(x) computes a TESLA MAC
+   key with inputs as defined in Section 6.
+
+   Section 6 of this document defines the default values for the
+   transform-specific TESLA parameters.
+
+4.4.  SRTP Processing
+
+   The SRTP packet processing is described in Section 3.3 of the SRTP
+   specification [RFC3711].  The use of TESLA slightly changes the
+   processing, as the SRTP MAC is checked upon packet arrival for DoS
+   prevention, but the current packet is not TESLA-authenticated.  Each
+   packet is buffered until a subsequent packet discloses its TESLA key.
+   The TESLA verification itself consists of some steps, such as tests
+   of TESLA security invariants, that are described in Sections 3.5-3.7
+   of [RFC4082].  The words "TESLA computation" and "TESLA verification"
+   hereby imply all those steps, which are not all spelled out in the
+   following.  In particular, notice that the TESLA verification implies
+   checking the safety condition (Section 3.5 of [RFC4082]).
+
+   As pointed out in [RFC4082], if the packet is deemed "unsafe", then
+   the receiver considers the packet unauthenticated.  It should discard
+   unsafe packets, but, at its own risk, it may choose to use them
+   unverified.  Hence, if the safe condition does not hold, it is
+   RECOMMENDED to discard the packet and log the event.
+
+
+
+
+Baugher & Carrara           Standards Track                     [Page 8]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+4.4.1.  Sender Processing
+
+   The sender processing is as described in Section 3.3 of [RFC3711], up
+   to step 5, inclusive.  After that, the following process is followed:
+
+   6. When TESLA is applied, identify the key in the TESLA chain to be
+      used in the current time interval, and the TESLA MAC key derived
+      from it.  Execute the TESLA computation to obtain the TESLA
+      authentication extension for the current packet, by appending the
+      current interval identifier (as i field), the disclosed key of the
+      chain for the previous disclosure interval (i.e., the key for
+      interval i is disclosed in interval i+d), and the TESLA MAC under
+      the current key from the chain.  This step uses the related TESLA
+      parameters from the crypto context as for Step 4.
+
+   7. If the MKI indicator in the SRTP crypto context is set to one,
+      append the MKI to the packet.
+
+   8. When TESLA is applied, and if the SRTP authentication (external
+      tag) is required (for DoS), compute the authentication tag as
+      described in step 7 of Section 3.3 of the SRTP specification, but
+      with coverage as defined in this specification (see Section 4.6).
+
+   9. If necessary, update the rollover counter (step 8 in Section 3.3
+      of [RFC3711]).
+
+4.4.2.  Receiver Processing
+
+   The receiver processing is as described in Section 3.3 of [RFC3711],
+   up to step 4, inclusive.
+
+   To authenticate and replay-protect the current packet, the processing
+   is as follows:
+
+      First, check if the packet has been replayed (as per Section 3.3
+      of [RFC3711]).  Note, however, that the SRTP replay list contains
+      SRTP indices of recently received packets that have been
+      authenticated by TESLA (i.e., replay list updates MUST NOT be
+      based on SRTP MAC).  If the packet is judged to be replayed, then
+      the packet MUST be discarded, and the event SHOULD be logged.
+
+      Next, perform verification of the SRTP integrity protection tag
+      (not the TESLA MAC), if present, using the rollover counter from
+      the current packet, the authentication algorithm indicated in the
+      cryptographic context, and the session authentication key.  If the
+      verification is unsuccessful, the packet MUST be discarded from
+      further processing, and the event SHOULD be logged.
+
+
+
+
+Baugher & Carrara           Standards Track                     [Page 9]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+      If the verification is successful, remove and store the MKI (if
+      present) and authentication tag fields from the packet.  The
+      packet is buffered, awaiting disclosure of the TESLA key in a
+      subsequent packet.
+
+      TESLA authentication is performed on a packet when the key is
+      disclosed in a subsequent packet.  Recall that a key for interval
+      i is disclosed during interval i+d, i.e., the same key is
+      disclosed in packets sent over d intervals of length t_int.  If
+      the interval identifier i from the packet (Section 4.1) has
+      advanced more than d intervals from the highest value of i that
+      has been received, then packets have been lost, and one or more
+      keys MUST be computed as described in Section 3.2, second
+      paragraph, of the TESLA specification [RFC4082].  The computation
+      is performed recursively for all disclosed keys that have been
+      lost, from the newly-received interval to the last-received
+      interval.
+
+      When a newly-disclosed key is received or computed, perform the
+      TESLA verification of the packet using the rollover counter from
+      the packet, the TESLA security parameters from the cryptographic
+      context, and the disclosed key.  If the verification is
+      unsuccessful, the packet MUST be discarded from further
+      processing, and the event SHOULD be logged.  If the TESLA
+      verification is successful, remove the TESLA authentication
+      extension from the packet.
+
+   To decrypt the current packet, the processing is as follows:
+
+      Decrypt the Encrypted Portion of the packet, using the decryption
+      algorithm indicated in the cryptographic context, the session
+      encryption key, and salt (if used) found in Step 4 with the index
+      from Step 2.
+
+   (Note that the order of decryption and TESLA verification is not
+   mandated.  It is RECOMMENDED that the TESLA verification be performed
+   before decryption.  TESLA application designers might choose to
+   implement optimistic processing techniques such as notification of
+   TESLA verification results after decryption or even after plaintext
+   processing.  Optimistic verification is beyond the scope of this
+   document.)
+
+   Update the rollover counter and highest sequence number, s_l, in the
+   cryptographic context, using the packet index estimated in Step 2.
+   If replay protection is provided, also update the Replay List (i.e.,
+   the Replay List is updated after the TESLA authentication is
+   successfully verified).
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 10]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+4.5.  SRTCP Packet Format
+
+   Figure 3 illustrates the format of the SRTCP packet when TESLA is
+   applied.  The TESLA authentication extension SHALL be inserted before
+   the MKI and authentication tag.  Recall from [RFC3711] that in SRTCP
+   the MKI is OPTIONAL, while the E-bit, the SRTCP index, and the
+   authentication tag are MANDATORY.  This means that the SRTP
+   (external) MAC is MANDATORY also when TESLA is used.
+
+   As in SRTP, the "Encrypted Portion" of an SRTCP packet consists of
+   the encryption of the RTCP payload of the equivalent compound RTCP
+   packet, from the first RTCP packet, i.e., from the ninth (9) byte to
+   the end of the compound packet.
+
+   The "Authenticated Portion" of an SRTCP packet consists of the entire
+   equivalent (eventually compound) RTCP packet, the E flag, the SRTCP
+   index (after any encryption has been applied to the payload), and the
+   TESLA extension.  Note that the definition is extended from [RFC3711]
+   by the inclusion of the TESLA authentication extension.
+
+   We define the "TESLA Authenticated Portion" of an SRTCP packet as
+   consisting of the RTCP header (first 8 bytes) and the Encrypted
+   Portion of the SRTCP packet.
+
+   Processing of an SRTCP packets is similar to the SRTP processing
+   (Section 4.3), but there are SRTCP-specific changes described in
+   Section 3.4 of the SRTP specification [RFC3711] and in Section 4.6 of
+   this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 11]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+<+
+  |V=2|P|    RC   |   PT=SR or RR   |             length          | | |
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+  |                         SSRC of sender                        | | |
++>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
+| ~                          sender info                          ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                         report block 1                        ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                         report block 2                        ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                              ...                              ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| |V=2|P|    SC   |  PT=SDES=202  |             length            | | |
+| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
+| |                          SSRC/CSRC_1                          | | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                           SDES items                          ~ | |
+| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
+| ~                              ...                              ~ | |
++>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | |
+| |E|                         SRTCP index                         | | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |
+| |                              i                                | | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                         Disclosed Key                         ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| ~                           TESLA MAC                           ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<|-+
+| ~                           SRTCP MKI                           ~ | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+| :                       authentication tag                      : | |
+| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+|                                                                   | |
++-- Encrypted Portion              TESLA Authenticated Portion -----+ |
+                                                                      |
+                                         Authenticated Portion -------+
+
+   Figure 3.  The format of the SRTCP packet when TESLA is applied.
+
+   Note that when additional fields are added to a packet, it will
+   increase the packet size and thus the RTCP average packet size.
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 12]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+4.6. TESLA MAC
+
+   Let M' denote packet data to be TESLA-authenticated.  In the case of
+   SRTP, M' SHALL consist of the SRTP TESLA Authenticated Portion (RTP
+   header and SRTP Encrypted Portion; see Figure 2) of the packet
+   concatenated with the rollover counter (ROC) of the same packet:
+
+   M' = ROC || TESLA Authenticated Portion.
+
+   In the case of SRTCP, M' SHALL consist of the SRTCP TESLA
+   Authenticated Portion only (RTCP header and SRTCP Encrypted Portion).
+
+   The normal authentication tag (OPTIONAL for SRTP, MANDATORY for
+   SRTCP) SHALL be applied with the same coverage as specified in
+   [RFC3711].  That is:
+
+   - for SRTP: Authenticated Portion || ROC (with the extended
+     definition of SRTP Authentication Portion as in Section 4.2).
+
+   - for SRTCP: Authenticated Portion (with the extended definition of
+     SRTCP Authentication Portion as in Section 4.2).
+
+   The predefined authentication transform in SRTP, HMAC-SHA1 [RFC2104],
+   is also used to generate the TESLA MAC.  For SRTP (and respectively
+   for SRTCP), the HMAC SHALL be applied to the key in the TESLA chain
+   corresponding to a particular time interval, and to M' as specified
+   above.  The HMAC output SHALL then be truncated to the n_m left-most
+   bits.  Default values are in Section 6.
+
+   As with SRTP, the predefined HMAC-SHA1 authentication algorithm MAY
+   be replaced with an alternative algorithm that is specified in a
+   future Internet RFC.
+
+4.7.  PRFs
+
+   TESLA requires a pseudo-random function (PRF) to implement
+
+   * one one-way function F(x) to derive the key chain, and
+   * one one-way function F'(x) to derive (from each key of the chain)
+     the key that is actually used to calculate the TESLA MAC.
+
+   When TESLA is used within SRTP, the default choice of the PRF SHALL
+   be HMAC-SHA1.  Default values are in Section 6.
+
+   Other PRFs can be chosen, and their use SHALL follow the common
+   guidelines in [RFC3711] when adding new security parameters.
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 13]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+5.  TESLA Bootstrapping and Cleanup
+
+   The extensions to the SRTP cryptographic context include a set of
+   TESLA parameters that are listed in Section 4.3 of this document.
+   Furthermore, TESLA MUST be bootstrapped at session setup (for the
+   parameter exchange and the initial key commitment) through a regular
+   data authentication system (a digital signature algorithm is
+   RECOMMENDED).  Key management procedures can take care of this
+   bootstrapping prior to the commencement of an SRTP session where
+   TESLA authentication is used.  The bootstrapping mechanism is out of
+   scope for this document (it could, for example, be part of the key
+   management protocol).
+
+   A critical factor for the security of TESLA is that the sender and
+   receiver need to be loosely synchronized.  TESLA requires a bound on
+   clock drift to be known (D_t).  Use of TESLA in SRTP assumes that the
+   time synchronization is guaranteed by out-of-band schemes (e.g., key
+   management).  That is, it is not in the scope of SRTP.
+
+   It also should be noted that TESLA has some reliability requirements
+   in that a key is disclosed for a packet in a subsequent packet, which
+   can get lost.  Since a key in a lost packet can be derived from a
+   future packet, TESLA is robust to packet loss.  This key stream
+   stops, however, when the key-bearing data stream packets stop at the
+   conclusion of the RTP session.  To avoid this nasty boundary
+   condition, send null packets with TESLA keys for one entire key-
+   disclosure period following the interval in which the stream ceases:
+   Null packets SHOULD be sent for d intervals of duration t_int (items
+   8 and 9 of Section 4.3).  The rate of null packets SHOULD be the
+   average rate of the session media stream.
+
+6.  SRTP TESLA Default Parameters
+
+   Key management procedures establish SRTP TESLA operating parameters,
+   which are listed in Section 4.3 of this document.  The operating
+   parameters appear in the SRTP cryptographic context and have the
+   default values that are described in this section.  In the future, an
+   Internet RFC MAY define alternative settings for SRTP TESLA that are
+   different than those specified here.  In particular, note that the
+   settings defined in this memo can have a large impact on bandwidth,
+   as they add 38 bytes to each packet (when the field length values are
+   the default ones).  For certain applications, this overhead may
+   represent more than a 50% increase in packet size.  Alternative
+   settings might seek to reduce the number and length of various TESLA
+   fields and outputs.  No such optimizations are considered in this
+   memo.
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 14]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+   It is RECOMMENDED that the SRTP MAC be truncated to 32 bits, since
+   the SRTP MAC provides only group authentication and serves only as
+   protection against external DoS.
+
+   The default values for the security parameters are listed in the
+   following table.
+
+   Parameter                        Mandatory-to-support     Default
+   ---------                        --------------------     -------
+   TESLA PRF                              HMAC-SHA1         HMAC-SHA1
+   BIT-OUTPUT LENGTH n_p                     160               160
+   BIT-OUTPUT LENGTH n_f                     160               160
+
+   TESLA MAC                              HMAC-SHA1         HMAC-SHA1
+    (TRUNCATED) BIT-OUTPUT LENGTH n_m         80                80
+
+   As shown above, TESLA implementations MUST support HMAC-SHA1
+   [RFC2104] for the TESLA MAC and the TESLA PRF.  The TESLA keychain
+   generator is recursively defined as follows [RFC4082].
+
+                    K_i=HMAC_SHA1(K_{i+1},0), i=0..N-1
+
+   where N-1=n_c from the cryptographic context.
+
+   The TESLA MAC key generator is defined as follows [RFC4082].
+
+                           K'_i=HMAC_SHA1(K_i,1)
+
+   The TESLA MAC uses a truncated output of ten bytes [RFC2104] and is
+   defined as follows.
+
+                            HMAC_SHA1(K'_i, M')
+
+   where M' is as specified in Section 4.6.
+
+7.  Security Considerations
+
+   Denial of Service (DoS) attacks on delayed authentication are
+   discussed in [PCST].  TESLA requires receiver buffering before
+   authentication; therefore, the receiver can suffer a denial of
+   service attack due to a flood of bogus packets.  To address this
+   problem, the external SRTP MAC, based on the group key, MAY be used
+   in addition to the TESLA MAC.  The short size of the SRTP MAC
+   (default 32 bits) is motivated because that MAC is purely for DoS
+   prevention from attackers external to the group.  The shorter output
+   tag means that an attacker has a better chance of getting a forged
+   packet accepted, which is about 2^31 attempts on average.  As a first
+   line of defense against a denial of service attack, a short tag is
+
+
+
+Baugher & Carrara           Standards Track                    [Page 15]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+   probably adequate; a victim will likely have ample evidence that it
+   is under attack before accepting a forged packet, which will
+   subsequently fail the TESLA check.  [RFC4082] describes other
+   mechanisms that can be used to prevent DoS, in place of the external
+   group-key MAC.  If used, they need to be added as processing steps
+   (following the guidelines of [RFC4082]).
+
+   The use of TESLA in SRTP defined in this specification is subject to
+   the security considerations discussed in the SRTP specification
+   [RFC3711] and in the TESLA specification [RFC4082].  In particular,
+   the TESLA security is dependent on the computation of the "safety
+   condition" as defined in Section 3.5 of [RFC4082].
+
+   SRTP TESLA depends on the effective security of the systems that
+   perform bootstrapping (time synchronization) and key management.
+   These systems are external to SRTP and are not considered in this
+   specification.
+
+   The length of the TESLA MAC is by default 80 bits.  RFC 2104 requires
+   the MAC length to be at least 80 bits and at least half the output
+   size of the underlying hash function.  The SHA-1 output size is 160
+   bits, so both of these requirements are met with the 80-bit MAC
+   specified in this document.  Note that IPsec implementations tend to
+   use 96 bits for their MAC values to align the header with a 64-bit
+   boundary.  Both MAC sizes are well beyond the reach of current
+   cryptanalytic techniques.
+
+8.  Acknowledgements
+
+   The authors would like to thank Ran Canetti, Karl Norrman, Mats
+   Naslund, Fredrik Lindholm, David McGrew, and Bob Briscoe for their
+   valuable help.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 16]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC4082]  Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
+              Briscoe, "Timed Efficient Stream Loss-Tolerant
+              Authentication (TESLA): Multicast Source Authentication
+              Transform Introduction", RFC 4082, June 2005.
+
+9.2.  Informative References
+
+   [PCST]     Perrig, A., Canetti, R., Song, D., Tygar, D., "Efficient
+              and Secure Source Authentication for Multicast", in Proc.
+              of Network and Distributed System Security Symposium NDSS
+              2001, pp. 35-46, 2001.
+
+   [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
+              Group Domain of Interpretation", RFC 3547, July 2003.
+
+   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
+              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
+              August 2004.
+
+   [RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
+              "Multicast Security (MSEC) Group Key Management
+              Architecture", RFC 4046, April 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 17]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+Authors' Addresses
+
+   Questions and comments should be directed to the authors and
+   msec@ietf.org.
+
+   Mark Baugher
+   Cisco Systems, Inc.
+   5510 SW Orchid Street
+   Portland, OR 97219 USA
+
+   Phone:  +1 408-853-4418
+   EMail:  mbaugher@cisco.com
+
+
+   Elisabetta Carrara
+   Royal Institute of Technology
+   Stockholm
+   Sweden
+
+   EMail:  carrara@kth.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 18]
+
+RFC 4383                       TESLA-SRTP                  February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Baugher & Carrara           Standards Track                    [Page 19]
+