draft-ietf-avt-srtp-not-mandatory-07.txt | draft-ietf-avt-srtp-not-mandatory-08.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: January 2, 2011 Ericsson | Expires: May 3, 2012 Ericsson | |||
July 1, 2010 | October 31, 2011 | |||
Why RTP Does Not Mandate a Single Security Mechanism | Why RTP Does Not Mandate a Single Security Mechanism | |||
draft-ietf-avt-srtp-not-mandatory-07.txt | draft-ietf-avt-srtp-not-mandatory-08.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. | single media security mechanism. It also discusses how applications | |||
using RTP can meet the goals of BCP 61 to have strong and mandatory | ||||
to implement security. | ||||
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 | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 2, 2011. | This Internet-Draft will expire on May 3, 2012. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2011 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
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. RTP Applications and Deployment Scenarios . . . . . . . . . . 3 | 2. RTP Applications and Deployment Scenarios . . . . . . . . . . 3 | |||
3. Implications for RTP Security . . . . . . . . . . . . . . . . 4 | 3. Implications for RTP Security . . . . . . . . . . . . . . . . 4 | |||
4. Implications for Key Management . . . . . . . . . . . . . . . 5 | 4. Implications for Key Management . . . . . . . . . . . . . . . 5 | |||
5. On the Requirement for Strong Security in IETF protocols . . . 6 | 5. On the Requirement for Strong Security in IETF protocols . . . 7 | |||
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
10. Informative References . . . . . . . . . . . . . . . . . . . . 8 | 10. Informative References . . . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
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 various | voice over IP, Internet television, video conferencing, and various | |||
other real-time and streaming media applications. Despite this, the | other real-time and streaming media applications. Despite this, the | |||
base RTP specification provides very limited options for media | base RTP specification provides very 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 to provide confidentiality and | number of extensions are defined to provide confidentiality and | |||
authentication of RTP media streams and RTCP control messages, and to | authentication of RTP media streams and RTCP control messages, and to | |||
exchange security keys. This memo outlines why it is appropriate | exchange security keys. This memo outlines why it is appropriate | |||
that multiple extension mechanisms are defined, rather than mandating | that multiple extension mechanisms are defined, rather than mandating | |||
a single security and keying mechanism. | a single security and keying mechanism. | |||
The consensus for Strong Security Requirements for IETF Standard | ||||
Protocols (BCP61) [RFC3365] describes the Danvers Doctrine, which | ||||
states that: | ||||
"The solution is that we MUST implement strong security in all | ||||
protocols to provide for the all too frequent day when the | ||||
protocol comes into widespread use in the global Internet." | ||||
BCP 61 also discusses that security must be implemented, and makes | ||||
the following statement: | ||||
"However security must be a MUST IMPLEMENT so that end users will | ||||
have the option of enabling it when the situation calls for it." | ||||
This IETF consensus provides a clear challange for RTP security, due | ||||
to the heterogenous scenarios in which RTP can be used, and the wide | ||||
choice of security mechanisms available. This memo describes how RTP | ||||
based applications, or classes of applications, can best meet the | ||||
security goals of BCP 61. | ||||
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. Section 2 describes the | The structure of this memo is as follows. Section 2 describes a | |||
scenarios in which RTP is deployed. Following this, Section 3 | number of scenarios in which RTP is deployed. Following this, | |||
outlines the implications of this range of scenarios for media | Section 3 outlines the implications of this range of scenarios for | |||
confidentially and authentication, and Section 4 outlines the | media confidentially and authentication, and Section 4 outlines the | |||
implications for key exchange. Section 5 outlines how the RTP | implications for key exchange. Section 5 outlines how the RTP | |||
framework meets the requirement of BCP 61. Section 6 then concludes | framework can meet the requirement of BCP 61. Section 6 then | |||
and gives some recommendations. | concludes and gives some recommendations. | |||
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 voice and 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 Source-specific multicast (SSM) streaming to large group (IPTV and | o Source-specific multicast (SSM) streaming to large group (IPTV and | |||
skipping to change at page 4, line 41 ¶ | skipping to change at page 5, line 13 ¶ | |||
headers) to provide some degree of confidentiality, and providing | 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 can run over a single | many client-server streaming media applications can run over a single | |||
TCP connection, multiplexing media data with control information on | TCP connection, multiplexing media data with control information on | |||
that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used | that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used | |||
example of such a protocol). The natural way to provide media | example of such a protocol). One way to provide media security for | |||
security for such client-server media applications is to use TLS | such client-server media applications is to use TLS [RFC5246] to | |||
[RFC5246] to protect the TCP connection, sending the RTP media data | protect the TCP connection, sending the RTP media data over the TLS | |||
over the TLS connection. Using the SRTP framework in addition to TLS | connection. Using the SRTP framework in addition to TLS is | |||
is unnecessary, and would result in double encryption of the media, | unnecessary, and would result in double encryption of the media, and | |||
and SRTP cannot be used instead of TLS since it is RTP-specific, and | SRTP cannot be used instead of TLS since it is RTP-specific, and so | |||
so cannot protect the control traffic. | cannot protect the control traffic. | |||
Other RTP use cases work over networks which provide security at the | Other RTP use cases work over networks which provide security at the | |||
network layer, using IPsec. For example, certain 3GPP networks need | network layer, using IPsec. For example, certain 3GPP networks need | |||
IPsec security associations for other purposes, and can reuse those | IPsec security associations for other purposes, and can reuse those | |||
to secure the RTP session [3GPP.33.210]. SRTP is, again, unnecessary | to secure the RTP session [TS-33210]. SRTP is, again, unnecessary in | |||
in such environments, and its use would only introduce overhead for | such environments, and its use would only introduce overhead for no | |||
no gain. | gain. | |||
For some applications it is sufficient to protect the RTP payload | For some applications it is sufficient to protect the RTP payload | |||
data while leaving RTP, transport, and network layer headers | data while leaving RTP, transport, and network layer headers | |||
unprotected. An example of this is RTP broadcast over DVB-H | unprotected. An example of this is RTP broadcast over DVB-H | |||
[ETSI.TS.102.474], where one mode of operation uses ISMAcryp | [ETSI.TS.102.474], where one mode of operation uses ISMA Cryp 2.0 | |||
(http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP | [ISMA] to encrypt the RTP payload data only. | |||
payload data only. | ||||
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 | ||||
operating in a studio environment, with physical link security). An | ||||
environment like this is inherently constrained, but might avoid the | ||||
need for application, transport, or network layer media security. | ||||
All these are application scenarios where RTP has seen commercial | All these are application scenarios where RTP has seen commercial | |||
deployment. Other use case also exist, with additional requirements. | deployment. Other use cases exist, with additional requirements. | |||
There is no media security protocol that is appropriate for all these | For example, if the media transport is done over UDP [RFC0768], DCCP | |||
environments. Accordingly, multiple RTP media security protocols can | [RFC4340] or SCTP [RFC4960], then using DTLS [RFC4347] to protect the | |||
be expected to remain in wide use. | whole RTP packets is an option. There is no media security protocol | |||
that is appropriate for all these environments. Accordingly, | ||||
multiple RTP media security protocols can be expected to remain in | ||||
wide use. | ||||
4. Implications for Key Management | 4. Implications for Key Management | |||
With such a diverse range of use cases come a range of different | With such a diverse range of use cases come a range of different | |||
protocols for RTP session establishment. Mechanisms used to provide | protocols for RTP session establishment. Mechanisms used to provide | |||
security keying for these different session establishment protocols | security keying for these different session establishment protocols | |||
can basically be put into two categories: inband and out-of-band in | can basically be put into two categories: inband and out-of-band in | |||
relation to the session establishment mechanism. The requirements | relation to the session establishment mechanism. The requirements | |||
for these solutions are highly varying. Thus a wide range of | for these solutions are highly varying. Thus a wide range of | |||
solutions have been developed in this space: | solutions have been developed in this space: | |||
o A common use case for RTP is probably point-to-point voice calls | o A common use case for RTP is probably point-to-point voice calls | |||
or centralised group conferences, negotiated using SIP [RFC3261] | or centralised group conferences, negotiated using SIP [RFC3261] | |||
with the SDP offer/answer model [RFC3264], operating on a trusted | with the SDP offer/answer model [RFC3264], operating on a trusted | |||
infrastructure. In such environments, SDP security descriptions | infrastructure. In such environments, SDP security descriptions | |||
[RFC4568] or the MIKEY [RFC4567] protocol are appropriate keying | [RFC4568], or the MIKEY [RFC3830] protocol using the Key | |||
mechanisms, piggybacked onto the SDP [RFC4566] exchange. The | Management Extensions for SDP [RFC4567], are appropriate keying | |||
infrastructure may be secured by protecting the SIP exchange using | mechanisms, where the keying messages/material are embedded in the | |||
TLS or S/MIME, for example [RFC3261]. Protocols such as DTLS | SDP [RFC4566] exchange. The infrastructure may be secured by | |||
[RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] are also appropriate | protecting the SDP exchange in SIP using TLS or S/MIME, for | |||
in such environments. | example [RFC3261]. Protocols such as DTLS-SRTP [RFC5764] or ZRTP | |||
[RFC6189] are also appropriate in such environments. | ||||
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. | can be run on the media path, bypassing the untrusted | |||
Protocols such as DTLS [RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] | infrastructure. Protocols such as DTLS-SRTP [RFC5764] or ZRTP | |||
are useful here. | [RFC6189] are useful here, as are inband mechanism that protect | |||
the keying material such as MIKEY [RFC3830] using the Key | ||||
Management Extensions for SDP [RFC4567]. It should be noted that | ||||
the end-points for all the above mechanisms must prevent total | ||||
downgrade to no security for the RTP media streams. | ||||
o For point-to-point client-server streaming of RTP over RTSP, a TLS | o For point-to-point client-server streaming of RTP over RTSP, a TLS | |||
association is appropriate to manage keying material, in much the | association is appropriate to manage keying material, in much the | |||
same manner as would be used to secure an HTTP session. | same manner as would be used to secure an HTTP session. But also | |||
using SRTP with DTLS-SRTP keying or DTLS are appropriate choices. | ||||
o A session description may be sent by email, secured using S/MIME | o A session description may be sent by email, secured using S/MIME | |||
or PGP, or retrieved from a web page, using HTTP with TLS. | or PGP, or retrieved from a web page, using HTTP with TLS. | |||
o A session description may be distributed to a multicast group | o A session description may be distributed to a multicast group | |||
using SAP or FLUTE secured with S/MIME. | using SAP or FLUTE secured with S/MIME. | |||
o A session description may be distributed using the Open Mobile | o A session description may be distributed using the Open Mobile | |||
Alliance DRM key management specification [OMA-DRM] when using a | Alliance DRM key management specification [OMA-DRM] when using a | |||
point-to-point streaming session setup with RTSP in the 3GPP PSS | point-to-point streaming session setup with RTSP in the 3GPP PSS | |||
environment [PSS]. | environment [PSS]. | |||
o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system, | o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system, | |||
HTTP and MIKEY are used for key management [MBMS-SEC]. | HTTP and MIKEY are used for key management [MBMS-SEC]. | |||
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 [RFC5479]. As can be seen, the range of | protocols can be found in [RFC5479]. As can be seen, the range of | |||
use cases is wide, and there is no single protocol that is | use cases is wide, and there is no single protocol that is | |||
appropriate for all scenarios. These solutions have been further | appropriate for all scenarios. These solutions have been further | |||
diversified by the existence of infrastructure elements such as | diversified by the existence of infrastructure elements such as | |||
authentication solutions that are tied into the key manangement. | authentication solutions that are tied into the key management. | |||
5. On the Requirement for Strong Security in IETF protocols | 5. On the Requirement for Strong Security in IETF protocols | |||
BCP 61 [RFC3365] puts a requirement on IETF protocols to provide | BCP 61 [RFC3365] puts a requirement on IETF protocols to provide | |||
strong, mandatory to implement, security solutions. This is actually | strong, mandatory to implement, security solution. This is actually | |||
quite a difficult requirement for any type of framework protocol, | quite a difficult requirement for any type of framework protocol like | |||
like RTP, since one can never know all the deployment scenarios, and | RTP, or for that matter the Reliable Multicast Transport suite | |||
[RFC3048], since one can never know all the deployment scenarios, and | ||||
if they are covered by the security solution. It would clearly be | if they are covered by the security solution. It would clearly be | |||
desirable if a single media security solution and a single key | desirable if a single media security solution and a single key | |||
management solution could be developed, satisfying the range of use | management solution could be developed, satisfying the range of use | |||
cases for RTP. The authors are not aware of any such solution, | cases for RTP. The authors are not aware of any such solution, | |||
however, and it is not clear that any single solution can be | however, and believe it is unlikely that any single solution can be | |||
developed. | developed. | |||
For a framework protocol it appears that the only sensible solution | For a framework protocol it appears that the only sensible solution | |||
to the requirement of BCP 61 is to develop or use security building | to the requirement of BCP 61 is to develop or use security building | |||
blocks, like SRTP, SDP security descriptions [RFC4568], MIKEY, DTLS, | blocks, like SRTP, SDP security descriptions, MIKEY, DTLS, DTLS-SRTP, | |||
or IPsec, to provide the basic security services of authorization, | or IPsec, to provide the basic security services of authorization, | |||
data integrity protection and date confidentiality protection. When | data integrity protection and date confidentiality protection. When | |||
new usages of the RTP framework arise, one needs to analyze the | new usages of the RTP framework arise, one needs to analyze the | |||
situation, to determine if the existing building blocks satisfy the | situation, to determine if the existing building blocks satisfy the | |||
requirements. If not, it is necessary to develop new security | requirements. If not, it is necessary to develop new security | |||
building blocks. | building blocks. | |||
When it comes to fulfilling the "MUST Implement" strong security for | When it comes to fulfilling the "MUST Implement" strong security for | |||
a specific application, it will fall on that application to actually | a specific application, or class of applications, it will fall on | |||
consider what building blocks it is required to support. To maximize | that application to actually consider what building blocks it is | |||
interoperability it is desirable if certain applications, or classes | required to support. To maximize interoperability it is desirable if | |||
of application with similar requirements, agree on what data security | certain applications, or classes of application with similar | |||
mechanisms and key-management should be used. If such agreement is | requirements, agree on what data security mechanisms and key- | |||
not possible, there will be increased cost, either in the lack of | management should be used. If such agreement is not possible, there | |||
interoperability, or in the need to implement more solutions. | will be increased cost, either in the lack of interoperability, or in | |||
Unfortunately this situation, if not handled reasonably well, can | the need to implement more solutions. Unfortunately this situation, | |||
result in a failure to satisfy the requirement of providing the users | if not handled reasonably well, can result in a failure to satisfy | |||
with an option of turning on strong security when desired. | the requirement of providing the users with an option of turning on | |||
strong security when desired. | ||||
The IETF needs to perform this selection of security building blocks | ||||
whenever it is possible. This can be done if the application, or | ||||
class of applications, is being specified within the IETF, or wich a | ||||
scope where the IETF can take the role to provide a security profile. | ||||
However, it is clear that many applications, or classes of | ||||
application, are specified outside the scope and influence of the | ||||
IETF. In those case we can't do other than strongly recommend these | ||||
organizations perform a security analysis, taking into account other | ||||
applications, to try to maximize the security and interoperability. | ||||
6. Conclusions | 6. Conclusions | |||
As discussed earlier it appears that a single solution can't be | As discussed earlier it appears that a single solution can't be | |||
designed to meet the diverse requirements. In the absence of such a | designed to meet the diverse requirements. In the absence of such a | |||
solution, it is hoped that this memo explains why SRTP is not | solution, it is hoped that this memo explains why SRTP is not | |||
mandatory as the media security solution for RTP-based systems, and | mandatory as the media security solution for RTP-based systems, and | |||
why we can expect multiple key management solutions for systems using | why we can expect multiple key management solutions for systems using | |||
RTP. | RTP. | |||
It is important for any RTP-based application to consider how it | It is very important for any RTP-based application to consider how it | |||
meets the security requirements. This will require some analysis to | meets the security requirements. This will require some analysis to | |||
determine these requirements, followed by the selection of a | determine these requirements, followed by the selection of a | |||
mandatory to implement solution, or in exceptional scenarios several | mandatory to implement solution, or in exceptional scenarios several | |||
solutions, including the desired RTP traffic protection and key- | solutions, including the desired RTP traffic protection and key- | |||
management. SRTP is a preferred solution for the protection of the | management. When defining applications or protocols using RTP within | |||
RTP traffic in those use cases where it is applicable. It is out of | the IETF, the responsibility for fulfilling the BCP 61 requirements | |||
scope for this memo to recommend a preferred key management solution. | will fall onto the developers of these applications. IETF also | |||
should be open to help other standards bodies by defining security | ||||
profiles suitable for classes of applications. | ||||
Anyone defining an RTP based application needs to take care to | ||||
consider how to fulfill its security goals and specify which | ||||
mechanisms that are to be implemented. In that work interoperability | ||||
with similar applications should be considered, so that when such | ||||
applications becomes desirable to interconnect those applications, | ||||
their security solutions are compatible and will not require | ||||
additional implementation or costly gateways that also reduce | ||||
security by forcing a trusted third party. | ||||
SRTP is a preferred solution for the protection of the RTP traffic in | ||||
those use cases where it is applicable. It is out of scope for this | ||||
memo to recommend a preferred key management solution in general. | ||||
The authors do note that DTLS-SRTP was developed in the IETF to meet | ||||
the goals of point to point media sessions established by SIP. | ||||
7. Security Considerations | 7. Security Considerations | |||
This entire memo is about security. | This entire memo is about security. | |||
8. IANA Considerations | 8. IANA Considerations | |||
No IANA actions are required. | No IANA actions are required. | |||
9. Acknowledgements | 9. 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, and Keith Drage for their feedback. | Martin Ellis, Ali Begen, and Keith Drage for their feedback. | |||
10. Informative References | 10. Informative References | |||
[3GPP.33.210] | ||||
3GPP, "IP network layer security", 3GPP TS 33.210. | ||||
[ETSI.TS.102.474] | [ETSI.TS.102.474] | |||
ETSI, "Digital Video Broadcasting (DVB); IP Datacast over | ETSI, "Digital Video Broadcasting (DVB); IP Datacast over | |||
DVB-H: Service Purchase and Protection", ETSI TS 102 474, | DVB-H: Service Purchase and Protection", ETSI TS 102 474, | |||
November 2007. | November 2007. | |||
[I-D.ietf-mmusic-rfc2326bis] | [I-D.ietf-mmusic-rfc2326bis] | |||
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., | |||
and M. Stiemerling, "Real Time Streaming Protocol 2.0 | and M. Stiemerling, "Real Time Streaming Protocol 2.0 | |||
(RTSP)", draft-ietf-mmusic-rfc2326bis-23 (work in | (RTSP)", draft-ietf-mmusic-rfc2326bis-28 (work in | |||
progress), March 2010. | progress), October 2011. | |||
[I-D.zimmermann-avt-zrtp] | [ISMA] Internet Streaming Media Alliance, "Encryption and | |||
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media | Authentication Version 2.0", November 2007. | |||
Path Key Agreement for Unicast Secure RTP", | ||||
draft-zimmermann-avt-zrtp-22 (work in progress), | ||||
June 2010. | ||||
[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". | |||
[MBMS-SEC] | [MBMS-SEC] | |||
3GPP, "Security of Multimedia Broadcast/Multicast Service | 3GPP, "Security of Multimedia Broadcast/Multicast Service | |||
(MBMS) TS 33.246". | (MBMS) TS 33.246". | |||
[OMA-DRM] Open Mobile Alliance, "DRM Specification 2.0". | [OMA-DRM] Open Mobile Alliance, "DRM Specification 2.0". | |||
[PSS] 3GPP, "Transparent end-to-end Packet-switched Streaming | [PSS] 3GPP, "Transparent end-to-end Packet-switched Streaming | |||
Service (PSS); Protocols and codecs TS 26.234". | Service (PSS); Protocols and codecs TS 26.234". | |||
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, | |||
August 1980. | August 1980. | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
RFC 793, September 1981. | RFC 793, September 1981. | |||
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., | ||||
Floyd, S., and M. Luby, "Reliable Multicast Transport | ||||
Building Blocks for One-to-Many Bulk-Data Transfer", | ||||
RFC 3048, January 2001. | ||||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | |||
A., Peterson, J., Sparks, R., Handley, M., and E. | A., Peterson, J., Sparks, R., Handley, M., and E. | |||
Schooler, "SIP: Session Initiation Protocol", RFC 3261, | Schooler, "SIP: Session Initiation Protocol", RFC 3261, | |||
June 2002. | June 2002. | |||
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | |||
with Session Description Protocol (SDP)", RFC 3264, | with Session Description Protocol (SDP)", RFC 3264, | |||
June 2002. | June 2002. | |||
[RFC3365] Schiller, J., "Strong Security Requirements for Internet | [RFC3365] Schiller, J., "Strong Security Requirements for Internet | |||
Engineering Task Force Standard Protocols", BCP 61, | Engineering Task Force Standard Protocols", BCP 61, | |||
RFC 3365, August 2002. | RFC 3365, August 2002. | |||
skipping to change at page 9, line 24 ¶ | skipping to change at page 10, line 22 ¶ | |||
RFC 3365, August 2002. | RFC 3365, August 2002. | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
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. | |||
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. | ||||
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, | ||||
August 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. | |||
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | ||||
Security", RFC 4347, April 2006. | ||||
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session | |||
Description Protocol", RFC 4566, July 2006. | Description Protocol", RFC 4566, July 2006. | |||
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. | [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. | |||
Carrara, "Key Management Extensions for Session | Carrara, "Key Management Extensions for Session | |||
Description Protocol (SDP) and Real Time Streaming | Description Protocol (SDP) and Real Time Streaming | |||
Protocol (RTSP)", RFC 4567, July 2006. | Protocol (RTSP)", RFC 4567, July 2006. | |||
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session | |||
Description Protocol (SDP) Security Descriptions for Media | Description Protocol (SDP) Security Descriptions for Media | |||
Streams", RFC 4568, July 2006. | Streams", RFC 4568, 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. | |||
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", | ||||
RFC 4960, September 2007. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |||
[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. | |||
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | |||
Security (DTLS) Extension to Establish Keys for the Secure | Security (DTLS) Extension to Establish Keys for the Secure | |||
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. | Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. | |||
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media | ||||
Path Key Agreement for Unicast Secure RTP", RFC 6189, | ||||
April 2011. | ||||
[TS-33210] | ||||
3GPP, "IP network layer security", 3GPP TS 33.210. | ||||
Authors' Addresses | Authors' Addresses | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | Department of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
UK | UK | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
End of changes. 34 change blocks. | ||||
85 lines changed or deleted | 153 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/ |