Skip to main content

Using Authenticated Encryption with Replay prOtection (AERO) in SRTP
draft-mcgrew-srtp-aero-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors David McGrew , Dan Wing , John Foley
Last updated 2013-10-21
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mcgrew-srtp-aero-00
AVT Working Group                                              D. McGrew
Internet-Draft                                                   D. Wing
Intended status: Standards Track                                   Cisco
Expires: April 24, 2014                                         J. Foley
                                                           Cisco Systems
                                                        October 21, 2013

  Using Authenticated Encryption with Replay prOtection (AERO) in SRTP
                       draft-mcgrew-srtp-aero-00

Abstract

   Authenticated Encryption with Replay prOtection (AERO) is a
   cryptographic technique that provides all of the security services
   that are used in the Secure Real-time Transport Protocol (SRTP).
   This note describes how to use AERO in SRTP.  AERO has minimal data
   expansion, avoids the need to manage implicit state, and provides
   strong misuse resistance.  These properties make it an ideal
   cryptographic transform for SRTP, as it enables SRTP to easily handle
   multiple senders sharing the same key, multiple receivers with late-
   joiners in a session, decentralized conferences with minimal control,
   and mixers that selectively forward RTP traffic.  RTP architectures
   that utilize AERO can use the normal SSRC collision detection
   mechanism, and can ignore problematic SRTP artifacts such as the
   Roll-Over Counter (ROC) and Initial Sequence Number.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 24, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

McGrew, et al.           Expires April 24, 2014                 [Page 1]
Internet-Draft                  AERO SRTP                   October 2013

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used In This Document  . . . . . . . . . . . .  3
     1.2.  History  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  SRTP AERO  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Decryption . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Contexts . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Secure RTCP  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Decryption . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  SRTP crypto suites . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  AERO_AES_128_XCB_80  . . . . . . . . . . . . . . . . . . . 10
     4.2.  AERO_AES_128_XCB_32  . . . . . . . . . . . . . . . . . . . 10
     4.3.  AERO_AES_256_XCB_128 . . . . . . . . . . . . . . . . . . . 11
   5.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Comparison to other approaches . . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     6.1.  SSRC collisions  . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Key scope  . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

McGrew, et al.           Expires April 24, 2014                 [Page 2]
Internet-Draft                  AERO SRTP                   October 2013

1.  Introduction

   RTP is designed to allow decentralized groups with minimal control to
   establish sessions, such as for multimedia conferences.
   Unfortunately, Secure RTP (SRTP [RFC3711]) cannot be used in many
   minimal-control scenarios, because it requires that SSRC values and
   other data be coordinated among all of the participants in a session.
   For example, if a participant joins a session that is already in
   progress, the SRTP Roll-Over Counter (ROC) of each SRTP source in the
   session needs to be provided to that participant.

   The inability of SRTP to work in the absence of central control was
   well understood during the design of that protocol; that omission was
   considered less important than optimizations such as bandwidth
   conservation.  Additionally, in many situations SRTP is used in
   conjunction with a signaling system that can provide much of the
   central control needed by SRTP.  However, there are several cases in
   which conventional signaling systems cannot easily provide all of the
   coordination required.  It is also desirable to eliminate the layer
   violations that occur when signaling systems coordinate certain SRTP
   parameters, such as SSRC values and ROCs.

   These issues are due to the particular cryptographic techniques used
   in SRTP, specifically a partially-implicit sequence number that is
   utilized for counter mode encryption, for replay protection, and for
   determining when re-keying should occur.  Authenticated Encryption
   with Replay prOtection (AERO) [I-D.mcgrew-aero] is a cryptographic
   technique that provides confidentiality, authentication, and replay
   protection; it is a stateful and self-synchronizing authenticated
   encryption method.  It has minimal data expansion, avoids the need to
   manage implicit state, and provides strong misuse resistance.  This
   document defines how AERO can be used in SRTP as a replacement for
   the default transforms of [RFC3711] in a way that avoids all of the
   issues identified above.

   This document is organized as follows.  Packet processing and
   contexts are described in Section 2 and Section 3.  A rationale for
   the design is offered in Section 5.  Security Considerations are
   provided in Section 6, and IANA considerations are provided in
   Section 7.

1.1.  Conventions Used In This Document

   The key words "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].

McGrew, et al.           Expires April 24, 2014                 [Page 3]
Internet-Draft                  AERO SRTP                   October 2013

