draft-ietf-avt-srtp-not-mandatory-10.txt | draft-ietf-avt-srtp-not-mandatory-11.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational M. Westerlund | Intended status: Informational M. Westerlund | |||
Expires: April 25, 2013 Ericsson | Expires: May 23, 2013 Ericsson | |||
October 22, 2012 | November 19, 2012 | |||
Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single | |||
Media Security Solution | Media Security Solution | |||
draft-ietf-avt-srtp-not-mandatory-10.txt | draft-ietf-avt-srtp-not-mandatory-11.txt | |||
Abstract | Abstract | |||
This memo discusses the problem of securing real-time multimedia | This memo discusses the problem of securing real-time multimedia | |||
sessions, and explains why the Real-time Transport Protocol (RTP), | sessions, and explains why the Real-time Transport Protocol (RTP), | |||
and the associated RTP control protocol (RTCP), do not mandate a | and the associated RTP control protocol (RTCP), do not mandate a | |||
single media security mechanism. Guidelines for designers and | single media security mechanism. Guidelines for designers and | |||
reviewers of future RTP extensions are provided, to ensure that | reviewers of future RTP extensions are provided, to ensure that | |||
appropriate security mechanisms are mandated, and that any such | appropriate security mechanisms are mandated, and that any such | |||
mechanisms are specified in a manner that conforms with the RTP | mechanisms are specified in a manner that conforms with the RTP | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
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 April 25, 2013. | This Internet-Draft will expire on May 23, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 20 | skipping to change at page 2, line 20 | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. RTP Applications and Deployment Scenarios . . . . . . . . . . . 3 | 2. RTP Applications and Deployment Scenarios . . . . . . . . . . . 3 | |||
3. RTP Media Security . . . . . . . . . . . . . . . . . . . . . . 4 | 3. RTP Media Security . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. RTP Session Establishment and Key Management . . . . . . . . . 5 | 4. RTP Session Establishment and Key Management . . . . . . . . . 5 | |||
5. On the Requirement for Strong Security in Framework | 5. On the Requirement for Strong Security in Framework | |||
protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
6. Guidelines for Securing the RTP Protocol Framework . . . . . . 6 | 6. Guidelines for Securing the RTP Protocol Framework . . . . . . 6 | |||
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
11. Informative References . . . . . . . . . . . . . . . . . . . . 8 | 11. Informative References . . . . . . . . . . . . . . . . . . . . 8 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [RFC3550] is widely used for | The Real-time Transport Protocol (RTP) [RFC3550] is widely used for | |||
voice over IP, Internet television, video conferencing, and other | voice over IP, Internet television, video conferencing, and other | |||
real-time and streaming media applications. Despite this use, the | real-time and streaming media applications. Despite this use, the | |||
basic RTP specification provides only limited options for media | basic RTP specification provides only limited options for media | |||
security, and defines no standard key exchange mechanism. Rather, a | security, and defines no standard key exchange mechanism. Rather, a | |||
number of extensions are defined that can provide confidentiality and | number of extensions are defined that can provide confidentiality and | |||
authentication of RTP media streams and RTP Control Protocol (RTCP) | authentication of RTP media streams and RTP Control Protocol (RTCP) | |||
skipping to change at page 6, line 31 | skipping to change at page 6, line 31 | |||
maximize interoperability it is important that common media security | maximize interoperability it is important that common media security | |||
and key management mechanisms are defined for classes of application | and key management mechanisms are defined for classes of application | |||
with similar requirements. The IETF needs to participate in this | with similar requirements. The IETF needs to participate in this | |||
selection of security building blocks for each class of applications | selection of security building blocks for each class of applications | |||
that use the protocol framework and are expected to interoperate | that use the protocol framework and are expected to interoperate | |||
where IETF has the appropriate knowledge of the class of | where IETF has the appropriate knowledge of the class of | |||
applications. | applications. | |||
6. Guidelines for Securing the RTP Protocol Framework | 6. Guidelines for Securing the RTP Protocol Framework | |||
RTP is a framework protocol, so the arguments in in Section 5 apply. | The IETF requires that protocols specify mandatory to implement (MTI) | |||
The security building blocks available for RTP at the time of this | strong security [RFC3365]. This applies to the specification of each | |||
writing are described in [I-D.ietf-avtcore-rtp-security-options]. | interoperable class of application that makes use of RTP. However, | |||
That memo also gives examples of how those security building blocks | RTP is a framework protocol, so the arguments made in Section 5 also | |||
can be combined to give mandatory to implement security for some RTP | apply. Given the variability of the classes of application that use | |||
application scenarios. | RTP, and the variety of the currently available security mechanisms | |||
described in [I-D.ietf-avtcore-rtp-security-options], no one set of | ||||
MTI security options can realistically be specified that apply to all | ||||
classes of RTP applications. | ||||
RTP can be extended in different ways. Two important extension | Documents that define an interoperable class of applications using | |||
points are RTP Payload Formats and RTP Profiles. An RTP Payload | RTP are subject to [RFC3365] and need to specify MTI security | |||
Format defines how the output of a new media codec can be used with | mechanisms. This is because such specifications do fully specify | |||
RTP. It is appropriate for an RTP payload format to discuss specific | interoperable applications that use RTP. Examples of such a | |||
security implications of using that codec with RTP, but it is not | documents in development at the time of this writing would be the | |||
appropriate for an RTP payload format to mandate the use of SRTP, or | RTCWEB Security Architecture [I-D.ietf-rtcweb-security-arch] and Real | |||
any other security building blocks, since that payload format might | Time Streaming Protocol 2.0 (RTSP) [I-D.ietf-mmusic-rfc2326bis]. It | |||
be used in a range of different scenarios. | is also expected that a similar document will be produced for voice- | |||
over-IP applications using SIP and RTP. | ||||
The RTP framework can be extended in ways that do not specify an | ||||
interoperable class of applications. Two important extension points | ||||
are RTP Payload Formats and RTP Profiles. An RTP Payload Format | ||||
defines how the output of a media codec can be used with RTP. At the | ||||
time of this writing, there are over 70 RTP Payload Formats defined | ||||
in published RFCs, with more in development. It is appropriate for | ||||
an RTP payload format to discuss specific security implications of | ||||
using that codec with RTP. However, an RTP payload format does not | ||||
specify an interoperable class of applications that use RTP, and is | ||||
neither secure in itself, nor something to which [RFC3365] applies. | ||||
Future RTP payload format specifications ought to explicitly state | ||||
this, and include a reference to this memo for explanation. It is | ||||
not appropriate for an RTP payload format to mandate the use of SRTP | ||||
[RFC3711], or any other security building blocks, since that RTP | ||||
payload format might be used by different classes of application that | ||||
use RTP, and that have different security requirements. | ||||
RTP profiles are larger extensions that adapt the RTP framework for | RTP profiles are larger extensions that adapt the RTP framework for | |||
use with particular classes of application. In some cases, those | use with particular classes of application. In some cases, those | |||
classes of application might share common security requirements so | classes of application might share common security requirements so | |||
that it could make sense for an RTP profile to mandate particular | that it could make sense for an RTP profile to mandate particular | |||
security options and building blocks. In other cases, though, an RTP | security options and building blocks (the RTP/SAVP profile [RFC3711] | |||
profile is applicable to such a wide range of applications that it | is an example of this type of RTP profile). In other cases, though, | |||
would not make sense for that profile to mandate particular security | an RTP profile is applicable to such a wide range of applications | |||
building blocks be used. Any new RTP profile ought to discuss if it | that it would not make sense for that profile to mandate particular | |||
makes sense to mandate particular security building blocks be used | security building blocks be used (the RTP/AVPF profile [RFC4585] is | |||
with implementations of that profile, but without the expectation | an example of this type of RTP profile, since it provides building | |||
that all RTP profiles will mandate particular security solutions. | blocks that can be used in different styles of application). Any new | |||
RTP profile needs to discuss if it makes sense to mandate particular | ||||
security building blocks be used with implementations of that | ||||
profile, but without the expectation that all RTP profiles will | ||||
mandate particular security solutions. RTP profiles that do not | ||||
specify an interoperable usage for a particular class of RTP | ||||
applications are neither secure in themselves, nor something to which | ||||
[RFC3365] applies; any future RTP profiles in this category need to | ||||
explicitly state this with justification, and include a reference to | ||||
this memo. | ||||
7. Conclusions | 7. Conclusions | |||
The RTP framework is used in a wide range of different scenarios, | The RTP framework is used in a wide range of different scenarios, | |||
with no common security requirements. Accordingly, neither SRTP | with no common security requirements. Accordingly, neither SRTP | |||
[RFC3711], nor any other single media security solution or keying | [RFC3711], nor any other single media security solution or keying | |||
mechanism, can be mandated for all uses of RTP. In the absence of a | mechanism, can be mandated for all uses of RTP. In the absence of a | |||
single common security solution, it is important to consider what | single common security solution, it is important to consider what | |||
mechanisms can be used to provide strong and interoperable security | mechanisms can be used to provide strong and interoperable security | |||
for each different scenario where RTP applications are used. This | for each different scenario where RTP applications are used. This | |||
skipping to change at page 7, line 42 | skipping to change at page 8, line 25 | |||
This entire memo is about security. | This entire memo is about security. | |||
9. IANA Considerations | 9. IANA Considerations | |||
None. | None. | |||
10. Acknowledgements | 10. Acknowledgements | |||
Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, | Thanks to Ralph Blom, Hannes Tschofenig, Dan York, Alfred Hoenes, | |||
Martin Ellis, Ali Begen, Keith Drage, and Ray van Brandenburg for | Martin Ellis, Ali Begen, Keith Drage, Ray van Brandenburg, Stephen | |||
their feedback. | Farrell, and Sean Turner for their feedback. | |||
11. Informative References | 11. Informative References | |||
[I-D.ietf-avtcore-rtp-security-options] | [I-D.ietf-avtcore-rtp-security-options] | |||
Westerlund, M. and C. Perkins, "Options for Securing RTP | Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
Sessions", draft-ietf-avtcore-rtp-security-options-00 | Sessions", draft-ietf-avtcore-rtp-security-options-01 | |||
(work in progress), July 2012. | (work in progress), October 2012. | |||
[I-D.ietf-mmusic-rfc2326bis] | ||||
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | ||||
and M. Stiemerling, "Real Time Streaming Protocol 2.0 | ||||
(RTSP)", draft-ietf-mmusic-rfc2326bis-30 (work in | ||||
progress), July 2012. | ||||
[I-D.ietf-rtcweb-security-arch] | ||||
Rescorla, E., "RTCWEB Security Architecture", | ||||
draft-ietf-rtcweb-security-arch-05 (work in progress), | ||||
October 2012. | ||||
[ISMACrypt2] | [ISMACrypt2] | |||
"ISMA Encryption and Authentication, Version 2.0 release | "ISMA Encryption and Authentication, Version 2.0 release | |||
version", November 2007. | version", November 2007. | |||
[MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); | [MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); | |||
Protocols and codecs TS 26.346". | Protocols and codecs TS 26.346". | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
August 1980. | August 1980. | |||
skipping to change at page 8, line 40 | skipping to change at page 9, line 30 | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, July 2003. | |||
[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. | |||
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram | [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram | |||
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. | Congestion Control Protocol (DCCP)", RFC 4340, March 2006. | |||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | ||||
"Extended RTP Profile for Real-time Transport Control | ||||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | ||||
July 2006. | ||||
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap | [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap | |||
for Transmission Control Protocol (TCP) Specification | for Transmission Control Protocol (TCP) Specification | |||
Documents", RFC 4614, September 2006. | Documents", RFC 4614, September 2006. | |||
[RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, | [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, | |||
"Requirements and Analysis of Media Security Management | "Requirements and Analysis of Media Security Management | |||
Protocols", RFC 5479, April 2009. | Protocols", RFC 5479, April 2009. | |||
Authors' Addresses | Authors' Addresses | |||
End of changes. 11 change blocks. | ||||
33 lines changed or deleted | 79 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |