draft-ietf-avt-srtp-not-mandatory-06.txt   draft-ietf-avt-srtp-not-mandatory-07.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 1, 2011 Ericsson Expires: January 2, 2011 Ericsson
June 30, 2010 July 1, 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-06.txt draft-ietf-avt-srtp-not-mandatory-07.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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 1, 2011. This Internet-Draft will expire on January 2, 2011.
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 5, line 46 skipping to change at page 5, line 46
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 [RFC4567] protocol are appropriate keying
mechanisms, piggybacked onto the SDP [RFC4566] exchange. The mechanisms, piggybacked onto the SDP [RFC4566] exchange. The
infrastructure may be secured by protecting the SIP exchange using infrastructure may be secured by protecting the SIP exchange using
TLS or S/MIME, for example [RFC3261]. Protocols such as DTLS TLS or S/MIME, for example [RFC3261]. Protocols such as DTLS
[RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] may also be [RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp] are also appropriate
appropriate in such environments. 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 [RFC5764] or ZRTP [I-D.zimmermann-avt-zrtp]
are useful here. 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
 End of changes. 4 change blocks. 
6 lines changed or deleted 6 lines changed or added

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