1.2.  History

   This section describes the evolution of this document as an Internet
   Draft, and it should be removed by the RFC Editor prior to
   publication as an RFC.

   This is the initial version of this note.  As it uses a cryptographic
   technique that was published recently, it may evolve over time as
   that technique is reviewed and experience is gained in its usage.
   Thus, while we encourage the implementation of the crypto suites
   specified in this note as the best way to obtain experience with
   their use in RTP architectures, we also expect that there may be
   changes to these crypto suites over time.

McGrew, et al.           Expires April 24, 2014                 [Page 4]
Internet-Draft                  AERO SRTP                   October 2013

2.  SRTP AERO

   The Secure Real-time Transport Protocol (SRTP) [RFC3711] is a profile
   of the Real-time Transport Protocol (RTP) that 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).  SRTP provides a framework for the
   encryption and message authentication of RTP and RTCP streams.
   Default cryptographic transforms are defined in [RFC3711], while the
   framework supports the addition of new cryptographic transforms.

   The note describes how to use Authenticated Encryption with Replay
   prOtection (AERO) [I-D.mcgrew-aero] in SRTP, which we refer to as
   SRTP-AERO.  All three security services - confidentiality, message
   authentication, and replay protection - are always provided with
   SRTP-AERO; none of those services is optional.  The SRTP framework
   includes provisions for separate encryption and authentication
   transforms; when AERO is used, it is considered an encryption
   transform and there MUST NOT be a separate authentication transform.

   This description mainly consists of how AERO encryption inputs and
   outputs are mapped to RTP and SRTP packets, respectively, how AERO
   decryption inputs and outputs are mapped to SRTP and RTP packets,
   respectively, and how the AERO context is stored in the SRTP context.
   A similar description is provided for SRTCP.  The security
   considerations are different from those in [RFC3711] (and are rather
   less stringent).

   With SRTP-AERO, the normal RTP SSRC collision detection and repair
   process can be followed.  This is in contrast to SRTP with the
   default transforms, which relies on external mechanisms to coordinate
   SSRC values.

   AERO is an Authenticated Encryption with Associated Data (AEAD)
   method, and thus SRTP-AERO processing is similar to that of
   [I-D.ietf-avtcore-srtp-aes-gcm].

2.1.  Encryption

   To protect an RTP packet using AERO, the inputs to the encryption
   operation are as follows:

      The associated data A is set to the RTP header, including the CSRC
      identifiers (if present), and the RTP header extension (if
      present).  (In Figure 1 of [RFC3711], this consists of the part of
      the Authenticated Portion of the packet that does not overlap with
      the Encrypted Portion.)

McGrew, et al.           Expires April 24, 2014                 [Page 5]
Internet-Draft                  AERO SRTP                   October 2013

      The plaintext is set to the RTP payload, RTP padding, and RTP pad
      count.  (In Figure 1 of [RFC3711], this is the Encrypted Portion.)

      The secret key K is set to the AERO key in the SRTP context.

   The ciphertext returned by that operation replaces the plaintext in
   the RTP packet.  Note that the ciphertext will be longer than the
   plaintext.

   AERO does not include a separate authentication tag, and thus this
   field is omitted from the SRTP packet; it MUST NOT be present.  This
   omission simplifies this specification (see Section 5).

   A Master Key Indicator (MKI) field MAY be present after the
   ciphertext; this field is optional in [RFC3711] and its usage is
   unchanged by this specification.

2.2.  Decryption

   To decrypt an SRTP packet using AERO, the inputs to the decryption
   operation are as follows:

      The associated data A is set as in SRTP encryption Section 2.1.

      The ciphertext C is set as follows.  It starts and the end of the
      RTP header extension, if that field is present.  If it is not,
      then it starts at the end of the last CSRC identifier, if any CSRC
      identifiers are present.  Otherwise, it starts at the end of the
      SSRC identifier.  If an MKI is in use, then the ciphertext ends at
      the start of the MKI.  Otherwise, the ciphertext ends at the end
      of the RTP packet.

      The secret key K is set to the AERO key in the SRTP context.

   If the decryption operation returns the symbol FAIL, then the SRTP
   packet is either a forgery attempt or a replay, and the packet MUST
   be discarded from further processing and the event MAY be logged.
   Otherwise, an RTP packet is formed from the SRTP packet and the
   plaintext returned by the decryption operation, by replacing the
   ciphertext with the plaintext, and discarding the MKI field if one is
   present.

   Steps 2 and the replay checking in Step 5 of the decryption
   processing in Section 3.4 of [RFC3711] SHOULD NOT be performed, since
   it is unnecessary.  The SRTP packet index used in Step 3 to determine
   the master key and salt SHOULD be set to the sequence number returned
   by the AERO decryption operation.

