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

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

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 behavior such B2BUAs should adhere to 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 February 22, 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 (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

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 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, 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).

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 may modify SIP and SDP information. They may also be present on the media path, in which case they may 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 or RTP Control Protocol (RTCP) headers; but it does not modify the payload of RTP/RTCP.

The following sections describe the behavior B2BUAs should follow in order to avoid any impact to end-to-end DTLS-SRTP streams.

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

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.

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.

 +-------+            +------------------+              +-----+         
 | 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 would be required between the peers. If RTP and RTCP are not multiplexed, then the peers would 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 may happen in parallel; thus, the B2BUA SHOULD be prepared to receive DTLS, STUN and media on the ports it advertised to Bob in the INVITE request. 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.

[I-D.ietf-stir-rfc4474bis] provides a means for signing portions of SIP requests in order to provide identity assurance and certificate pinning by providing a signature over the fingerprint of keying material in SDP 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 may be authorized by the authorization server (SIP proxy) in its domain using the procedures in Section 5 of [I-D.ietf-stir-rfc4474bis]. 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, it would break the identity verification procedure explained in Section 4.2 of [I-D.ietf-stir-rfc4474bis] resulting in a 438 error response being returned.

3.1.2. 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. A media-aware relay inspects received SRTP and SRTCP packets and may modify the headers before forwarding the packets.

3.1.2.1. RTP and RTCP Header Inspection

A media-aware relay does not modify the RTP and RTCP headers but only inspects the header values. It MUST NOT terminate the DTLS-SRTP connection on which the packets are received.

3.1.2.2. RTP and RTCP Header Modification

In addition to inspecting the RTP and RTCP headers, a media-aware relay may also modify them. In order to modify headers a B2BUA needs to act as a DTLS endpoint and terminate the DTLS connection and decrypt/re-encrypt RTP packets. This would break end-to-end security and hence a B2BUA MUST NOT terminate DTLS-SRTP sessions. This security and privacy problem can be mitigated by having separate keys for encrypting the RTP header and media payload as discussed in [I-D.jones-perc-private-media-reqts]. 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) may reach multiple remote endpoints. As a result, multiple DTLS-SRTP connections may 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 DTLS operates on the 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.

                                          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 connections. B2BUA replaces the 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) should follow when acting on the media plane that uses SRTP security context setup with the DTLS protocol. Attempting to cover media-aware relay and media termination scenarios involving secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA acting as a man-in-the-middle, and as such its behavior is unspecified and discouraged. This document does not introduce any specific security considerations beyond those detailed in [RFC5763]. In addition, the B2BUA behaviors outlined in this document do not impact the security and integrity of a DTLS-SRTP connection or the data exchanged over it. A malicious B2BUA may try to break into the DTLS connection, but such an attack can be prevented using the identity validation mechanism discussed in [I-D.ietf-stir-rfc4474bis].

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 and Christer Holmberg for their constructive comments,suggestions, and early reviews that were critical to the formulation and refinement 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.
[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.
[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.
[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.
[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.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012.

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", Internet-Draft draft-ietf-avtext-rtp-grouping-taxonomy-08, July 2015.
[I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C. and E. Rescorla, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", Internet-Draft draft-ietf-stir-rfc4474bis-04, 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", Internet-Draft draft-jones-perc-private-media-reqts-00, 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.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002.
[RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006.
[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.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010.
[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.

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, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India EMail: tireddy@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US EMail: gsalguei@cisco.com
Victor Pascual Quobis Spain EMail: victor.pascual.avila@gmail.com
Parthasarathi Ravindran Nokia Networks Bangalore, Karnataka India EMail: partha@parthasarathi.co.in