draft-ietf-avt-srtp-not-mandatory-04.txt | draft-ietf-avt-srtp-not-mandatory-05.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: June 25, 2010 Ericsson | Expires: July 26, 2010 Ericsson | |||
December 22, 2009 | January 22, 2010 | |||
Why RTP Does Not Mandate a Single Security Mechanism | Why RTP Does Not Mandate a Single Security Mechanism | |||
draft-ietf-avt-srtp-not-mandatory-04.txt | draft-ietf-avt-srtp-not-mandatory-05.txt | |||
Abstract | ||||
This memo discusses the problem of securing real-time multimedia | ||||
sessions, and explains why the Real-time Transport Protocol (RTP), | ||||
and the associated RTP control protocol (RTCP), do not mandate a | ||||
single media security mechanism. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
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." | |||
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 June 25, 2010. | This Internet-Draft will expire on July 26, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 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 in effect on the date of | Provisions Relating to IETF Documents | |||
publication of this document (http://trustee.ietf.org/license-info). | (http://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | ||||
Abstract | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | ||||
This memo discusses the problem of securing real-time multimedia | described in the Simplified BSD License. | |||
sessions, and explains why the Real-time Transport Protocol (RTP), | ||||
and the associated RTP control protocol (RTCP), do 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 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 . . . 6 | |||
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
skipping to change at page 3, line 21 | skipping to change at page 3, line 21 | |||
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. | |||
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. Section 2 describes the | |||
describing the scenarios in which RTP is deployed. Following this, | scenarios in which RTP is deployed. Following this, Section 3 | |||
Section 3 outlines the implications of this range of scenarios for | outlines the implications of this range of scenarios for media | |||
media confidentially and authentication, and Section 4 outlines the | 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 meets the requirement of BCP 61. Section 6 then concludes | |||
and gives some recommendations. Finally, Section 7 outlines the | and gives some recommendations. | |||
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 | |||
skipping to change at page 5, line 22 | skipping to change at page 5, line 22 | |||
[ETSI.TS.102.474], where one mode of operation uses ISMAcryp | [ETSI.TS.102.474], where one mode of operation uses ISMAcryp | |||
(http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP | (http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP | |||
payload data only. | payload data only. | |||
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 commercial | |||
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 | |||
With such a diverse range of use case 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 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 | calls or centralised group conferences, negotiated using SIP | |||
[RFC3261] with the SDP offer/answer model [RFC3264], operating on | [RFC3261] with the SDP offer/answer model [RFC3264], operating on | |||
skipping to change at page 6, line 12 | skipping to change at page 6, line 12 | |||
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. | |||
Protocols such as DTLS [I-D.ietf-avt-dtls-srtp] or ZRTP | Protocols such as DTLS [I-D.ietf-avt-dtls-srtp] or ZRTP | |||
[I-D.zimmermann-avt-zrtp] are useful here. | [I-D.zimmermann-avt-zrtp] are useful here. | |||
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. | |||
o A session description may be sent by email, secured using X.500 or | o A session description may be sent by email, secured using S/MIME | |||
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, | |||
skipping to change at page 8, line 31 | skipping to change at page 8, line 31 | |||
[I-D.ietf-avt-dtls-srtp] | [I-D.ietf-avt-dtls-srtp] | |||
McGrew, D. and E. Rescorla, "Datagram Transport Layer | McGrew, D. and E. Rescorla, "Datagram Transport Layer | |||
Security (DTLS) Extension to Establish Keys for Secure | Security (DTLS) Extension to Establish Keys for Secure | |||
Real-time Transport Protocol (SRTP)", | Real-time Transport Protocol (SRTP)", | |||
draft-ietf-avt-dtls-srtp-07 (work in progress), | draft-ietf-avt-dtls-srtp-07 (work in progress), | |||
February 2009. | February 2009. | |||
[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-21 (work in | (RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in | |||
progress), June 2009. | progress), July 2009. | |||
[I-D.ietf-sip-media-security-requirements] | [I-D.ietf-sip-media-security-requirements] | |||
Wing, D., Fries, S., Tschofenig, H., and F. Audet, | Wing, D., Fries, S., Tschofenig, H., and F. Audet, | |||
"Requirements and Analysis of Media Security Management | "Requirements and Analysis of Media Security Management | |||
Protocols", draft-ietf-sip-media-security-requirements-09 | Protocols", draft-ietf-sip-media-security-requirements-09 | |||
(work in progress), January 2009. | (work in progress), January 2009. | |||
[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-15 (work in progress), | draft-zimmermann-avt-zrtp-17 (work in progress), | |||
March 2009. | January 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". | |||
End of changes. 13 change blocks. | ||||
31 lines changed or deleted | 34 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/ |