McGrew, et al.           Expires April 24, 2014                 [Page 6]
Internet-Draft                  AERO SRTP                   October 2013

2.3.  Contexts

   The AERO context is stored in the transform-dependent parameters of
   the SRTP context, as the SRTP encryption transform.  That is, the
   identifier for the encryption algorithm describes the particular AERO
   algorithm that is in use.

   When AERO is used, an SRTP implementation MAY omit the following
   transform-independent parameters:

      the ROC,

      the replay list maintained by an SRTP/SRTCP receiver, and

      the identifier for the message authentication algorithm.

   The ROC and replay list are not needed because AERO provides replay
   protection, and the message authentication algorithm identifier is
   not needed because AERO provides that security service.

McGrew, et al.           Expires April 24, 2014                 [Page 7]
Internet-Draft                  AERO SRTP                   October 2013

3.  Secure RTCP

   The use of AERO in SRTCP follows that in SRTP.

3.1.  Encryption

   To protect an RTCP packet using AERO, the inputs to the encryption
   operation are as follows:

      The associated data A is set to the RTCP header, including all of
      the fields starting with the Version and up to and including the
      SSRC of the sender.

      The plaintext is set to the remaining part of the RTCP packet.

      The secret key K is set to the AERO key in the SRTCP context.

   The ciphertext returned by that operation replaces the plaintext in
   the RTCP packet.  Note that the ciphertext will be longer than the
   plaintext.

   AERO does not include a separate authentication tag, and thus this
   field is omitted from the SRTCP packet; it MUST NOT be present (see
   Section 5 for the rationale).

   A Master Key Indicator (MKI) field MAY be present after the
   ciphertext; this field is optional in [RFC3711] and its usage is
   unchanged by this specification.

   The "E" flag and the SRTCP index MUST NOT be included in the SRTCP
   packet.

3.2.  Decryption

   To decrypt an SRTCP packet using AERO, the inputs to the decryption
   operation are as follows:

      The associated data A is set as in SRTCP encryption Section 2.1.

      The ciphertext C consists of all of the data after the associated
      data, to the end of the packet.

      The secret key K is set to the AERO key in the SRTCP context.

   If the decryption operation returns the symbol FAIL, then the SRTCP
   packet is either a forgery attempt or a replay, and the packet MUST
   be discarded from further processing and the event MAY be logged.
   Otherwise, an RTCP packet is formed from the SRTCP packet and the

McGrew, et al.           Expires April 24, 2014                 [Page 8]
Internet-Draft                  AERO SRTP                   October 2013

   plaintext returned by the decryption operation, by replacing the
   ciphertext with the plaintext, and discarding the MKI field if one is
   present.

McGrew, et al.           Expires April 24, 2014                 [Page 9]
Internet-Draft                  AERO SRTP                   October 2013

4.  SRTP crypto suites

   This section defines some crypto suites for use in SRTP, which can be
   signaled by SDP Security Descriptions [RFC4568] or MIKEY [RFC3830].
   The use of these crypto suites in SDP Security Descriptions is
   straightforward; the particular crypto suite to be used is specified
   by the "crypto-suite" parameter.  For MIKEY, the use of a particular
   crypto suite is specified by both the MIKEY "encryption algorithm"
   parameter and the "session encryption key length" parameter, as noted
   below.

4.1.  AERO_AES_128_XCB_80

   The AERO_AES_128_XCB_80 crypto suite uses the AERO_AES_128_XCB
   algorithm defined in [I-D.mcgrew-aero], with a sequence number length
   T of 72 bits.  It provides authentication strength equivalent to an
   ideal message authentication code with a 70-bit tag.  The data
   expansion is 80 bits; the ciphertext will be at most 80 bits longer
   than the plaintext.  The master-key length is 128 bits and has a
   default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP
   packets, whichever comes first (see page 39 [RFC3711]).

   The SRTP and SRTCP encryption key lengths are 128 bits.  The master
   salt value is 112 bits in length and the session salt value is 112
   bits in length.  The pseudo-random function (PRF) is the default SRTP
   pseudo-random function that uses AES Counter Mode with a 128-bit key
   length.

   The length of the base64-decoded key and salt value for this crypto
   suite MUST be 30 characters (i.e., 240 bits); otherwise, the crypto
   attribute is considered invalid.

   To signal the use of AERO_AES_128_XCB_80 with MIKEY, the following
   MIKEY SRTP Policy Parameters MUST be used:

      An encryption algorithm parameter of TBD Section 7

      A session encryption key length of 128 bits.

      An authentication tag length of 80 bits.

