draft-perkins-avt-srtp-not-mandatory-00.txt | draft-perkins-avt-srtp-not-mandatory-01.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: August 20, 2008 Ericsson | Expires: January 15, 2009 Ericsson | |||
February 17, 2008 | July 14, 2008 | |||
Why RTP Does Not Mandate a Single Security Mechanism | Why RTP Does Not Mandate a Single Security Mechanism | |||
draft-perkins-avt-srtp-not-mandatory-00.txt | draft-perkins-avt-srtp-not-mandatory-01.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||
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." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on August 20, 2008. | This Internet-Draft will expire on January 15, 2009. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
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) | |||
does not mandate a single media security mechanism. | does not mandate a single media security mechanism. | |||
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. Implications for RTP Media Security . . . . . . . . . . . . . . 4 | 3. Implications for RTP Media Security . . . . . . . . . . . . . . 4 | |||
4. Implications for Key Management . . . . . . . . . . . . . . . . 5 | 4. Implications for Key Management . . . . . . . . . . . . . . . . 5 | |||
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 5. On the Requirement for Strong Security in IETF protocols . . . 6 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 | 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 | |||
8. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 | |||
9. Informative References . . . . . . . . . . . . . . . . . . . . 7 | 9. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 | 10. Informative References . . . . . . . . . . . . . . . . . . . . 7 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 9 | Intellectual Property and Copyright Statements . . . . . . . . . . 9 | |||
1. Introduction | 1. Introduction | |||
The Real-time Transport Protocol (RTP) [1] is widely used for voice | The Real-time Transport Protocol (RTP) [1] is widely used for voice | |||
over IP, Internet television, video conferencing, and various other | over IP, Internet television, video conferencing, and various other | |||
real-time and streaming media applications. Despite this, the base | real-time and streaming media applications. Despite this, the base | |||
RTP specification provides very limited options for media security, | RTP specification provides very limited options for media security, | |||
and defines no standard key exchange mechanism. Rather, a number of | and defines no standard key exchange mechanism. Rather, a number of | |||
extensions are defined to provide confidentiality and authentication | extensions are defined to provide confidentiality and authentication | |||
skipping to change at page 3, line 24 ¶ | skipping to change at page 3, line 24 ¶ | |||
why it is appropriate that multiple extension mechanisms are defined, | why it is appropriate that multiple extension mechanisms are defined, | |||
rather than mandating a single media security and keying mechanism. | rather than mandating a single media security and keying mechanism. | |||
This memo provides information for the community; it does not specify | This memo provides information for the community; it does not specify | |||
a standard of any kind. | a standard of any kind. | |||
The structure of this memo is as follows: we begin, in Section 2 by | The structure of this memo is as follows: we begin, in Section 2 by | |||
describing the scenarios in which RTP is deployed. Following this, | describing the scenarios in which RTP is deployed. Following this, | |||
Section 3 outlines the implications of this range of scenarios for | Section 3 outlines the implications of this range of scenarios for | |||
media confidentially and authentication, and Section 4 outlines the | media confidentially and authentication, and Section 4 outlines the | |||
implications for key exchange. Section 5 then concludes and gives | implications for key exchange. Section 5 outlines how the RTP | |||
some recommendations. Finally, Section 6 outlines the security | framework meets the requirement of BCP 61. Section 6 then concludes | |||
considerations, and Section 7 outlines IANA considerations. | and gives some recommendations. Finally, Section 7 outlines the | |||
security considerations, and Section 8 outlines IANA considerations. | ||||
2. RTP Applications and Deployment Scenarios | 2. RTP Applications and Deployment Scenarios | |||
The range of application and deployment scenarios where RTP has been | The range of application and deployment scenarios where RTP has been | |||
used includes, but is not limited to, the following: | used includes, but is not limited to, the following: | |||
o Point-to-point voice telephony (fixed and wireless networks) | o Point-to-point voice telephony (fixed and wireless networks) | |||
o Point-to-point video conferencing | o Point-to-point video conferencing | |||
o Centralised group video conferencing with a multipoint conference | o Centralised group video conferencing with a multipoint conference | |||
unit (MCU) | unit (MCU) | |||
o Any Source Multicast video conferencing (light-weight sessions; | o Any Source Multicast video conferencing (light-weight sessions; | |||
Mbone conferencing) | Mbone conferencing) | |||
o Point-to-point streaming audio and/or video | o Point-to-point streaming audio and/or video | |||
o Single Source Multicast streaming to large group (IPTV) | o Single Source Multicast streaming to large group (IPTV and MBMS | |||
[2]) | ||||
o Replicated unicast streaming to a group | o Replicated unicast streaming to a group | |||
o Interconnecting components in music production studios and video | o Interconnecting components in music production studios and video | |||
editing suites | editing suites | |||
o Interconnecting components of distributed simulation systems | o Interconnecting components of distributed simulation systems | |||
o Streaming real-time sensor data | o Streaming real-time sensor data | |||
As can be seen, these scenarios vary from point-to-point to very | As can be seen, these scenarios vary from point-to-point to very | |||
large multicast groups, from interactive to non-interactive, and from | large multicast groups, from interactive to non-interactive, and from | |||
low bandwidth (kilobits per second) to very high bandwidth (multiple | low bandwidth (kilobits per second) to very high bandwidth (multiple | |||
skipping to change at page 4, line 25 ¶ | skipping to change at page 4, line 27 ¶ | |||
Some applications of RTP operate entirely within a single trust | Some applications of RTP operate entirely within a single trust | |||
domain, others are inter-domain, with untrusted (and potentially | domain, others are inter-domain, with untrusted (and potentially | |||
unknown) users. The range of scenarios is wide, and growing both in | unknown) users. The range of scenarios is wide, and growing both in | |||
number and in heterogeneity. | number and in heterogeneity. | |||
3. Implications for RTP Media Security | 3. Implications for RTP Media Security | |||
The wide range of application scenarios where RTP is used has led to | The wide range of application scenarios where RTP is used has led to | |||
the development of multiple solutions for media security, considering | the development of multiple solutions for media security, considering | |||
different requirements. Perhaps the most general of these solutions | different requirements. Perhaps the most general of these solutions | |||
is the Secure RTP (SRTP) framework [2]. This is an application-level | is the Secure RTP (SRTP) framework [3]. This is an application-level | |||
media security solution, encrypting the media payload data (not the | media security solution, encrypting the media payload data (not the | |||
RTP headers) to provide some degree of confidentiality, and providing | RTP headers) to provide some degree of confidentiality, and providing | |||
optional source origin authentication. It was carefully designed to | optional source origin authentication. It was carefully designed to | |||
be both low overhead, and to support the group communication features | be both low overhead, and to support the group communication features | |||
of RTP, across a range of networks. | of RTP, across a range of networks. | |||
SRTP is not the only media security solution in use, however, and | SRTP is not the only media security solution in use, however, and | |||
alternatives are more appropriate for some scenarios. For example, | alternatives are more appropriate for some scenarios. For example, | |||
many client-server streaming media applications run over a single TCP | many client-server streaming media applications run over a single TCP | |||
connection, multiplexing media data with control information on that | connection, multiplexing media data with control information on that | |||
connection (for example, on an RTSP connection). The natural way to | connection (for example, on an RTSP connection). The natural way to | |||
provide media security for such client-server media applications is | provide media security for such client-server media applications is | |||
to use TLS to protect the TCP connection, sending the RTP media data | to use TLS to protect the TCP connection, sending the RTP media data | |||
over the TLS connection. Using the SRTP framework in addition to TLS | over the TLS connection. Using the SRTP framework in addition to TLS | |||
is unncessary, and would result in double encryption of the media, | is unncessary, and would result in double encryption of the media, | |||
and SRTP cannot be used instead of TLS since it is RTP-specific, and | and SRTP cannot be used instead of TLS since it is RTP-specific, and | |||
so cannot protect the control traffic. | so cannot protect the control traffic. | |||
Other RTP use cases work over networks which provide security at the | ||||
network layer, using IPsec. For example, certain 3GPP networks need | ||||
IPsec security associations for other purposes, and can reuse those | ||||
to secure the RTP session. SRTP is, once again, unnecessary in such | ||||
environments, and its use would only introduce overhead for no gain. | ||||
Finally, the link layer may be secure, and it may be known that the | Finally, the link layer may be secure, and it may be known that the | |||
RTP media data is constrained to that single link (for example, when | RTP media data is constrained to that single link (for example, when | |||
operating in a studio environment, with physical link security). An | operating in a studio environment, with physical link security). An | |||
environment like this is inherently constrained, but might avoid the | environment like this is inherently constrained, but might avoid the | |||
need for application, transport, or network layer media security. | need for application, transport, or network layer media security. | |||
All these are application scenarios where RTP has seen commerical | All these are application scenarios where RTP has seen commerical | |||
deployment. Other use case also exist, with additional requirements. | deployment. Other use case also exist, with additional requirements. | |||
There is no media security protocol that is appropriate for all these | There is no media security protocol that is appropriate for all these | |||
environments. Accordingly, multiple RTP media security protocols can | environments. Accordingly, multiple RTP media security protocols can | |||
be expected to remain in wide use. | be expected to remain in wide use. | |||
4. Implications for Key Management | 4. Implications for Key Management | |||
Similar issues apply when considering key management protocols for | More diverse than the different use cases is the different protocols | |||
RTP sessions, and a wide range of solutions have been developed in | used for RTP session establishment. Providing keying for these | |||
this space: | different session establishment can basically be put into two | |||
categories, inband and out-of-band in relation to the session | ||||
establishment mechanism. The requirement on these solution are | ||||
highly varying. Thus a wide range of solutions have been developed | ||||
in this space: | ||||
o The most common use case for RTP is probably point-to-point voice | o The most common use case for RTP is probably point-to-point voice | |||
calls or centralised group conferences, negotiated using SIP with | calls or centralised group conferences, negotiated using SIP with | |||
the SDP offer/answer model, operating on a trusted infrastructure. | the SDP offer/answer model, operating on a trusted infrastructure. | |||
In such environments, SDP security descriptions [3] or the MIKEY | In such environments, SDP security descriptions [4] or the MIKEY | |||
[4] protocol are appropriate keying mechanisms, piggybacked onto | [5] protocol are appropriate keying mechanisms, piggybacked onto | |||
the SDP exchange. | the SDP exchange. | |||
o SIP/SDP with SIPS | o SIP/SDP with SIPS | |||
o SIP/SDP with S/MIME | o SIP/SDP with S/MIME | |||
o Point-to-point RTP sessions may be negotiated using SIP with the | o Point-to-point RTP sessions may be negotiated using SIP with the | |||
offer/answer model, but operating over a network with untrusted | offer/answer model, but operating over a network with untrusted | |||
infrastructure. In such environments, the key management protocol | infrastructure. In such environments, the key management protocol | |||
is run on the media path, bypassing the untrusted infrastructure. | is run on the media path, bypassing the untrusted infrastructure. | |||
skipping to change at page 5, line 49 ¶ | skipping to change at page 5, line 50 ¶ | |||
same manner as would be used to secure an HTTP session. | same manner as would be used to secure an HTTP session. | |||
o Email with SDP, secured using X.500 or PGP | o Email with SDP, secured using X.500 or PGP | |||
o SDP file retrieved using HTTPS | o SDP file retrieved using HTTPS | |||
o FLUTE using S/MIME to secure SDP | o FLUTE using S/MIME to secure SDP | |||
o SAP with SDP | o SAP with SDP | |||
o (TBD: complete this list) | o OMAs DRM keymanagement [6] with pointer from SDP for point to | |||
point streamingsetup with RTSP in 3GPP [7]. | ||||
o Usage of HTTP and MIKEY for key management in MBMS [8]. | ||||
A more detailed survey of requirements for media security management | A more detailed survey of requirements for media security management | |||
protocols can be found in [5]. As can be seen, the range of use | protocols can be found in [9]. As can be seen, the range of use | |||
cases is wide, and there is no single protocol that is appropriate | cases is wide, and there is no single protocol that is appropriate | |||
for all scenarios. | for all scenarios. These solutions have be further diversified by | |||
the existence of infrastructure elements such as authentication | ||||
solutions that is tied into the key manangement. | ||||
5. Conclusions | 5. On the Requirement for Strong Security in IETF protocols | |||
It would clearly be desirable if a single media security solution and | BCP 61 [10] puts a requirement on IETF protocols to provide strong, | |||
a single key management solution could be developed, satisfying the | mandatory to implement, security solutions. This is actually quite a | |||
range of use cases for RTP. The authors are not aware of any such | difficult requirement for any type of framework protocol, like RTP, | |||
solution, however, and it is not clear that any single solution can | since one can never know all the deployement scenarios, and if the | |||
be developed. In the absense of such a solution, it is hoped that | security solution provided covers them. It would clearly be | |||
this memo explains why SRTP is not mandatory as the media security | desirable if a single media security solution and a single key | |||
solution for RTP-based systems, and why we can expect multiple key | management solution could be developed, satisfying the range of use | |||
management solutions for systems using RTP. | cases for RTP. The authors are not aware of any such solution, | |||
however, and it is not clear that any single solution can be | ||||
developed. | ||||
For a framework protocol it appears that the only sensible solution | ||||
to the requirement of BCP 61 is to develop or use security building | ||||
blocks, like SRTP, SDES, MIKEY, DTLS, or IPsec, to provide the basic | ||||
security services of authorization, data integrity protocetion and | ||||
date confidentiality protection. When new usages of the RTP | ||||
framework arise, one needs to analyze the situation, to determine of | ||||
the existing building blocks satisfy the requirements. If not, it is | ||||
necessary to develop new security building blocks. | ||||
When it comes to fulfilling the "MUST Implement" strong security for | ||||
a specific application, it will fall on that application to actually | ||||
consider what building blocks it is required to support. To maximize | ||||
interoperability it is desirable if certain applications, or classes | ||||
of application with similar requirements, agree on what data security | ||||
mechanisms and key-management should be used. If such agreement is | ||||
not possible, there will be increased cost, either in the lack of | ||||
interoperability, or in the need to implement more solutions. | ||||
Unfortunately this situation, if not handled reasonably well, can | ||||
result in a failure to satisfy the requirement of providing the users | ||||
with an option of turining on strong security when desired. | ||||
6. Conclusions | ||||
As discussed earlier it appears that a single solution can't be | ||||
designed meet the diverse requirements. In the absense of such a | ||||
solution, it is hoped that this memo explains why SRTP is not | ||||
mandatory as the media security solution for RTP-based systems, and | ||||
why we can expect multiple key management solutions for systems using | ||||
RTP. | ||||
In respect to the above it is important for any RTP-based application | In respect to the above it is important for any RTP-based application | |||
to consider how they meet the application's security requirements. | to consider how they meet the application's security requirements. | |||
This will requires some analysis to determine these requirements. | This will requires some analysis to determine these requirements. | |||
Followed by a selection of preferably a single to mandatory to | Followed by a selection of preferably a single to mandatory to | |||
implement solution including the desired RTP traffic protection and | implement solution including the desired RTP traffic protection and | |||
key-management. As SRTP can be used in a large number of use cases, | key-management. As SRTP can be used in a large number of use cases, | |||
it is a preferred solution for the protection of the RTP traffic, for | it is a preferred solution for the protection of the RTP traffic, for | |||
those use cases where it is applicable. Currently it is much harder | those use cases where it is applicable. Currently it is much harder | |||
to point out a preferred key-management solution. | to point out a preferred key-management solution. | |||
6. Security Considerations | 7. Security Considerations | |||
This entire memo is about security. | This entire memo is about security. | |||
7. IANA Considerations | 8. IANA Considerations | |||
No IANA actions are required. | No IANA actions are required. | |||
8. To Do | 9. To Do | |||
Complete Section 4 | Update references | |||
Incorporate discussion of RFC 3365 [6] into this document, to explain | IPsec example | |||
how those requirements are satisfied. | ||||
9. Informative References | 10. Informative References | |||
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, | [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, | |||
"RTP: A Transport Protocol for Real-Time Applications", STD 64, | "RTP: A Transport Protocol for Real-Time Applications", STD 64, | |||
RFC 3550, July 2003. | RFC 3550, July 2003. | |||
[2] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [2] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); Protocols | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | and codecs TS 26.346". | |||
RFC 3711, March 2004. | ||||
[3] Andreasen, F., Baugher, M., and D. Wing, "Session Description | [3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Protocol (SDP) Security Descriptions for Media Streams", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 4568, July 2006. | RFC 3711, March 2004. | |||
[4] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. | [4] Andreasen, F., Baugher, M., and D. Wing, "Session Description | |||
Carrara, "Key Management Extensions for Session Description | Protocol (SDP) Security Descriptions for Media Streams", | |||
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", | RFC 4568, July 2006. | |||
RFC 4567, July 2006. | ||||
[5] Wing, D., Fries, S., Tschofenig, H., and F. Audet, "Requirements | [5] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. | |||
and Analysis of Media Security Management Protocols", | Carrara, "Key Management Extensions for Session Description | |||
draft-ietf-sip-media-security-requirements-02 (work in | Protocol (SDP) and Real Time Streaming Protocol (RTSP)", | |||
progress), January 2008. | RFC 4567, July 2006. | |||
[6] Schiller, J., "Strong Security Requirements for Internet | [6] Open Mobile Alliance, "DRM Specification 2.0". | |||
Engineering Task Force Standard Protocols", BCP 61, RFC 3365, | ||||
August 2002. | [7] 3GPP, "Transparent end-to-end Packet-switched Streaming Service | |||
(PSS); Protocols and codecs TS 26.234". | ||||
[8] 3GPP, "Security of Multimedia Broadcast/Multicast Service | ||||
(MBMS) TS 33.246". | ||||
[9] Wing, D., Fries, S., Tschofenig, H., and F. Audet, | ||||
"Requirements and Analysis of Media Security Management | ||||
Protocols", draft-ietf-sip-media-security-requirements-02 (work | ||||
in progress), January 2008. | ||||
[10] Schiller, J., "Strong Security Requirements for Internet | ||||
Engineering Task Force Standard Protocols", BCP 61, RFC 3365, | ||||
August 2002. | ||||
Authors' Addresses | Authors' Addresses | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | Department of Computing Science | |||
Sir Alwyn Williams Building | Sir Alwyn Williams Building | |||
Lilybank Gardens | Lilybank Gardens | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
End of changes. 28 change blocks. | ||||
66 lines changed or deleted | 114 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/ |