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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------