4.2.  AERO_AES_128_XCB_32

   This crypto suite is identical to AERO_AES_128_XCB_80, except that it
   uses a sequence number length T of 24 bits.  Its authentication
   strength is about 24 bits, and its data overhead is at most 32 bits.

   To signal the use of AERO_AES_128_XCB_32 with MIKEY, the following

McGrew, et al.           Expires April 24, 2014                [Page 10]
Internet-Draft                  AERO SRTP                   October 2013

   MIKEY SRTP Policy Parameters MUST be used:

      An encryption algorithm parameter of TBD Section 7

      A session encryption key length of 128 bits.

      An authentication tag length of 32 bits.

4.3.  AERO_AES_256_XCB_128

   The AERO_AES_256_XCB_128 crypto suite uses the AERO_AES_256_XCB
   algorithm defined in [I-D.mcgrew-aero], with a sequence number length
   T of 128 bits.  It provides authentication strength equivalent to an
   ideal message authentication code with a 121-bit tag.  The data
   expansion is 128 bits; the ciphertext will be exactly 128 bits longer
   than the plaintext.  The master-key length is 128 bits and has a
   default lifetime of a maximum of 2^48 SRTP packets or 2^31 SRTCP
   packets, whichever comes first (see page 39 [RFC3711]).

   The SRTP and SRTCP encryption key lengths are 256 bits.  The master
   salt value is 112 bits in length and the session salt value is 112
   bits in length.  The pseudo-random function (PRF) is the
   AES_256_CM_PRF key derivation function [RFC6188] which uses AES
   Counter Mode with a 256-bit key length.

   The length of the base64-decoded key and salt value for this crypto
   suite MUST be 46 characters (i.e., 368 bits); otherwise, the crypto
   attribute is considered invalid.

   To signal the use of AERO_AES_128_XCB_80 with MIKEY, the following
   MIKEY SRTP Policy Parameters MUST be used:

      An encryption algorithm parameter of TBD Section 7

      A session encryption key length of 256 bits.

      An authentication tag length of 128 bits.

McGrew, et al.           Expires April 24, 2014                [Page 11]
Internet-Draft                  AERO SRTP                   October 2013

5.  Rationale

   There is no need to allow the SRTP or SRTCP Authentication Tag fields
   to be present, and thus it is forbidden instead of being optional.
   Compatibility with [RFC4771], which uses this field as a means of
   conveying the Roll-Over Counter (ROC), is not needed because AERO
   removes any need for the ROC.  Omitting this field simplifies
   implementations and avoids confusion.

   The SSRC field serves as a Sender Identifier, and meets the
   requirements described in Section 3.5 of [I-D.mcgrew-aero].

5.1.  Comparison to other approaches

   There are other approaches that have been used to address the issues
   identified in Section 1.  In this section, we compare them to SRTP
   AERO.

   With the SRTP Integrity Transform Carrying Roll-Over Counter
   [RFC4771], the sender periodically includes the ROC in the SRTP
   authentication tag, in which case the authentication process is
   altered so that the ROC is authenticated.  This approach addresses
   synchronization issues that are due to multiple receivers, such as
   the problem of "late joiners" in a session.  However, it does not
   address any of the issues that are due to multiple senders using the
   same encryption key.  It also does not change the need for misuse
   resistance.

   With SRTP Encrypted Key Transport (EKT) [SRTP-EKT], the sender
   periodically includes additional data about the session in its
   outbound packets.  This data includes the value of the master key
   being used for that SRTP source, encrypted under a master key that is
   used for all sources in the session.  EKT address the issues that
   arise in multiple-sender sessions by providing a way that each source
   can use a distinct master key.  EKT also includes the initial RTP
   sequence number, to aid receivers in establishing the appropriate
   SRTP packet index for the first packet in a session.  EKT is more
   complex than SRTP-AERO, as it requires a separate authenticated
   encryption method for protecting the data that is conveyed, and it
   adds complexities to the packet processing rules.  It also adds data
   overhead to SRTP and SRTCP packets in a way that is non-uniform, with
   some packets growing by a single byte, and others growing by over 24
   bytes.  In contrast, SRTP-AERO has data overhead that is constant,
   and need not be greater than a single byte at equivalent security
   levels.

McGrew, et al.           Expires April 24, 2014                [Page 12]
Internet-Draft                  AERO SRTP                   October 2013

6.  Security Considerations

