Guidelines for the Use of Variable Bit Rate Audio with Secure RTP
RFC 6562
|
| Document |
Type |
|
RFC - Proposed Standard
(March 2012; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Replaces |
|
draft-perkins-avt-srtp-vbr-audio
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
Submitted to IESG for Publication
Other - see Comment Log
|
|
Document shepherd |
|
Magnus Westerlund
|
|
Shepherd write-up |
|
Show
(last changed 2011-09-30)
|
| IESG |
IESG state |
|
RFC 6562 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Robert Sparks
|
|
IESG note |
|
Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd.
|
|
Send notices to |
|
(None)
|
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 6562 University of Glasgow
Category: Standards Track JM. Valin
ISSN: 2070-1721 Mozilla Corporation
March 2012
Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP
Abstract
This memo discusses potential security issues that arise when using
variable bit rate (VBR) audio with the secure RTP profile.
Guidelines to mitigate these issues are suggested.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6562.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Perkins & Valin Standards Track [Page 1]
RFC 6562 VBR Audio with SRTP March 2012
Table of Contents
1. Introduction ...................................................2
2. Scenario-Dependent Risk ........................................2
3. Guidelines for Use of VBR Audio with SRTP ......................3
4. Guidelines for Use of Voice Activity Detection with SRTP .......3
5. Padding the Output of VBR Codecs ...............................4
6. Security Considerations ........................................5
7. Acknowledgements ...............................................5
8. References .....................................................5
8.1. Normative References ......................................5
8.2. Informative References ....................................6
1. Introduction
The Secure RTP (SRTP) framework [RFC3711] is a widely used framework
for securing RTP sessions [RFC3550]. SRTP provides the ability to
encrypt the payload of an RTP packet, and optionally add an
authentication tag, while leaving the RTP header and any header
extension in the clear. A range of encryption transforms can be used
with SRTP, but none of the predefined encryption transforms use any
padding; the RTP and SRTP payload sizes match exactly.
When using SRTP with voice streams compressed using variable bit rate
(VBR) codecs, the length of the compressed packets will depend on the
characteristics of the speech signal. This variation in packet size
will leak a small amount of information about the contents of the
speech signal. This is potentially a security risk for some
applications. For example, [spot-me] shows that known phrases in an
encrypted call using the Speex codec in VBR mode can be recognized
with high accuracy in certain circumstances, and [fon-iks] shows that
approximate transcripts of encrypted VBR calls can be derived for
some codecs without breaking the encryption. How significant these
results are, and how they generalize to other codecs, is still an
open question. This memo discusses ways in which such traffic
analysis risks may be mitigated.
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 RFC 2119 [RFC2119].
2. Scenario-Dependent Risk
Whether the information leaks and attacks discussed in [spot-me],
[fon-iks], and similar works are significant is highly dependent on
the application and use scenario. In the worst case, using the rate
information to recognize a prerecorded message knowing the set of all
Show full document text