STRAW R. Ravindranath
Internet-Draft T. Reddy
Intended status: Standards Track G. Salgueiro
Expires: March 17, 2016 Cisco
V. Pascual
Quobis
Parthasarathi. Ravindran
Nokia Networks
September 14, 2015
DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
User Agents (B2BUAs)
draft-ietf-straw-b2bua-dtls-srtp-07
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 can 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 March 17, 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 March 17, 2016 [Page 1]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 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 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 March 17, 2016 [Page 2]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 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 MUST follow in
order to avoid any impact to end-to-end DTLS-SRTP sessions.
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].
Ravindranath, et al. Expires March 17, 2016 [Page 3]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 2015
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 March 17, 2016 [Page 4]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 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 March 17, 2016 [Page 5]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 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 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. 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.
[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 can 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. 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
relay, those that merely inspect the RTP headers and RTCP packets,
and those that inspect and modify the RTP headers and RTCP packets.
The mechanism described in Security Considerations section MUST be
used by endpoint to detect malicious B2BUA's that MAY attempt to
terminate the DTLS-SRTP session.
3.1.2.1. RTP header and RTCP packets Inspection
This kind of media aware relay does not modify the RTP headers and
RTCP packets but only inspects the packets. It MUST NOT terminate
the DTLS-SRTP session on which the packets are received.
Ravindranath, et al. Expires March 17, 2016 [Page 6]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 2015
3.1.2.2. RTP header and RTCP packet Modification
In order to modify headers a B2BUA needs to act as a DTLS endpoint
and terminate the DTLS-SRTP session and decrypt/re-encrypt RTP
payload. This would break end-to-end security and hence a B2BUA MUST
NOT terminate DTLS-SRTP session. 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 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.
Ravindranath, et al. Expires March 17, 2016 [Page 7]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 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 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) 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
a B2BUA MUST NOT terminate DTLS-SRTP session. 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
session 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 [RFC4474] and
getting updated in [I-D.ietf-stir-rfc4474bis]. Either the endpoints
Ravindranath, et al. Expires March 17, 2016 [Page 8]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 2015
or authentication service proxies involved in 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 and Colin Perkins 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,
<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>.
[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>.
Ravindranath, et al. Expires March 17, 2016 [Page 9]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 2015
[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.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., and E. Rescorla,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-05
(work in progress), September 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 March 17, 2016 [Page 10]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 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, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Ravindranath, et al. Expires March 17, 2016 [Page 11]
Internet-Draft DTLS-SRTP Handling in SIP B2BUA September 2015
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
Ravindranath, et al. Expires March 17, 2016 [Page 12]