6.1.  SSRC collisions

   With SRTP-AERO, SSRC collisions do not undermine security; instead,
   there is a limited and quantifiable loss of confidentiality, which is
   described in Section 11.4 of [I-D.mcgrew-aero].  In essence, if there
   is an SSRC collision between two senders, then the attacker will be
   able to detect the event that both senders encrypt two distinct
   packets that happen to have exactly the same plaintext and associated
   data values.  Even if an SSRC collision occurs, it is unlikely that
   the RTP sequence number, the RTP timestamp, and the plaintexts will
   all be identical.  Thus, in many setting the unpredictability of the
   RTP header and payload provide additional protection even in the
   unlikely occurrence of an SSRC collision.

   An SSRC collision will not undermine authentication.

   The normal RTP mechanism for detection and correction of SSRC
   collisions MUST be used.  In practice, if an SRTP or SRTCP sender
   receives a valid SRTP or SRTCP packet that it did not itself
   originate, which has an SSRC value equal to its own, then it MUST
   stop using that SSRC value, and select a new SSRC value at random.  A
   packet is valid only if its AERO decryption does not return FAIL.

6.2.  Key scope

   With SRTP-AERO, a single master key MAY be used with multiple SRTP
   sources or multiple SRTP receivers within a single session.
   Scenarios in which there may be multiple sources in a single session
   include multicast SRTP, as well as an RTP mixer that retransmits
   packets from one selected source to an entire set of sources.  In
   this latter case, a set of participants in a session can all use a
   single SRTP master key, and a mixer can selectively retransmit
   packets, e.g. from the "loudest talker", without re-encrypting the
   packets.

   A single master key MUST NOT be used across distinct SRTP sessions.
   This property is not specific to AERO, but instead is general to all
   uses of SRTP, and it follows from the fact that RTP and RTCP
   receivers have no way of distinguishing between the packets from one
   session and those from another.  This fact would allow an attacker to
   substitute packets from one session to another, if both sessions were
   using the same master key.

McGrew, et al.           Expires April 24, 2014                [Page 13]
Internet-Draft                  AERO SRTP                   October 2013

7.  IANA Considerations

   This section registers with IANA the following SRTP crypto-suite
   parameters for SDP Security Descriptions [RFC4568]:

   o  SRTP_AERO_128_XCB_80

   o  SRTP_AERO_128_XCB_32

   o  SRTP_AERO_256_XCB_128

   They are specified in Section 4 of this note.

   We also request the following IANA assignment from the MIKEY registry
   of SRTP policy parameters:

   o  An Encryption Algorithm parameter value of TBD.

   This value indicates the use AERO_AES_XCB in SRTP, and corresponds to
   either SRTP_AERO_128_XCB_80, SRTP_AERO_128_XCB_32, and
   SRTP_AERO_256_XCB_128.

McGrew, et al.           Expires April 24, 2014                [Page 14]
Internet-Draft                  AERO SRTP                   October 2013

8.  References

8.1.  Normative References

   [I-D.ietf-avtcore-srtp-aes-gcm]
              McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
              Encryption in Secure RTP (SRTP)",
              draft-ietf-avtcore-srtp-aes-gcm-10 (work in progress),
              September 2013.

   [I-D.mcgrew-aero]
              McGrew, D. and J. Foley, "Authenticated Encryption with
              Replay prOtection (AERO)", draft-mcgrew-aero-00 (work in
              progress), October 2013.

   [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.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [RFC4771]  Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity
              Transform Carrying Roll-Over Counter for the Secure Real-
              time Transport Protocol (SRTP)", RFC 4771, January 2007.

   [RFC6188]  McGrew, D., "The Use of AES-192 and AES-256 in Secure
              RTP", RFC 6188, March 2011.

8.2.  Informative References

   [SRTP-EKT]
              McGrew, D., Andreason, F., Wing, D., and K. Fisher,
              "Encrypted Key Transport for Secure RTP", Internet Draft;
              Work In Progress. <draft-ietf-avtcore-srtp-ekt-00.txt>.

McGrew, et al.           Expires April 24, 2014                [Page 15]
Internet-Draft                  AERO SRTP                   October 2013

Authors' Addresses

   David A. McGrew
   Cisco Systems, Inc.
   510 McCarthy Blvd.
   Milpitas, CA  95035
   US

   Phone: (408) 525 8651
   Email: mcgrew@cisco.com
   URI:   http://www.mindspring.com/~dmcgrew/dam.htm

   Dan Wing
   Cisco Systems, Inc.
   510 McCarthy Blvd.
   Milpitas, CA  95035
   US

   Phone: (408) 853 4197
   Email: dwing@cisco.com

   John Foley
   Cisco Systems
   7025-2 Kit Creek Road
   Research Triangle Park, NC  14987
   US

   Email: foleyj@cisco.com

McGrew, et al.           Expires April 24, 2014                [Page 16]