[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ram-straw-b2bua-dtls-srtp) 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 7879

STRAW                                                    R. Ravindranath
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                            G. Salgueiro
Expires: May 25, 2016                                              Cisco
                                                              V. Pascual
                                                                  Quobis
                                                Parthasarathi. Ravindran
                                                          Nokia Networks
                                                       November 22, 2015


  DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
                          User Agents (B2BUAs)
                  draft-ietf-straw-b2bua-dtls-srtp-09

Abstract

   Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
   often act on the media plane rather than just on the signaling path.
   This document describes the behaviour of such B2BUAs when acting on
   the media plane that uses an Secure Real-time Transport (SRTP)
   security context set up with the Datagram Transport Layer Security
   (DTLS) protocol.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 25, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Ravindranath, et al.      Expires May 25, 2016                  [Page 1]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Media Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . .   4
     3.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Media Relay . . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  RTP/RTCP-aware Media Aware B2BUA  . . . . . . . . . .   6
     3.2.  Media Plane B2BUA with NAT Handling . . . . . . . . . . .   7
   4.  Forking Considerations  . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

1.1.  Overview

   [RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261]
   can be used to establish a Secure Real-time Transport Protocol (SRTP)
   [RFC3711] security context with the Datagram Transport Layer Security
   (DTLS) [RFC6347] protocol.  It describes a mechanism for transporting
   a certificate fingerprint using Session Description Protocol (SDP)
   [RFC4566].  The fingerprint identifies the certificate that will be
   presented during the DTLS handshake.  DTLS-SRTP is currently defined
   for point-to-point media sessions, in which there are exactly two
   participants.  Each DTLS-SRTP session (described in Section 3 of
   [RFC5764]) contains a single DTLS connection (if RTP and RTCP are
   multiplexed) or two DTLS connections (if RTP and RTCP are not
   multiplexed), and either two SRTP contexts (if media traffic is
   flowing in both directions on the same 5-tuple) or one SRTP context
   (if media traffic is only flowing in one direction).




Ravindranath, et al.      Expires May 25, 2016                  [Page 2]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   In many SIP deployments, SIP Back-to-Back User Agents (B2BUA)
   entities exist on the SIP signaling path between the endpoints.  As
   described in [RFC7092], these B2BUAs can modify SIP and SDP
   information.  They can also be present on the media path, in which
   case they modify parts of the SDP information (like IP address, port)
   and subsequently modify the RTP headers as well.  Such B2BUAs are
   referred to as media plane B2BUAs.

1.2.  Goals

   [RFC7092] describes two different categories of media plane B2BUAs,
   according to the level of activities performed on the media plane:

      A B2BUA that acts as a simple media relay effectively unaware of
      anything that is transported and only terminates the media plane
      at the IP and transport (UDP/TCP) layers.

      A B2BUA that performs a media-aware role.  It inspects and
      potentially modifies RTP headers or RTP Control Protocol (RTCP)
      packets.

   The following sections describe the behavior B2BUAs can follow to
   avoid breaking end-to-end DTLS-SRTP sessions.  B2BUAs terminating
   DTLS-SRTP session are outside the scope of this document.  When
   [RFC4474] is used for DTLS-SRTP sessions, the fingerprint attributes
   are integrity protected.  Thus, under circumstances when [RFC4474] is
   used, B2BUAs cannot terminate the DTLS-SRTP session without
   invalidating the signature and causing the session to fail.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Transport Address: The combination of an IP address and port number.

   The following generalized terms are defined in [RFC3261], Section 6.

      B2BUA: a SIP Back-to-Back User Agent, which is the logical
      combination of a User Agent Server (UAS) and User Agent Client
      (UAC).

      UAS: a SIP User Agent Server.

      UAC: a SIP User Agent Client.





Ravindranath, et al.      Expires May 25, 2016                  [Page 3]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   All of the pertinent B2BUA terminology and taxonomy used in this
   document is based on [RFC7092].

   It is assumed the reader is already familiar with the fundamental
   concepts of the RTP protocol [RFC3550] and its taxonomy
   [I-D.ietf-avtext-rtp-grouping-taxonomy], as well as those of SRTP
   [RFC3711], and DTLS [RFC6347].

3.  Media Plane B2BUA Handling of DTLS-SRTP

