idnits 2.17.1 draft-ietf-straw-b2bua-dtls-srtp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STRAW R. Ravindranath 3 Internet-Draft T. Reddy 4 Intended status: Standards Track G. Salgueiro 5 Expires: April 21, 2016 Cisco 6 V. Pascual 7 Quobis 8 Parthasarathi. Ravindran 9 Nokia Networks 10 October 19, 2015 12 DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back 13 User Agents (B2BUAs) 14 draft-ietf-straw-b2bua-dtls-srtp-08 16 Abstract 18 Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) 19 often act on the media plane, rather than just on the signaling path. 20 This document describes the behavior such B2BUAs can adhere to when 21 acting on the media plane that uses an Secure Real-time Transport 22 (SRTP) security context set up with the Datagram Transport Layer 23 Security (DTLS) protocol. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 21, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Media Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 4 64 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 4 66 3.1.2. RTP/RTCP-aware Media Aware B2BUA . . . . . . . . . . 6 67 3.2. Media Plane B2BUA with NAT Handling . . . . . . . . . . . 7 68 4. Forking Considerations . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 1.1. Overview 82 [RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261] 83 can be used to establish a Secure Real-time Transport Protocol (SRTP) 84 [RFC3711] security context with the Datagram Transport Layer Security 85 (DTLS) [RFC6347] protocol. It describes a mechanism for transporting 86 a certificate fingerprint using Session Description Protocol (SDP) 87 [RFC4566]. The fingerprint, identifies the certificate that will be 88 presented during the DTLS handshake. DTLS-SRTP is currently defined 89 for point-to-point media sessions, in which there are exactly two 90 participants. Each DTLS-SRTP session (described in Section 3 of 91 [RFC5764]) contains a single DTLS connection (if RTP and RTCP are 92 multiplexed) or two DTLS connections (if RTP and RTCP are not 93 multiplexed), and either two SRTP contexts (if media traffic is 94 flowing in both directions on the same 5-tuple) or one SRTP context 95 (if media traffic is only flowing in one direction). 97 In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) 98 entities exist on the SIP signaling path between the endpoints. As 99 described in [RFC7092], these B2BUAs can modify SIP and SDP 100 information. They can also be present on the media path, in which 101 case they modify parts of the SDP information (like IP address, port) 102 and subsequently modify the RTP headers as well. Such B2BUAs are 103 referred to as media plane B2BUAs. 105 1.2. Goals 107 [RFC7092] describes two different categories of media plane B2BUAs, 108 according to the level of activities performed on the media plane: 110 A B2BUA that acts as a simple media relay effectively unaware of 111 anything that is transported and only terminates the media plane 112 at the IP and transport (UDP/TCP) layers. 114 A B2BUA that performs a media-aware role. It inspects and 115 potentially modifies RTP headers or RTP Control Protocol (RTCP) 116 packets. 118 The following sections describe the behavior B2BUAs MUST follow in 119 order to avoid any impact to end-to-end DTLS-SRTP sessions. The 120 DTLS-SRTP framework [RFC5763] recommends that endpoints or proxy 121 server in the endpoint domain use [RFC4474] to integrity protect the 122 fingerprint attributes. Thus, under most circumstances, B2BUAs 123 cannot terminate the DTLS-SRTP session without invalidating the 124 signature and causing the session to fail. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 Transport Address: The combination of an IP address and port number. 134 The following generalized terms are defined in [RFC3261], Section 6. 136 B2BUA: a SIP Back-to-Back User Agent, which is the logical 137 combination of a User Agent Server (UAS) and User Agent Client 138 (UAC). 140 UAS: a SIP User Agent Server. 142 UAC: a SIP User Agent Client. 144 All of the pertinent B2BUA terminology and taxonomy used in this 145 document is based on [RFC7092]. 147 It is assumed the reader is already familiar with the fundamental 148 concepts of the RTP protocol [RFC3550] and its taxonomy 149 [I-D.ietf-avtext-rtp-grouping-taxonomy], as well as those of SRTP 150 [RFC3711], and DTLS [RFC6347]. 152 3. Media Plane B2BUA Handling of DTLS-SRTP 154 3.1. General 156 This section describes the DTLS-SRTP handling by the different types 157 of media plane B2BUAs defined in [RFC7092]. 159 3.1.1. Media Relay 161 A media relay, as defined in section 3.2.1 of [RFC7092], from an 162 application layer point-of-view, forwards all packets it receives on 163 a negotiated connection, without inspecting or modifying the packet 164 contents. A media relay only modifies the transport layer (UDP/TCP) 165 and IP headers. 167 A media relay B2BUA MUST forward the certificate fingerprint and SDP 168 setup attribute it receives from one endpoint unmodified towards the 169 other endpoint and vice-versa. The example below shows a SIP call 170 establishment flow, with both SIP endpoints (user agents) using DTLS- 171 SRTP, and a media relay B2BUA. 173 +-------+ +------------------+ +-----+ 174 | Alice | | MediaRelay B2BUA | | Bob | 175 +-------+ +------------------+ +-----+ 176 |(1) INVITE | (3)INVITE | 177 | a=setup:actpass | a=setup:actpass | 178 | a=fingerprint1 | a= fingerprint1 | 179 | (alice's IP/port) | (B2BUAs IP/port) | 180 |------------------------>|-------------------------->| 181 | | | 182 | (2) 100 trying | | 183 |<------------------------| | 184 | | (4) 100 trying | 185 | |<--------------------------| 186 | | | 187 | | (5)200 OK | 188 | | a=setup:active | 189 | | a=fingerprint2 | 190 | | (Bob's IP/port) | 191 |<------------------------|<--------------------------| 192 | (6) 200 OK | | 193 | a=setup:active | | 194 | a=fingerprint2 | | 195 | B2BUAs IP/port | | 196 | (7, 8)ClientHello + use_srtp | 197 |<------------------------|<--------------------------| 198 | | | 199 | | | 200 | (9,10)ServerHello + use_srtp | 201 |------------------------>|-------------------------->| 202 | (11) | | 203 | [Certificate exchange between Alice and Bob over | 204 | DTLS ] | | 205 | | | 206 | (12) | | 207 |<---------SRTP/SRTCP---->|<----SRTP/SRTCP----------->| 208 | [B2BUA changes transport(UDP/TCP) and IP headers] | 210 Figure 1: INVITE with SDP call-flow for Media Relay B2BUA 212 NOTE: For brevity the entire value of the SDP fingerprint attribute 213 is not shown. The example here shows only one DTLS connection for 214 the sake of simplicity. In reality depending on whether the RTP and 215 RTCP flows are multiplexed or demultiplexed there will be one or two 216 DTLS connections. 218 If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a 219 single port then only a single DTLS connection is required between 220 the peers. If RTP and RTCP are not multiplexed, then the peers would 221 have to establish two DTLS connections. In this case, Bob, after he 222 receives an INVITE request, triggers the establishment of a DTLS 223 connection. Note that the DTLS handshake and the sending of INVITE 224 response can happen in parallel; thus, the B2BUA MUST be prepared to 225 receive DTLS, STUN and media on the ports it advertised to Bob in the 226 SIP offer before it receives a SIP answer from Bob. Since a media 227 relay B2BUA does not differentiate between a DTLS message, RTP or any 228 packet it receives, it only changes the transport layer (UDP/TCP) and 229 IP headers and forwards the packet towards the other endpoint. The 230 B2BUA cannot decrypt the RTP payload as the payload is encrypted 231 using the SRTP keys derived from the DTLS connection setup between 232 Alice and Bob. 234 [RFC4474] provides a means for signing portions of SIP requests in 235 order to provide identity assurance and certificate pinning by 236 providing a signature over the SDP that carries the fingerprint of 237 keying for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST ensure that 238 it does not modify any of the information used to construct the 239 signature. 241 In the above example, Alice can be authorized by the authorization 242 server (SIP proxy) in its domain using the procedures in Section 5 of 243 [RFC4474]. In such a case, if the B2BUA modifies some of the SIP 244 headers or SDP content that was used by Alice's authorization server 245 to generate the identity, it would break the identity verification 246 procedure explained in Section 6 of [RFC4474] resulting in a 438 247 error response being returned. 249 3.1.2. RTP/RTCP-aware Media Aware B2BUA 251 Unlike the media relay discussed in Section 3.1.1, a media-aware 252 relay as defined in Section 3.2.2 of [RFC7092], is aware of the type 253 of media traffic it is receiving. There are two types of media-aware 254 relay, those that merely inspect the RTP headers and unencrypted 255 portions of RTCP packets, and those that inspect and modify the RTP 256 headers and unencrypted portions of RTCP packets. The identity 257 integrity protection procedures described in Security Considerations 258 section MUST be used by the endpoint or the proxy server in the 259 endpoints network to detect malicious B2BUAs that attempt to 260 terminate the DTLS-SRTP session. 262 3.1.2.1. RTP header and RTCP packets Inspection 264 This kind of media aware relay does not modify the RTP headers and 265 RTCP packets but only inspects the packets. It MUST NOT terminate 266 the DTLS-SRTP session on which the packets are received. 268 3.1.2.2. RTP header and RTCP packet Modification 270 A B2BUA cannot modify RTP headers or RTCP packets, as to do so it 271 would need to act as a DTLS endpoint, terminate the DTLS-SRTP session 272 and decrypt/re-encrypt RTP packet. This would cause the identity and 273 integrity protection procedures discussed in [RFC4474] to fail and 274 hence a B2BUA MUST NOT terminate the DTLS-SRTP session. This 275 security and privacy problem can be mitigated by having different 276 keys for protecting RTP header integrity and encrypting the RTP 277 payload. For example, the approach discussed in 278 [I-D.jones-perc-private-media-reqts] can be used. With such an 279 approach, the B2BUA is not aware of the keys used to decrypt the 280 media payload. 282 3.2. Media Plane B2BUA with NAT Handling 284 DTLS-SRTP handshakes and SDP offer/answer exchanges [RFC3264] may 285 happen in parallel. If an endpoint is behind a NAT, and the endpoint 286 is acting as a DTLS server, the ClientHello message from a B2BUA 287 (acting as DTLS client) is likely to be lost, as described in 288 Section 7.3 of [RFC5763]. In order to overcome this problem, the 289 endpoint and B2BUA can support the Interactive Connectivity 290 Establishment (ICE) mechanism [RFC5245], as discussed in Section 7.3 291 of [RFC5763]. If the ICE check is successful then the endpoint will 292 receive the ClientHello message from the B2BUA. 294 4. Forking Considerations 296 Due to forking [RFC3261], a SIP request carrying an SDP offer sent by 297 an endpoint (offerer) can reach multiple remote endpoints. As a 298 result, multiple DTLS-SRTP sessions can be established, one between 299 the endpoint that sent the SIP request and each of the remote 300 endpoints that received the request. Both media relays and media- 301 aware relays MUST forward the certificate fingerprints and SDP setup 302 attributes it received in the SDP answer from each endpoint 303 (answerer) unmodified towards the offerer. Since each DTLS 304 connection is setup on a unique 5-tuple, B2BUA MUST replace the 305 answerer's transport addresses in each answer with its unique 306 transport addresses so that the offerer can establish a DTLS 307 connection with each answerer. 309 Bob (192.0.2.1:6666) 310 / 311 / 312 / DTLS-SRTP=XXX 313 / 314 / 315 DTLS-SRTP=XXX v 316 <-----------> (192.0.2.3:7777) 317 Alice (192.0.2.0:5555) B2BUA 318 <-----------> (192.0.2.3:8888) 319 DTLS-SRTP=YYY ^ 320 \ 321 \ DTLS-SRTP=YYY 322 \ 323 \ 324 \ 325 Charlie (192.0.2.2:6666) 327 Figure 2: B2BUA handling multiple answers 329 For instance, as shown in Figure 2 Alice sends a request with an 330 offer, and the request is forked. Alice receives answers from both 331 Bob and Charlie. B2BUA MUST advertise different B2BUA transport 332 address in each answer, as shown in Figure2, where XXX and YYY 333 represent different DTLS-SRTP sessions. B2BUA replaces the Bob's 334 transport address (192.0.2.1:6666) in the answer with its transport 335 address (192.0.2.3:7777) and Charlie's transport address 336 (192.0.2.2:6666) in the answer with its transport address 337 (192.0.2.3:8888). B2BUA tracks the remote sources (Bob and Charlie) 338 and associates them to the local sources that are used to send 339 packets to Alice. 341 5. Security Considerations 343 This document describes the behavior media plane B2BUAs (media-aware 344 and media-unaware) MUST follow when acting on the media plane that 345 uses SRTP security context setup with the DTLS protocol. Attempting 346 to cover media-aware relay modifying RTP headers and media 347 termination scenarios involving secure sessions (like DTLS-SRTP) will 348 inevitably lead to the B2BUA acting as a man-in-the-middle, and hence 349 a B2BUA MUST NOT terminate DTLS-SRTP session. Security 350 considerations discussed in [RFC5763] are also applicable to this 351 document. In addition, the B2BUA behaviors outlined in this document 352 do not impact the security and integrity of a DTLS-SRTP session or 353 the data exchanged over it. A malicious B2BUA can try to break into 354 the DTLS connection, but such an attack can be prevented using the 355 identity validation mechanism discussed in [RFC4474]. Either the 356 endpoints or authentication service proxies involved in the call MUST 357 use the identity validation mechanisms discussed in [RFC4474] to 358 validate the identity of peers and detect malicious B2BUA's that can 359 attempt to terminate the DTLS connection to decrypt the RTP payload. 361 6. IANA Considerations 363 This document makes no request of IANA. 365 7. Acknowledgments 367 Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, 368 Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing, 369 Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa, 370 Christer Holmberg, Colin Perkins and Ben Campbell for their 371 constructive comments,suggestions, and early reviews that were 372 critical to the formulation and refinement of this document. 374 8. Contributors 376 Rajeev Seth provided substantial contributions to this document. 378 9. References 380 9.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 388 Jacobson, "RTP: A Transport Protocol for Real-Time 389 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 390 July 2003, . 392 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 393 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 394 RFC 3711, DOI 10.17487/RFC3711, March 2004, 395 . 397 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 398 Authenticated Identity Management in the Session 399 Initiation Protocol (SIP)", RFC 4474, 400 DOI 10.17487/RFC4474, August 2006, 401 . 403 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 404 for Establishing a Secure Real-time Transport Protocol 405 (SRTP) Security Context Using Datagram Transport Layer 406 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 407 2010, . 409 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 410 Security (DTLS) Extension to Establish Keys for the Secure 411 Real-time Transport Protocol (SRTP)", RFC 5764, 412 DOI 10.17487/RFC5764, May 2010, 413 . 415 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 416 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 417 January 2012, . 419 9.2. Informative References 421 [I-D.ietf-avtext-rtp-grouping-taxonomy] 422 Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 423 B. Burman, "A Taxonomy of Semantics and Mechanisms for 424 Real-Time Transport Protocol (RTP) Sources", draft-ietf- 425 avtext-rtp-grouping-taxonomy-08 (work in progress), July 426 2015. 428 [I-D.jones-perc-private-media-reqts] 429 Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson, 430 J., and R. Barnes, "Private Media Requirements in Privacy 431 Enhanced RTP Conferencing", draft-jones-perc-private- 432 media-reqts-00 (work in progress), July 2015. 434 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 435 A., Peterson, J., Sparks, R., Handley, M., and E. 436 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 437 DOI 10.17487/RFC3261, June 2002, 438 . 440 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 441 with Session Description Protocol (SDP)", RFC 3264, 442 DOI 10.17487/RFC3264, June 2002, 443 . 445 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 446 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 447 July 2006, . 449 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 450 (ICE): A Protocol for Network Address Translator (NAT) 451 Traversal for Offer/Answer Protocols", RFC 5245, 452 DOI 10.17487/RFC5245, April 2010, 453 . 455 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 456 Control Packets on a Single Port", RFC 5761, 457 DOI 10.17487/RFC5761, April 2010, 458 . 460 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 461 Initiation Protocol (SIP) Back-to-Back User Agents", 462 RFC 7092, DOI 10.17487/RFC7092, December 2013, 463 . 465 Authors' Addresses 467 Ram Mohan Ravindranath 468 Cisco 469 Cessna Business Park 470 Sarjapur-Marathahalli Outer Ring Road 471 Bangalore, Karnataka 560103 472 India 474 Email: rmohanr@cisco.com 476 Tirumaleswar Reddy 477 Cisco 478 Cessna Business Park, Varthur Hobli 479 Sarjapur Marathalli Outer Ring Road 480 Bangalore, Karnataka 560103 481 India 483 Email: tireddy@cisco.com 485 Gonzalo Salgueiro 486 Cisco Systems, Inc. 487 7200-12 Kit Creek Road 488 Research Triangle Park, NC 27709 489 US 491 Email: gsalguei@cisco.com 492 Victor Pascual 493 Quobis 495 Email: victor.pascual.avila@gmail.com 497 Parthasarathi Ravindran 498 Nokia Networks 499 Bangalore, Karnataka 500 India 502 Email: partha@parthasarathi.co.in