| STRAW | R. Ravindranath |
| Internet-Draft | T. Reddy |
| Intended status: Standards Track | G. Salgueiro |
| Expires: October 6, 2016 | Cisco |
| V. Pascual | |
| Oracle | |
| Parthasarathi. Ravindran | |
| Nokia Networks | |
| April 4, 2016 |
DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-dtls-srtp-12
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-time Transport (SRTP) security context is set up with the Datagram Transport Layer Security (DTLS) protocol.
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 October 6, 2016.
Copyright (c) 2016 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.
[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).
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. For example, as described in Section 3.1.3 of [RFC7092], SDP-modifying signaling-only B2BUAs can potentially modify the SDP. B2BUAs 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. [RFC7092] describes two different categories of media plane B2BUAs, according to the level of activities performed on the media plane.
When B2BUAs are present in a call between two SIP User Agents (UAs) they often make end-to-end DTLS-SRTP sessions impossible. End-to-end DTLS-SRTP session means that man-in-middle devices cannot break the DTLS-SRTP session between the endpoints. In other words, the man-in-middle device cannot create a separate DTLS-SRTP session between the client and the middle device, on one side, and the middle device and the remote peer on the other side. B2BUAs may be deployed for address hiding or media latching [RFC7362], although TURN (and ICE) is expected to be used more often for this purpose as it provides better security properties. Such B2BUAs are able to perform their functions without requiring termination of DTLS-SRTP sessions i.e. these B2BUAs need not act as DTLS proxy and decrypt the RTP payload.
A B2BUA could be deployed for address hiding or media latching, as described in [RFC7362]. Such B2BUAs only terminate the media plane at the IP and transport (UDP/TCP) layers and may inspect the RTP headers or RTP Control Protocol (RTCP) packets. The goal of this specification is to provide guidance on how such B2BUAs function without breaking the end-to-end DTLS-SRTP session. A B2BUA could also terminate the media or modify the RTP headers or RTP Control Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS-SRTP. The recommendations made in this document are not expected to be applied by B2BUAs terminating DTLS-SRTP sessions given deployment reality.
This specification assumes that a B2BUA is not providing identity assurance and is not authorized to terminate the DTLS-SRTP session. A B2BUA that provides identity assurance on behalf of endpoints behind it can modify any portion of SIP and SDP before it generates the identity signature. As the B2BUA is generating the identity signature it is not possible to detect if a B2BUA has terminated the DTLS-SRTP session. B2BUAs providing identity assurance and terminating DTLS-SRTP session are out of scope of this document.
The following sections describe the behavior B2BUAs can follow to avoid breaking end-to-end DTLS-SRTP sessions.
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.
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 [RFC7656], as well as those of SRTP [RFC3711], and DTLS [RFC6347].
A B2BUA MUST follow the rules mentioned below to allow end-to-end DTLS-SRTP session.
Section 3.1 of [RFC7092] describes different categories of signaling plane B2BUAs. This section explains how these B2BUAs are expected to comply with the recommendations in Section 3.
Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only the Via and Record-Route SIP headers. These B2BUAs can continue to perform their function and still allow end-to-end DTLS-SRTP sessions since it does not modify any of the headers used to construct the identity signature.
These categories of B2BUAs are likely to modify headers that are used to construct the identity signature. For example, a signaling-only B2BUA can modify the Contact URI. Such B2BUAs are likely to violate rule 2 or rule 3 in Section 3. Depending upon the application requirements, such a B2BUA may be able to limit modification of header fields to those allowed to be modified by [RFC4474] or [I-D.ietf-stir-rfc4474bis].
This section describes how the different types of media plane B2BUAs defined in [RFC7092] are expected to comply with the recommendations in Section 3.
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 follows the rule 1 mentioned in Section 3 and forwards 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 |
|<----------------------------------------------------|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (9,10)ServerHello + use_srtp |
|---------------------------------------------------->|
|(B2BUA changes transport(UDP/TCP) and IP header) |
| | |
| | |
| (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 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 has to 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.
If the endpoints use [RFC4474], a B2BUA cannot function as a media-relay without violating rule 2 in Section 3. If [4474bis] is used, a B2BUA can modify the IP address in the c= line and the port in the m= line, as shown in Figure 1, as long as it does not otherwise violate rule 3 in Section 3.
Unlike the media relay discussed in Section 5.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.
A RTP/RTCP aware media relay does not modify the RTP headers and RTCP packets but only inspects the packets. Such B2BUAs follow rule 4 in Section 3 and can continue to do their function while allowing end-to-end DTLS-SRTP. Inspection by the B2BUA will not reveal the clear-text for encrypted parts of the SRTP/SRTCP packets.
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 packets. If a B2BUA modifies unencrypted or encrypted portions of the RTP or RTCP packets then the integrity check will fail and the packet will be dropped by the endpoint. The unencrypted and encrypted portions of the RTP or RTCP packets are integrity protected using the HMAC algorithm negotiated during DTLS handshake (discussed in Section 4.1.2 of [RFC5764]). B2BUAs have to follow the rules in Section 3 to avoid breaking integrity of SRTP/SRTCP streams.
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. B2BUAs have to follow rule 1 in Section 3 while handling offer/answer and 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 replaces 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. The B2BUA acting as a media relay here follows rule 4 mentioned in Section 3.
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. The B2BUA advertises different B2BUA transport address in each answer, as shown in Figure2, where XXX and YYY represent different DTLS-SRTP sessions. The 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). The B2BUA tracks the remote sources (Bob and Charlie) and associates them to the local sources that are used to send packets to Alice.
This document describes the behavior B2BUAs must follow to avoid breaking end-to-end DTLS-SRTP. Media relays that modify RTP or RTCP, or modify SIP header fields or SDP fields that are protected by the identity signature, are incompatible with end-to-end DTLS-SRTP. Such relays are out of scope for this document. 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] or [I-D.ietf-stir-rfc4474bis]. Either the endpoints or authentication service proxies involved in the call can use the identity validation mechanisms discussed in [RFC4474] or [I-D.ietf-stir-rfc4474bis] to validate the identity of peers and detect malicious B2BUA's that can attempt to terminate the DTLS connection to decrypt the RTP payload.
This document makes no request of IANA.
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, Ben Campbell and Alissa Cooper 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, Paul Wouters and Stephen Farrell for their review and feedback of this document.
Rajeev Seth provided substantial contributions to this document.