draft-perkins-avt-srtp-vbr-audio-04.txt | draft-perkins-avt-srtp-vbr-audio-05.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: BCP JM. Valin | Intended status: BCP JM. Valin | |||
Expires: January 10, 2011 Octasic Inc. | Expires: June 15, 2011 Octasic Inc. | |||
July 9, 2010 | December 12, 2010 | |||
Guidelines for the use of Variable Bit Rate Audio with Secure RTP | Guidelines for the use of Variable Bit Rate Audio with Secure RTP | |||
draft-perkins-avt-srtp-vbr-audio-04.txt | draft-perkins-avt-srtp-vbr-audio-05.txt | |||
Abstract | Abstract | |||
This memo discusses potential security issues that arise when using | This memo discusses potential security issues that arise when using | |||
variable bit rate audio with the secure RTP profile. Guidelines to | variable bit rate audio with the secure RTP profile. Guidelines to | |||
mitigate these issues are suggested. | mitigate these issues are suggested. | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 10, 2011. | This Internet-Draft will expire on June 15, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 13 ¶ | skipping to change at page 2, line 13 ¶ | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Scenario-Dependent Risk . . . . . . . . . . . . . . . . . . . . 3 | 2. Scenario-Dependent Risk . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Guidelines for use of VBR Audio with SRTP . . . . . . . . . . . 4 | 3. Guidelines for use of VBR Audio with SRTP . . . . . . . . . . . 4 | |||
4. Guidelines for use of Voice Activity Detection with SRTP . . . 4 | 4. Guidelines for use of Voice Activity Detection with SRTP . . . 4 | |||
5. Padding the output of VBR codecs . . . . . . . . . . . . . . . 5 | 5. Padding the output of VBR codecs . . . . . . . . . . . . . . . 5 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 6 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1. Introduction | 1. Introduction | |||
The secure RTP framework (SRTP) [RFC3711] is a widely used framework | The secure RTP framework (SRTP) [RFC3711] is a widely used framework | |||
for securing RTP sessions. SRTP provides the ability to encrypt the | for securing RTP sessions. SRTP provides the ability to encrypt the | |||
skipping to change at page 4, line 13 ¶ | skipping to change at page 4, line 13 ¶ | |||
related information, such as the fact that the source and destination | related information, such as the fact that the source and destination | |||
IP addresses are available. | IP addresses are available. | |||
3. Guidelines for use of VBR Audio with SRTP | 3. Guidelines for use of VBR Audio with SRTP | |||
It is the responsibility of the application designer to determine the | It is the responsibility of the application designer to determine the | |||
appropriate trade-off between security and bandwidth overhead. As a | appropriate trade-off between security and bandwidth overhead. As a | |||
general rule, VBR codecs should be considered safe in the context of | general rule, VBR codecs should be considered safe in the context of | |||
encrypted one-to-one calls. However, applications that make use of | encrypted one-to-one calls. However, applications that make use of | |||
pre-recorded messages where the contents of such pre-recorded | pre-recorded messages where the contents of such pre-recorded | |||
messages may be of any value to an evesdropper (i.e. messages beyond | messages may be of any value to an evesdropper (i.e., messages beyond | |||
standard greeting messages) SHOULD NOT use codecs in VBR mode. IVR | standard greeting messages) SHOULD NOT use codecs in VBR mode. IVR | |||
applications would be particularly vulnerable since an evesdropper | applications would be particularly vulnerable since an evesdropper | |||
could easily use the rate information to easily recognize the prompts | could easily use the rate information to easily recognize the prompts | |||
being played out. | being played out. | |||
It is safe to use variable rate coding to adapt the output of a voice | It is safe to use variable rate coding to adapt the output of a voice | |||
codec to match characteristics of a network channel, for example for | codec to match characteristics of a network channel, for example for | |||
congestion control purposes, provided this adaptation done in a way | congestion control purposes, provided this adaptation done in a way | |||
that does not expose any information on the speech signal. That is, | that does not expose any information on the speech signal. That is, | |||
if the variation is driven by the available network bandwidth, not by | if the variation is driven by the available network bandwidth, not by | |||
the input speech (i.e. if the packet sizes and spacing are constant | the input speech (i.e., if the packet sizes and spacing are constant | |||
unless the network conditions change). VBR speech codecs can safely | unless the network conditions change). VBR speech codecs can safely | |||
be used in this fashion with SRTP while avoiding leaking information | be used in this fashion with SRTP while avoiding leaking information | |||
on the contents of the speech signal that might be useful for traffic | on the contents of the speech signal that might be useful for traffic | |||
analysis. | analysis. | |||
4. Guidelines for use of Voice Activity Detection with SRTP | 4. Guidelines for use of Voice Activity Detection with SRTP | |||
Many speech codecs employ some form of voice activity detection (VAD) | Many speech codecs employ some form of voice activity detection (VAD) | |||
to either suppress output frames, or generate some form of lower-rate | to either suppress output frames, or generate some form of lower-rate | |||
comfort noise frames, during periods when the speaker is not active. | comfort noise frames, during periods when the speaker is not active. | |||
skipping to change at page 5, line 10 ¶ | skipping to change at page 5, line 10 ¶ | |||
overhang applied to each talkspurt must be randomly chosen in such a | overhang applied to each talkspurt must be randomly chosen in such a | |||
way that it is computationally infeasible for an attacker to reliably | way that it is computationally infeasible for an attacker to reliably | |||
estimate the length of that talkspurt. The audio data comprising the | estimate the length of that talkspurt. The audio data comprising the | |||
overhang period must be packetised and transmitted in RTP packets in | overhang period must be packetised and transmitted in RTP packets in | |||
a manner that is indistinguishable from the other data in the | a manner that is indistinguishable from the other data in the | |||
talkspurt. | talkspurt. | |||
The overhang period SHOULD have an exponentially-decreasing | The overhang period SHOULD have an exponentially-decreasing | |||
probability distribution function. This ensures a long tail, while | probability distribution function. This ensures a long tail, while | |||
being easy to compute. It is RECOMMENDED to use an overhang with a | being easy to compute. It is RECOMMENDED to use an overhang with a | |||
"half life" of at least 1 second. Despite the overhang (and no | "half life" of a few hundred milliseconds (this should be sufficient | |||
matter what the duration is), there is still a small amount of | to obscure the presence of inter-word pauses and the lengths of | |||
information leaked about the start time of the talkspurt due to the | single words spoken in isolation, for example the digits of a credit | |||
fact that we cannot apply an overhang to the start of a talkspurt | card number clearly enunciated for an automated system, but not so | |||
without unacceptably affecting intelligibility. For that reason, VAD | long as to significantly reduce the effectiveness of VAD for | |||
SHOULD NOT be used in encrypted IVR applications where the content of | detecting listening pauses). Despite the overhang (and no matter | |||
pre-recorded messages may be of any value to an eavesdropper. | what the duration is), there is still a small amount of information | |||
leaked about the start time of the talkspurt due to the fact that we | ||||
cannot apply an overhang to the start of a talkspurt without | ||||
unacceptably affecting intelligibility. For that reason, VAD SHOULD | ||||
NOT be used in encrypted IVR applications where the content of pre- | ||||
recorded messages may be of any value to an eavesdropper. | ||||
The application of a random overhang period to each talkspurt will | The application of a random overhang period to each talkspurt will | |||
reduce the effectiveness of VAD in SRTP sessions when compared to | reduce the effectiveness of VAD in SRTP sessions when compared to | |||
non-SRTP sessions. It is, however, still expected that the use of | non-SRTP sessions. It is, however, still expected that the use of | |||
VAD will provide a significant bandwidth saving for many encrypted | VAD will provide a significant bandwidth saving for many encrypted | |||
sessions. | sessions. | |||
5. Padding the output of VBR codecs | 5. Padding the output of VBR codecs | |||
For scenarios where VBR is considered unsafe, the codec SHOULD be | For scenarios where VBR is considered unsafe, the codec SHOULD be | |||
skipping to change at page 6, line 12 ¶ | skipping to change at page 6, line 16 ¶ | |||
No IANA actions are required. | No IANA actions are required. | |||
8. Acknowledgements | 8. Acknowledgements | |||
This memo is based on the discussion in [spot-me]. Recent versions | This memo is based on the discussion in [spot-me]. Recent versions | |||
of ZRTP [I-D.zimmermann-avt-zrtp] contain a similar recommendation; | of ZRTP [I-D.zimmermann-avt-zrtp] contain a similar recommendation; | |||
the purpose of this memo is to highlight these issues to a wider | the purpose of this memo is to highlight these issues to a wider | |||
audience, since they are not specific to ZRTP. Thanks are due to | audience, since they are not specific to ZRTP. Thanks are due to | |||
Phil Zimmermann, Stefan Doehla, Mats Naslund, Gregory Maxwell, David | Phil Zimmermann, Stefan Doehla, Mats Naslund, Gregory Maxwell, David | |||
McGrew, Mark Baugher, and Koen Vos for their comments and feedback on | McGrew, Mark Baugher, Koen Vos, and Ingemar Johansson for their | |||
this memo. | comments and feedback on this memo. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, March 2004. | RFC 3711, March 2004. | |||
9.2. Informative References | 9.2. Informative References | |||
[I-D.zimmermann-avt-zrtp] | [I-D.zimmermann-avt-zrtp] | |||
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media | Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media | |||
Path Key Agreement for Secure RTP", | Path Key Agreement for Secure RTP", | |||
draft-zimmermann-avt-zrtp-17 (work in progress), | draft-zimmermann-avt-zrtp-22 (work in progress), | |||
January 2010. | January 2010. | |||
[spot-me] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. | [spot-me] Wright, C., Ballard, L., Coull, S., Monrose, F., and G. | |||
Masson, "Spot me if you can: Uncovering spoken phrases in | Masson, "Spot me if you can: Uncovering spoken phrases in | |||
encrypted VoIP conversation", Proceedings of the IEEE | encrypted VoIP conversation", Proceedings of the IEEE | |||
Symposium on Security and Privacy 2008, May 2008. | Symposium on Security and Privacy 2008, May 2008. | |||
Authors' Addresses | Authors' Addresses | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
Jean-Marc Valin | Jean-Marc Valin | |||
Octasic Inc. | Octasic Inc. | |||
4101 Molson Street, Suite 300 | 4101 Molson Street, Suite 300 | |||
Montreal, Quebec H1Y 3L1 | Montreal, Quebec H1Y 3L1 | |||
Canada | Canada | |||
Email: Jean-Marc.Valin@octasic.com | Email: Jean-Marc.Valin@octasic.com | |||
End of changes. 11 change blocks. | ||||
18 lines changed or deleted | 24 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |