draft-ietf-avt-srtp-not-mandatory-05.txt   draft-ietf-avt-srtp-not-mandatory-06.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: July 26, 2010 Ericsson Expires: January 1, 2011 Ericsson
January 22, 2010 June 30, 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-05.txt draft-ietf-avt-srtp-not-mandatory-06.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.
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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 1, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 45 skipping to change at page 4, line 45
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). The natural way to provide media
security for such client-server media applications is to use TLS security for such client-server media applications is to use TLS
[RFC5246] to protect the TCP connection, sending the RTP media data [RFC5246] 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 unnecessary, 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 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 [3GPP.33.210]. SRTP is, again, unnecessary
in such environments, and its use would only introduce overhead for in such environments, and its use would only introduce overhead for
no gain. no gain.
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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 The most common use case for RTP is probably point-to-point voice o A common use case for RTP is probably point-to-point voice calls
calls or centralised group conferences, negotiated using SIP or centralised group conferences, negotiated using SIP [RFC3261]
[RFC3261] with the SDP offer/answer model [RFC3264], operating on with the SDP offer/answer model [RFC3264], operating on a trusted
a trusted infrastructure. In such environments, SDP security infrastructure. In such environments, SDP security descriptions
descriptions [RFC4568] or the MIKEY [RFC4567] protocol are [RFC4568] or the MIKEY [RFC4567] protocol are appropriate keying
appropriate keying mechanisms, piggybacked onto the SDP [RFC4566] mechanisms, piggybacked onto the SDP [RFC4566] exchange. The
exchange. The infrastructure may be secured by protecting the SIP infrastructure may be secured by protecting the SIP exchange using
exchange using TLS or S/MIME, for example [RFC3261]. TLS or S/MIME, for example [RFC3261]. Protocols such as DTLS
[RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] may also be
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. is run on the media path, bypassing the untrusted infrastructure.
Protocols such as DTLS [RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp]
Protocols such as DTLS [I-D.ietf-avt-dtls-srtp] or 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 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 [I-D.ietf-sip-media-security-requirements]. protocols can be found in [RFC5479]. As can be seen, the range of
As can be seen, the range of use cases is wide, and there is no use cases is wide, and there is no single protocol that is
single protocol that is appropriate for all scenarios. These appropriate for all scenarios. These solutions have been further
solutions have been further diversified by the existence of diversified by the existence of infrastructure elements such as
infrastructure elements such as authentication solutions that are authentication solutions that are tied into the key manangement.
tied into the key manangement.
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 solutions. This is actually
quite a difficult requirement for any type of framework protocol, quite a difficult requirement for any type of framework protocol,
like RTP, since one can never know all the deployment scenarios, and like RTP, 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
skipping to change at page 8, line 8 skipping to change at page 8, line 8
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, and Ali Begen for their feedback. Martin Ellis, Ali Begen, and Keith Drage for their feedback.
10. Informative References 10. Informative References
[3GPP.33.210] [3GPP.33.210]
3GPP, "IP network layer security", 3GPP TS 33.210, 3GPP, "IP network layer security", 3GPP TS 33.210.
September 2008.
[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-avt-dtls-srtp]
McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for Secure
Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-07 (work in progress),
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-22 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-23 (work in
progress), July 2009. progress), March 2010.
[I-D.ietf-sip-media-security-requirements]
Wing, D., Fries, S., Tschofenig, H., and F. Audet,
"Requirements and Analysis of Media Security Management
Protocols", draft-ietf-sip-media-security-requirements-09
(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 Unicast Secure RTP",
draft-zimmermann-avt-zrtp-17 (work in progress), draft-zimmermann-avt-zrtp-22 (work in progress),
January 2010. 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".
skipping to change at page 10, line 10 skipping to change at page 9, line 46
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.
[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,
"Requirements and Analysis of Media Security Management
Protocols", RFC 5479, April 2009.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
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. 14 change blocks. 
52 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/