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