idnits 2.17.1 draft-ietf-sipbrandy-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 (September 9, 2016) is 2786 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) == Missing Reference: 'TBD' is mentioned on line 314, but not defined == Unused Reference: 'RFC3264' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'RFC5124' is defined on line 484, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-04 == Outdated reference: A later version (-18) exists of draft-ietf-mmusic-trickle-ice-sip-05 == Outdated reference: A later version (-12) exists of draft-ietf-perc-double-01 == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-07 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-11 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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: March 13, 2017 R. Barnes 6 Mozilla 7 R. Housley 8 Vigilsec 9 September 9, 2016 11 Best Practices for Securing RTP Media Signaled with SIP 12 draft-ietf-sipbrandy-rtpsec-00.txt 14 Abstract 16 Although the Session Initiation 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 best practices for negotiating 23 confidential media with SIP, including both comprehensive protection 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 March 13, 2017. 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 Protection . . . . . . . . . . . . . . . . 3 65 3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4 66 4. STIR Profile for Endpoint Authentication and Verification 67 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 70 4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 6 71 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 7 72 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 7 73 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 8 74 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 8 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 12. Informative References . . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The Session Initiation Protocol (SIP) [RFC3261] includes a suite of 84 security services, ranging from Digest authentication for 85 authenticating entities with a shared secret, to TLS for transport 86 security, to S/MIME (optional) for body security. SIP is frequently 87 used to establish media sessions, in particular audio or audiovisual 88 sessions, which have their own security mechanisms available, such as 89 Secure RTP [RFC3711]. However, the practices needed to bind security 90 at the media layer to security at the SIP layer, to provide an 91 assurance that protection is in place all the way up the stack, rely 92 on a great many external security mechanisms and practices, and 93 require a central point of documentation to explain their optimal use 94 as a best practice. 96 Revelations about widespread pervasive monitoring of the Internet 97 have led to a reevaluation of the threat model for Internet 98 communications [RFC7258]. In order to maximize the use of security 99 features, especially of media confidentiality, opportunistic measures 100 must often serve as a stopgap when a full suite of services cannot be 101 negotiated all the way up the stack. This document explains the 102 limitations that may inhibit the use of comprehensive protection, and 103 provides recommendations for which external security mechanisms 104 implementers should use to negotiate secure media with SIP. It 105 moreover gives a gap analysis of the limitations of existing 106 solutions, and specifies solutions to address them. 108 Various specifications that user agents must implement to support 109 media confidentiality are given in the sections below; a summary of 110 the best current practices appears in Section 8. 112 2. Terminology 114 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 115 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 116 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 117 described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 119 3. Security at the SIP and SDP layer 121 There are two approaches to providing confidentiality for media 122 sessions set up with SIP: comprehensive protection and opportunistic 123 security (as defined in [RFC7435]). 125 3.1. Comprehensive Protection 127 Comprehensive protection for media sessions established by SIP 128 requires the interaction of three protocols: SIP, the Session 129 Description Protocol (SDP), and the Real-time Protocol, in particular 130 its secure profile SRTP. Broadly, it is the responsibility of SIP to 131 provide integrity for the media keying attributes conveyed by SDP, 132 and those attributes will in turn identify the keys used by endpoints 133 in the RTP media session that SDP negotiates. In that way, once SIP 134 and SDP have exchanged the necessary information to initiate a 135 session, the media endpoints will have a strong assurance that the 136 keys they exchange have not been tampered with by third parties, and 137 that end-to-end confidentiality is available. 139 Our current target mechanism for establishing the identity of the 140 endpoints of a SIP session is the use of STIR 141 [I-D.ietf-stir-rfc4474bis]. The STIR signature has been designed to 142 prevent a class of impersonation attacks that are commonly used in 143 robocalling, voicemail hacking, and related threats. STIR generates 144 a signature over certain features of SIP requests, including header 145 field values that contain an identity for the originator of the 146 request, such as the From header field or P-Asserted-Identity field, 147 and also over the media keys in SDP if they are present. As 148 currently defined, STIR only provides a signature over the 149 "a=fingerprint" attribute, which is a key fingerprint utilized by 150 DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive 151 protection for SIP sessions, in concert with SDP and SRTP, when DTLS- 152 SRTP is the media security service. The underlying security object 153 of STIR is extensible, however, and it would be possible to provide 154 signatures over other SDP attributes that contain alternate keying 155 material. A profile for using STIR to provide media confidentiality 156 is given in Section 4. 158 3.2. Opportunistic Security 160 Work is already underway on defining approaches to opportunistic 161 media security for SIP in [I-D.johnston-dispatch-osrtp], which builds 162 on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The 163 major protocol change proposed by that draft is to signal the use of 164 opportunistic encryption by negotiating the AVP profile in SDP, 165 rather than the SAVP profile (as specified in [RFC3711]) that would 166 ordinarily be used when negotiating SRTP. 168 Opportunistic encryption approaches typically have no integrity 169 protection for the keying material in SDP. Sending SIP over TLS hop- 170 by-hop between user agents and any intermediaries will reduce the 171 prospect that active attackers can alter keys for session requests on 172 the wire. However, opportunistic confidentiality for media will 173 prevent passive attacks of the form most common in the threat of 174 pervasive monitoring. 176 4. STIR Profile for Endpoint Authentication and Verification Services 178 A STIR [I-D.ietf-stir-rfc4474bis] verification service can act in 179 concert with an SRTP media endpoint to ensure that the key 180 fingerprints, as given in SDP, match the keys exchanged to establish 181 DTLS-SRTP. Typically, the verification service function would in 182 this case be implemented in the SIP UAS, which would be composed with 183 the media endpoint. If the STIR authentication service or 184 verification service functions are implemented at an intermediary 185 rather than an endpoint, this introduces the possibility that the 186 intermediary could act as a man-in-the-middle, altering key 187 fingerprints. As this attack is not in STIR's core threat model, 188 which focuses on impersonation rather than man-in-the-middle attacks, 189 STIR offers no specific protections against it. However, it would be 190 possible to build a deployment profile of STIR for media 191 confidentiality which shifts these responsibilities to the endpoints 192 rather than the intermediaries. 194 In order to be compliant with best practices for SIP media 195 confidentiality with comprehensive protection, user agent 196 implementations MUST implement both the authentication service and 197 verification service roles described in [I-D.ietf-stir-rfc4474bis]. 199 When generating either an offer or an answer, compliant 200 implementations MUST include an "a=fingerprint" attribute containing 201 the fingerprint of an appropriate key (see Section 4.1). 203 4.1. Credentials 205 In order to implement the authentication service function, SIP 206 endpoints must acquire the credentials needed to sign for their own 207 identity. That identity is typically carried in the From header 208 field of a SIP request, and either contains a greenfield SIP URI 209 (e.g. "sip:alice@example.com") or a telephone number, which can 210 appear in a variety of ways (e.g. "sip:+17004561212@example.com). 211 [I-D.ietf-stir-rfc4474bis] Section 7 contains guidance for separating 212 the two, and determining what sort of credential is needed to sign 213 for each. 215 To date, few commercial certificate authorities issue certificates 216 for SIP URIs or telephone numbers. This is one reason why the STIR 217 standard is architected to permit intermediaries to act as an 218 authentication service on behalf of an entire domain, just as in SIP 219 an proxy server can provide domain-level SIP service. While 220 certificate authorities that offered proof-of-possession certificates 221 similar to those used in the email world could be offered for SIP, 222 either for greenfield identifiers or for telephone numbers, this 223 specification does not require their use. 225 For users who do not possess such certificates, DTLS-SRTP [RFC5763] 226 permits the use of self-signed keys. This profile of STIR for media 227 confidentiality therefore relaxes the authority requirements of 228 [I-D.ietf-stir-rfc4474bis] to allow the use of self-signed keys for 229 authentication services that are composed with user agents, by 230 generating a certificate (per the guidance of 231 [I-D.ietf-stir-certificates]) with a subject corresponding to the 232 user's identity. Such a credential could be used for trust on first 233 use (see [RFC7435]) by relying parties. Note that relying parties 234 SHOULD NOT use certificate revocation mechanisms or real-time 235 certificate verification systems for self-signed certificates as they 236 will not increase confidence in the certificate. 238 Users who wish to remain anonymous can instead generate self-signed 239 certificates as described in Section 4.2. 241 4.2. Anonymous Communications 243 In some cases, the identity of the initiator of a SIP session may be 244 withheld due to user or provider policy. Per the recommendations of 245 [RFC3323], this may involve using an identity such as 246 "anonymous@anonymous.invalid" in the identity fields of a SIP 247 request. [I-D.ietf-stir-rfc4474bis] does not currently permit 248 authentication services to sign for requests that supply this 249 identity. It does however permit signing for valid domains, such as 250 "anonymous@example.com," as a way of implementation an anonymization 251 service as specified in [RFC3323]. 253 Even for anonymous sessions, providing media confidentiality and 254 partial SDP integrity is still desirable. This specification 255 RECOMMENDS using one-time self-signed certificates for anonymous 256 communications, with a subjectAltName of 257 "sip:anonymous@anonymous.invalid". After a session is terminated, 258 the certificate should be discarded, and a new one, with new keying 259 material, should be generated before each future anonymous call. As 260 with self-signed certificates, relying parties SHOULD NOT use 261 certificate revocation mechanisms or real-time certificate 262 verification systems for anonymous certificates as they will not 263 increase confidence in the certificate. 265 4.3. Connected Identity Usage 267 STIR [I-D.ietf-stir-rfc4474bis] provides integrity protection for the 268 SDP bodies of SIP requests, but not SIP responses. When a session is 269 established, therefore, any SDP body carried by a 200 class response 270 in the backwards direction will not be protected by an authentication 271 service and cannot be verified. Thus, sending a secured SDP body in 272 the backwards direction will require an extra RTT, typically a 273 request sent in the backwards direction. 275 The problem of providing "Connected Identity" for the original 276 RFC4474 was explored in [RFC4916], which uses a provisional or mid- 277 dialog UPDATE request in the backwards direction to convey an 278 Identity header for the recipient of an INVITE. The procedures in 279 that specification are largely compatible with the revision of the 280 Identity header in [I-D.ietf-stir-rfc4474bis]. However, the 281 following updates to [RFC4916] are required: 283 The UPDATE carrying signed SDP with a fingerprint in the backwards 284 direction MUST be sent during dialog establishment, following the 285 receipt of a PRACK after a provisional 1xx response. 287 For use with this STIR Profile for media confidentiality, the UAS 288 that responds to the INVITE request MUST act as an authentication 289 service for the UPDATE sent in the backwards direction. 291 The use of RFC4916 has some further interactions with ICE; see 292 Section 7. 294 5. Media Security Protocols 296 As there are several ways to negotiate media security with SDP, any 297 of which might be used with either opportunistic or comprehensive 298 protection, further guidance to implementers is needed. In 299 [I-D.johnston-dispatch-osrtp], opportunistic approaches considered 300 include DTLS-SRTP, security descriptions [RFC4568], and ZRTP 301 [RFC6189]. In order to prevent men-in-the-middle from decrypting 302 media traffic, the "a=crypto" SDP parameter of security descriptions 303 requires signaling confidentiality which STIR and related 304 comprehensive protection approaches cannot provide, so delivering 305 keys by value in SDP in this fashion is NOT RECOMMENDED. Both DTLS- 306 SRTP and ZRTP instead provide hashes which are carried in SDP, and 307 thus require only integrity protection rather than confidentiality. 309 Of DTLS-SRTP and ZRTP, only DTLS-SRTP is a Standards Track Internet 310 protocol. For that reason, this specification REQUIRES support for 311 DTLS-SRTP, and allows support for other media security protocols 312 OPTIONALLY. 314 [TBD] Future versions of this specification will explore the issue of 315 multiple fingerprints appearing in the message, and offers that 316 include both DTLS-SRTP and ZRTP security. 318 6. Relayed Media and Conferencing 320 Providing end-to-end media confidentiality for SIP is complicated by 321 the presence of many forms of media relays. While many media relays 322 merely proxy media to a destination, others present themselves as 323 media endpoints and terminate security associations before re- 324 originating media to its destination. 326 Centralized conference bridges are one type of entity that typically 327 terminates a media session in order to mux media from multiple 328 sources and then to re-originate the muxed media to conference 329 participants. In many such implementations, only hop-by-hop media 330 confidentiality is possible. Work is ongoing to specify a means to 331 encrypt both the hop-by-hop media between a user agent and a 332 centralized server as well as the end-to-end media between user 333 agents. As this is the best practice for supporting 334 [I-D.ietf-perc-double]. 336 Another class of entities that might relay SIP media are back-to-back 337 user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], 338 it may be possible for those devices to act as media relays while 339 still permitting end-to-end confidentiality between user agents. 341 Ultimately, if an endpoint can decrypt media it receives, then that 342 endpoint can forward the decrypted media without the knowledge or 343 consent of the media's originator. No media confidentiality 344 mechanism can protect against these sorts of relayed disclosures, or 345 trusted entities that can decrypt media and then record a copy to be 346 sent elsewhere (see [RFC7245]). 348 7. ICE and Connected Identity 350 Providing confidentiality for media with comprehensive protection 351 requires careful timing of when media streams should be sent and when 352 a user interface should signify that confidentiality is in place. 354 In order to best enable end-to-end connectivity between user agents, 355 and to avoid media relays as much as possible, implementations of 356 this specification must support ICE [I-D.ietf-ice-rfc5245bis]. To 357 speed up call establishment, it is RECOMMENDED that implementations 358 support trickle ICE [I-D.ietf-mmusic-trickle-ice-sip]. 360 Note that in the comprehensive protection case, the use of Connected 361 Identity [RFC4916] with ICE entails that the answer containing the 362 key fingerprints, and thus the STIR signature, will come in an UPDATE 363 sent in the backwards direction a provisional response and 364 acknowledgment (PRACK), rather than in any earlier SDP body. Only at 365 such a time as that UPDATE is received will the media keys be 366 considered exchanged in this case. 368 Similarly, in order to prevent, or at least mitigate, the denial-of- 369 service attack envisioned in [RFC5245] Section 18.5.1, this 370 specification incorporates best practices for ensuring that 371 recipients of media flows have consented to receive such flows. 372 Implementations of this specification MUST implement the STUN usage 373 for consent freshness defined in [RFC7675]. 375 8. Best Current Practices 377 The following are the best practices for SIP user agents to provide 378 media confidentiality for SIP sessions. 380 Implementations MUST support the STIR endpoint profile given in 381 Section 4. 383 Implementations MUST support DTLS-SRTP for key-management, as 384 described in Section 5. 386 Implementations MUST support the ICE, and the STUN consent freshness 387 mechanism, as specified in Section 7. 389 Implementations MUST support the PERC "double" mechanism, as 390 specifies in Section 6. 392 9. Acknowledgments 394 We would like to thank Adam Roach, Andrew Hutton, and Ben Campbell 395 for contributions to this problem statement and framework. 397 10. IANA Considerations 399 This memo includes no requests to the IANA. 401 11. Security Considerations 403 This document describes the security features that provide media 404 sessions established with SIP with confidentiality, integrity, and 405 authentication. 407 12. Informative References 409 [I-D.ietf-ice-rfc5245bis] 410 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 411 Connectivity Establishment (ICE): A Protocol for Network 412 Address Translator (NAT) Traversal", draft-ietf-ice- 413 rfc5245bis-04 (work in progress), June 2016. 415 [I-D.ietf-mmusic-trickle-ice-sip] 416 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 417 Session Initiation Protocol (SIP) usage for Trickle ICE", 418 draft-ietf-mmusic-trickle-ice-sip-05 (work in progress), 419 August 2016. 421 [I-D.ietf-perc-double] 422 Jennings, C., Jones, P., and A. Roach, "SRTP Double 423 Encryption Procedures", draft-ietf-perc-double-01 (work in 424 progress), July 2016. 426 [I-D.ietf-stir-certificates] 427 Peterson, J. and S. Turner, "Secure Telephone Identity 428 Credentials: Certificates", draft-ietf-stir- 429 certificates-07 (work in progress), July 2016. 431 [I-D.ietf-stir-rfc4474bis] 432 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 433 "Authenticated Identity Management in the Session 434 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-11 435 (work in progress), August 2016. 437 [I-D.johnston-dispatch-osrtp] 438 Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T. 439 Stach, "An Opportunistic Approach for Secure Real-time 440 Transport Protocol (OSRTP)", draft-johnston-dispatch- 441 osrtp-02 (work in progress), February 2016. 443 [I-D.kaplan-mmusic-best-effort-srtp] 444 Audet, F. and H. Kaplan, "Session Description Protocol 445 (SDP) Offer/Answer Negotiation For Best-Effort Secure 446 Real-Time Transport Protocol", draft-kaplan-mmusic-best- 447 effort-srtp-01 (work in progress), October 2006. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 455 A., Peterson, J., Sparks, R., Handley, M., and E. 456 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 457 DOI 10.17487/RFC3261, June 2002, 458 . 460 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 461 with Session Description Protocol (SDP)", RFC 3264, 462 DOI 10.17487/RFC3264, June 2002, 463 . 465 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 466 Initiation Protocol (SIP)", RFC 3323, 467 DOI 10.17487/RFC3323, November 2002, 468 . 470 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 471 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 472 RFC 3711, DOI 10.17487/RFC3711, March 2004, 473 . 475 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 476 Description Protocol (SDP) Security Descriptions for Media 477 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 478 . 480 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 481 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 482 2007, . 484 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 485 Real-time Transport Control Protocol (RTCP)-Based Feedback 486 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 487 2008, . 489 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 490 (ICE): A Protocol for Network Address Translator (NAT) 491 Traversal for Offer/Answer Protocols", RFC 5245, 492 DOI 10.17487/RFC5245, April 2010, 493 . 495 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 496 for Establishing a Secure Real-time Transport Protocol 497 (SRTP) Security Context Using Datagram Transport Layer 498 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 499 2010, . 501 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 502 Media Path Key Agreement for Unicast Secure RTP", 503 RFC 6189, DOI 10.17487/RFC6189, April 2011, 504 . 506 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 507 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 508 DOI 10.17487/RFC6919, April 2013, 509 . 511 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 512 "An Architecture for Media Recording Using the Session 513 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 514 2014, . 516 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 517 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 518 2014, . 520 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 521 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 522 December 2014, . 524 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 525 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 526 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 527 October 2015, . 529 [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., 530 and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back 531 User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, 532 . 534 Authors' Addresses 536 Jon Peterson 537 Neustar, Inc. 538 1800 Sutter St Suite 570 539 Concord, CA 94520 540 US 542 Email: jon.peterson@neustar.biz 544 Eric Rescorla 545 Mozilla 547 Email: ekr@rtfm.com 549 Richard Barnes 550 Mozilla 552 Email: rlb@ipv.sx 554 Russ Housley 555 Vigilsec 557 Email: housley@vigilsec.com