idnits 2.17.1 draft-peterson-dispatch-rtpsec-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 21, 2016) is 2952 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3264' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC5124' is defined on line 297, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Best Current Practice E. Rescorla 5 Expires: September 22, 2016 R. Barnes 6 Mozilla 7 R. Housley 8 Vigilsec 9 March 21, 2016 11 Best Practices for Securing RTP Media Signaled with SIP 12 draft-peterson-dispatch-rtpsec-00.txt 14 Abstract 16 Although the Session Initital Protocol (SIP) includes a suite of 17 security services that has been expanded by numerous specifications 18 over the years, there is no single place that explains how to use SIP 19 to establish confidential media sessions. Additionally, existing 20 mechanisms have some feature gaps that need to be identified and 21 resolved in order for them to address the pervasive monitoring threat 22 model. This specification describes practices for negotiating 23 confidential media with SIP, including both comprehensive security 24 solutions which bind the media to SIP-layer identities as well as 25 opportunistic security solutions. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 22, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 64 3.1. Comprehensive Security . . . . . . . . . . . . . . . . . 3 65 3.1.1. Anonymous Communications . . . . . . . . . . . . . . 4 66 3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 5 67 4. Media Security . . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 8. Informative References . . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The Session Initiation Protocol (SIP) [RFC3261] includes a suite of 77 security services, ranging from Digest authentication for 78 authenticating entities with a shared secret, to TLS for transport 79 security, to S/MIME (optional) for body security. SIP is frequently 80 used to establish media sessions, in particular audio or audiovisual 81 sessions, which have their own security mechanisms available, such as 82 Secure RTP [RFC3711]. However, the practices needed to bind security 83 at the media layer to security at the SIP layer, to provide an 84 assurance that protection is in place all the way up the stack, rely 85 on a great many external security mechanisms and practices, and 86 require a central point of documentation to explain their optimal use 87 as a best practice. 89 Revelations about widespread pervasive monitoring of the Internet 90 have led to a reevaluation of the threat model for Internet 91 communications [RFC7258]. In order to maximize the use of security 92 features, especially of media confidentiality, opportunistic measures 93 must often serve as a stopgap when a full suite of services cannot be 94 negotiated all the way up the stack. This document explains the 95 limitations that may inhibit the use of comprehensive security, and 96 provides recommendations for which external security mechanisms 97 implementers should use to negotiate secure media with SIP. It 98 moreover gives a gap analysis of the limitations of existing 99 solutions, and specifies solutions to address them. 101 2. Terminology 103 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 104 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 105 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 106 described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 108 3. Security at the SIP and SDP layer 110 There are two approaches to providing confidentiality for media 111 sessions set up with SIP: comprehensive security and opportunistic 112 security. 114 3.1. Comprehensive Security 116 Comprehensive security for media sessions established by SIP requires 117 the interaction of three protocols: SIP, the Session Description 118 Protocol (SDP), and the Real-time Protocol, in particular its secure 119 profile SRTP. Broadly, it is the responsibility of SIP to provide 120 integrity for the media keying attributes conveyed by SDP, and those 121 attributes will in turn identify the keys used by endpoints in the 122 RTP media session that SDP negotiates. In that way, once SIP and SDP 123 have exchanged the necessary information to initiate a session, the 124 media endpoints will have a strong assurance that the keys they 125 exchange have not been tampered with by third parties, and that end- 126 to-end confidentiality is available. 128 Our current target mechanism for establishing the identity of the 129 endpoints of a SIP session is the use of STIR 130 [I-D.ietf-stir-rfc4474bis]. The STIR signature has been designed to 131 prevent a class of impersonation attacks that are commonly used in 132 robocalling, voicemail hacking, and related threats. STIR generates 133 a signature over certain features of SIP requests, including header 134 field values that contain an identity for the originator of the 135 request, such as the From header field or P-Asserted-Identity field, 136 and also over the media keys in SDP if they are present. As 137 currently defined, STIR only provides a signature over the 138 "a=fingerprint" attribute, which is a key fingerprint utilized by 139 DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive 140 security for SIP sessions, in concert with SDP and SRTP, when DTLS- 141 SRTP is the media security service. The underlying security object 142 of STIR is extensible, however, and it would be possible to provide 143 signatures over other SDP attributes that contain alternate keying 144 material. 146 A STIR verification service can act in concept with an SRTP media 147 endpoint to ensure that the key fingerprints, as given in SDP, match 148 the keys exchanged to establish DTLS-SRTP. Typically, the 149 verification service function would in this case be implemented in 150 the SIP UAS, which would be composed with the media endpoint. If the 151 STIR authentication service or verification service functions are 152 implemented at an intermediary rather than an endpoint, this 153 introduces the possibility that the intermediary could act as a man- 154 in-the-middle, altering key fingerprints. As this attack is not in 155 STIR's core threat model, which focuses on impersonation rather than 156 man-in-the-middle attacks, STIR offers no specific protections 157 against it. However, it would be possible to build a deployment 158 profile of STIR for media confidentiality which shifts these 159 responsibilities to the endpoints rather than the intermediaries. 161 Note that STIR provides integrity protection for the SDP bodies of 162 SIP requests, but not SIP responses. When a session is established, 163 therefore, any SDP body carried by a 200 class response in the 164 backwards direction will not be protected by an authentication 165 service and cannot be verified. Thus, sending a secured SDP body in 166 the backwards direction will require an extra RTT, typically a re- 167 INVITE in the backwards direction. Again, this could be specified as 168 a component of a secure media profile for STIR. 170 Future versions of this specification will show in detail how those 171 gaps can be filled. 173 3.1.1. Anonymous Communications 175 In some cases, the identity of the initiator of a SIP session may be 176 withheld due to user or provider policy. Per the recommendations of 177 [RFC3323], this may involve using an identity such as 178 "anonymous@anonymous.invalid" in the identity fields of a SIP 179 request. [I-D.ietf-stir-rfc4474bis] does not currently permit 180 authentication services to sign for requests that supply this 181 identity. It does however permit signing for valid domains, such as 182 "anonymous@example.com," as a way of implementation an anonymization 183 service as specified in [RFC3323]. 185 Even for anonymous sessions, providing media confidentiality and 186 partial SDP integrity is still desirable. Barring the use of an 187 anonymization service, this can only be accomplished with 188 opportunistic security; the value of trying to provide an 189 intermediate level between comprehensive and opportunistic security 190 for this use case is a matter for futher discussion and study. 192 3.2. Opportunistic Security 194 Work is already underway on defining approaches to opportunistic 195 media security for SIP in [I-D.johnston-dispatch-osrtp], which builds 196 on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The 197 major protocol change proposed by that draft is to signal the use of 198 opportunistic encryption by negotiating the AVP profile in SDP, 199 rather than the SAVP profile (as specified in [RFC3711]) that would 200 ordinarily be used when negotiating SRTP. 202 Opportunistic encryption approaches typically have no integrity 203 protection for the keying material in SDP. Sending SIP over TLS hop- 204 by-hop between user agents and any intermediaries will reduce the 205 prospect that active attackers can alter keys for session requests on 206 the wire. 208 4. Media Security 210 As there are several ways to negotiate media security with SDP, any 211 of which might be used with either opportunistic or comprehensive 212 security, further guidance to implementers is needed. In 213 [I-D.johnston-dispatch-osrtp], opportunistic approaches considered 214 include DTLS-SRTP, security descriptions [RFC4568], and ZRTP 215 [RFC6189]. In order to prevent men-in-the-middle from decrypting 216 media traffic, the "a=crypto" SDP parameter of security descriptions 217 requires signaling confidentiality which STIR and related 218 comprehensive security approaches cannot provide, so delivering keys 219 by value in SDP in this fashion is NOT RECOMMENDED. Both DTLS-SRTP 220 and ZRTP instead provide hashes which are carried in SDP, and thus 221 require only integrity protection rather than confidentiality. 223 Of DTLS-SRTP and ZRTP, only DTLS-SRTP is a Standards Track Internet 224 protocol. Future versions of this specification will give specific 225 recommendations on support for media security protocols. 227 Future versions of this specification will explore the issue of 228 multiple fingerprints appearing in the message, and offers that 229 include both DTLS-SRTP and ZRTP security. 231 5. Acknowledgments 233 We would like to thank YOU for contributions to this problem 234 statement and framework. 236 6. IANA Considerations 238 This memo includes no requests to the IANA. 240 7. Security Considerations 242 This document describes the security features that provide media 243 sessions established with SIP with confidentiality, integrity, and 244 authentication. 246 8. Informative References 248 [I-D.ietf-stir-rfc4474bis] 249 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 250 "Authenticated Identity Management in the Session 251 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-07 252 (work in progress), February 2016. 254 [I-D.johnston-dispatch-osrtp] 255 Johnston, A., Aboba, B., Hutton, A., Liess, L., and T. 256 Thomas, "An Opportunistic Approach for Secure Real-time 257 Transport Protocol (OSRTP)", draft-johnston-dispatch- 258 osrtp-02 (work in progress), February 2016. 260 [I-D.kaplan-mmusic-best-effort-srtp] 261 Audet, F. and H. Kaplan, "Session Description Protocol 262 (SDP) Offer/Answer Negotiation For Best-Effort Secure 263 Real-Time Transport Protocol", draft-kaplan-mmusic-best- 264 effort-srtp-01 (work in progress), October 2006. 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, 268 DOI 10.17487/RFC2119, March 1997, 269 . 271 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 272 A., Peterson, J., Sparks, R., Handley, M., and E. 273 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 274 DOI 10.17487/RFC3261, June 2002, 275 . 277 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 278 with Session Description Protocol (SDP)", RFC 3264, 279 DOI 10.17487/RFC3264, June 2002, 280 . 282 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 283 Initiation Protocol (SIP)", RFC 3323, 284 DOI 10.17487/RFC3323, November 2002, 285 . 287 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 288 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 289 RFC 3711, DOI 10.17487/RFC3711, March 2004, 290 . 292 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 293 Description Protocol (SDP) Security Descriptions for Media 294 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 295 . 297 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 298 Real-time Transport Control Protocol (RTCP)-Based Feedback 299 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 300 2008, . 302 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 303 for Establishing a Secure Real-time Transport Protocol 304 (SRTP) Security Context Using Datagram Transport Layer 305 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 306 2010, . 308 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 309 Media Path Key Agreement for Unicast Secure RTP", 310 RFC 6189, DOI 10.17487/RFC6189, April 2011, 311 . 313 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 314 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 315 DOI 10.17487/RFC6919, April 2013, 316 . 318 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 319 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 320 2014, . 322 Authors' Addresses 323 Jon Peterson 324 Neustar, Inc. 325 1800 Sutter St Suite 570 326 Concord, CA 94520 327 US 329 Email: jon.peterson@neustar.biz 331 Eric Rescorla 332 Mozilla 334 Email: ekr@rtfm.com 336 Richard Barnes 337 Mozilla 339 Email: rbarnes@mozilla.com 341 Russ Housley 342 Vigilsec 344 Email: rhousley@vigilsec.com