idnits 2.17.00 (12 Aug 2021) /tmp/idnits13853/draft-ietf-sipbrandy-rtpsec-05.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 12, 2018) is 1317 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 486, but not defined == Unused Reference: 'RFC3264' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC5124' is defined on line 542, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Downref: Normative reference to an Informational RFC: RFC 6189 ** Downref: Normative reference to an Experimental RFC: RFC 6919 ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) ** Downref: Normative reference to an Informational RFC: RFC 7245 ** Downref: Normative reference to an Informational RFC: RFC 7435 == Outdated reference: draft-ietf-ice-rfc5245bis has been published as RFC 8445 == Outdated reference: draft-ietf-mmusic-trickle-ice-sip has been published as RFC 8840 Summary: 7 errors (**), 0 flaws (~~), 7 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 R. Barnes 5 Expires: April 15, 2019 Mozilla 6 R. Housley 7 Vigil Security 8 October 12, 2018 10 Best Practices for Securing RTP Media Signaled with SIP 11 draft-ietf-sipbrandy-rtpsec-05 13 Abstract 15 Although the Session Initiation Protocol (SIP) includes a suite of 16 security services that has been expanded by numerous specifications 17 over the years, there is no single place that explains how to use SIP 18 to establish confidential media sessions. Additionally, existing 19 mechanisms have some feature gaps that need to be identified and 20 resolved in order for them to address the pervasive monitoring threat 21 model. This specification describes best practices for negotiating 22 confidential media with SIP, including both comprehensive protection 23 solutions which bind the media to SIP-layer identities as well as 24 opportunistic security solutions. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 15, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 63 3.1. Comprehensive Protection . . . . . . . . . . . . . . . . 3 64 3.2. Opportunistic Security . . . . . . . . . . . . . . . . . 4 65 4. STIR Profile for Endpoint Authentication and Verification 66 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 69 4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7 70 4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8 71 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 9 72 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9 73 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 10 74 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 12.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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) [RFC4566], and the Real-time Protocol 132 (RTP) [RFC3550], in particular its secure profile Secure RTP (SRTP) 133 [RFC3711]. Broadly, it is the responsibility of SIP to provide 134 integrity protection for the media keying attributes conveyed by SDP, 135 and those attributes will in turn identify the keys used by endpoints 136 in the RTP media session(s) that SDP negotiates. Note that this 137 framework does not apply to keys that also require confidentiality 138 protection in the signaling layer, such as the SDP "k=" line, which 139 MUST NOT be used in conjunction with this profile. In that way, once 140 SIP and SDP have exchanged the necessary information to initiate a 141 session, media endpoints will have a strong assurance that the keys 142 they exchange have not been tampered with by third parties, and that 143 end-to-end confidentiality is available. 145 To establishing the identity of the endpoints of a SIP session, this 146 specification uses STIR [RFC8224]. The STIR Identity header has been 147 designed to prevent a class of impersonation attacks that are 148 commonly used in robocalling, voicemail hacking, and related threats. 149 STIR generates a signature over certain features of SIP requests, 150 including header field values that contain an identity for the 151 originator of the request, such as the From header field or P- 152 Asserted-Identity field, and also over the media keys in SDP if they 153 are present. As currently defined, STIR only provides a signature 154 over the "a=fingerprint" attribute, which is a key fingerprint 155 utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers 156 comprehensive protection for SIP sessions, in concert with SDP and 157 SRTP, when DTLS-SRTP is the media security service. The underlying 158 PASSporT [RFC8225] object used by STIR is extensible, however, and it 159 would be possible to provide signatures over other SDP attributes 160 that contain alternate keying material. A profile for using STIR to 161 provide media confidentiality is given in Section 4. 163 3.2. Opportunistic Security 165 Work is already underway on defining approaches to opportunistic 166 media security for SIP in [I-D.johnston-dispatch-osrtp], which builds 167 on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The 168 major protocol change proposed by that specification is to signal the 169 use of opportunistic encryption by negotiating the AVP profile in 170 SDP, rather than the SAVP profile (as specified in [RFC3711]) that 171 would ordinarily be used when negotiating SRTP. 173 Opportunistic encryption approaches typically have no integrity 174 protection for the keying material in SDP. Sending SIP over TLS hop- 175 by-hop between user agents and any intermediaries will reduce the 176 prospect that active attackers can alter keys for session requests on 177 the wire. However, opportunistic confidentiality for media will 178 prevent passive attacks of the form most common in the threat of 179 pervasive monitoring. 181 4. STIR Profile for Endpoint Authentication and Verification Services 183 STIR [RFC8224] defines the Identity header field for SIP, which 184 provides a cryptographic attestation of the source of communications. 185 This profile of STIR assumes that a STIR verification service will 186 act in concert with an SRTP media endpoint to ensure that the key 187 fingerprints, as given in SDP, match the keys exchanged to establish 188 DTLS-SRTP. To satisfy this condition, the verification service 189 function would in this case be implemented in the SIP UAS, which 190 would be composed with the media endpoint. If the STIR 191 authentication service or verification service functions are 192 implemented at an intermediary rather than an endpoint, this 193 introduces the possibility that the intermediary could act as a man 194 in the middle, altering key fingerprints. As this attack is not in 195 STIR's core threat model, which focuses on impersonation rather than 196 man-in-the-middle attacks, STIR offers no specific protections 197 against such interference. 199 The SIPBRANDY deployment profile of STIR for media confidentiality 200 thus shifts these responsibilities to the endpoints rather than the 201 intermediaries. While intermediaries MAY provide the verification 202 service function of STIR for SIPBRANDY transactions, intermediaries 203 supporting this specification MUST NOT block or otherwise redirects 204 calls if they do not trust the signing credential. The SIPBRANDY 205 profile is based on an end-to-end trust model, so it is up to the 206 endpoints to determine if they support signing credentials, not 207 intermediaries. 209 In order to be compliant with best practices for SIP media 210 confidentiality with comprehensive protection, user agent 211 implementations MUST implement both the authentication service and 212 verification service roles described in [RFC8224]. STIR 213 authentication services MUST signal their compliance with this 214 specification by adding the "msec" header element defined in this 215 specification to the PASSporT header. Implementations MUST provide 216 key fingerprints in SDP and the appropriate signatures over them per 217 [RFC8225]. 219 When generating either an offer or an answer, compliant 220 implementations MUST include an "a=fingerprint" attribute containing 221 the fingerprint of an appropriate key (see Section 4.1). 223 4.1. Credentials 225 In order to implement the authentication service function in the user 226 agent, SIP endpoints will need to acquire the credentials needed to 227 sign for their own identity. That identity is typically carried in 228 the From header field of a SIP request, and either contains a 229 greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone 230 number, which can appear in a variety of ways (e.g. 231 "sip:+17004561212@example.com;user=phone"). [RFC8224] Section 8 232 contains guidance for separating the two, and determining what sort 233 of credential is needed to sign for each. 235 To date, few commercial certificate authorities issue certificates 236 for SIP URIs or telephone numbers; though work is ongoing on systems 237 for this purpose (such as [I-D.ietf-acme-telephone]) it is not mature 238 enough to be recommended as a best practice. This is one reason why 239 the STIR standard is architected to permit intermediaries to act as 240 an authentication service on behalf of an entire domain, just as in 241 SIP an proxy server can provide domain-level SIP service. While 242 certificate authorities that offered proof-of-possession certificates 243 similar to those used in the email world could be offered for SIP, 244 either for greenfield identifiers or for telephone numbers, this 245 specification does not require their use. 247 For users who do not possess such certificates, DTLS-SRTP [RFC5763] 248 permits the use of self-signed keys. This profile of STIR therefore 249 relaxes the authority requirements of [RFC8224] to allow the use of 250 self-signed keys for authentication services that are composed with 251 user agents, by generating a certificate (per the guidance of 252 [RFC8226]) with a subject corresponding to the user's identity. Such 253 a credential could be used for trust on first use (see [RFC7435]) by 254 relying parties. Note that relying parties SHOULD NOT use 255 certificate revocation mechanisms or real-time certificate 256 verification systems for self-signed certificates as they will not 257 increase confidence in the certificate. 259 Users who wish to remain anonymous can instead generate self-signed 260 certificates as described in Section 4.2. 262 Generally speaking, without access to out-of-band information about 263 which certificates were issued to whom, it will be very difficult for 264 relying parties to ascertain whether or not the signer of a SIP 265 request is genuinely an "endpoint." Even the term "endpoint" is a 266 problematic one, as SIP user agents can be composed in a variety of 267 architectures and may not be devices under direct user control. 268 While it is possible that techniques based on certificate 269 transparency [RFC6962] or similar practices could help user agents to 270 recognize one another's certificates, those operational systems will 271 need to ramp up with the certificate authorities that issue 272 credentials to end user devices going forward. 274 4.2. Anonymous Communications 276 In some cases, the identity of the initiator of a SIP session may be 277 withheld due to user or provider policy. Per the recommendations of 278 [RFC3323], this may involve using an identity such as 279 "anonymous@anonymous.invalid" in the identity fields of a SIP 280 request. [RFC8224] does not currently permit authentication services 281 to sign for requests that supply this identity. It does however 282 permit signing for valid domains, such as "anonymous@example.com," as 283 a way of implementation an anonymization service as specified in 284 [RFC3323]. 286 Even for anonymous sessions, providing media confidentiality and 287 partial SDP integrity is still desirable. This specification 288 RECOMMENDS using one-time self-signed certificates for anonymous 289 communications, with a subjectAltName of 290 "sip:anonymous@anonymous.invalid". After a session is terminated, 291 the certificate SHOULD be discarded, and a new one, with new keying 292 material, SHOULD be generated before each future anonymous call. As 293 with self-signed certificates, relying parties SHOULD NOT use 294 certificate revocation mechanisms or real-time certificate 295 verification systems for anonymous certificates as they will not 296 increase confidence in the certificate. 298 Note that when using one-time anonymous self-signed certificates, any 299 man in the middle could strip the Identity header and replace it with 300 one signed by its own one-time certificate, changing the "mkey" 301 parameters of PASSporT and any "a=fingerprint" attributes in SDP as 302 it chooses. This signature only provides protection against non- 303 Identity aware entities that might modify SDP without altering the 304 PASSporT conveyed in the Identity header. 306 4.3. Connected Identity Usage 308 STIR [RFC8224] provides integrity protection for the SDP bodies of 309 SIP requests, but not SIP responses. When a session is established, 310 therefore, any SDP body carried by a 200 class response in the 311 backwards direction will not be protected by an authentication 312 service and cannot be verified. Thus, sending a secured SDP body in 313 the backwards direction will require an extra RTT, typically a 314 request sent in the backwards direction. 316 The problem of providing "Connected Identity" for the original 317 RFC4474 was explored in [RFC4916], which uses a provisional or mid- 318 dialog UPDATE request in the backwards direction to convey an 319 Identity header for the recipient of an INVITE. The procedures in 320 that specification are largely compatible with the revision of the 321 Identity header in [RFC8224]. However, the following updates to 322 [RFC4916] are required: 324 The UPDATE carrying signed SDP with a fingerprint in the backwards 325 direction MUST be sent during dialog establishment, following the 326 receipt of a PRACK after a provisional 1xx response. 328 For use with this STIR Profile for media confidentiality, the UAS 329 that responds to the INVITE request MUST act as an authentication 330 service for the UPDATE sent in the backwards direction. 332 The text in RFC4916 Section 4.4.1 regarding the receipt at a UAC 333 of error codes 428, 436, 437 and 438 in response to a mid-dialog 334 request RECOMMENDS treating the dialog as terminated. [RFC8224] 335 allows the retransmission of requests with repairable error 336 conditions (see section 6.1.1) in a way that can override that 337 SHOULD in RFC4916. In particular, an authentication service MAY 338 retry a mid-dialog as [RFC8224] allows rather than treating the 339 dialog as terminated, though note that only one such retry is 340 permitted. 342 The examples in RFC4916 are based on the original RFC4474, and 343 will not match signatures using [RFC8224]. 345 Future work may be done to revise RFC4916 for STIR; that work should 346 take into account any impacts on the profile described in this 347 document. The use of RFC4916 has some further interactions with ICE; 348 see Section 7. 350 4.4. Authorization Decisions 352 [RFC8224] grants STIR verification services a great deal of latitude 353 when making authorization decisions based on the presence of the 354 Identity header field. It is largely a matter of local policy 355 whether an endpoint rejects a call based on absence of an Identity 356 header field, or even the presence of a header that fails an 357 integrity check against the request. 359 For this profile, however, a compliant verification service that 360 receives a dialog-forming SIP request containing an Identity header 361 with a PASSporT type of "msec", after validating the request per the 362 steps described in [RFC8224] Section 6.2, MUST reject the request if 363 there is any failure in that validation process with the appropriate 364 status code per Section 6.2.2. If the request is valid, then if a 365 terminating user accepts the request, it MUST then follow the steps 366 in Section 4.3 to act as an authentication service and send a signed 367 request with the "msec" PASSPorT type in its Identity header as well, 368 in order to enable end-to-end bidirectional confidentiality. 370 For the purposes of this profile, the "msec" PASSporT type can be 371 used by authentication services in one of two ways: as a mandatory 372 request for media security, or as a merely opportunistic request for 373 media security. As any verification service that receives an 374 Identity header in a SIP request with an unrecognized PASSporT type 375 will simply ignore that Identity header, an authentication service 376 will know whether or not the terminating side supports "msec" based 377 on whether or not its user agent receives a signed request in the 378 backwards direction per Section 4.3. If no such requests are 379 received, the UA may do one or two things: shut down the dialog, if 380 the policy of the UA requires that "msec" be supported by the 381 terminating side for this dialog; or, if policy permits, allow the 382 dialog to continue without media security. 384 5. Media Security Protocols 386 As there are several ways to negotiate media security with SDP, any 387 of which might be used with either opportunistic or comprehensive 388 protection, further guidance to implementers is needed. In 389 [I-D.johnston-dispatch-osrtp], opportunistic approaches considered 390 include DTLS-SRTP, security descriptions [RFC4568], and ZRTP 391 [RFC6189]. 393 Support for DTLS-SRTP is REQUIRED by this specification. 395 The "mkey" claim of PASSporT provides integrity protection for 396 "a=fingerprint" attributes in SDP, including cases where multiple 397 "a=fingerprint" attributes appear in the same SDP. 399 6. Relayed Media and Conferencing 401 Providing end-to-end media confidentiality for SIP is complicated by 402 the presence of many forms of media relays. While many media relays 403 merely proxy media to a destination, others present themselves as 404 media endpoints and terminate security associations before re- 405 originating media to its destination. 407 Centralized conference bridges are one type of entity that typically 408 terminates a media session in order to mux media from multiple 409 sources and then to re-originate the muxed media to conference 410 participants. In many such implementations, only hop-by-hop media 411 confidentiality is possible. Work is ongoing to specify a means to 412 encrypt both the hop-by-hop media between a user agent and a 413 centralized server as well as the end-to-end media between user 414 agents, but is not sufficiently mature at this time to make a 415 recommendation for a best practice here. Those protocols are 416 expected to identify their own best practice recommendations as they 417 mature. 419 Another class of entities that might relay SIP media are back-to-back 420 user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], 421 it may be possible for those devices to act as media relays while 422 still permitting end-to-end confidentiality between user agents. 424 Ultimately, if an endpoint can decrypt media it receives, then that 425 endpoint can forward the decrypted media without the knowledge or 426 consent of the media's originator. No media confidentiality 427 mechanism can protect against these sorts of relayed disclosures, or 428 trusted entities that can decrypt media and then record a copy to be 429 sent elsewhere (see [RFC7245]). 431 7. ICE and Connected Identity 433 Providing confidentiality for media with comprehensive protection 434 requires careful timing of when media streams should be sent and when 435 a user interface should signify that confidentiality is in place. 437 In order to best enable end-to-end connectivity between user agents, 438 and to avoid media relays as much as possible, implementations of 439 this specification must support ICE [I-D.ietf-ice-rfc5245bis]. To 440 speed up call establishment, it is RECOMMENDED that implementations 441 support trickle ICE [I-D.ietf-mmusic-trickle-ice-sip]. 443 Note that in the comprehensive protection case, the use of Connected 444 Identity [RFC4916] with ICE entails that the answer containing the 445 key fingerprints, and thus the STIR signature, will come in an UPDATE 446 sent in the backwards direction a provisional response and 447 acknowledgment (PRACK), rather than in any earlier SDP body. Only at 448 such a time as that UPDATE is received will the media keys be 449 considered exchanged in this case. 451 Similarly, in order to prevent, or at least mitigate, the denial-of- 452 service attack envisioned in [RFC5245] Section 18.5.1, this 453 specification incorporates best practices for ensuring that 454 recipients of media flows have consented to receive such flows. 455 Implementations of this specification MUST implement the STUN usage 456 for consent freshness defined in [RFC7675]. 458 8. Best Current Practices 460 The following are the best practices for SIP user agents to provide 461 media confidentiality for SIP sessions. 463 Implementations MUST support the STIR endpoint profile given in 464 Section 4, and signal that in PASSporT with the "msec" header 465 element. 467 Implementations MUST follow the authorization decision behavior in 468 Section 4.4. 470 Implementations MUST support DTLS-SRTP for key-management, as 471 described in Section 5. 473 Implementations MUST support the ICE, and the STUN consent freshness 474 mechanism, as specified in Section 7. 476 9. Acknowledgments 478 We would like to thank Eric Rescorla, Adam Roach, Andrew Hutton, and 479 Ben Campbell for contributions to this problem statement and 480 framework. 482 10. IANA Considerations 484 This specification defines a new values for the PASSporT Type 485 registry called "msec," and the IANA is requested to add that to the 486 registry with a value pointing to [RFCThis]. 488 11. Security Considerations 490 This document describes the security features that provide media 491 sessions established with SIP with confidentiality, integrity, and 492 authentication. 494 12. References 496 12.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 504 A., Peterson, J., Sparks, R., Handley, M., and E. 505 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 506 DOI 10.17487/RFC3261, June 2002, 507 . 509 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 510 with Session Description Protocol (SDP)", RFC 3264, 511 DOI 10.17487/RFC3264, June 2002, 512 . 514 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 515 Initiation Protocol (SIP)", RFC 3323, 516 DOI 10.17487/RFC3323, November 2002, 517 . 519 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 520 Jacobson, "RTP: A Transport Protocol for Real-Time 521 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 522 July 2003, . 524 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 525 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 526 RFC 3711, DOI 10.17487/RFC3711, March 2004, 527 . 529 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 530 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 531 July 2006, . 533 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 534 Description Protocol (SDP) Security Descriptions for Media 535 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 536 . 538 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 539 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 540 2007, . 542 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 543 Real-time Transport Control Protocol (RTCP)-Based Feedback 544 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 545 2008, . 547 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 548 (ICE): A Protocol for Network Address Translator (NAT) 549 Traversal for Offer/Answer Protocols", RFC 5245, 550 DOI 10.17487/RFC5245, April 2010, 551 . 553 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 554 for Establishing a Secure Real-time Transport Protocol 555 (SRTP) Security Context Using Datagram Transport Layer 556 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 557 2010, . 559 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 560 Media Path Key Agreement for Unicast Secure RTP", 561 RFC 6189, DOI 10.17487/RFC6189, April 2011, 562 . 564 [RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words 565 for Use in RFCs to Indicate Requirement Levels", RFC 6919, 566 DOI 10.17487/RFC6919, April 2013, 567 . 569 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 570 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 571 . 573 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 574 "An Architecture for Media Recording Using the Session 575 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 576 2014, . 578 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 579 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 580 2014, . 582 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 583 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 584 December 2014, . 586 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 587 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 588 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 589 October 2015, . 591 [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., 592 and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back 593 User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, 594 . 596 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 597 "Authenticated Identity Management in the Session 598 Initiation Protocol (SIP)", RFC 8224, 599 DOI 10.17487/RFC8224, February 2018, 600 . 602 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 603 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 604 . 606 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 607 Credentials: Certificates", RFC 8226, 608 DOI 10.17487/RFC8226, February 2018, 609 . 611 12.2. Informative References 613 [I-D.ietf-acme-telephone] 614 Peterson, J. and R. Barnes, "ACME Identifiers and 615 Challenges for Telephone Numbers", draft-ietf-acme- 616 telephone-01 (work in progress), October 2017. 618 [I-D.ietf-ice-rfc5245bis] 619 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 620 Connectivity Establishment (ICE): A Protocol for Network 621 Address Translator (NAT) Traversal", draft-ietf-ice- 622 rfc5245bis-20 (work in progress), March 2018. 624 [I-D.ietf-mmusic-trickle-ice-sip] 625 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 626 Session Initiation Protocol (SIP) Usage for Incremental 627 Provisioning of Candidates for the Interactive 628 Connectivity Establishment (Trickle ICE)", draft-ietf- 629 mmusic-trickle-ice-sip-18 (work in progress), June 2018. 631 [I-D.johnston-dispatch-osrtp] 632 Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T. 633 Stach, "An Opportunistic Approach for Secure Real-time 634 Transport Protocol (OSRTP)", draft-johnston-dispatch- 635 osrtp-02 (work in progress), February 2016. 637 [I-D.kaplan-mmusic-best-effort-srtp] 638 Audet, F. and H. Kaplan, "Session Description Protocol 639 (SDP) Offer/Answer Negotiation For Best-Effort Secure 640 Real-Time Transport Protocol", draft-kaplan-mmusic-best- 641 effort-srtp-01 (work in progress), October 2006. 643 Authors' Addresses 645 Jon Peterson 646 Neustar, Inc. 648 Email: jon.peterson@team.neustar 650 Richard Barnes 651 Mozilla 653 Email: rlb@ipv.sx 655 Russ Housley 656 Vigil Security, LLC 658 Email: housley@vigilsec.com