rfc3711.txt

mediastreamer2是开源的网络传输媒体流的库

Network Working Group                                         M. Baugher
Request for Comments: 3711                                     D. McGrew
Category: Standards Track                            Cisco Systems, Inc.
                                                              M. Naslund
                                                              E. Carrara
                                                              K. Norrman
                                                       Ericsson Research
                                                              March 2004


             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 (2004).  All Rights Reserved.

Abstract

   This document describes the Secure Real-time Transport Protocol
   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
   can provide confidentiality, message authentication, and replay
   protection to the RTP traffic and to the control traffic for RTP, the
   Real-time Transport Control Protocol (RTCP).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Notational Conventions . . . . . . . . . . . . . . . . .  3
   2.  Goals and Features . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.  Features . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  SRTP Framework . . . . . . . . . . . . . . . . . . . . . . . .  5
       3.1.  Secure RTP . . . . . . . . . . . . . . . . . . . . . . .  6
       3.2.  SRTP Cryptographic Contexts. . . . . . . . . . . . . . .  7
             3.2.1.  Transform-independent parameters . . . . . . . .  8
             3.2.2.  Transform-dependent parameters . . . . . . . . . 10
             3.2.3.  Mapping SRTP Packets to Cryptographic Contexts . 10
       3.3.  SRTP Packet Processing . . . . . . . . . . . . . . . . . 11
             3.3.1.  Packet Index Determination, and ROC, s_l Update. 13
             3.3.2.  Replay Protection. . . . . . . . . . . . . . . . 15
      3.4.  Secure RTCP . . . . . . . . . . . . . . . . . . . . . . . 15



Baugher, et al.             Standards Track                     [Page 1]

RFC 3711                          SRTP                        March 2004


   4.  Pre-Defined Cryptographic Transforms . . . . . . . . . . . . . 19
       4.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . . 19
             4.1.1.  AES in Counter Mode. . . . . . . . . . . . . . . 21
             4.1.2.  AES in f8-mode . . . . . . . . . . . . . . . . . 22
             4.1.3.  NULL Cipher. . . . . . . . . . . . . . . . . . . 25
       4.2.  Message Authentication and Integrity . . . . . . . . . . 25
             4.2.1.  HMAC-SHA1. . . . . . . . . . . . . . . . . . . . 25
       4.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . . 26
             4.3.1.  Key Derivation Algorithm . . . . . . . . . . . . 26
             4.3.2.  SRTCP Key Derivation . . . . . . . . . . . . . . 28
             4.3.3.  AES-CM PRF . . . . . . . . . . . . . . . . . . . 28
   5.  Default and mandatory-to-implement Transforms. . . . . . . . . 28
       5.1.  Encryption: AES-CM and NULL. . . . . . . . . . . . . . . 29
       5.2.  Message Authentication/Integrity: HMAC-SHA1. . . . . . . 29
       5.3.  Key Derivation: AES-CM PRF . . . . . . . . . . . . . . . 29
   6.  Adding SRTP Transforms . . . . . . . . . . . . . . . . . . . . 29
   7.  Rationale. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
       7.1.  Key derivation . . . . . . . . . . . . . . . . . . . . . 30
       7.2.  Salting key. . . . . . . . . . . . . . . . . . . . . . . 30
       7.3.  Message Integrity from Universal Hashing . . . . . . . . 31
       7.4.  Data Origin Authentication Considerations. . . . . . . . 31
       7.5.  Short and Zero-length Message Authentication . . . . . . 32
   8.  Key Management Considerations. . . . . . . . . . . . . . . . . 33
       8.1.  Re-keying  . . . . . . . . . . . . . . . . . . . . . . . 34
             8.1.1.  Use of the <From, To> for re-keying. . . . . . . 34
       8.2.  Key Management parameters. . . . . . . . . . . . . . . . 35
   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 37
       9.1.  SSRC collision and two-time pad. . . . . . . . . . . . . 37
       9.2.  Key Usage. . . . . . . . . . . . . . . . . . . . . . . . 38
       9.3.  Confidentiality of the RTP Payload . . . . . . . . . . . 39
       9.4.  Confidentiality of the RTP Header. . . . . . . . . . . . 40
       9.5.  Integrity of the RTP payload and header. . . . . . . . . 40
             9.5.1. Risks of Weak or Null Message Authentication. . . 42
             9.5.2.  Implicit Header Authentication . . . . . . . . . 43
   10.  Interaction with Forward Error Correction mechanisms. . . . . 43
   11.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 43
       11.1. Unicast. . . . . . . . . . . . . . . . . . . . . . . . . 43
       11.2. Multicast (one sender) . . . . . . . . . . . . . . . . . 44
       11.3. Re-keying and access control . . . . . . . . . . . . . . 45
       11.4. Summary of basic scenarios . . . . . . . . . . . . . . . 46
   12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 46
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
       14.1. Normative References . . . . . . . . . . . . . . . . . . 47
       14.2. Informative References . . . . . . . . . . . . . . . . . 48
   Appendix A: Pseudocode for Index Determination . . . . . . . . . . 51
   Appendix B: Test Vectors . . . . . . . . . . . . . . . . . . . . . 51
       B.1.  AES-f8 Test Vectors. . . . . . . . . . . . . . . . . . . 51



Baugher, et al.             Standards Track                     [Page 2]

RFC 3711                          SRTP                        March 2004


       B.2.  AES-CM Test Vectors. . . . . . . . . . . . . . . . . . . 52
       B.3.  Key Derivation Test Vectors. . . . . . . . . . . . . . . 53
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 56