3.1.  General

   This section describes the DTLS-SRTP handling by the different types
   of media plane B2BUAs defined in [RFC7092].

3.1.1.  Media Relay

   A media relay, as defined in section 3.2.1 of [RFC7092], from an
   application layer point-of-view, forwards all packets it receives on
   a negotiated connection, without inspecting or modifying the packet
   contents.  A media relay only modifies the transport layer (UDP/TCP)
   and IP headers.

   A media relay B2BUA MUST forward the certificate fingerprint and SDP
   setup attribute it receives from one endpoint unmodified towards the
   other endpoint and vice-versa.  The example below shows a SIP call
   establishment flow, with both SIP endpoints (user agents) using DTLS-
   SRTP, and a media relay B2BUA.























Ravindranath, et al.      Expires May 25, 2016                  [Page 4]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


       +-------+            +------------------+              +-----+
       | Alice |            | MediaRelay B2BUA |              | Bob |
       +-------+            +------------------+              +-----+
           |(1) INVITE               |  (3)INVITE                |
           |   a=setup:actpass       |   a=setup:actpass         |
           |   a=fingerprint1        |   a=fingerprint1          |
           |   (alice's IP/port)     |   (B2BUAs IP/port)        |
           |------------------------>|-------------------------->|
           |                         |                           |
           |    (2)  100 trying      |                           |
           |<------------------------|                           |
           |                         | (4) 100 trying            |
           |                         |<--------------------------|
           |                         |                           |
           |                         |  (5)200 OK                |
           |                         |   a=setup:active          |
           |                         |    a=fingerprint2         |
           |                         |  (Bob's IP/port)          |
           |<------------------------|<--------------------------|
           |    (6) 200 OK           |                           |
           |    a=setup:active       |                           |
           |    a=fingerprint2       |                           |
           |    B2BUAs IP/port       |                           |
           |               (7, 8)ClientHello + use_srtp          |
           |<------------------------|<--------------------------|
           |                         |                           |
           |                         |                           |
           |           (9,10)ServerHello + use_srtp              |
           |------------------------>|-------------------------->|
           |                 (11)    |                           |
           |  [Certificate exchange between Alice and Bob over   |
           |   DTLS ]                |                           |
           |                         |                           |
           |         (12)            |                           |
           |<---------SRTP/SRTCP---->|<----SRTP/SRTCP----------->|
           | [B2BUA changes transport(UDP/TCP) and IP headers]   |

         Figure 1: INVITE with SDP call-flow for Media Relay B2BUA

   NOTE: For brevity the entire value of the SDP fingerprint attribute
   is not shown.  The example here shows only one DTLS connection for
   the sake of simplicity.  In reality depending on whether the RTP and
   RTCP flows are multiplexed or demultiplexed there will be one or two
   DTLS connections.

   If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a
   single port then only a single DTLS connection is required between
   the peers.  If RTP and RTCP are not multiplexed, then the peers would



Ravindranath, et al.      Expires May 25, 2016                  [Page 5]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   have to establish two DTLS connections.  In this case, Bob, after he
   receives an INVITE request, triggers the establishment of a DTLS
   connection.  Note that the DTLS handshake and the sending of INVITE
   response can happen in parallel; thus, the B2BUA MUST be prepared to
   receive DTLS, STUN and media on the ports it advertised to Bob in the
   SDP offer before it receives a SDP answer from Bob. Since a media
   relay B2BUA does not differentiate between a DTLS message, RTP or any
   packet it receives, it only changes the transport layer (UDP/TCP) and
   IP headers and forwards the packet towards the other endpoint.  The
   B2BUA cannot decrypt the RTP payload as the payload is encrypted
   using the SRTP keys derived from the DTLS connection setup between
   Alice and Bob.

   [RFC4474] provides a means for signing portions of SIP requests in
   order to provide identity assurance and certificate pinning by
   providing a signature over the SDP that carries the fingerprint of
   keying for DTLS-SRTP [RFC5763].  A media relay B2BUA MUST ensure that
   it does not modify any of the information used to construct the
   signature.

   In the above example, Alice can be authorized by the authorization
   server (SIP proxy) in its domain using the procedures in Section 5 of
   [RFC4474].  In such a case, if the B2BUA modifies some of the SIP
   headers or SDP content that was used by Alice's authorization server
   to generate the identity signature and place it in the Identity
   header field, it would break the identity verification procedure
   explained in Section 6 of [RFC4474] resulting in a 438 error response
   being returned.

3.1.2.  RTP/RTCP-aware Media Aware B2BUA

   Unlike the media relay discussed in Section 3.1.1, a media-aware
   relay as defined in Section 3.2.2 of [RFC7092], is aware of the type
   of media traffic it is receiving.  There are two types of media-aware
   relays, those that merely inspect the RTP headers and unencrypted
   portions of RTCP packets, and those that inspect and modify the RTP
   headers and unencrypted portions of RTCP packets.  The identity
   integrity protection procedures described in Section 5 can be used by
   the endpoint or the proxy server in the endpoints network to detect
   malicious B2BUAs that attempt to terminate the DTLS-SRTP session.

3.1.2.1.  RTP header and RTCP packets Inspection

   A RTP/RTCP aware media relay does not modify the RTP headers and RTCP
   packets but only inspects the packets.  It is RECOMMENDED that these
   B2BUAs do not terminate DTLS-SRTP session on which the packets are
   received.




Ravindranath, et al.      Expires May 25, 2016                  [Page 6]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


3.1.2.2.  RTP header and RTCP packet Modification

   A B2BUA cannot modify RTP headers or RTCP packets, as to do so it
   would need to act as a DTLS endpoint, terminate the DTLS-SRTP session
   and decrypt/re-encrypt RTP packet.  This would cause the identity and
   integrity protection procedures discussed in [RFC4474] to fail.  This
   security and privacy problem can be mitigated by having different
   keys for protecting RTP header integrity and encrypting the RTP
   payload.  For example, the approach discussed in
   [I-D.jones-perc-private-media-reqts] can be used.  With such an
   approach, the B2BUA is not aware of the keys used to decrypt the
   media payload.

3.2.  Media Plane B2BUA with NAT Handling

   DTLS-SRTP handshakes and SDP offer/answer exchanges [RFC3264] may
   happen in parallel.  If an endpoint is behind a NAT, and the endpoint
   is acting as a DTLS server, the ClientHello message from a B2BUA
   (acting as DTLS client) is likely to be lost, as described in
   Section 7.3 of [RFC5763].  In order to overcome this problem, the
   endpoint and B2BUA can support the Interactive Connectivity
   Establishment (ICE) mechanism [RFC5245], as discussed in Section 7.3
   of [RFC5763].  If the ICE check is successful then the endpoint will
   receive the ClientHello message from the B2BUA.

4.  Forking Considerations

   Due to forking [RFC3261], a SIP request carrying an SDP offer sent by
   an endpoint (offerer) can reach multiple remote endpoints.  As a
   result, multiple DTLS-SRTP sessions can be established, one between
   the endpoint that sent the SIP request and each of the remote
   endpoints that received the request.  Both media relays and media-
   aware relays MUST forward the certificate fingerprints and SDP setup
   attributes it received in the SDP answer from each endpoint
   (answerer) unmodified towards the offerer.  Since each DTLS
   connection is setup on a unique 5-tuple, B2BUA MUST replace the
   answerer's transport addresses in each answer with its unique
   transport addresses so that the offerer can establish a DTLS
   connection with each answerer.












Ravindranath, et al.      Expires May 25, 2016                  [Page 7]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


                                             Bob (192.0.2.1:6666)
                                            /
                                           /
                                          / DTLS-SRTP=XXX
                                         /
                                        /
                         DTLS-SRTP=XXX v
                         <----------->  (192.0.2.3:7777)
   Alice (192.0.2.0:5555)             B2BUA
                         <----------->  (192.0.2.3:8888)
                         DTLS-SRTP=YYY ^
                                        \
                                         \  DTLS-SRTP=YYY
                                          \
                                           \
                                            \
                                             Charlie (192.0.2.2:6666)

                 Figure 2: B2BUA handling multiple answers

   For instance, as shown in Figure 2 Alice sends a request with an
   offer, and the request is forked.  Alice receives answers from both
   Bob and Charlie.  B2BUA MUST advertise different B2BUA transport
   address in each answer, as shown in Figure2, where XXX and YYY
   represent different DTLS-SRTP sessions.  B2BUA replaces Bob's
   transport address (192.0.2.1:6666) in the answer with its transport
   address (192.0.2.3:7777) and Charlie's transport address
   (192.0.2.2:6666) in the answer with its transport address
   (192.0.2.3:8888).  B2BUA tracks the remote sources (Bob and Charlie)
   and associates them to the local sources that are used to send
   packets to Alice.

5.  Security Considerations

   This document describes the behavior media plane B2BUAs (media-aware
   and media-unaware) MUST follow when acting on the media plane that
   uses SRTP security context setup with the DTLS protocol.  Attempting
   to cover media-aware relay modifying RTP headers and media
   termination scenarios involving secure sessions (like DTLS-SRTP) will
   inevitably lead to the B2BUA acting as a man-in-the-middle, and hence
   it is RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session.
   Security considerations discussed in [RFC5763] are also applicable to
   this document.  In addition, the B2BUA behaviors outlined in this
   document do not impact the security and integrity of a DTLS-SRTP
   session or the data exchanged over it.  A malicious B2BUA can try to
   break into the DTLS connection, but such an attack can be prevented
   using the identity validation mechanism discussed in [RFC4474].
   Either the endpoints or authentication service proxies involved in



Ravindranath, et al.      Expires May 25, 2016                  [Page 8]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   the call MUST use the identity validation mechanisms discussed in
   [RFC4474] to validate the identity of peers and detect malicious
   B2BUA's that can attempt to terminate the DTLS connection to decrypt
   the RTP payload.

6.  IANA Considerations

   This document makes no request of IANA.

7.  Acknowledgments

   Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan,
   Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing,
   Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa,
   Christer Holmberg, Colin Perkins and Ben Campbell for their
   constructive comments, suggestions, and early reviews that were
   critical to the formulation and refinement of this document.  The
   authors would also like to thank Dan Romascanu, Vijay K.  Gurbani,
   Francis Dupont and Paul Wouters for their review and feedback of this
   document.

8.  Contributors

   Rajeev Seth provided substantial contributions to this document.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.








Ravindranath, et al.      Expires May 25, 2016                  [Page 9]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474,
              DOI 10.17487/RFC4474, August 2006,
              <http://www.rfc-editor.org/info/rfc4474>.

   [RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
              for Establishing a Secure Real-time Transport Protocol
              (SRTP) Security Context Using Datagram Transport Layer
              Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
              2010, <http://www.rfc-editor.org/info/rfc5763>.

   [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,
              DOI 10.17487/RFC5764, May 2010,
              <http://www.rfc-editor.org/info/rfc5764>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

9.2.  Informative References

   [I-D.ietf-avtext-rtp-grouping-taxonomy]
              Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
              B. Burman, "A Taxonomy of Semantics and Mechanisms for
              Real-Time Transport Protocol (RTP) Sources", draft-ietf-
              avtext-rtp-grouping-taxonomy-08 (work in progress), July
              2015.

   [I-D.jones-perc-private-media-reqts]
              Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson,
              J., and R. Barnes, "Private Media Requirements in Privacy
              Enhanced RTP Conferencing", draft-jones-perc-private-
              media-reqts-00 (work in progress), July 2015.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.




Ravindranath, et al.      Expires May 25, 2016                 [Page 10]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              DOI 10.17487/RFC5245, April 2010,
              <http://www.rfc-editor.org/info/rfc5245>.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761,
              DOI 10.17487/RFC5761, April 2010,
              <http://www.rfc-editor.org/info/rfc5761>.

   [RFC7092]  Kaplan, H. and V. Pascual, "A Taxonomy of Session
              Initiation Protocol (SIP) Back-to-Back User Agents",
              RFC 7092, DOI 10.17487/RFC7092, December 2013,
              <http://www.rfc-editor.org/info/rfc7092>.

Authors' Addresses

   Ram Mohan Ravindranath
   Cisco
   Cessna Business Park
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com


   Tirumaleswar Reddy
   Cisco
   Cessna Business Park
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com











Ravindranath, et al.      Expires May 25, 2016                 [Page 11]


Internet-Draft       DTLS-SRTP Handling in SIP B2BUA       November 2015


   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: gsalguei@cisco.com


   Victor Pascual
   Quobis

   Email: victor.pascual.avila@gmail.com


   Parthasarathi Ravindran
   Nokia Networks
   Bangalore, Karnataka
   India

   Email: partha@parthasarathi.co.in






























Ravindranath, et al.      Expires May 25, 2016                 [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/