idnits 2.17.1 draft-ietf-straw-b2bua-dtls-srtp-00.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 (March 23, 2015) is 3316 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 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-08) exists of draft-ietf-avtext-rtp-grouping-taxonomy-06 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-03 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 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: September 24, 2015 Cisco 6 V. Pascual 7 Quobis 8 Parthasarathi. Ravindran 9 Nokia Networks 10 March 23, 2015 12 DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back 13 User Agents (B2BUAs) 14 draft-ietf-straw-b2bua-dtls-srtp-00 16 Abstract 18 Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) 19 often function on the media plane, rather than just on the signaling 20 path. This document describes the behavior B2BUAs should follow when 21 acting on the media plane that use Secure Real-time Transport (SRTP) 22 security context setup with Datagram Transport Layer Security (DTLS) 23 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 September 24, 2015. 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 B2BUAs . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Media Aware Relay . . . . . . . . . . . . . . . . . . . . 6 66 3.2.1. RTP and RTCP Header Inspection . . . . . . . . . . . 6 67 3.2.2. RTP and RTCP Header Modification . . . . . . . . . . 6 68 3.3. Media Plane B2BUA with NAT handling . . . . . . . . . . . 7 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 8.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 Datagram Transport Layer Security 85 (DTLS) [RFC6347] protocol. It describes a mechanism of transporting 86 a certificate fingerprint in the Session Description Protocol (SDP) 87 [RFC4566], which identifies the certificate that will be presented 88 during the DTLS handshake. DTLS-SRTP is defined for point-to-point 89 media sessions, in which there are exactly two participants. Each 90 DTLS-SRTP session contains a single DTLS association, and either two 91 SRTP contexts (if media traffic is flowing in both directions on the 92 same host/port quartet) or one SRTP context (if media traffic is only 93 flowing in one direction). 95 In many SIP deployments, SIP entities exist in the SIP signaling path 96 between the originating and final terminating endpoints. These SIP 97 entities, as described in [RFC7092], modify SIP and SDP bodies and 98 also are likely to be on the media path. Such entities, when present 99 in the signaling/media path, are likely to do several things. For 100 example, some B2BUAs modify parts of the SDP body (like IP address, 101 port) and subsequently modify the RTP headers as well. 103 1.2. Goals 105 [RFC7092] describes two different categories of such B2BUAs, 106 according to the level of activities performed on the media plane: 108 A B2BUA that act as a simple media relay effectively unaware of 109 anything that is transported and only modifies the UDP/IP header 110 of the packets. 112 A B2BUA that performs a media-aware role. It inspects and 113 potentially modifies RTP or RTP Control Protocol (RTCP) headers; 114 but it does not modify the payload of RTP/RTCP. 116 The following sections describe the behaviour B2BUAs should follow in 117 order to avoid any impact on end-to-end DTLS-SRTP streams. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 The following generalized terms are defined in [RFC3261], Section 6. 127 B2BUA: a SIP Back-to-Back User Agent, which is the logical 128 combination of a User Agent Server (UAS) and User Agent Client 129 (UAC). 131 UAS: a SIP User Agent Server. 133 UAC: a SIP User Agent Client. 135 All of the pertinent B2BUA terminology and taxonomy used in this 136 document is based on [RFC7092]. 138 It is assumed the reader is already familiar with the fundamental 139 concepts of the RTP protocol [RFC3550] and its taxonomy 140 [I-D.ietf-avtext-rtp-grouping-taxonomy], as well as those of SRTP 141 [RFC3711], and DTLS [RFC6347]. 143 3. Media Plane B2BUAs 145 3.1. Media Relay 147 A media relay, as defined in section 3.2.1 of [RFC7092], from an 148 application layer point-of-view, forwards all packets it receives on 149 a negotiated UDP connection, without inspecting or modifying them. 150 It forwards the UDP payload as-is changing only the UDP/IP header. 152 A media relay B2BUA MUST forward the certificate fingerprint and 153 setup attribute it receives in the SDP from the originating endpoint 154 as-is to the remote side and vice-versa. The example below shows an 155 "INVITE with SDP" SIP call flow, with both SIP user agents doing 156 DTLS-SRTP and a media relay B2BUA that changes only the IP address/ 157 port. 159 +-------+ +------------------+ +-----+ 160 | Alice | | MediaRelay B2BUA | | Bob | 161 +-------+ +------------------+ +-----+ 162 |(1) INVITE | (3)INVITE | 163 | a=setup:actpass | a=setup:actpass | 164 | a=fingerprint1 | a= fingerprint1 | 165 | (alice's IP/port) | (B2BUA's IP, port) | 166 |------------------------>|-------------------------->| 167 | | | 168 | (2) 100 trying | | 169 |<------------------------| | 170 | | (4) 100 trying | 171 | |<--------------------------| 172 | | | 173 | | (5)200 OK | 174 | | a=setup:active | 175 | | a=fingerprint2 | 176 | | (Bob's IP, port) | 177 |<------------------------|<--------------------------| 178 | (6) 200 OK | | 179 | a=setup:active | | 180 | a=fingerprint2 | | 181 | B2BUA's address,port | | 182 | (7, 8)ClientHello + use_srtp | 183 |<------------------------|<--------------------------| 184 | | | 185 | | | 186 | (9,10)ServerHello + use_srtp | 187 |------------------------>|-------------------------->| 188 | (11) | | 189 | [Certificate exchange between Alice and Bob over | 190 | DTLS ] | | 191 | | | 192 | (12) | | 193 |<---------SRTP/SRTCP---->|<----SRTP/SRTCP----------->| 194 | [B2BUA just changes UDP/IP header] | 196 Figure 1: INVITE with SDP callflow for Media Relay B2BUA 198 NOTE: For brevity the entire fingerprint attribute is not shown. 200 For each RTP or RTCP flow, the peers do a DTLS handshake on the same 201 source and destination port pair to establish a DTLS association. In 202 this case, Bob, after he receives an INVITE, triggers a DTLS 203 connection. Note the DTLS handshake and the response to the INVITE 204 may happen in parallel; thus, the B2BUA SHOULD be prepared to receive 205 media on the ports it advertised to Bob in the OFFER. Since a media 206 relay B2BUA does not differentiate between a DTLS, RTP or any packet 207 sent it receives, it just changes the UDP/IP addresses and forwards 208 the packet on either leg. 210 [I-D.ietf-stir-rfc4474bis] provides a means for signing portions of 211 SIP requests in order to provide identity assurance and certificate 212 pinning by providing a signature over the fingerprint of keying 213 material in SDP for DTLS-SRTP [RFC5763]. A media relay B2BUA MUST 214 ensure that it does not modify any of the headers used to construct 215 the signature. 217 In the above example Alice may be authorized by the authorization 218 server (SIP proxy) in its domain using the procedures in section 5 of 219 [I-D.ietf-stir-rfc4474bis]. In such a case, if B2BUA changes some of 220 the SIP headers or SDP content that was used by Alice's authorization 221 server to generate the identity, it would break the identity 222 verification procedure explained in section 4.2 of 223 [I-D.ietf-stir-rfc4474bis] resulting in a 438 error response being 224 returned. 226 3.2. Media Aware Relay 228 A media-aware relay, unlike the media relay discussed in the previous 229 section, is actually aware of the media traffic it is handling. A 230 media-aware relay inspects SRTP and SRTCP packets flowing through it, 231 and may or may not modify the headers of the packets before 232 forwarding them. 234 3.2.1. RTP and RTCP Header Inspection 236 B2BUAs explained in Section 3.2.2 of [RFC7092] do not modify the RTP 237 and RTCP headers but only inspect the headers. Such B2BUA MUST NOT 238 terminate the DTLS-SRTP session. 240 3.2.2. RTP and RTCP Header Modification 242 In addition to inspecting the RTP and RTCP headers, the B2BUAs 243 explained in section 3.2.2 [RFC7092], can also potentially modify 244 them. To modify media headers a B2BUA needs to act as a DTLS 245 intermediary and terminate the DTLS connection so it can decrypt/re- 246 encrypt RTP packets. This breaks end-to-end security. This security 247 and privacy problem can be addressed by having separate keys for 248 encrypting the RTP header and media payload as discussed in 249 [I-D.jones-avtcore-private-media-reqts], in which case the B2BUA is 250 not aware of the keys used to decrypt the media payload. 252 3.3. Media Plane B2BUA with NAT handling 254 DTLS-SRTP handshakes and offer/answer can happen in parallel. If a 255 UA is behind a NAT and acting as a DTLS server, the ClientHello 256 message from a B2BUA(DTLS client) is likely to be lost, as described 257 in section 7.3 of [RFC5763]. In order to overcome this problem, a UA 258 and B2BUA must support ICE as discussed in section 7.3 of [RFC5763]. 259 If ICE check is successful then UA will receive ClientHello packet 260 from B2BUA. 262 4. Security Considerations 264 This document describes the behavior media plane B2BUAs (media-aware 265 and media-unaware) should follow when acting on the media plane that 266 uses SRTP security context setup with the DTLS protocol. It does not 267 introduce any specific security considerations beyond those detailed 268 in [RFC5763]. The B2BUA behaviors outlined here also do not impact 269 the security and integrity of the DTLS-SRTP session nor the data 270 exchanged over it. A malicious B2BUA can try to break into the DTLS 271 session, but such an attack can be prevented using the identity 272 validation mechanism discussed in [I-D.ietf-stir-rfc4474bis]. 274 5. IANA Considerations 276 This document makes no request of IANA. 278 6. Acknowledgments 280 Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, 281 Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing and 282 Charles Eckel for their constructive comments, suggestions, and early 283 reviews that were critical to the formulation and refinement of this 284 document. 286 7. Contributors 288 Rajeev Seth provided substantial contributions to this document. 290 8. References 292 8.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 298 Jacobson, "RTP: A Transport Protocol for Real-Time 299 Applications", STD 64, RFC 3550, July 2003. 301 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 302 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 303 RFC 3711, March 2004. 305 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 306 for Establishing a Secure Real-time Transport Protocol 307 (SRTP) Security Context Using Datagram Transport Layer 308 Security (DTLS)", RFC 5763, May 2010. 310 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 311 Security Version 1.2", RFC 6347, January 2012. 313 8.2. Informative References 315 [I-D.ietf-avtext-rtp-grouping-taxonomy] 316 Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, 317 "A Taxonomy of Grouping Semantics and Mechanisms for Real- 318 Time Transport Protocol (RTP) Sources", draft-ietf-avtext- 319 rtp-grouping-taxonomy-06 (work in progress), March 2015. 321 [I-D.ietf-stir-rfc4474bis] 322 Peterson, J., Jennings, C., and E. Rescorla, 323 "Authenticated Identity Management in the Session 324 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-03 325 (work in progress), March 2015. 327 [I-D.jones-avtcore-private-media-reqts] 328 Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson, 329 J., Cheng, Y., and R. Barnes, "Requirements for Private 330 Media in a Switched Conferencing Environment", draft- 331 jones-avtcore-private-media-reqts-01 (work in progress), 332 March 2015. 334 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 335 A., Peterson, J., Sparks, R., Handley, M., and E. 336 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 337 June 2002. 339 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 340 Description Protocol", RFC 4566, July 2006. 342 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 343 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 344 7092, December 2013. 346 Authors' Addresses 348 Ram Mohan Ravindranath 349 Cisco 350 Cessna Business Park 351 Sarjapur-Marathahalli Outer Ring Road 352 Bangalore, Karnataka 560103 353 India 355 Email: rmohanr@cisco.com 357 Tirumaleswar Reddy 358 Cisco 359 Cessna Business Park, Varthur Hobli 360 Sarjapur Marathalli Outer Ring Road 361 Bangalore, Karnataka 560103 362 India 364 Email: tireddy@cisco.com 366 Gonzalo Salgueiro 367 Cisco Systems, Inc. 368 7200-12 Kit Creek Road 369 Research Triangle Park, NC 27709 370 US 372 Email: gsalguei@cisco.com 374 Victor Pascual 375 Quobis 376 Spain 378 Email: victor.pascual@quobis.com 380 Parthasarathi Ravindran 381 Nokia Networks 382 Bangalore, Karnataka 383 India 385 Email: partha@parthasarathi.co.in