1.  Introduction

   This document describes the Secure Real-time Transport Protocol
   (SRTP), a profile of the Real-time Transport Protocol (RTP), which
   can provide confidentiality, message authentication, and replay
   protection to the RTP traffic and to the control traffic for RTP,
   RTCP (the Real-time Transport Control Protocol) [RFC3350].

   SRTP provides a framework for encryption and message authentication
   of RTP and RTCP streams (Section 3).  SRTP defines a set of default
   cryptographic transforms (Sections 4 and 5), and it allows new
   transforms to be introduced in the future (Section 6).  With
   appropriate key management (Sections 7 and 8), SRTP is secure
   (Sections 9) for unicast and multicast RTP applications (Section 11).

   SRTP can achieve high throughput and low packet expansion.  SRTP
   proves to be a suitable protection for heterogeneous environments
   (mix of wired and wireless networks).  To get such features, default
   transforms are described, based on an additive stream cipher for
   encryption, a keyed-hash based function for message authentication,
   and an "implicit" index for sequencing/synchronization based on the
   RTP sequence number for SRTP and an index number for Secure RTCP
   (SRTCP).

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].  The
   terminology conforms to [RFC2828] with the following exception.  For
   simplicity we use the term "random" throughout the document to denote
   randomly or pseudo-randomly generated values.  Large amounts of
   random bits may be difficult to obtain, and for the security of SRTP,
   pseudo-randomness is sufficient [RFC1750].

   By convention, the adopted representation is the network byte order,
   i.e., the left most bit (octet) is the most significant one.  By XOR
   we mean bitwise addition modulo 2 of binary strings, and || denotes
   concatenation.  In other words, if C = A || B, then the most
   significant bits of C are the bits of A, and the least significant
   bits of C equal the bits of B.  Hexadecimal numbers are prefixed by
   0x.




Baugher, et al.             Standards Track                     [Page 3]

RFC 3711                          SRTP                        March 2004


   The word "encryption" includes also use of the NULL algorithm (which
   in practice does leave the data in the clear).

   With slight abuse of notation, we use the terms "message
   authentication" and "authentication tag" as is common practice, even
   though in some circumstances, e.g., group communication, the service
   provided is actually only integrity protection and not data origin
   authentication.

2.  Goals and Features

   The security goals for SRTP are to ensure:

   *  the confidentiality of the RTP and RTCP payloads, and

   *  the integrity of the entire RTP and RTCP packets, together with
      protection against replayed packets.

   These security services are optional and independent from each other,
   except that SRTCP integrity protection is mandatory (malicious or
   erroneous alteration of RTCP messages could otherwise disrupt the
   processing of the RTP stream).

   Other, functional, goals for the protocol are:

   *  a framework that permits upgrading with new cryptographic
      transforms,

   *  low bandwidth cost, i.e., a framework preserving RTP header
      compression efficiency,

   and, asserted by the pre-defined transforms:

   *  a low computational cost,

   *  a small footprint (i.e., small code size and data memory for
      keying information and replay lists),

   *  limited packet expansion to support the bandwidth economy goal,

   *  independence from the underlying transport, network, and physical
      layers used by RTP, in particular high tolerance to packet loss
      and re-ordering.

   These properties ensure that SRTP is a suitable protection scheme for
   RTP/RTCP in both wired and wireless scenarios.





Baugher, et al.             Standards Track                     [Page 4]

RFC 3711                          SRTP                        March 2004


2.1.  Features

   Besides the above mentioned direct goals, SRTP provides for some
   additional features.  They have been introduced to lighten the burden
   on key management and to further increase security.  They include:

   *  A single "master key" can provide keying material for
      confidentiality and integrity protection, both for the SRTP stream
      and the corresponding SRTCP stream.  This is achieved with a key
      derivation function (see Section 4.3), providing "session keys"
      for the respective security primitive, securely derived from the
      master key.

   *  In addition, the key derivation can be configured to periodically
      refresh the session keys, which limits the amount of ciphertext
      produced by a fixed key, available for an adversary to
      cryptanalyze.

   *  "Salting keys" are used to protect against pre-computation and
      time-memory tradeoff attacks [MF00] [BS00].

   Detailed rationale for these features can be found in Section 7.

3.  SRTP Framework

   RTP is the Real-time Transport Protocol [RFC3550].  We define SRTP as
   a profile of RTP.  This profile is an extension to the RTP
   Audio/Video Profile [RFC3551].  Except where explicitly noted, all
   aspects of that profile apply, with the addition of the SRTP security
   features.  Conceptually, we consider SRTP to be a "bump in the stack"
   implementation which resides between the RTP application and the
   transport layer.  SRTP intercepts RTP packets and then forwards an
   equivalent SRTP packet on the sending side, and intercepts SRTP
   packets and passes an equivalent RTP packet up the stack on the
   receiving side.

   Secure RTCP (SRTCP) provides the same security services to RTCP as
   SRTP does to RTP.  SRTCP message authentication is MANDATORY and
   thereby protects the RTCP fields to keep track of membership, provide
   feedback to RTP senders, or maintain packet sequence counters.  SRTCP
   is described in Section 3.4.










Baugher, et al.             Standards Track                     [Page 5]

RFC 3711                          SRTP                        March 2004


3.1.  Secure RTP

      The format of an SRTP packet is illustrated in Figure 1.

        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                           | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |