idnits 2.17.1 draft-ietf-avtcore-rtp-security-options-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 21, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5760' is defined on line 1486, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-avt-srtp-not-mandatory-14 == Outdated reference: A later version (-11) exists of draft-ietf-avtcore-aria-srtp-05 == Outdated reference: A later version (-17) exists of draft-ietf-avtcore-srtp-aes-gcm-10 == Outdated reference: A later version (-03) exists of draft-ietf-avtcore-srtp-ekt-00 == Outdated reference: A later version (-40) exists of draft-ietf-mmusic-rfc2326bis-38 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-08 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-07 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Intended status: Informational C. S. Perkins 5 Expires: April 24, 2014 University of Glasgow 6 October 21, 2013 8 Options for Securing RTP Sessions 9 draft-ietf-avtcore-rtp-security-options-08 11 Abstract 13 The Real-time Transport Protocol (RTP) is used in a large number of 14 different application domains and environments. This heterogeneity 15 implies that different security mechanisms are needed to provide 16 services such as confidentiality, integrity and source authentication 17 of RTP/RTCP packets suitable for the various environments. The range 18 of solutions makes it difficult for RTP-based application developers 19 to pick the most suitable mechanism. This document provides an 20 overview of a number of security solutions for RTP, and gives 21 guidance for developers on how to choose the appropriate security 22 mechanism. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 24, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Point-to-Point Sessions . . . . . . . . . . . . . . . . . 4 61 2.2. Sessions Using an RTP Mixer . . . . . . . . . . . . . . . 4 62 2.3. Sessions Using an RTP Translator . . . . . . . . . . . . 5 63 2.3.1. Transport Translator (Relay) . . . . . . . . . . . . 5 64 2.3.2. Gateway . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3.3. Media Transcoder . . . . . . . . . . . . . . . . . . 7 66 2.4. Any Source Multicast . . . . . . . . . . . . . . . . . . 7 67 2.5. Source-Specific Multicast . . . . . . . . . . . . . . . . 7 68 3. Security Options . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.1. Key Management for SRTP: DTLS-SRTP . . . . . . . . . 11 71 3.1.2. Key Management for SRTP: MIKEY . . . . . . . . . . . 12 72 3.1.3. Key Management for SRTP: Security Descriptions . . . 14 73 3.1.4. Key Management for SRTP: Encrypted Key Transport . . 15 74 3.1.5. Key Management for SRTP: Other systems . . . . . . . 15 75 3.2. RTP Legacy Confidentiality . . . . . . . . . . . . . . . 15 76 3.3. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 3.4. RTP over TLS over TCP . . . . . . . . . . . . . . . . . . 16 78 3.5. RTP over Datagram TLS (DTLS) . . . . . . . . . . . . . . 16 79 3.6. Media Content Security/Digital Rights Management . . . . 17 80 3.6.1. ISMA Encryption and Authentication . . . . . . . . . 18 81 4. Securing RTP Applications . . . . . . . . . . . . . . . . . . 18 82 4.1. Application Requirements . . . . . . . . . . . . . . . . 18 83 4.1.1. Confidentiality . . . . . . . . . . . . . . . . . . . 18 84 4.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 20 85 4.1.3. Source Authentication . . . . . . . . . . . . . . . . 20 86 4.1.4. Identity . . . . . . . . . . . . . . . . . . . . . . 22 87 4.1.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . 22 88 4.2. Application Structure . . . . . . . . . . . . . . . . . . 23 89 4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 23 90 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 5.1. Media Security for SIP-established Sessions using DTLS- 92 SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 5.2. Media Security for WebRTC Sessions . . . . . . . . . . . 25 94 5.3. IP Multimedia Subsystem (IMS) Media Security . . . . . . 26 95 5.4. 3GPP Packet Based Streaming Service (PSS) . . . . . . . . 26 96 5.5. RTSP 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 27 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 100 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 101 9. Informative References . . . . . . . . . . . . . . . . . . . 28 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 104 1. Introduction 106 Real-time Transport Protocol (RTP) [RFC3550] is widely used in a 107 large variety of multimedia applications, including Voice over IP 108 (VoIP), centralized multimedia conferencing, sensor data transport, 109 and Internet television (IPTV) services. These applications can 110 range from point-to-point phone calls, through centralised group 111 teleconferences, to large-scale television distribution services. 112 The types of media can vary significantly, as can the signalling 113 methods used to establish the RTP sessions. 115 This multi-dimensional heterogeneity has so far prevented development 116 of a single security solution that meets the needs of the different 117 applications. Instead significant number of different solutions have 118 been developed to meet different sets of security goals. This makes 119 it difficult for application developers to know what solutions exist, 120 and whether their properties are appropriate. This memo gives an 121 overview of the available RTP solutions, and provides guidance on 122 their applicability for different application domains. It also 123 attempts to provide indication of actual and intended usage at time 124 of writing as additional input to help with considerations such as 125 interoperability, availability of implementations etc. The guidance 126 provided is not exhaustive, and this memo does not provide normative 127 recommendations. 129 It is important that application developers consider the security 130 goals and requirements for their application. The IETF considers it 131 important that protocols implement, and makes available to the user, 132 secure modes of operation [RFC3365]. Because of the heterogeneity of 133 RTP applications and use cases, however, a single security solution 134 cannot be mandated [I-D.ietf-avt-srtp-not-mandatory]. Instead, 135 application developers need to select mechanisms that provide 136 appropriate security for their environment. It is strongly 137 encouraged that common mechanisms are used by related applications in 138 common environments. The IETF publishes guidelines for specific 139 classes of applications, so it is worth searching for such 140 guidelines. 142 The remainder of this document is structured as follows. Section 2 143 provides additional background. Section 3 outlines the available 144 security mechanisms at the time of this writing, and lists their key 145 security properties and constraints. That is followed by guidelines 146 and important aspects to consider when securing an RTP application in 147 Section 4. Finally, we give some examples of application domains 148 where guidelines for security exist in Section 5. 150 2. Background 152 RTP can be used in a wide variety of topologies due to its support 153 for point-to-point sessions, multicast groups, and other topologies 154 built around different types of RTP middleboxes. In the following we 155 review the different topologies supported by RTP to understand their 156 implications for the security properties and trust relations that can 157 exist in RTP sessions. 159 2.1. Point-to-Point Sessions 161 The most basic use case is two directly connected end-points, shown 162 in Figure 1, where A has established an RTP session with B. In this 163 case the RTP security is primarily about ensuring that any third 164 party can't compromise the confidentiality and integrity of the media 165 communication. This requires confidentiality protection of the RTP 166 session, integrity protection of the RTP/RTCP packets, and source 167 authentication of all the packets to ensure no man-in-the-middle 168 attack is taking place. 170 The source authentication can also be tied to a user or an end- 171 point's verifiable identity to ensure that the peer knows who they 172 are communicating with. Here the combination of the security 173 protocol protecting the RTP session and its RTP and RTCP traffic and 174 the key-management protocol becomes important in which security 175 statements one can do. 177 +---+ +---+ 178 | A |<------->| B | 179 +---+ +---+ 181 Figure 1: Point-to-point topology 183 2.2. Sessions Using an RTP Mixer 185 An RTP mixer is an RTP session-level middlebox that one can build a 186 multi-party RTP based conference around. The RTP mixer might 187 actually perform media mixing, like mixing audio or compositing video 188 images into a new media stream being sent from the mixer to a given 189 participant; or it might provide a conceptual stream, for example the 190 video of the current active speaker. From a security point of view, 191 the important features of an RTP mixer is that it generates a new 192 media stream, and has its own source identifier, and does not simply 193 forward the original media. 195 An RTP session using a mixer might have a topology like that in 196 Figure 2. In this example, participants A through D each send 197 unicast RTP traffic to the RTP mixer, and receive an RTP stream from 198 the mixer, comprising a mixture of the streams from the other 199 participants. 201 +---+ +------------+ +---+ 202 | A |<---->| |<---->| B | 203 +---+ | | +---+ 204 | Mixer | 205 +---+ | | +---+ 206 | C |<---->| |<---->| D | 207 +---+ +------------+ +---+ 209 Figure 2: Example RTP mixer Topology 211 A consequence of an RTP mixer having its own source identifier, and 212 acting as an active participant towards the other end-points is that 213 the RTP mixer needs to be a trusted device that has access to the 214 security context(s) established. The RTP mixer can also become a 215 security enforcing entity. For example, a common approach to secure 216 the topology in Figure 2 is to establish a security context between 217 the mixer and each participant independently, and have the mixer 218 source authenticate each peer. The mixer then ensures that one 219 participant cannot impersonate another. 221 2.3. Sessions Using an RTP Translator 223 RTP translators are middleboxes that provide various levels of in- 224 network media translation and transcoding. Their security properties 225 vary widely, depending on which type of operations they attempt to 226 perform. We identify three different categories of RTP translator: 227 transport translators, gateways, and media transcoders. We discuss 228 each in turn. 230 2.3.1. Transport Translator (Relay) 232 A transport translator [RFC5117] operates on a level below RTP and 233 RTCP. It relays the RTP/RTCP traffic from one end-point to one or 234 more other addresses. This can be done based only on IP addresses 235 and transport protocol ports, with each receive port on the 236 translator can have a very basic list of where to forward traffic. 237 Transport translators also need to implement ingress filtering to 238 prevent random traffic from being forwarded that isn't coming from a 239 participant in the conference. 241 Figure 3 shows an example transport translator, where traffic from 242 any one of the four participants will be forwarded to the other three 243 participants unchanged. The resulting topology is very similar to 244 Any Source Multicast (ASM) session (as discussed in Section 2.4), but 245 implemented at the application layer. 247 +---+ +------------+ +---+ 248 | A |<---->| |<---->| B | 249 +---+ | Relay | +---+ 250 | Translator | 251 +---+ | | +---+ 252 | C |<---->| |<---->| D | 253 +---+ +------------+ +---+ 255 Figure 3: RTP relay translator topology 257 A transport translator can often operate without needing access to 258 the security context, as long as the security mechanism does not 259 provide protection over the transport-layer information. A transport 260 translator does, however, make the group communication visible, and 261 so can complicate keying and source authentication mechanisms. This 262 is further discussed in Section 2.4. 264 2.3.2. Gateway 266 Gateways are deployed when the endpoints are not fully compatible. 267 Figure 4 shows an example topology. The functions a gateway provides 268 can be diverse, and range from transport layer relaying between two 269 domains not allowing direct communication, via transport or media 270 protocol function initiation or termination, to protocol or media 271 encoding translation. The supported security protocol might even be 272 one of the reasons a gateway is needed. 274 +---+ +-----------+ +---+ 275 | A |<---->| Gateway |<---->| B | 276 +---+ +-----------+ +---+ 278 Figure 4: RTP gateway topology 280 The choice of security protocol, and the details of the gateway 281 function, will determine if the gateway needs to be trusted with 282 access to the application security context. Many gateways need to be 283 trusted by all peers to perform the translation; in other cases some 284 or all peers might not be aware of the presence of the gateway. The 285 security protocols have different properties depending on the degree 286 of trust and visibility needed. Ensuring communication is possible 287 without trusting the gateway can be strong incentive for accepting 288 different security properties. Some security solutions will be able 289 to detect the gateways as manipulating the media stream, unless the 290 gateway is a trusted device. 292 2.3.3. Media Transcoder 294 A Media transcoder is a special type of gateway device that changes 295 the encoding of the media being transported by RTP. The discussion 296 in Section 2.3.2 applies. A media transcoder alters the media data, 297 and thus needs to be trusted with access to the security context. 299 2.4. Any Source Multicast 301 Any Source Multicast [RFC1112] is the original multicast model where 302 any multicast group participant can send to the multicast group, and 303 get their packets delivered to all group members (see Figure 5). 304 This form of communication has interesting security properties, due 305 to the many-to-many nature of the group. Source authentication is 306 important, but all participants with access to group security context 307 will have the necessary secrets to decrypt and verify integrity of 308 the traffic. Thus use of any group security context fails if the 309 goal is to separate individual sources; alternate solutions are 310 needed. 312 +-----+ 313 +---+ / \ +---+ 314 | A |----/ \---| B | 315 +---+ / Multi- \ +---+ 316 + Cast + 317 +---+ \ Network / +---+ 318 | C |----\ /---| D | 319 +---+ \ / +---+ 320 +-----+ 322 Figure 5: Any source multicast (ASM) group 324 In addition the potential large size of multicast groups creates some 325 considerations for the scalability of the solution and how the key- 326 management is handled. 328 2.5. Source-Specific Multicast 330 Source-Specific Multicast [RFC4607] allows only a specific end-point 331 to send traffic to the multicast group, irrespective of the number of 332 RTP media sources. The end-point is known as the media Distribution 333 Source. Figure 6 shows a sample SSM-based RTP session where several 334 media sources, MS1...MSm, all send media to a Distribution Source, 335 which then forwards the media data to the SSM group for delivery to 336 the receivers, R1...Rn, and the Feedback Targets, FT1...FTn. RTCP 337 reception quality feedback is sent unicast from each receiver to one 338 of the Feedback Targets. The feedback targets aggregate reception 339 quality feedback and forward it upstream towards the distribution 340 source. The distribution source forwards (possibly aggregated and 341 summarised) reception feedback to the SSM group, and back to the 342 original media sources. The feedback targets are also members of the 343 SSM group and receive the media data, so they can send unicast repair 344 data to the receivers in response to feedback if appropriate. 346 +-----+ +-----+ +-----+ 347 | MS1 | | MS2 | .... | MSm | 348 +-----+ +-----+ +-----+ 349 ^ ^ ^ 350 | | | 351 V V V 352 +---------------------------------+ 353 | Distribution Source | 354 +--------+ | 355 | FT Agg | | 356 +--------+------------------------+ 357 ^ ^ | 358 : . | 359 : +...................+ 360 : | . 361 : / \ . 362 +------+ / \ +-----+ 363 | FT1 |<----+ +----->| FT2 | 364 +------+ / \ +-----+ 365 ^ ^ / \ ^ ^ 366 : : / \ : : 367 : : / \ : : 368 : : / \ : : 369 : ./\ /\. : 370 : /. \ / .\ : 371 : V . V V . V : 372 +----+ +----+ +----+ +----+ 373 | R1 | | R2 | ... |Rn-1| | Rn | 374 +----+ +----+ +----+ +----+ 376 Figure 6: Example SSM-based RTP session with two feedback targets 378 The use of SSM makes it more difficult to inject traffic into the 379 multicast group, but not impossible. Source authentication 380 requirements apply for SSM sessions too, and an individual 381 verification of who sent the RTP and RTCP packets is needed. An RTP 382 session using SSM will have a group security context that includes 383 the media sources, distribution source, feedback targets, and the 384 receivers. Each has a different role and will be trusted to perform 385 different actions. For example, the distribution source will need to 386 authenticate the media sources to prevent unwanted traffic being 387 distributed via the SSM group. Similarly, the receivers need to 388 authenticate both the distribution source and their feedback target, 389 to prevent injection attacks from malicious devices claiming to be 390 feedback targets. An understanding of the trust relationships and 391 group security context is needed between all components of the 392 system. 394 3. Security Options 396 This section provides an overview of security requirements, and the 397 current RTP security mechanisms that implement those requirements. 398 This cannot be a complete survey, since new security mechanisms are 399 defined regularly. The goal is to help applications designer by 400 reviewing the types of solution that are available. This section 401 will use a number of different security related terms, described in 402 the Internet Security Glossary, Version 2 [RFC4949]. 404 3.1. Secure RTP 406 The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly 407 used mechanisms to provide confidentiality, integrity protection, 408 source authentication and replay protection for RTP. SRTP was 409 developed with RTP header compression and third party monitors in 410 mind. Thus the RTP header is not encrypted in RTP data packets, and 411 the first 8 bytes of the first RTCP packet header in each compound 412 RTCP packet are not encrypted. The entirety of RTP packets and 413 compound RTCP packets are integrity protected. This allows RTP 414 header compression to work, and lets third party monitors determine 415 what RTP traffic flows exist based on the SSRC fields, but protects 416 the sensitive content. 418 SRTP works with transforms where different combinations of encryption 419 algorithm, authentication algorithm, and pseudo-random function can 420 be used, and the authentication tag length can be set to any value. 421 SRTP can also be easily extended with additional cryptographic 422 transforms. This gives flexibility, but requires more security 423 knowledge by the application developer. To simplify things, SDP 424 Security Descriptions (see Section 3.1.3) and DTLS-SRTP (see 425 Section 3.1.1) use pre-defined combinations of transforms, known as 426 SRTP crypto suites and SRTP protection profiles, that bundle together 427 transforms and other parameters, making them easier to use but 428 reducing flexibility. The MIKEY protocol (see Section 3.1.2) 429 provides flexibility to negotiate the full selection of transforms. 430 At the time of this writing, the following transforms, SRTP crypto 431 suites, and SRTP protection profiles are defined or under definition: 433 AES-CM and HMAC-SHA-1: AES Counter Mode encryption with 128-bit keys 434 combined with 160-bit keyed HMAC-SHA-1 with 80-bit authentication 435 tag. This is the default cryptographic transform that needs to be 436 supported. The transforms are defined in SRTP [RFC3711], with the 437 corresponding SRTP crypto suite in [RFC4568] and SRTP protection 438 profile in [RFC5764]. 440 AES-f8 and HMAC-SHA-1: AES f8 mode encryption using 128-bit keys 441 combined with keyed HMAC-SHA-1 using 80-bit authentication. The 442 transforms are defined in [RFC3711], with the corresponding SRTP 443 crypto suite in [RFC4568]. The corresponding SRTP protection 444 profile is not defined. 446 SEED: A Korean national standard cryptographic transform that is 447 defined to be used with SRTP in [RFC5669]. Three options are 448 defined, one using SHA-1 authentication, one using Counter mode 449 with CBC-MAC, and finally one using Galois Counter mode. 451 ARIA: A Korean block cipher [I-D.ietf-avtcore-aria-srtp], that 452 supports 128-, 192- and 256- bit keys. It also defines three 453 options, Counter mode where combined with HMAC-SHA-1 with 80 or 32 454 bits authentication tags, Counter mode with CBC-MAC and Galois 455 Counter mode. It also defines a different key derivation function 456 than the AES based systems. 458 AES-192-CM and AES-256-CM: Cryptographic transforms for SRTP based 459 on AES-192 and AES-256 counter mode encryption and 160-bit keyed 460 HMAC-SHA-1 with 80- and 32-bit authentication tags. These provide 461 192- and 256-bit encryption keys, but otherwise match the default 462 128-bit AES-CM transform. The transforms are defined in [RFC3711] 463 and [RFC6188], with the SRTP crypto suites in [RFC6188]. 465 AES-GCM and AES-CCM: AES Galois Counter Mode and AES Counter with 466 CBC MAC for AES-128 and AES-256. This authentication is included 467 in the cipher text which becomes expanded with the length of the 468 authentication tag instead of using the SRTP authentication tag. 469 This is defined in [I-D.ietf-avtcore-srtp-aes-gcm]. 471 NULL: SRTP [RFC3711] also provides a NULL cipher that can be used 472 when no confidentiality for RTP/RTCP is requested. The 473 corresponding SRTP protection profile is defined in [RFC5764]. 475 The source authentication guarantees provided by SRTP depend on the 476 cryptographic transform and key-management used. Some transforms 477 give strong source authentication even in multiparty sessions; others 478 give weaker guarantees and can authenticate group membership but not 479 sources. TESLA [RFC4383] offers a complement to the regular 480 symmetric keyed authentication transforms, like HMAC-SHA-1, and can 481 provide per-source authentication in some group communication 482 scenarios. The downside is need for buffering the packets for a 483 while before authenticity can be verified. 485 [RFC4771] defines a variant of the authentication tag that enables a 486 receiver to obtain the Roll over Counter for the RTP sequence number 487 that is part of the Initialization vector (IV) for many cryptographic 488 transforms. This enables quicker and easier options for joining a 489 long lived secure RTP group, for example a broadcast session. 491 RTP header extensions are normally carried in the clear and only 492 integrity protected in SRTP. This can be problematic in some cases, 493 so [RFC6904] defines an extension to also encrypt selected header 494 extensions. 496 SRTP is specified and deployed in a number of RTP usage contexts; 497 Significant support in SIP-established VoIP clients including IMS; 498 RTSP [I-D.ietf-mmusic-rfc2326bis] and RTP based media streaming. 499 Thus SRTP in general is widely deployed. When it comes to 500 cryptographic transforms the default (AES-CM and HMAC-SHA-1) is the 501 most commonly used, but it might be expected that AES-GCM, 502 AES-192-CM, and AES-256-CM will gain usage in future, especially due 503 to the AES- and GCM-specific instructions in new CPUs. 505 SRTP does not contain an integrated key-management solution, and 506 instead relies on an external key management protocol. There are 507 several protocols that can be used. The following sections outline 508 some popular schemes. 510 3.1.1. Key Management for SRTP: DTLS-SRTP 512 A Datagram Transport Layer Security extension exists for establishing 513 SRTP keys [RFC5763][RFC5764]. This extension provides secure key- 514 exchange between two peers, enabling perfect forward secrecy and 515 binding strong identity verification to an end-point. The default 516 key generation will generate a key that contains material contributed 517 by both peers. The key-exchange happens in the media plane directly 518 between the peers. The common key-exchange procedures will take two 519 round trips assuming no losses. TLS resumption can be used when 520 establishing additional media streams with the same peer, and reduces 521 the set-up time to one RTT for these streams (see [RFC5764] for a 522 discussion of TLS resumption in this context). 524 The actual security properties of an established SRTP session using 525 DTLS will depend on the cipher suites offered and used, as well as 526 the mechanism for identifying the end-points of the hand-shake. For 527 example some cipher suits provide perfect forward secrecy (PFS), 528 while other do not. When using DTLS, the application designer needs 529 to select which cipher suites DTLS-SRTP can offer and accept so that 530 the desired security properties are achieved. The next choice is how 531 to verify the identity of the peer end-point. One choice can be to 532 rely on the certificates and use a PKI to verify them to make an 533 identity assertion. However, this is not the most common way, 534 instead self-signed certificate are common to use, and instead 535 establish trust through signalling or other third party solutions. 537 DTLS-SRTP key management can use the signalling protocol in four 538 ways. First, to agree on using DTLS-SRTP for media security. 539 Secondly, to determine the network location (address and port) where 540 each side is running a DTLS listener to let the parts perform the 541 key-management handshakes that generate the keys used by SRTP. 542 Thirdly, to exchange hashes of each side's certificates to bind these 543 to the signalling, and ensure there is no man-in-the-middle attack. 544 This assumes that one can trust the signalling solution to be 545 resistant to modification, and not be in collaboration with an 546 attacker. Finally to provide an assertable identity, e.g. [RFC4474] 547 that can be used to prevent modification of the signalling and the 548 exchange of certificate hashes. That way enabling binding between 549 the key-exchange and the signalling. 551 This usage is well defined for SIP/SDP in [RFC5763], and in most 552 cases can be adopted for use with other bi-directional signalling 553 solutions. It is to be noted that there is work underway to revisit 554 the SIP Identity mechanism [RFC4474] in the IETF STIR working group. 556 The main question regarding DTLS-SRTP's security properties is how 557 one verifies any peer identity or at least prevents man-in-the-middle 558 attacks. This do requires trust in some DTLS-SRTP external party, 559 either a PKI, a signalling system or some identity provider. 561 DTLS-SRTP usage is clearly on the rise. It is mandatory to support 562 in WebRTC. It has growing support among SIP end-points. DTLS-SRTP 563 was developed in IETF primarily to meet security requirements for 564 SIP. 566 3.1.2. Key Management for SRTP: MIKEY 568 Multimedia Internet Keying (MIKEY) [RFC3830] is a keying protocol 569 that has several modes with different properties. MIKEY can be used 570 in point-to-point applications using SIP and RTSP (e.g., VoIP calls), 571 but is also suitable for use in broadcast and multicast applications, 572 and centralized group communications. 574 MIKEY can establish multiple security contexts or cryptographic 575 sessions with a single message. It is useable in scenarios where one 576 entity generates the key and needs to distribute the key to a number 577 of participants. The different modes and the resulting properties 578 are highly dependent on the cryptographic method used to establish 579 the session keys actually used by the security protocol, like SRTP. 581 MIKEY has the following modes of operation: 583 Pre-Shared Key: Uses a pre-shared secret for symmetric key crypto 584 used to secure a keying message carrying the already generated 585 session key. This system is the most efficient from the 586 perspective of having small messages and processing demands. The 587 downside is scalability, where usually the effort for the 588 provisioning of pre-shared keys is only manageable if the number 589 of endpoints is small. 591 Public Key encryption: Uses a public key crypto to secure a keying 592 message carrying the already-generated session key. This is more 593 resource intensive but enables scalable systems. It does require 594 a public key infrastructure to enable verification. 596 Diffie-Hellman: Uses Diffie-Hellman key-agreement to generate the 597 session key, thus providing perfect forward secrecy. The downside 598 is high resource consumption in bandwidth and processing during 599 the MIKEY exchange. This method can't be used to establish group 600 keys as each pair of peers performing the MIKEY exchange will 601 establish different keys. 603 HMAC-Authenticated Diffie-Hellman: [RFC4650] defines a variant of 604 the Diffie-Hellman exchange that uses a pre-shared key in a keyed 605 HMAC to verify authenticity of the keying material instead of a 606 digital signature as in the previous method. This method is still 607 restricted to point-to-point usage. 609 RSA-R: MIKEY-RSA in Reverse mode [RFC4738] is a variant of the 610 public key method which doesn't rely on the initiator of the key- 611 exchange knowing the responder's certificate. This method lets 612 both the initiator and the responder to specify the session keying 613 material depending on use case. Usage of this mode requires one 614 round-trip time. 616 TICKET: [RFC6043] is a MIKEY extension using a trusted centralized 617 key management service (KMS). The Initiator and Responder do not 618 share any credentials; instead, they trust a third party, the KMS, 619 with which they both have or can establish shared credentials. 621 IBAKE: [RFC6267] uses a key management services (KMS) infrastructure 622 but with lower demand on the KMS. Claims to provides both perfect 623 forward and backwards secrecy, the exact meaning is unclear (See 624 Perfect Forward Secrecy in [RFC4949]). 626 SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. 627 Based on Identity based Public Key Cryptography and a KMS 628 infrastructure to establish a shared secret value and certificate 629 less signatures to provide source authentication. Its features 630 include simplex transmission, scalability, low-latency call set- 631 up, and support for secure deferred delivery. 633 MIKEY messages have several different transports. [RFC4567] defines 634 how MIKEY messages can be embedded in general SDP for usage with the 635 signalling protocols SIP, SAP and RTSP. There also exist a 3GPP 636 defined usage of MIKEY that sends MIKEY messages directly over UDP 637 [T3GPP.33.246] to key the receivers of Multimedia Broadcast and 638 Multicast Service (MBMS) [T3GPP.26.346]. [RFC3830] defines the 639 application/mikey media type allowing MIKEY to be used in, e.g., 640 email and HTTP. 642 Based on the many choices it is important to consider the properties 643 needed in ones solution and based on that evaluate which modes that 644 are candidates for ones usage. More information on the applicability 645 of the different MIKEY modes can be found in [RFC5197]. 647 MIKEY with pre-shared keys are used by 3GPP MBMS [T3GPP.33.246] and 648 IMS media security [T3GPP.33.328] specifies the use of the TICKET 649 mode transported over SIP and HTTP. RTSP 2.0 650 [I-D.ietf-mmusic-rfc2326bis] specifies use of the RSA-R mode. There 651 are some SIP end-points that support MIKEY. The modes they use are 652 unknown to the authors. 654 3.1.3. Key Management for SRTP: Security Descriptions 656 [RFC4568] provides a keying solution based on sending plain text keys 657 in SDP [RFC4566]. It is primarily used with SIP and the SDP Offer/ 658 Answer model, and is well-defined in point-to-point sessions where 659 each side declares its own unique key. Using Security Descriptions 660 to establish group keys is less well defined, and can have security 661 issues since it's difficult to guarantee unique SSRCs (as needed to 662 avoid a "two-time pad" attack - see Section 9 of [RFC3711]). 664 Since keys are transported in plain text in SDP, they can easily be 665 intercepted unless the SDP carrying protocol provides strong end-to- 666 end confidentiality and authentication guarantees. This is not 667 normally the case, where instead hop-by-hop security is provided 668 between signalling nodes using TLS. This leaves the keying material 669 sensitive to capture by the traversed signalling nodes. Thus, in 670 most cases, the security properties of security descriptions are 671 weak. The usage of security descriptions usually requires additional 672 security measures, e.g. the signalling nodes be trusted and 673 protected by strict access control. Usage of security descriptions 674 requires careful design in order to ensure that the security goals 675 can be met. 677 Security Descriptions is the most commonly deployed keying solution 678 for SIP-based end-points, where almost all end-points that support 679 SRTP also support Security Descriptions. It is also used for access 680 protection in IMS Media Security [T3GPP.33.328]. 682 3.1.4. Key Management for SRTP: Encrypted Key Transport 684 Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP 685 extension that enables group keying despite using a keying mechanism 686 like DTLS-SRTP that doesn't support group keys. It is designed for 687 centralized conferencing, but can also be used in sessions where end- 688 points connect to a conference bridge or a gateway, and need to be 689 provisioned with the keys each participant on the bridge or gateway 690 uses to avoid decryption and encryption cycles on the bridge or 691 gateway. This can enable interworking between DTLS-SRTP and other 692 keying systems where either party can set the key (e.g., interworking 693 with security descriptions). 695 The mechanism is based on establishing an additional EKT key which 696 everyone uses to protect their actual session key. The actual 697 session key is sent in a expanded authentication tag to the other 698 session participants. This key is only sent occasionally or 699 periodically depending on use cases and depending on what 700 requirements exist for timely delivery or notification. 702 The only known deployment of EKT so far are in some Cisco video 703 conferencing products. 705 3.1.5. Key Management for SRTP: Other systems 707 The ZRTP [RFC6189] key-management system for SRTP was proposed as an 708 alternative to DTLS-SRTP. ZRTP provides best effort encryption 709 independent of the signalling protocol and utilizes key continuity, 710 Short Authentication Strings, or a PKI for authentication. ZRTP 711 wasn't adopted as an IETF standards track protocol, but was instead 712 published as an informational RFC. Commercial implementations exist. 714 Additional proprietary solutions are also known to exist. 716 3.2. RTP Legacy Confidentiality 718 Section 9 of the RTP standard [RFC3550] defines a DES or 3DES based 719 encryption of RTP and RTCP packets. This mechanism is keyed using 720 plain text keys in SDP [RFC4566] using the "k=" SDP field. This 721 method can provide confidentiality but, as discussed in Section 9 of 722 [RFC3550], it has extremely weak security properties and is not to be 723 used. 725 3.3. IPsec 727 IPsec [RFC4301] can be used in either tunnel or transport mode to 728 protect RTP and RTCP packets in transit from one network interface to 729 another. This can be sufficient when the network interfaces have a 730 direct relation, or in a secured environment where it can be 731 controlled who can read the packets from those interfaces. 733 The main concern with using IPsec to protect RTP traffic is that in 734 most cases using a VPN approach that terminates the security 735 association at some node prior to the RTP end-point leaves the 736 traffic vulnerable to attack between the VPN termination node and the 737 end-point. Thus usage of IPsec requires careful thought and design 738 of its usage so that it meets the security goals. A important 739 question is how one ensures the IPsec terminating peer and the 740 ultimate destination are the same. Applications can have issues 741 using existing APIs with determining if IPsec is being used or not, 742 and when used who the authenticated peer entity is. 744 IPsec with RTP is more commonly used as a security solution between 745 infrastructure nodes that exchange many RTP sessions and media 746 streams. The establishment of a secure tunnel between such nodes 747 minimizes the key-management overhead. 749 3.4. RTP over TLS over TCP 751 Just as RTP can be sent over TCP [RFC4571], it can also be sent over 752 TLS over TCP [RFC4572], using TLS to provide point-to-point security 753 services. The security properties TLS provides are confidentiality, 754 integrity protection and possible source authentication if the client 755 or server certificates are verified and provide a usable identity. 756 When used in multi-party scenarios using a central node for media 757 distribution, the security provide is only between the central node 758 and the peers, so the security properties for the whole session are 759 dependent on what trust one can place in the central node. 761 RTSP 1.0 [RFC2326] and 2.0 [I-D.ietf-mmusic-rfc2326bis] specifies the 762 usage of RTP over the same TLS/TCP connection that the RTSP messages 763 are sent over. It appears that RTP over TLS/TCP is also used in some 764 proprietary solutions that uses TLS to bypass firewalls. 766 3.5. RTP over Datagram TLS (DTLS) 768 Datagram Transport Layer Security (DTLS) [RFC6347] is a based on TLS 769 [RFC5246], but designed to work over a unreliable datagram oriented 770 transport rather than requiring reliable byte stream semantics from 771 the transport protocol. Accordingly, DTLS can provide point-to-point 772 security for RTP flows analogous to that provided by TLS, but over an 773 datagram transport such as UDP. The two peers establish an DTLS 774 association between each other, including the possibility to do 775 certificate-based source authentication when establishing the 776 association. All RTP and RTCP packets flowing will be protected by 777 this DTLS association. 779 Note that using DTLS for RTP flows is different to using DTLS-SRTP 780 key management. DTLS-SRTP uses the same key-management steps as 781 DTLS, but uses SRTP for the per packet security operations. Using 782 DTLS for RTP flows uses the normal datagram TLS data protection, 783 wrapping complete RTP packets. When using DTLS for RTP flows, the 784 RTP and RTCP packets are completely encrypted with no headers in the 785 clear; when using DTLS-SRTP, the RTP headers are in the clear and 786 only the payload data is encrypted. 788 DTLS can use similar techniques to those available for DTLS-SRTP to 789 bind a signalling-side agreement to communicate to the certificates 790 used by the end-point when doing the DTLS handshake. This enables 791 use without having a certificate-based trust chain to a trusted 792 certificate root. 794 There does not appear to be significant usage of DTLS for RTP. 796 3.6. Media Content Security/Digital Rights Management 798 Mechanisms have been defined that encrypt only the media content, 799 operating within the RTP payload data and leaving the RTP headers and 800 RTCP unaffected. There are several reasons why this might be 801 appropriate, but a common rationale is to ensure that the content 802 stored by RTSP streaming servers has the media content in a protected 803 format that cannot be read by the streaming server (this is mostly 804 done in the context of Digital Rights Management). These approaches 805 then use a key-management solution between the rights provider and 806 the consuming client to deliver the key used to protect the content 807 and do not give the media server access to the security context. 808 Such methods have several security weaknesses such as the fact that 809 the same key is handed out to a potentially large group of receiving 810 clients, increasing the risk of a leak. 812 Use of this type of solution can be of interest in environments that 813 allow middleboxes to rewrite the RTP headers and select which streams 814 are delivered to an end-point (e.g., some types of centralised video 815 conference systems). The advantage of encrypting and possibly 816 integrity protecting the payload but not the headers is that the 817 middlebox can't eavesdrop on the media content, but can still provide 818 stream switching functionality. The downside of such a system is 819 that it likely needs two levels of security: the payload level 820 solution to provide confidentiality and source authentication, and a 821 second layer with additional transport security ensuring source 822 authentication and integrity of the RTP headers associated with the 823 encrypted payloads. This can also results in the need to have two 824 different key-management systems as the entity protecting the packets 825 and payloads are different with different set of keys. 827 The aspect of two tiers of security are present in ISMACryp (see 828 Section 3.6.1) and the deprecated 3GPP Packet Based Streaming Service 829 Annex.K [T3GPP.26.234R8] solution. 831 3.6.1. ISMA Encryption and Authentication 833 The Internet Streaming Media Alliance (ISMA) has defined ISMA 834 Encryption and Authentication 2.0 [ISMACryp2]. This specification 835 defines how one encrypts and packetizes the encrypted application 836 data units (ADUs) in an RTP payload using the MPEG-4 Generic payload 837 format [RFC3640]. The ADU types that are allowed are those that can 838 be stored as elementary streams in an ISO Media File format based 839 file. ISMACryp uses SRTP for packet level integrity and source 840 authentication from a streaming server to the receiver. 842 Key-management for a ISMACryp based system can be achieved through 843 Open Mobile Alliance (OMA) Digital Rights Management 2.0 [OMADRMv2], 844 for example. 846 4. Securing RTP Applications 848 In the following we provide guidelines for how to choose appropriate 849 security mechanisms for RTP applications. 851 4.1. Application Requirements 853 This section discusses a number of application requirements that need 854 be considered. An application designer choosing security solutions 855 requires a good understanding of what level of security is needed and 856 what behaviour they strive to achieve. 858 4.1.1. Confidentiality 860 When it comes to confidentiality of an RTP session there are several 861 aspects to consider: 863 Probability of compromise: When using encryption to provide media 864 confidentiality, it is necessary to have some rough understanding 865 of the security goal and how long one expect the protected content 866 to remain confidential. National or other regulations might 867 provide additional requirements on a particular usage of an RTP. 868 From that, one can determine which encryption algorithms are to be 869 used from the set of available transforms. 871 Potential for other leakage: RTP based security in most of its forms 872 simply wraps RTP and RTCP packets into cryptographic containers. 873 This commonly means that the size of the original RTP payload is 874 visible to observers of the protected packet flow. This can 875 provide information to those observers. A well-documented case is 876 the risk with variable bit-rate speech codecs that produce 877 different sized packets based on the speech input [RFC6562]. 878 Potential threats such as these need to be considered and, if they 879 are significant, then restrictions will be needed on mode choices 880 in the codec, or additional padding will need to be added to make 881 all packets equal size and remove the informational leakage. 883 Another case is RTP header extensions. If SRTP is used, header 884 extensions are normally not protected by the security mechanism 885 protecting the RTP payload. If the header extension carries 886 information that is considered sensitive, then the application 887 needs to be modified to ensure that mechanisms used to protect 888 against such information leakage are employed. 890 Who has access: When considering the confidentiality properties of a 891 system, it is important to consider where the media handled in the 892 clear. For example, if the system is based on an RTP mixer that 893 needs the keys to decrypt the media, process, and repacketize it, 894 then is the mixer providing the security guarantees expected by 895 the other parts of the system? Furthermore, it is important to 896 consider who has access to the keys. The policies for the 897 handling of the keys, and who can access the keys, need to be 898 considered along with the confidentiality goals. 900 As can be seen the actual confidentiality level has likely more to do 901 with the application's usage of centralized nodes, and the details of 902 the key-management solution chosen, than with the actual choice of 903 encryption algorithm (although, of course, the encryption algorithm 904 needs to be chosen appropriately for the desired security level). 906 4.1.2. Integrity 908 Protection against modification of content by a third party, or due 909 to errors in the network, is another factor to consider. The first 910 aspect that one considers is what resilience one has against 911 modifications to the content. Some media types are extremely 912 sensitive to network bit errors, whereas others might be able to 913 tolerate some degree of data corruption. Equally important is to 914 consider the sensitivity of the content, who is providing the 915 integrity assertion, what is the source of the integrity tag, and 916 what are the risks of modifications happening prior to that point 917 where protection is applied? These issues affect what cryptographic 918 algorithm is used, and the length of the integrity tags, and whether 919 the entire payload is protected. 921 RTP applications that rely on central nodes need to consider if hop- 922 by-hop integrity is acceptable, or if true end-to-end integrity 923 protection is needed? Is it important to be able to tell if a 924 middlebox has modified the data? There are some uses of RTP that 925 require trusted middleboxes that can modify the data in a way that 926 doesn't break integrity protection as seen by the receiver, for 927 example local advertisement insertion in IPTV systems; there are also 928 uses where it is essential that such in-network modification be 929 detectable. RTP can support both, with appropriate choices of 930 security mechanisms. 932 Integrity of the data is commonly closely tied to the question of 933 source authentication. That is, it becomes important to know who 934 makes an integrity assertion for the data. 936 4.1.3. Source Authentication 938 Source authentication is about determining who sent a particular RTP 939 or RTCP packet. It is normally closely tied with integrity, since a 940 receiver generally also wants to ensure that the data received is 941 what the source really sent, so source authentication without 942 integrity is not particularly useful. Similarly, integrity 943 protection without source authentication is also not particularly 944 useful; a claim that a packet is unchanged that cannot itself be 945 validated as from the source (or some from other known and trusted 946 party) is meaningless. 948 Source authentication can be asserted in several different ways: 950 Base level: Using cryptographic mechanisms that give authentication 951 with some type of key-management provide an implicit method for 952 source authentication. Assuming that the mechanism has sufficient 953 strength to not be circumvented in the time frame when you would 954 accept the packet as valid, it is possible to assert a source- 955 authenticated statement; this message is likely from a source that 956 has the cryptographic key(s) to this communication. 958 What that assertion actually means is highly dependent on the 959 application and how it handles the keys. If only the two peers 960 have access to the keys, this can form a basis for a strong trust 961 relationship that traffic is authenticated coming from one of the 962 peers. However, in a multi-party scenario where security contexts 963 are shared among participants, most base-level authentication 964 solutions can't even assert that this packet is from the same 965 source as the previous packet. 967 Binding the source and the signalling: A step up in the assertion 968 that can be done in base-level systems is to tie the signalling to 969 the key-exchange. Here, the goal is to at least be able to assert 970 that the source of the packets is the same entity that the 971 receiver established the session with. How feasible this is 972 depends on the properties of the key-management system, the 973 ability to tie the signalling to a particular source, and the 974 degree of trust the receiver places on the different nodes 975 involved. 977 For example, systems where the key-exchange is done using the 978 signalling systems, such as Security Descriptions [RFC4568], 979 enable a direct binding between signalling and key-exchange. In 980 such systems, the actual security depends on the trust one can 981 place in the signalling system to correctly associate the peer's 982 identity with the key-exchange. 984 Using Identities: If the applications have access to a system that 985 can provide verifiable identities, then the source authentication 986 can be bound to that identity. For example, in a point-to-point 987 communication even symmetric key crypto, where the key-management 988 can assert that the key has only been exchanged with a particular 989 identity, can provide a strong assertion about the source of the 990 traffic. SIP identity [RFC4474] provides one example of how this 991 can be done, and could be used to bind DTLS-SRTP certificates to 992 the identity provider's public key to authenticate the source of a 993 DTLS-SRTP flow. 995 Note that all levels of the system need to have matching 996 capability to assert identity. If the signalling can assert that 997 only a given entity in a multiparty session has a key, then the 998 media layer might be able to provide guarantees about the identity 999 of the media sender. However, using an signalling authentication 1000 mechanism built on a group key can limit the media layer to 1001 asserting only group membership. 1003 4.1.4. Identity 1005 There exist many different types of identity systems with different 1006 properties (e.g., SIP identity [RFC4474]). In the context of RTP 1007 applications, the most important property is the possibility to 1008 perform source authentication and verify such assertions in relation 1009 to any claimed identities. What an identity really is can also vary 1010 but, in the context of communication, one of the most obvious is the 1011 identity of the human user one communicates with. However, the human 1012 user can also have additional identities in a particular role. For 1013 example, the human Alice, can also be a police officer and in some 1014 cases her identity as police officer will be more relevant then that 1015 she is Alice. This is common in contact with organizations, where it 1016 is important to prove the persons right to represent the 1017 organization. Some examples of identity mechanisms that can be used: 1019 Certificate based: A certificate is used to prove the identity, by 1020 having access to the private part of the certificate one can 1021 perform signing to assert ones identity. Any entity interested in 1022 verifying the assertion then needs the public part of the 1023 certificate. By having the certificate, one can verify the 1024 signature against the certificate. The next step is to determine 1025 if one trusts the certificate's trust chain. Commonly by 1026 provisioning the verifier with the public part of a root 1027 certificate, this enables the verifier to verify a trust chain 1028 from the root certificate down to the identity certificate. 1029 However, the trust is based on all steps in the certificate chain 1030 being verifiable and trusted. Thus provisioning of root 1031 certificates and the ability to revoke compromised certificates 1032 are aspects that will require infrastructure. 1034 Online Identity Providers: An online identity provider (IdP) can 1035 authenticate a user's right to use an identity, then perform 1036 assertions on their behalf or provision the requester with short- 1037 term credentials to assert their identity. The verifier can then 1038 contact the IdP to request verification of a particular identity. 1039 Here the trust is highly dependent on how much one trusts the IdP. 1040 The system also becomes dependent on having access to the relevant 1041 IdP. 1043 In all of the above examples, an important part of the security 1044 properties are related to the method for authenticating the access to 1045 the identity. 1047 4.1.5. Privacy 1049 RTP applications need to consider what privacy goals they have. As 1050 RTP applications communicate directly between peers in many cases, 1051 the IP addresses of any communication peer will be available. The 1052 main privacy concern with IP addresses is related to geographical 1053 location and the possibility to track a user of an end-point. The 1054 main way of avoid such concerns is the introduction of relay (e.g., a 1055 TURN server [RFC5766]) or centralized media mixers or forwarders that 1056 hides the address of a peer from any other peer. The security and 1057 trust placed in these relays obviously needs to be carefully 1058 considered. 1060 RTP itself can contribute to enabling a particular user to be tracked 1061 between communication sessions if the CNAME is generated according to 1062 the RTP specification in the form of user@host. Such RTCP CNAMEs are 1063 likely long term stable over multiple sessions, allowing tracking of 1064 users. This can be desirable for long-term fault tracking and 1065 diagnosis, but clearly has privacy implications. Instead 1066 cryptographically random ones could be used as defined by Guidelines 1067 for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) 1068 [RFC7022]. 1070 If there exist privacy goals, these need to be considered, and the 1071 system designed with them in mind. In addition certain RTP features 1072 might have to be configured to safeguard privacy, or have 1073 requirements on how the implementation is done. 1075 4.2. Application Structure 1077 When it comes to RTP security, the most appropriate solution is often 1078 highly dependent on the topology of the communication session. The 1079 signalling also impacts what information can be provided, and if this 1080 can be instance specific, or common for a group. In the end the key- 1081 management system will highly affect the security properties achieved 1082 by the application. At the same time, the communication structure of 1083 the application limits what key management methods are applicable. 1084 As different key-management have different requirements on underlying 1085 infrastructure it is important to take that aspect into consideration 1086 early in the design. 1088 4.3. Interoperability 1090 Few RTP applications exist as independent applications that never 1091 interoperate with anything else. Rather, they enable communication 1092 with a potentially large number of other systems. To minimize the 1093 number of security mechanisms that need to be implemented, it is 1094 important to consider if one can use the same security mechanisms as 1095 other applications. This can also reduce problems of determining 1096 what security level is actually negotiated in a particular session. 1098 The desire to be interoperable can, in some cases, be in conflict 1099 with the security requirements of an application. To meet the 1100 security goals, it might be necessary to sacrifice interoperability. 1101 Alternatively, one can implement multiple security mechanisms, this 1102 however introduces the complication of ensuring that the user 1103 understands what it means to use a particular security system. In 1104 addition, the application can then become vulnerable to bid-down 1105 attack. 1107 5. Examples 1109 In the following we describe a number of example security solutions 1110 for applications using RTP services or frameworks. These examples 1111 are provided to illustrate the choices available. They are not 1112 normative recommendations for security. 1114 5.1. Media Security for SIP-established Sessions using DTLS-SRTP 1116 The IETF evaluated media security for RTP sessions established using 1117 point-to-point SIP sessions in 2009. A number of requirements were 1118 determined, and based on those, the existing solutions for media 1119 security and especially the keying methods were analysed. The 1120 resulting requirements and analysis were published in [RFC5479]. 1121 Based on this analysis and working group discussion, DTLS-SRTP was 1122 determined to be the best solution. 1124 The security solution for SIP using DTLS-SRTP is defined in the 1125 Framework for Establishing a Secure Real-time Transport Protocol 1126 (SRTP) Security Context Using Datagram Transport Layer Security 1127 (DTLS) [RFC5763]. On a high level the framework uses SIP with SDP 1128 offer/answer procedures to exchange the network addresses where the 1129 server end-point will have a DTLS-SRTP enable server running. The 1130 SIP signalling is also used to exchange the fingerprints of the 1131 certificate each end-point will use in the DTLS establishment 1132 process. When the signalling is sufficiently completed, the DTLS- 1133 SRTP client performs DTLS handshakes and establishes SRTP session 1134 keys. The clients also verify the fingerprints of the certificates 1135 to verify that no man in the middle has inserted themselves into the 1136 exchange. 1138 DTLS has a number of good security properties. For example, to 1139 enable a man in the middle someone in the signalling path needs to 1140 perform an active action and modify both the signalling message and 1141 the DTLS handshake. There also exists solutions that enables the 1142 fingerprints to be bound to identities. SIP Identity provides an 1143 identity established by the first proxy for each user [RFC4474]. 1144 This reduces the number of nodes the connecting user User Agent has 1145 to trust to include just the first hop proxy, rather than the full 1146 signalling path. The biggest security weakness of this system is its 1147 dependency on the signalling. SIP signalling passes multiple nodes 1148 and there is usually no message security deployed, only hop-by-hop 1149 transport security, if any, between the nodes. 1151 5.2. Media Security for WebRTC Sessions 1153 Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] is a 1154 solution providing JavaScript web applications with real-time media 1155 directly between browsers. Media is transported using RTP protected 1156 using a mandatory application of SRTP [RFC3711], with keying done 1157 using DTLS-SRTP [RFC5764]. The security configuration is further 1158 defined in the WebRTC Security Architecture 1159 [I-D.ietf-rtcweb-security-arch]. 1161 A hash of the peer's certificate is provided to the JavaScript web 1162 application, allowing that web application to verify identity of the 1163 peer. There are several ways in which the certificate hashes can be 1164 verified. An approach identified in the WebRTC security architecture 1165 [I-D.ietf-rtcweb-security-arch] is to use an identity provider. In 1166 this solution the Identity Provider, which is a third party to the 1167 web application, signs the DTLS-SRTP hash combined with a statement 1168 on the validity of the user identity that has been used to sign the 1169 hash. The receiver of such an identity assertion can then 1170 independently verify the user identity to ensure that it is the 1171 identity that the receiver intended to communicate with, and that the 1172 cryptographic assertion holds; this way a user can be certain that 1173 the application also can't perform a MITM and acquire the keys to the 1174 media communication. Other ways of verifying the certificate hashes 1175 exist, for example they could be verified against a hash carried in 1176 some out of band channel (e.g., compare with a hash printed on a 1177 business card), or using a verbal short authentication string (e.g., 1178 as in ZRTP [RFC6189]), or using hash continuity. 1180 In the development of WebRTC there has also been attention given to 1181 privacy considerations. The main RTP-related concerns that have been 1182 raised are: 1184 Location Disclosure: As ICE negotiation [RFC5245] provides IP 1185 addresses and ports for the browser, this leaks location 1186 information in the signalling to the peer. To prevent this one 1187 can block the usage of any ICE candidate that isn't a relay 1188 candidate, i.e. where the IP and port provided belong to the 1189 service providers media traffic relay. 1191 Prevent tracking between sessions: static RTP CNAMEs and DTLS-SRTP 1192 certificates provide information that is re-used between session 1193 instances. Thus to prevent tracking, such information is ought 1194 not be re-used between sessions, or the information ought not sent 1195 in the clear. Note, that generating new certificates each time 1196 prevents continuity in authentication, however, as WebRTC users 1197 are expected to use multiple devices to access the same 1198 communication service, such continuity can't be expected anyway, 1199 instead the above described identity mechanism has to be relied 1200 on. 1202 Note: The above cases are focused on providing privacy from other 1203 parties, not on providing privacy from the web server that provides 1204 the WebRTC Javascript application. 1206 5.3. IP Multimedia Subsystem (IMS) Media Security 1208 In IMS, the core network is controlled by a single operator, or by 1209 several operators with high trust in each other. Except for some 1210 types of accesses, the operator is in full control, and no packages 1211 are routed over the Internet. Nodes in the core network offer 1212 services such as voice mail, interworking with legacy systems (PSTN, 1213 GSM, and 3G), and transcoding. End-points are authenticated during 1214 the SIP registration using either IMS-AKA (using SIM credentials) or 1215 SIP Digest (using password). 1217 In IMS media security [T3GPP.33.328], end-to-end encryption is 1218 therefore not seen as needed or desired as it would hinder for 1219 example interworking and transcoding, making calls between 1220 incompatible terminals impossible. Because of this IMS media 1221 security mostly uses end-to-access-edge security where SRTP is 1222 terminated in the first node in the core network. As the SIP 1223 signaling is trusted and encrypted (with TLS or IPsec), security 1224 descriptions [RFC4568] is considered to give good protection against 1225 eavesdropping over the accesses that are not already encrypted (GSM, 1226 3G, LTE). Media source authentication is based on knowledge of the 1227 SRTP session key and trust in that the IMS network will only forward 1228 media from the correct end-point. 1230 For enterprises and government agencies, which might have weaker 1231 trust in the IMS core network and can be assumed to have compatible 1232 terminals, end-to-end security can be achieved by deploying their own 1233 key management server. 1235 Work on Interworking with WebRTC is currently ongoing; the security 1236 will still be end-to-access-edge, but using DTLS-SRTP [RFC5763] 1237 instead of security descriptions. 1239 5.4. 3GPP Packet Based Streaming Service (PSS) 1240 The 3GPP Release 11 PSS specification of the Packet Based Streaming 1241 Service (PSS) [T3GPP.26.234R11] defines, in Annex R, a set of 1242 security mechanisms. These security mechanisms are concerned with 1243 protecting the content from being copied, i.e. Digital Rights 1244 Management. To meet these goals with the specified solution, the 1245 client implementation and the application platform are trusted to 1246 protect against access and modification by an attacker. 1248 PSS is RTSP 1.0 [RFC2326] controlled media streaming over RTP. Thus 1249 an RTSP client whose user wants to access a protected content will 1250 request a session description (SDP [RFC4566]) for the protected 1251 content. This SDP will indicate that the media is ISMACryp 2.0 1252 [ISMACryp2] protected media encoding application units (AUs). The 1253 key(s) used to protect the media are provided in either of two ways. 1254 If a single key is used then the client uses some DRM system to 1255 retrieve the key as indicated in the SDP. Commonly OMA DRM v2 1256 [OMADRMv2] will be used to retrieve the key. If multiple keys are to 1257 be used, then an additional RTSP stream for key-updates in parallel 1258 with the media streams is established, where key updates are sent to 1259 the client using Short Term Key Messages defined in the "Service and 1260 Content Protection for Mobile Broadcast Services" section of the OMA 1261 Mobile Broadcast Services [OMABCAST]. 1263 Worth noting is that this solution doesn't provide any integrity 1264 verification method for the RTP header and payload header 1265 information, only the encoded media AU is protected. 3GPP has not 1266 defined any requirement for supporting any solution that could 1267 provide that service. Thus, replay or insertion attacks are 1268 possible. Another property is that the media content can be 1269 protected by the ones providing the media, so that the operators of 1270 the RTSP server has no access to unprotected content. Instead all 1271 that want to access the media is supposed to contact the DRM keying 1272 server and if the device is acceptable they will be given the key to 1273 decrypt the media. 1275 To protect the signalling, RTSP 1.0 supports the usage of TLS. This 1276 is, however, not explicitly discussed in the PSS specification. 1277 Usage of TLS can prevent both modification of the session description 1278 information and help maintain some privacy of what content the user 1279 is watching as all URLs would then be confidentiality protected. 1281 5.5. RTSP 2.0 1283 Real-time Streaming Protocol 2.0 [I-D.ietf-mmusic-rfc2326bis] offers 1284 an interesting comparison to the PSS service (Section 5.4) that is 1285 based on RTSP 1.0 and service requirements perceived by mobile 1286 operators. A major difference between RTSP 1.0 and RTSP 2.0 is that 1287 2.0 is fully defined under the requirement to have mandatory to 1288 implement security mechanism. As it specifies how one transport 1289 media over RTP it is also defining security mechanisms for the RTP 1290 transported media streams. 1292 The security goals for RTP in RTSP 2.0 is to ensure that there is 1293 confidentiality, integrity and source authentication between the RTSP 1294 server and the client. This to prevent eavesdropping on what the 1295 user is watching for privacy reasons and to prevent replay or 1296 injection attacks on the media stream. To reach these goals, the 1297 signalling also has to be protected, requiring the use of TLS between 1298 the client and server. 1300 Using TLS-protected signalling the client and server agree on the 1301 media transport method when doing the SETUP request and response. 1302 The secured media transport is SRTP (SAVP/RTP) normally over UDP. 1303 The key management for SRTP is MIKEY using RSA-R mode. The RSA-R 1304 mode is selected as it allows the RTSP Server to select the key 1305 despite having the RTSP Client initiate the MIKEY exchange. It also 1306 enables the reuse of the RTSP servers TLS certificate when creating 1307 the MIKEY messages thus ensuring a binding between the RTSP server 1308 and the key exchange. Assuming the SETUP process works, this will 1309 establish a SRTP crypto context to be used between the RTSP Server 1310 and the Client for the RTP transported media streams. 1312 6. IANA Considerations 1314 This document makes no request of IANA. 1316 Note to RFC Editor: this section can be removed on publication as an 1317 RFC. 1319 7. Security Considerations 1321 This entire document is about security. Please read it. 1323 8. Acknowledgements 1325 We thank the IESG for their careful review of 1326 [I-D.ietf-avt-srtp-not-mandatory] which led to the writing of this 1327 memo. John Mattsson has contributed the IMS Media Security example 1328 (Section 5.3). 1330 The authors wished to thank Christian Correll, Dan Wing, Kevin Gross, 1331 Alan Johnston, Michael Peck, Ole Jacobsen, and John Mattsson for 1332 review and proposals for improvements of the text. 1334 9. Informative References 1336 [I-D.ietf-avt-srtp-not-mandatory] 1337 Perkins, C. and M. Westerlund, "Securing the RTP Protocol 1338 Framework: Why RTP Does Not Mandate a Single Media 1339 Security Solution", draft-ietf-avt-srtp-not-mandatory-14 1340 (work in progress), October 2013. 1342 [I-D.ietf-avtcore-aria-srtp] 1343 Kim, W., Lee, J., Kim, D., Park, J., and D. Kwon, "The 1344 ARIA Algorithm and Its Use with the Secure Real-time 1345 Transport Protocol(SRTP)", draft-ietf-avtcore-aria-srtp-05 1346 (work in progress), September 2013. 1348 [I-D.ietf-avtcore-srtp-aes-gcm] 1349 McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated 1350 Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- 1351 aes-gcm-10 (work in progress), September 2013. 1353 [I-D.ietf-avtcore-srtp-ekt] 1354 McGrew, D., Wing, D., and K. Fischer, "Encrypted Key 1355 Transport for Secure RTP", draft-ietf-avtcore-srtp-ekt-00 1356 (work in progress), July 2012. 1358 [I-D.ietf-mmusic-rfc2326bis] 1359 Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 1360 and M. Stiemerling, "Real Time Streaming Protocol 2.0 1361 (RTSP)", draft-ietf-mmusic-rfc2326bis-38 (work in 1362 progress), October 2013. 1364 [I-D.ietf-rtcweb-overview] 1365 Alvestrand, H., "Overview: Real Time Protocols for Brower- 1366 based Applications", draft-ietf-rtcweb-overview-08 (work 1367 in progress), September 2013. 1369 [I-D.ietf-rtcweb-security-arch] 1370 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1371 rtcweb-security-arch-07 (work in progress), July 2013. 1373 [ISMACryp2] 1374 Internet Streaming Media Alliance (ISMA), "ISMA Encryption 1375 and Authentication, Version 2.0 release version", November 1376 2007. 1378 [OMABCAST] 1379 Open Mobile Alliance, "OMA Mobile Broadcast Services 1380 V1.0", February 2009. 1382 [OMADRMv2] 1383 Open Mobile Alliance, "OMA Digital Rights Management 1384 V2.0", July 2008. 1386 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1387 RFC 1112, August 1989. 1389 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1390 Streaming Protocol (RTSP)", RFC 2326, April 1998. 1392 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 1393 Engineering Task Force Standard Protocols", BCP 61, RFC 1394 3365, August 2002. 1396 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1397 Jacobson, "RTP: A Transport Protocol for Real-Time 1398 Applications", STD 64, RFC 3550, July 2003. 1400 [RFC3640] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., 1401 and P. Gentric, "RTP Payload Format for Transport of 1402 MPEG-4 Elementary Streams", RFC 3640, November 2003. 1404 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1405 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1406 RFC 3711, March 2004. 1408 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1409 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1410 August 2004. 1412 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1413 Internet Protocol", RFC 4301, December 2005. 1415 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 1416 Stream Loss-Tolerant Authentication (TESLA) in the Secure 1417 Real-time Transport Protocol (SRTP)", RFC 4383, February 1418 2006. 1420 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1421 Authenticated Identity Management in the Session 1422 Initiation Protocol (SIP)", RFC 4474, August 2006. 1424 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1425 Description Protocol", RFC 4566, July 2006. 1427 [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 1428 Carrara, "Key Management Extensions for Session 1429 Description Protocol (SDP) and Real Time Streaming 1430 Protocol (RTSP)", RFC 4567, July 2006. 1432 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1433 Description Protocol (SDP) Security Descriptions for Media 1434 Streams", RFC 4568, July 2006. 1436 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 1437 and RTP Control Protocol (RTCP) Packets over Connection- 1438 Oriented Transport", RFC 4571, July 2006. 1440 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1441 Transport Layer Security (TLS) Protocol in the Session 1442 Description Protocol (SDP)", RFC 4572, July 2006. 1444 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1445 IP", RFC 4607, August 2006. 1447 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1448 Multimedia Internet KEYing (MIKEY)", RFC 4650, September 1449 2006. 1451 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1452 RSA-R: An Additional Mode of Key Distribution in 1453 Multimedia Internet KEYing (MIKEY)", RFC 4738, November 1454 2006. 1456 [RFC4771] Lehtovirta, V., Naslund, M., and K. Norrman, "Integrity 1457 Transform Carrying Roll-Over Counter for the Secure Real- 1458 time Transport Protocol (SRTP)", RFC 4771, January 2007. 1460 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1461 4949, August 2007. 1463 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 1464 January 2008. 1466 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 1467 Various Multimedia Internet KEYing (MIKEY) Modes and 1468 Extensions", RFC 5197, June 2008. 1470 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1471 (ICE): A Protocol for Network Address Translator (NAT) 1472 Traversal for Offer/Answer Protocols", RFC 5245, April 1473 2010. 1475 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1476 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1478 [RFC5479] Wing, D., Fries, S., Tschofenig, H., and F. Audet, 1479 "Requirements and Analysis of Media Security Management 1480 Protocols", RFC 5479, April 2009. 1482 [RFC5669] Yoon, S., Kim, J., Park, H., Jeong, H., and Y. Won, "The 1483 SEED Cipher Algorithm and Its Use with the Secure Real- 1484 Time Transport Protocol (SRTP)", RFC 5669, August 2010. 1486 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 1487 Protocol (RTCP) Extensions for Single-Source Multicast 1488 Sessions with Unicast Feedback", RFC 5760, February 2010. 1490 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1491 for Establishing a Secure Real-time Transport Protocol 1492 (SRTP) Security Context Using Datagram Transport Layer 1493 Security (DTLS)", RFC 5763, May 2010. 1495 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1496 Security (DTLS) Extension to Establish Keys for the Secure 1497 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1499 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1500 Relays around NAT (TURN): Relay Extensions to Session 1501 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1503 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 1504 Modes of Key Distribution in Multimedia Internet KEYing 1505 (MIKEY)", RFC 6043, March 2011. 1507 [RFC6188] McGrew, D., "The Use of AES-192 and AES-256 in Secure 1508 RTP", RFC 6188, March 2011. 1510 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 1511 Path Key Agreement for Unicast Secure RTP", RFC 6189, 1512 April 2011. 1514 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based 1515 Authenticated Key Exchange (IBAKE) Mode of Key 1516 Distribution in Multimedia Internet KEYing (MIKEY)", RFC 1517 6267, June 2011. 1519 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1520 Security Version 1.2", RFC 6347, January 2012. 1522 [RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in 1523 Multimedia Internet KEYing (MIKEY)", RFC 6509, February 1524 2012. 1526 [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of 1527 Variable Bit Rate Audio with Secure RTP", RFC 6562, March 1528 2012. 1530 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1531 Real-time Transport Protocol (SRTP)", RFC 6904, April 1532 2013. 1534 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 1535 "Guidelines for Choosing RTP Control Protocol (RTCP) 1536 Canonical Names (CNAMEs)", RFC 7022, September 2013. 1538 [T3GPP.26.234R11] 1539 3GPP, "Technical Specification Group Services and System 1540 Aspects; Transparent end-to-end Packet-switched Streaming 1541 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1542 11.1.0, September 2012. 1544 [T3GPP.26.234R8] 1545 3GPP, "Technical Specification Group Services and System 1546 Aspects; Transparent end-to-end Packet-switched Streaming 1547 Service (PSS); Protocols and codecs", 3GPP TS 26.234 1548 8.4.0, September 2009. 1550 [T3GPP.26.346] 1551 3GPP, "Multimedia Broadcast/Multicast Service (MBMS); 1552 Protocols and codecs", 3GPP TS 26.346 10.7.0, March 2013. 1554 [T3GPP.33.246] 1555 3GPP, "3G Security; Security of Multimedia Broadcast/ 1556 Multicast Service (MBMS)", 3GPP TS 33.246 12.1.0, December 1557 2012. 1559 [T3GPP.33.328] 1560 3GPP, "IP Multimedia Subsystem (IMS) media plane 1561 security", 3GPP TS 33.328 12.1.0, December 2012. 1563 Authors' Addresses 1565 Magnus Westerlund 1566 Ericsson 1567 Farogatan 6 1568 SE-164 80 Kista 1569 Sweden 1571 Phone: +46 10 714 82 87 1572 Email: magnus.westerlund@ericsson.com 1573 Colin Perkins 1574 University of Glasgow 1575 School of Computing Science 1576 Glasgow G12 8QQ 1577 United Kingdom 1579 Email: csp@csperkins.org 1580 URI: http://csperkins.org/