idnits 2.17.00 (12 Aug 2021) /tmp/idnits15380/draft-ietf-sipbrandy-rtpsec-07.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4916, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4916, updated by this document, for RFC5378 checks: 2006-04-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 01, 2019) is 1205 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 491, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: draft-ietf-mmusic-trickle-ice-sip has been published as RFC 8840 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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 Updates: 4916 (if approved) R. Barnes 5 Intended status: Best Current Practice Cisco 6 Expires: August 5, 2019 R. Housley 7 Vigil Security 8 February 01, 2019 10 Best Practices for Securing RTP Media Signaled with SIP 11 draft-ietf-sipbrandy-rtpsec-07 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 August 5, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. Security at the SIP and SDP layer 124 There are two approaches to providing confidentiality for media 125 sessions set up with SIP: comprehensive protection and opportunistic 126 security (as defined in [RFC7435]). 128 3.1. Comprehensive Protection 130 Comprehensive protection for media sessions established by SIP 131 requires the interaction of three protocols: SIP, the Session 132 Description Protocol (SDP) [RFC4566], and the Real-time Protocol 133 (RTP) [RFC3550], in particular its secure profile Secure RTP (SRTP) 134 [RFC3711]. Broadly, it is the responsibility of SIP to provide 135 integrity protection for the media keying attributes conveyed by SDP, 136 and those attributes will in turn identify the keys used by endpoints 137 in the RTP media session(s) that SDP negotiates. Note that this 138 framework does not apply to keys that also require confidentiality 139 protection in the signaling layer, such as the SDP "k=" line, which 140 MUST NOT be used in conjunction with this profile. In that way, once 141 SIP and SDP have exchanged the necessary information to initiate a 142 session, media endpoints will have a strong assurance that the keys 143 they exchange have not been tampered with by third parties, and that 144 end-to-end confidentiality is available. 146 To establishing the identity of the endpoints of a SIP session, this 147 specification uses STIR [RFC8224]. The STIR Identity header has been 148 designed to prevent a class of impersonation attacks that are 149 commonly used in robocalling, voicemail hacking, and related threats. 150 STIR generates a signature over certain features of SIP requests, 151 including header field values that contain an identity for the 152 originator of the request, such as the From header field or P- 153 Asserted-Identity field, and also over the media keys in SDP if they 154 are present. As currently defined, STIR only provides a signature 155 over the "a=fingerprint" attribute, which is a key fingerprint 156 utilized by DTLS-SRTP [RFC5763]; consequently, STIR only offers 157 comprehensive protection for SIP sessions, in concert with SDP and 158 SRTP, when DTLS-SRTP is the media security service. The underlying 159 PASSporT [RFC8225] object used by STIR is extensible, however, and it 160 would be possible to provide signatures over other SDP attributes 161 that contain alternate keying material. A profile for using STIR to 162 provide media confidentiality is given in Section 4. 164 3.2. Opportunistic Security 166 Work is already underway on defining approaches to opportunistic 167 media security for SIP in [I-D.johnston-dispatch-osrtp], which builds 168 on the prior efforts of [I-D.kaplan-mmusic-best-effort-srtp]. The 169 major protocol change proposed by that specification is to signal the 170 use of opportunistic encryption by negotiating the AVP profile in 171 SDP, rather than the SAVP profile (as specified in [RFC3711]) that 172 would ordinarily be used when negotiating SRTP. 174 Opportunistic encryption approaches typically have no integrity 175 protection for the keying material in SDP. Sending SIP over TLS hop- 176 by-hop between user agents and any intermediaries will reduce the 177 prospect that active attackers can alter keys for session requests on 178 the wire. However, opportunistic confidentiality for media will 179 prevent passive attacks of the form most common in the threat of 180 pervasive monitoring. 182 4. STIR Profile for Endpoint Authentication and Verification Services 184 STIR [RFC8224] defines the Identity header field for SIP, which 185 provides a cryptographic attestation of the source of communications. 186 This profile of STIR assumes that a STIR verification service will 187 act in concert with an SRTP media endpoint to ensure that the key 188 fingerprints, as given in SDP, match the keys exchanged to establish 189 DTLS-SRTP. To satisfy this condition, the verification service 190 function would in this case be implemented in the SIP UAS, which 191 would be composed with the media endpoint. If the STIR 192 authentication service or verification service functions are 193 implemented at an intermediary rather than an endpoint, this 194 introduces the possibility that the intermediary could act as a man 195 in the middle, altering key fingerprints. As this attack is not in 196 STIR's core threat model, which focuses on impersonation rather than 197 man-in-the-middle attacks, STIR offers no specific protections 198 against such interference. 200 The SIPBRANDY deployment profile of STIR for media confidentiality 201 thus shifts these responsibilities to the endpoints rather than the 202 intermediaries. While intermediaries MAY provide the verification 203 service function of STIR for SIPBRANDY transactions, the verification 204 needs to be repeated at the endpoint obtain the end-to-end assurance. 205 Intermediaries supporting this specification MUST NOT block or 206 otherwise redirects calls if they do not trust the signing 207 credential. The SIPBRANDY profile is based on an end-to-end trust 208 model, so it is up to the endpoints to determine if they support 209 signing credentials, not intermediaries. 211 In order to be compliant with best practices for SIP media 212 confidentiality with comprehensive protection, user agent 213 implementations MUST implement both the authentication service and 214 verification service roles described in [RFC8224]. STIR 215 authentication services MUST signal their compliance with this 216 specification by adding the "msec" header element defined in this 217 specification to the PASSporT header. Implementations MUST provide 218 key fingerprints in SDP and the appropriate signatures over them per 219 [RFC8225]. 221 When generating either an offer or an answer [RFC3264], compliant 222 implementations MUST include an "a=fingerprint" attribute containing 223 the fingerprint of an appropriate key (see Section 4.1). 225 4.1. Credentials 227 In order to implement the authentication service function in the user 228 agent, SIP endpoints will need to acquire the credentials needed to 229 sign for their own identity. That identity is typically carried in 230 the From header field of a SIP request, and either contains a 231 greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone 232 number, which can appear in a variety of ways (e.g. 233 "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224] 234 contains guidance for separating the two, and determining what sort 235 of credential is needed to sign for each. 237 To date, few commercial certification authorities (CAs) issue 238 certificates for SIP URIs or telephone numbers; though work is 239 ongoing on systems for this purpose (such as 240 [I-D.ietf-acme-telephone]) it is not mature enough to be recommended 241 as a best practice. This is one reason why the STIR standard is 242 architected to permit intermediaries to act as an authentication 243 service on behalf of an entire domain, just as in SIP an proxy server 244 can provide domain-level SIP service. While CAs that offer proof-of- 245 possession certificates similar to those used in the email world 246 could be offered for SIP, either for greenfield identifiers or for 247 telephone numbers, this specification does not require their use. 249 For users who do not possess such certificates, DTLS-SRTP [RFC5763] 250 permits the use of self-signed keys. This profile of STIR employs 251 more relaxed authority requirements of [RFC8224] to allow the use of 252 self-signed keys for authentication services that are composed with 253 user agents, by generating a certificate (per the guidance of 254 [RFC8226]) with a subject corresponding to the user's identity. To 255 obtain comprehensive protection with a self-signed certificate, some 256 out-of-band verification is needed as well. Such a credential could 257 be used for trust on first use (see [RFC7435]) by relying parties. 258 Note that relying parties SHOULD NOT use certificate revocation 259 mechanisms or real-time certificate verification systems for self- 260 signed certificates as they will not increase confidence in the 261 certificate. 263 Users who wish to remain anonymous can instead generate self-signed 264 certificates as described in Section 4.2. 266 Generally speaking, without access to out-of-band information about 267 which certificates were issued to whom, it will be very difficult for 268 relying parties to ascertain whether or not the signer of a SIP 269 request is genuinely an "endpoint." Even the term "endpoint" is a 270 problematic one, as SIP user agents can be composed in a variety of 271 architectures and may not be devices under direct user control. 272 While it is possible that techniques based on certificate 273 transparency [RFC6962] or similar practices could help user agents to 274 recognize one another's certificates, those operational systems will 275 need to ramp up with the certificate authorities that issue 276 credentials to end user devices going forward. 278 4.2. Anonymous Communications 280 In some cases, the identity of the initiator of a SIP session may be 281 withheld due to user or provider policy. Per the recommendations of 282 [RFC3323], this may involve using an identity such as 283 "anonymous@anonymous.invalid" in the identity fields of a SIP 284 request. [RFC8224] does not currently permit authentication services 285 to sign for requests that supply this identity. It does however 286 permit signing for valid domains, such as "anonymous@example.com," as 287 a way of implementation an anonymization service as specified in 288 [RFC3323]. 290 Even for anonymous sessions, providing media confidentiality and 291 partial SDP integrity is still desirable. This specification 292 RECOMMENDS using one-time self-signed certificates for anonymous 293 communications, with a subjectAltName of 294 "sip:anonymous@anonymous.invalid". After a session is terminated, 295 the certificate SHOULD be discarded, and a new one, with new keying 296 material, SHOULD be generated before each future anonymous call. As 297 with self-signed certificates, relying parties SHOULD NOT use 298 certificate revocation mechanisms or real-time certificate 299 verification systems for anonymous certificates as they will not 300 increase confidence in the certificate. 302 Note that when using one-time anonymous self-signed certificates, any 303 man in the middle could strip the Identity header and replace it with 304 one signed by its own one-time certificate, changing the "mkey" 305 parameters of PASSporT and any "a=fingerprint" attributes in SDP as 306 it chooses. This signature only provides protection against non- 307 Identity aware entities that might modify SDP without altering the 308 PASSporT conveyed in the Identity header. 310 4.3. Connected Identity Usage 312 STIR [RFC8224] provides integrity protection for the SDP bodies of 313 SIP requests, but not SIP responses. When a session is established, 314 therefore, any SDP body carried by a 200 class response in the 315 backwards direction will not be protected by an authentication 316 service and cannot be verified. Thus, sending a secured SDP body in 317 the backwards direction will require an extra RTT, typically a 318 request sent in the backwards direction. 320 The problem of providing "Connected Identity" for the original 321 RFC4474 was explored in [RFC4916], which uses a provisional or mid- 322 dialog UPDATE request in the backwards direction to convey an 323 Identity header for the recipient of an INVITE. The procedures in 324 that specification are largely compatible with the revision of the 325 Identity header in [RFC8224]. However, the following updates to 326 [RFC4916] are required: 328 The UPDATE carrying signed SDP with a fingerprint in the backwards 329 direction MUST be sent during dialog establishment, following the 330 receipt of a PRACK after a provisional 1xx response. 332 For use with this STIR Profile for media confidentiality, the UAS 333 that responds to the INVITE request MUST act as an authentication 334 service for the UPDATE sent in the backwards direction. 336 The text in Section 4.4.1 of [RFC4916] regarding the receipt at a 337 UAC of error codes 428, 436, 437 and 438 in response to a mid- 338 dialog request RECOMMENDS treating the dialog as terminated. 339 [RFC8224] allows the retransmission of requests with repairable 340 error conditions (see Section 6.1.1) in a way that can override 341 that SHOULD in [RFC4916]. In particular, an authentication 342 service MAY retry a mid-dialog as [RFC8224] allows rather than 343 treating the dialog as terminated, though note that only one such 344 retry is permitted. 346 The examples in [RFC4916] are based on the original [RFC4916], and 347 will not match signatures using [RFC4474]. 349 Future work may be done to revise [RFC4916] for STIR; that work 350 should take into account any impacts on the profile described in this 351 document. The use of [RFC4916] has some further interactions with 352 ICE; see Section 7. 354 4.4. Authorization Decisions 356 [RFC8224] grants STIR verification services a great deal of latitude 357 when making authorization decisions based on the presence of the 358 Identity header field. It is largely a matter of local policy 359 whether an endpoint rejects a call based on absence of an Identity 360 header field, or even the presence of a header that fails an 361 integrity check against the request. 363 For this profile, however, a compliant verification service that 364 receives a dialog-forming SIP request containing an Identity header 365 with a PASSporT type of "msec", after validating the request per the 366 steps described in Section 6.2 of [RFC8224], MUST reject the request 367 if there is any failure in that validation process with the 368 appropriate status code per Section 6.2.2. If the request is valid, 369 then if a terminating user accepts the request, it MUST then follow 370 the steps in Section 4.3 to act as an authentication service and send 371 a signed request with the "msec" PASSPorT type in its Identity header 372 as well, in order to enable end-to-end bidirectional confidentiality. 374 For the purposes of this profile, the "msec" PASSporT type can be 375 used by authentication services in one of two ways: as a mandatory 376 request for media security, or as a merely opportunistic request for 377 media security. As any verification service that receives an 378 Identity header in a SIP request with an unrecognized PASSporT type 379 will simply ignore that Identity header, an authentication service 380 will know whether or not the terminating side supports "msec" based 381 on whether or not its user agent receives a signed request in the 382 backwards direction per Section 4.3. If no such requests are 383 received, the UA may do one or two things: shut down the dialog, if 384 the policy of the UA requires that "msec" be supported by the 385 terminating side for this dialog; or, if policy permits (e.g. an 386 explicit acceptance by the user), allow the dialog to continue 387 without media security. 389 5. Media Security Protocols 391 As there are several ways to negotiate media security with SDP, any 392 of which might be used with either opportunistic or comprehensive 393 protection, further guidance to implementers is needed. In 394 [I-D.johnston-dispatch-osrtp], opportunistic approaches considered 395 include DTLS-SRTP, security descriptions [RFC4568], and ZRTP 396 [RFC6189]. 398 Support for DTLS-SRTP is REQUIRED by this specification. 400 The "mkey" claim of PASSporT provides integrity protection for 401 "a=fingerprint" attributes in SDP, including cases where multiple 402 "a=fingerprint" attributes appear in the same SDP. 404 6. Relayed Media and Conferencing 406 Providing end-to-end media confidentiality for SIP is complicated by 407 the presence of many forms of media relays. While many media relays 408 merely proxy media to a destination, others present themselves as 409 media endpoints and terminate security associations before re- 410 originating media to its destination. 412 Centralized conference bridges are one type of entity that typically 413 terminates a media session in order to mux media from multiple 414 sources and then to re-originate the muxed media to conference 415 participants. In many such implementations, only hop-by-hop media 416 confidentiality is possible. Work is ongoing to specify a means to 417 encrypt both the hop-by-hop media between a user agent and a 418 centralized server as well as the end-to-end media between user 419 agents, but is not sufficiently mature at this time to make a 420 recommendation for a best practice here. Those protocols are 421 expected to identify their own best practice recommendations as they 422 mature. 424 Another class of entities that might relay SIP media are back-to-back 425 user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], 426 it may be possible for those devices to act as media relays while 427 still permitting end-to-end confidentiality between user agents. 429 Ultimately, if an endpoint can decrypt media it receives, then that 430 endpoint can forward the decrypted media without the knowledge or 431 consent of the media's originator. No media confidentiality 432 mechanism can protect against these sorts of relayed disclosures, or 433 trusted entities that can decrypt media and then record a copy to be 434 sent elsewhere (see [RFC7245]). 436 7. ICE and Connected Identity 438 Providing confidentiality for media with comprehensive protection 439 requires careful timing of when media streams should be sent and when 440 a user interface should signify that confidentiality is in place. 442 In order to best enable end-to-end connectivity between user agents, 443 and to avoid media relays as much as possible, implementations of 444 this specification must support ICE [RFC8445]. To speed up call 445 establishment, it is RECOMMENDED that implementations support trickle 446 ICE [I-D.ietf-mmusic-trickle-ice-sip]. 448 Note that in the comprehensive protection case, the use of Connected 449 Identity [RFC4916] with ICE entails that the answer containing the 450 key fingerprints, and thus the STIR signature, will come in an UPDATE 451 sent in the backwards direction a provisional response and 452 acknowledgment (PRACK), rather than in any earlier SDP body. Only at 453 such a time as that UPDATE is received will the media keys be 454 considered exchanged in this case. 456 Similarly, in order to prevent, or at least mitigate, the denial-of- 457 service attack described in Section 19.5.1 of [RFC8445], this 458 specification incorporates best practices for ensuring that 459 recipients of media flows have consented to receive such flows. 460 Implementations of this specification MUST implement the STUN usage 461 for consent freshness defined in [RFC7675]. 463 8. Best Current Practices 465 The following are the best practices for SIP user agents to provide 466 media confidentiality for SIP sessions. 468 Implementations MUST support the STIR endpoint profile given in 469 Section 4, and signal that in PASSporT with the "msec" header 470 element. 472 Implementations MUST follow the authorization decision behavior in 473 Section 4.4. 475 Implementations MUST support DTLS-SRTP for key-management, as 476 described in Section 5. 478 Implementations MUST support the ICE, and the STUN consent freshness 479 mechanism, as specified in Section 7. 481 9. Acknowledgments 483 We would like to thank Eric Rescorla, Adam Roach, Andrew Hutton, and 484 Ben Campbell for contributions to this problem statement and 485 framework. 487 10. IANA Considerations 489 This specification defines a new values for the PASSporT Type 490 registry called "msec," and the IANA is requested to add that to the 491 registry with a value pointing to [RFCThis]. 493 11. Security Considerations 495 This document describes the security features that provide media 496 sessions established with SIP with confidentiality, integrity, and 497 authentication. 499 12. References 501 12.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 509 A., Peterson, J., Sparks, R., Handley, M., and E. 510 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 511 DOI 10.17487/RFC3261, June 2002, 512 . 514 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 515 with Session Description Protocol (SDP)", RFC 3264, 516 DOI 10.17487/RFC3264, June 2002, 517 . 519 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 520 Initiation Protocol (SIP)", RFC 3323, 521 DOI 10.17487/RFC3323, November 2002, 522 . 524 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 525 Jacobson, "RTP: A Transport Protocol for Real-Time 526 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 527 July 2003, . 529 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 530 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 531 RFC 3711, DOI 10.17487/RFC3711, March 2004, 532 . 534 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 535 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 536 July 2006, . 538 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 539 Description Protocol (SDP) Security Descriptions for Media 540 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 541 . 543 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 544 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 545 2007, . 547 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 548 for Establishing a Secure Real-time Transport Protocol 549 (SRTP) Security Context Using Datagram Transport Layer 550 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 551 2010, . 553 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 554 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 555 2014, . 557 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 558 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 559 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 560 October 2015, . 562 [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., 563 and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back 564 User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, 565 . 567 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 568 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 569 May 2017, . 571 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 572 "Authenticated Identity Management in the Session 573 Initiation Protocol (SIP)", RFC 8224, 574 DOI 10.17487/RFC8224, February 2018, 575 . 577 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 578 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 579 . 581 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 582 Credentials: Certificates", RFC 8226, 583 DOI 10.17487/RFC8226, February 2018, 584 . 586 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 587 Connectivity Establishment (ICE): A Protocol for Network 588 Address Translator (NAT) Traversal", RFC 8445, 589 DOI 10.17487/RFC8445, July 2018, 590 . 592 12.2. Informative References 594 [I-D.ietf-acme-telephone] 595 Peterson, J. and R. Barnes, "ACME Identifiers and 596 Challenges for Telephone Numbers", draft-ietf-acme- 597 telephone-01 (work in progress), October 2017. 599 [I-D.ietf-mmusic-trickle-ice-sip] 600 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 601 Session Initiation Protocol (SIP) Usage for Incremental 602 Provisioning of Candidates for the Interactive 603 Connectivity Establishment (Trickle ICE)", draft-ietf- 604 mmusic-trickle-ice-sip-18 (work in progress), June 2018. 606 [I-D.johnston-dispatch-osrtp] 607 Johnston, A., Ph.D., D., Hutton, A., Liess, L., and T. 608 Stach, "An Opportunistic Approach for Secure Real-time 609 Transport Protocol (OSRTP)", draft-johnston-dispatch- 610 osrtp-02 (work in progress), February 2016. 612 [I-D.kaplan-mmusic-best-effort-srtp] 613 Audet, F. and H. Kaplan, "Session Description Protocol 614 (SDP) Offer/Answer Negotiation For Best-Effort Secure 615 Real-Time Transport Protocol", draft-kaplan-mmusic-best- 616 effort-srtp-01 (work in progress), October 2006. 618 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 619 Authenticated Identity Management in the Session 620 Initiation Protocol (SIP)", RFC 4474, 621 DOI 10.17487/RFC4474, August 2006, 622 . 624 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 625 Media Path Key Agreement for Unicast Secure RTP", 626 RFC 6189, DOI 10.17487/RFC6189, April 2011, 627 . 629 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 630 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 631 . 633 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 634 "An Architecture for Media Recording Using the Session 635 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 636 2014, . 638 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 639 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 640 December 2014, . 642 Authors' Addresses 644 Jon Peterson 645 Neustar, Inc. 647 Email: jon.peterson@team.neustar 649 Richard Barnes 650 Cisco 652 Email: rlb@ipv.sx 654 Russ Housley 655 Vigil Security, LLC 657 Email: housley@vigilsec.com