Re: [rtcweb] SRTP mandatory to implement versus mandatory to use

[Bernard Aboba <[e-mail]>]

The problem is that WebRTC is not actually a single use case or "application" -- 
it is a framework that could be used to implement applications, including 
many of the unicast use cases described in the srtp-not-mandatory draft. 

As the srtp-not-mandatory draft points out, it is hard for one keying scheme to 
handle a wide range of scenarios.  Even if we exclude the multicast cases, 
there is enough diversity in the unicast scenarios described in the use case 
document (e.g. point-to-point and conferencing) for the logic to still hold up. 

> Date: Thu, 10 Nov 2011 11:01:38 +0100
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> Subject: Re: [rtcweb] SRTP mandatory to implement versus mandatory to use
> 
> Hi,
> 
> Regarding the srtp-not-mandatory draft. In the discussion I have so far 
> had with for example the security ADs one conclusion is that when we get 
> into something that is actually an application or class of applications 
> and when that is specified by IETF, IETF do need to pick at least one 
> mandatory to implement solution.
> 
> As WebRTC is an application using RTP this becomes very applicable to 
> the WebRTC work. We do need to pick at least one mandatory to implement 
> keying mechanism. We might pick additional mandatory ones if we think 
> that is necessary to address the space of usages we see. I think that is 
> what the WG must come to consensus on.
> 
> Cheers
> 
> Magnus
> 
> On 2011-11-09 02:25, Bernard Aboba wrote:
> > I support SRTP being "mandatory to implement" but not "mandatory to use".
> >
> > With respect to mandating a keying mechanism, I would point out the
> > arguments in the following document:
> >
> > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory
> >
> > It appears that the arguments made in this document also apply to RTCWEB
> > in that many (though not all) of the use cases mentioned there are also
> > to be supported by RTCWEB, potentially leading to disparate keying
> > requirements.
> >
> >
> >     2. RTP Applications and Deployment Scenarios
> >
> > The range of application and deployment scenarios where RTP has been
> > Perkins & Westerlund Expires May 3, 2012 [Page 3]
> >
> >      used includes, but is not limited to, the following:
> >
> >     o  Point-to-point voice telephony (fixed and wireless networks)
> >
> >     o  Point-to-point voice and video conferencing
> >
> >     o  Centralised group video conferencing with a multipoint conference
> >        unit (MCU)
> >
> >     o  Any Source Multicast video conferencing (light-weight sessions;
> >        Mbone conferencing)
> >
> >     o  Point-to-point streaming audio and/or video
> >
> >     o  Source-specific multicast (SSM) streaming to large group (IPTV and
> >        3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-MBMS>])
> >
> >     o  Replicated unicast streaming to a group
> >
> >     o  Interconnecting components in music production studios and video
> >        editing suites
> >
> >     o  Interconnecting components of distributed simulation systems
> >
> >     o  Streaming real-time sensor data
> >
> >     As can be seen, these scenarios vary from point-to-point to very
> >     large multicast groups, from interactive to non-interactive, and from
> >     low bandwidth (kilobits per second) to very high bandwidth (multiple
> >     gigabits per second).  While most of these applications run over UDP
> >     [RFC0768  <http://tools.ietf.org/html/rfc0768>], some use TCP [RFC0793  <http://tools.ietf.org/html/rfc0793>], [RFC4614  <http://tools.ietf.org/html/rfc4614>] or DCCP [RFC4340  <http://tools.ietf.org/html/rfc4340>] as
> >     their underlying transport.  Some run on highly reliable optical
> >     networks, others use low rate unreliable wireless networks.  Some
> >     applications of RTP operate entirely within a single trust domain,
> >     others are inter-domain, with untrusted (and potentially unknown)
> >     users.  The range of scenarios is wide, and growing both in number
> >     and in heterogeneity.
> >
> >
> >
> >
> >     3. Implications for RTP Security
> >
> >
> >
> >     The wide range of application scenarios where RTP is used has led to
> >     the development of multiple solutions for securing RTP media streams
> >     and RTCP control messages, considering different requirements.
> >     Perhaps the most widely applicable of these solutions is the Secure
> >     RTP (SRTP) framework [RFC3711  <http://tools.ietf.org/html/rfc3711>].  This is an application-level media
> >     security solution, encrypting the media payload data (but not the RTP
> >     headers) to provide some degree of confidentiality, and providing
> >
> >     optional source origin authentication.  It was carefully designed to
> >     be both low overhead, and to support the group communication features
> >     of RTP, across a range of networks.
> >
> >     SRTP is not the only media security solution in use, however, and
> >     alternatives are more appropriate for some scenarios.  For example,
> >     many client-server streaming media applications can run over a single
> >     TCP connection, multiplexing media data with control information on
> >     that connection (RTSP [I-D.ietf-mmusic-rfc2326bis  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-I-D.ietf-mmusic-rfc2326bis>] is a widely used
> >     example of such a protocol).  One way to provide media security for
> >     such client-server media applications is to use TLS [RFC5246  <http://tools.ietf.org/html/rfc5246>] to
> >     protect the TCP connection, sending the RTP media data over the TLS
> >     connection.  Using the SRTP framework in addition to TLS 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 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 [TS-33210  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-TS-33210>].  SRTP is, again, unnecessary in
> >     such environments, and its use would only introduce overhead for no
> >     gain.
> >
> >     For some applications it is sufficient to protect the RTP payload
> >     data while leaving RTP, transport, and network layer headers
> >     unprotected.  An example of this is RTP broadcast over DVB-H
> >     [ETSI.TS.102.474  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-ETSI.TS.102.474>], where one mode of operation uses ISMA Cryp 2.0
> >     [ISMA  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-ISMA>] to encrypt the RTP payload data only.
> >
> >     All these are application scenarios where RTP has seen commercial
> >     deployment.  Other use cases exist, with additional requirements.
> >     For example, if the media transport is done over UDP [RFC0768  <http://tools.ietf.org/html/rfc0768>], DCCP
> >     [RFC4340  <http://tools.ietf.org/html/rfc4340>] or SCTP [RFC4960  <http://tools.ietf.org/html/rfc4960>], then using DTLS [RFC4347  <http://tools.ietf.org/html/rfc4347>] to protect the
> >     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
> >
> >
> >
> >     With such a diverse range of use cases come a range of different
> >     protocols for RTP session establishment.  Mechanisms used to provide
> >     security keying for these different session establishment protocols
> >     can basically be put into two categories: inband and out-of-band in
> >     relation to the session establishment mechanism.  The requirements
> >     for these solutions are highly varying.  Thus a wide range of
> >
> >    solutions have been developed in this space:
> >
> >     o  A common use case for RTP is probably point-to-point voice calls
> >        or centralised group conferences, negotiated using SIP [RFC3261  <http://tools.ietf.org/html/rfc3261>]
> >        with the SDP offer/answer model [RFC3264  <http://tools.ietf.org/html/rfc3264>], operating on a trusted
> >        infrastructure.  In such environments, SDP security descriptions
> >        [RFC4568  <http://tools.ietf.org/html/rfc4568>], or the MIKEY [RFC3830  <http://tools.ietf.org/html/rfc3830>] protocol using the Key
> >        Management Extensions for SDP [RFC4567  <http://tools.ietf.org/html/rfc4567>], are appropriate keying
> >        mechanisms, where the keying messages/material are embedded in the
> >        SDP [RFC4566  <http://tools.ietf.org/html/rfc4566>] exchange.  The infrastructure may be secured by
> >        protecting the SDP exchange in SIP using TLS or S/MIME, for
> >        example [RFC3261  <http://tools.ietf.org/html/rfc3261>].  Protocols such as DTLS-SRTP [RFC5764  <http://tools.ietf.org/html/rfc5764>] or ZRTP
> >        [RFC6189  <http://tools.ietf.org/html/rfc6189>] are also appropriate in such environments.
> >
> >     o  Point-to-point RTP sessions may be negotiated using SIP with the
> >        offer/answer model, but operating over a network with untrusted
> >        infrastructure.  In such environments, the key management protocol
> >        can be run on the media path, bypassing the untrusted
> >        infrastructure.  Protocols such as DTLS-SRTP [RFC5764  <http://tools.ietf.org/html/rfc5764>] or ZRTP
> >        [RFC6189  <http://tools.ietf.org/html/rfc6189>] are useful here, as are inband mechanism that protect
> >        the keying material such as MIKEY [RFC3830  <http://tools.ietf.org/html/rfc3830>] using the Key
> >        Management Extensions for SDP [RFC4567  <http://tools.ietf.org/html/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
> >        association is appropriate to manage keying material, in much the
> >        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
> >        or PGP, or retrieved from a web page, using HTTP with TLS.
> >
> >     o  A session description may be distributed to a multicast group
> >        using SAP or FLUTE secured with S/MIME.
> >
> >     o  A session description may be distributed using the Open Mobile
> >        Alliance DRM key management specification [OMA-DRM  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-OMA-DRM>] when using a
> >        point-to-point streaming session setup with RTSP in the 3GPP PSS
> >        environment [PSS  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-PSS>].
> >
> >     o  In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system,
> >        HTTP and MIKEY are used for key management [MBMS-SEC  <http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-MBMS-SEC>].
> >
> >     A more detailed survey of requirements for media security management
> >     protocols can be found in [RFC5479  <http://tools.ietf.org/html/rfc5479>].  As can be seen, the range of
> >     use cases is wide, and there is no single protocol that is
> >     appropriate for all scenarios.  These solutions have been further
> >
> >    diversified by the existence of infrastructure elements such as
> >     authentication solutions that are tied into the key management.
> >
> >
> >
> >
> >
> > Magnus said:
> >
> >
> > "Yes, we haven't spent much time on the security consideration section
> > yet. "A mandatory to implement media security solution will be required
> > to be picked" is pointer at this WG not the implementor.
> >
> > I would also point at our Charter that in its last paragraph says:
> > "The products of the working group will support security and keying as
> > required by BCP 61"
> >
> > If you haven't read BCP 61 you probably should. It is basically says two
> > things. IETF should pick strong security and it shall be MANDATORY to
> > IMPLEMENT. I at least as chair will ensure that we have fulfilled this.
> > And that means for RTP not only encryption and integrity protection,
> > probably SRTP, but also a keying method.
> >
> > Yes, we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP is
> > a MUST implement as soon as we have that consensus established. But we
> > will need a keying scheme also and determine where it should be documented.
> >
> > Cheers
> >
> > Magnus Westerlund
> > "
> >
> >
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>