idnits 2.17.1 draft-ietf-sipbrandy-rtpsec-08.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 date (April 25, 2019) is 1821 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 475, but not defined == Unused Reference: 'RFC8446' is defined on line 589, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-09) exists of draft-ietf-acme-authority-token-03 == Outdated reference: A later version (-10) exists of draft-ietf-sipbrandy-osrtp-08 -- 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 (~~), 5 warnings (==), 3 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 R. Barnes 5 Expires: October 27, 2019 Cisco 6 R. Housley 7 Vigil Security 8 April 25, 2019 10 Best Practices for Securing RTP Media Signaled with SIP 11 draft-ietf-sipbrandy-rtpsec-08 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 a comprehensive protection 23 solution that binds the media layer to SIP layer identities. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 27, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Security at the SIP and SDP layer . . . . . . . . . . . . . . 3 62 4. STIR Profile for Endpoint Authentication and Verification 63 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Anonymous Communications . . . . . . . . . . . . . . . . 6 66 4.3. Connected Identity Usage . . . . . . . . . . . . . . . . 7 67 4.4. Authorization Decisions . . . . . . . . . . . . . . . . . 8 68 5. Media Security Protocols . . . . . . . . . . . . . . . . . . 8 69 6. Relayed Media and Conferencing . . . . . . . . . . . . . . . 9 70 7. ICE and Connected Identity . . . . . . . . . . . . . . . . . 9 71 8. Best Current Practices . . . . . . . . . . . . . . . . . . . 10 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 12.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 The Session Initiation Protocol (SIP) [RFC3261] includes a suite of 83 security services, including Digest authentication, for 84 authenticating entities with a shared secret, TLS for transport 85 security, and S/MIME (optionally) for body security. SIP is 86 frequently used to establish media sessions, in particular audio or 87 audiovisual sessions, which have their own security mechanisms 88 available, such as Secure RTP [RFC3711]. However, the practices 89 needed to bind security at the media layer to security at the SIP 90 layer, to provide an assurance that protection is in place all the 91 way up the stack, rely on a great many external security mechanisms 92 and practices. This document provides documentation to explain their 93 optimal use as a best practice. 95 Revelations about widespread pervasive monitoring of the Internet 96 have led to a greater desire to protect Internet communications 98 [RFC7258]. In order to maximize the use of security features, 99 especially of media confidentiality, opportunistic measures serve as 100 a stopgap when a full suite of services cannot be negotiated all the 101 way up the stack. Opportunistic media security for SIP is described 102 in [I-D.ietf-sipbrandy-osrtp], which builds on the prior efforts of 103 [I-D.kaplan-mmusic-best-effort-srtp]. With opportunistic encryption, 104 there is an attempt to negotiate the use of encryption, but if the 105 negotiation fails, then cleartext is used. Opportunistic encryption 106 approaches typically have no integrity protection for the keying 107 material. 109 This document contains the SIPBRANDY profile of STIR [RFC8224] for 110 media confidentiality, providing a comprehensive security solution 111 for SIP media that includes integrity protection for keying material 112 and offers application-layer assurance that media confidentiality is 113 place. Various specifications that user agents must implement to 114 support media confidentiality are given in the sections below; a 115 summary of the best current practices appears in Section 8. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in 122 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Security at the SIP and SDP layer 127 There are two approaches to providing confidentiality for media 128 sessions set up with SIP: comprehensive protection and opportunistic 129 security (as defined in [RFC7435]). This document only addresses 130 comprehensive protection. 132 Comprehensive protection for media sessions established by SIP 133 requires the interaction of three protocols: Session Initiation 134 Protocol (SIP) [RFC3261], the Session Description Protocol (SDP) 135 [RFC4566], and the Real-time Protocol (RTP) [RFC3550], in particular 136 its secure profile Secure RTP (SRTP) [RFC3711]. Broadly, it is the 137 responsibility of SIP to provide integrity protection for the media 138 keying attributes conveyed by SDP, and those attributes will in turn 139 identify the keys used by endpoints in the RTP media session(s) that 140 SDP negotiates. 142 Note that this framework does not apply to keys that also require 143 confidentiality protection in the signaling layer, such as the SDP 144 "k=" line, which MUST NOT be used in conjunction with this profile. 146 In that way, once SIP and SDP have exchanged the necessary 147 information to initiate a session, media endpoints will have a strong 148 assurance that the keys they exchange have not been tampered with by 149 third parties, and that end-to-end confidentiality is available. 151 To establishing the identity of the endpoints of a SIP session, this 152 specification uses STIR [RFC8224]. The STIR Identity header has been 153 designed to prevent a class of impersonation attacks that are 154 commonly used in robocalling, voicemail hacking, and related threats. 155 STIR generates a signature over certain features of SIP requests, 156 including header field values that contain an identity for the 157 originator of the request, such as the From header field or P- 158 Asserted-Identity field, and also over the media keys in SDP if they 159 are present. As currently defined, STIR provides a signature over 160 the "a=fingerprint" attribute, which is a fingerprint of the key used 161 by DTLS-SRTP [RFC5763]; consequently, STIR only offers comprehensive 162 protection for SIP sessions in concert with SDP and SRTP when DTLS- 163 SRTP is the media security service. The underlying PASSporT 164 [RFC8225] object used by STIR is extensible, however, and it would be 165 possible to provide signatures over other SDP attributes that contain 166 alternate keying material. A profile for using STIR to provide media 167 confidentiality is given in Section 4. 169 4. STIR Profile for Endpoint Authentication and Verification Services 171 STIR [RFC8224] defines the Identity header field for SIP, which 172 provides a cryptographic attestation of the source of communications. 173 This document includes a profile of STIR, called the SIPBRANDY 174 profile, where the STIR verification service will act in concert with 175 an SRTP media endpoint to ensure that the key fingerprints, as given 176 in SDP, match the keys exchanged to establish DTLS-SRTP. To satisfy 177 this condition, the verification service function would in this case 178 be implemented in the SIP User Agent Server (UAS), which would be 179 composed with the media endpoint. If the STIR authentication service 180 or verification service functions are implemented at an intermediary 181 rather than an endpoint, this introduces the possibility that the 182 intermediary could act as a man in the middle, altering key 183 fingerprints. As this attack is not in STIR's core threat model, 184 which focuses on impersonation rather than man-in-the-middle attacks, 185 STIR offers no specific protections against such interference. 187 The SIPBRANDY profile for media confidentiality thus shifts these 188 responsibilities to the endpoints rather than the intermediaries. 189 While intermediaries MAY provide the verification service function of 190 STIR for SIPBRANDY transactions, the verification needs to be 191 repeated at the endpoint to obtain end-to-end assurance. 192 Intermediaries supporting this specification MUST NOT block or 193 otherwise redirect calls if they do not trust the signing credential. 195 The SIPBRANDY profile is based on an end-to-end trust model, so it is 196 up to the endpoints to determine if they support signing credentials, 197 not 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 [RFC8224]. STIR 203 authentication services MUST signal their compliance with this 204 specification by including the "msec" claim defined in this 205 specification to the PASSporT payload. Implementations MUST provide 206 key fingerprints in SDP and the appropriate signatures over them as 207 specified in [RFC8225]. 209 When generating either an offer or an answer [RFC3264], 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 will need to acquire the credentials needed to 217 sign for their own identity. That identity is typically carried in 218 the From header field of a SIP request, and either contains a 219 greenfield SIP URI (e.g. "sip:alice@example.com") or a telephone 220 number, which can appear in a variety of ways (e.g. 221 "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224] 222 contains guidance for separating the two, and determining what sort 223 of credential is needed to sign for each. 225 To date, few commercial certification authorities (CAs) issue 226 certificates for SIP URIs or telephone numbers; though work is 227 ongoing on systems for this purpose (such as 228 [I-D.ietf-acme-authority-token]) it is not yet mature enough to be 229 recommended as a best practice. This is one reason why STIR permits 230 intermediaries to act as an authentication service on behalf of an 231 entire domain, just as in SIP a proxy server can provide domain-level 232 SIP service. While CAs that offer proof-of-possession certificates 233 similar to those used for email could be offered for SIP, either for 234 greenfield identifiers or for telephone numbers, this specification 235 does not require their use. 237 For users who do not possess such certificates, DTLS-SRTP [RFC5763] 238 permits the use of self-signed public keys. This profile of STIR 239 employs more relaxed authority requirements of [RFC8224] to allow the 240 use of self-signed public keys for authentication services that are 241 composed with user agents, by generating a certificate (per the 242 guidance in [RFC8226]) with a subject corresponding to the user's 243 identity. To obtain comprehensive protection with a self-signed 244 certificate, some out-of-band verification is needed as well. Such a 245 credential could be used for trust on first use (see [RFC7435]) by 246 relying parties. Note that relying parties SHOULD NOT use 247 certificate revocation mechanisms or real-time certificate 248 verification systems for self-signed certificates as they will not 249 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 Generally speaking, without access to out-of-band information about 255 which certificates were issued to whom, it will be very difficult for 256 relying parties to ascertain whether or not the signer of a SIP 257 request is genuinely an "endpoint." Even the term "endpoint" is a 258 problematic one, as SIP user agents can be composed in a variety of 259 architectures and may not be devices under direct user control. 260 While it is possible that techniques based on certificate 261 transparency [RFC6962] or similar practices could help user agents to 262 recognize one another's certificates, those operational systems will 263 need to ramp up with the CAs that issue credentials to end user 264 devices going forward. 266 4.2. Anonymous Communications 268 In some cases, the identity of the initiator of a SIP session may be 269 withheld due to user or provider policy. Following the 270 recommendations of [RFC3323], this may involve using an identity such 271 as "anonymous@anonymous.invalid" in the identity fields of a SIP 272 request. [RFC8224] does not currently permit authentication services 273 to sign for requests that supply this identity. It does however 274 permit signing for valid domains, such as "anonymous@example.com," as 275 a way of implementation an anonymization service as specified in 276 [RFC3323]. 278 Even for anonymous sessions, providing media confidentiality and 279 partial SDP integrity is still desirable. This specification 280 RECOMMENDS using one-time self-signed certificates for anonymous 281 communications, with a subjectAltName of 282 "sip:anonymous@anonymous.invalid". After a session is terminated, 283 the certificate SHOULD be discarded, and a new one, with fresh keying 284 material, SHOULD be generated before each future anonymous call. As 285 with self-signed certificates, relying parties SHOULD NOT use 286 certificate revocation mechanisms or real-time certificate 287 verification systems for anonymous certificates as they will not 288 increase confidence in the certificate. 290 Note that when using one-time anonymous self-signed certificates, any 291 man in the middle could strip the Identity header and replace it with 292 one signed by its own one-time certificate, changing the "mkey" 293 parameters of PASSporT and any "a=fingerprint" attributes in SDP as 294 it chooses. This signature only provides protection against non- 295 Identity aware entities that might modify SDP without altering the 296 PASSporT conveyed in the Identity header. 298 4.3. Connected Identity Usage 300 STIR [RFC8224] provides integrity protection for the fingerprint 301 attributes in SIP request bodies, but not SIP responses. When a 302 session is established, therefore, any SDP body carried by a 200 303 class response in the backwards direction will not be protected by an 304 authentication service and cannot be verified. Thus, sending a 305 secured SDP body in the backwards direction will require an extra 306 RTT, typically a request sent in the backwards direction. 308 The problem of providing "Connected Identity" in [RFC4474], which is 309 obsoleted by STIR, was explored in [RFC4916], which uses a 310 provisional or mid-dialog UPDATE request in the backwards direction 311 to convey an Identity header field for the recipient of an INVITE. 312 The procedures in that specification are largely compatible with the 313 revision of the Identity header in STIR [RFC8224]. However, the 314 following need to be considered: 316 The UPDATE carrying signed SDP with a fingerprint in the backwards 317 direction needs to be sent during dialog establishment, following 318 the receipt of a PRACK after a provisional 1xx response. 320 For use with this SIPBRANDY profile for media confidentiality, the 321 UAS that responds to the INVITE request needs to act as an 322 authentication service for the UPDATE sent in the backwards 323 direction. 325 The text in Section 4.4.1 of [RFC4916] regarding the receipt at a 326 UAC of error codes 428, 436, 437 and 438 in response to a mid- 327 dialog request RECOMMENDS treating the dialog as terminated. 328 However, Section 6.1.1 of [RFC8224] allows the retransmission of 329 requests with repairable error conditions. In particular, an 330 authentication service might retry a mid-dialog rather than 331 treating the dialog as terminated, although only one such retry is 332 permitted. 334 Note that the examples in [RFC4916] are based on the original 335 [RFC4474], and will not match signatures using STIR [RFC8224]. 337 Future work may be done to revise [RFC4916] for STIR; that work 338 should take into account any impacts on the SIPBRANDY profile 339 described in this document. The use of [RFC4916] has some further 340 interactions with ICE; see Section 7. 342 4.4. Authorization Decisions 344 [RFC8224] grants STIR verification services a great deal of latitude 345 when making authorization decisions based on the presence of the 346 Identity header field. It is largely a matter of local policy 347 whether an endpoint rejects a call based on absence of an Identity 348 header field, or even the presence of a header that fails an 349 integrity check against the request. 351 For this SIPBRANDY profile of STIR, however, a compliant verification 352 service that receives a dialog-forming SIP request containing an 353 Identity header with a PASSporT type of "msec", after validating the 354 request per the steps described in Section 6.2 of [RFC8224], MUST 355 reject the request if there is any failure in that validation process 356 with the appropriate status code per Section 6.2.2. If the request 357 is valid, then if a terminating user accepts the request, it MUST 358 then follow the steps in Section 4.3 to act as an authentication 359 service and send a signed request with the "msec" PASSPorT type in 360 its Identity header as well, in order to enable end-to-end 361 bidirectional confidentiality. 363 For the purposes of this profile, the "msec" PASSporT type can be 364 used by authentication services in one of two ways: as a mandatory 365 request for media security, or as a merely opportunistic request for 366 media security. As any verification service that receives an 367 Identity header field in a SIP request with an unrecognized PASSporT 368 type will simply ignore that Identity header, an authentication 369 service will know whether or not the terminating side supports "msec" 370 based on whether or not its user agent receives a signed request in 371 the backwards direction per Section 4.3. If no such requests are 372 received, the UA may do one or two things: shut down the dialog, if 373 the policy of the UA requires that "msec" be supported by the 374 terminating side for this dialog; or, if policy permits (e.g., an 375 explicit acceptance by the user), allow the dialog to continue 376 without media security. 378 5. Media Security Protocols 380 As there are several ways to negotiate media security with SDP, any 381 of which might be used with either opportunistic or comprehensive 382 protection, further guidance to implementers is needed. In 383 [I-D.ietf-sipbrandy-osrtp], opportunistic approaches considered 384 include DTLS-SRTP, security descriptions [RFC4568], and ZRTP 385 [RFC6189]. 387 Support for DTLS-SRTP is REQUIRED by this specification. 389 The "mkey" claim of PASSporT provides integrity protection for 390 "a=fingerprint" attributes in SDP, including cases where multiple 391 "a=fingerprint" attributes appear in the same SDP. 393 6. Relayed Media and Conferencing 395 Providing end-to-end media confidentiality for SIP is complicated by 396 the presence of many forms of media relays. While many media relays 397 merely proxy media to a destination, others present themselves as 398 media endpoints and terminate security associations before re- 399 originating media to its destination. 401 Centralized conference bridges are one type of entity that typically 402 terminates a media session in order to mux media from multiple 403 sources and then to re-originate the muxed media to conference 404 participants. In many such implementations, only hop-by-hop media 405 confidentiality is possible. Work is ongoing to specify a means to 406 encrypt both the hop-by-hop media between a user agent and a 407 centralized server as well as the end-to-end media between user 408 agents, but is not sufficiently mature at this time to make a 409 recommendation for a best practice here. Those protocols are 410 expected to identify their own best practice recommendations as they 411 mature. 413 Another class of entities that might relay SIP media are back-to-back 414 user agents (B2BUAs). If a B2BUA follows the guidance in [RFC7879], 415 it may be possible for those devices to act as media relays while 416 still permitting end-to-end confidentiality between user agents. 418 Ultimately, if an endpoint can decrypt media it receives, then that 419 endpoint can forward the decrypted media without the knowledge or 420 consent of the media's originator. No media confidentiality 421 mechanism can protect against these sorts of relayed disclosures, or 422 trusted entities that can decrypt media and then record a copy to be 423 sent elsewhere (see [RFC7245]). 425 7. ICE and Connected Identity 427 Providing confidentiality for media with comprehensive protection 428 requires careful timing of when media streams should be sent and when 429 a user interface should signify that confidentiality is in place. 431 In order to best enable end-to-end connectivity between user agents, 432 and to avoid media relays as much as possible, implementations of 433 this specification MUST support ICE [RFC8445]. To speed up call 434 establishment, it is RECOMMENDED that implementations support trickle 435 ICE [I-D.ietf-mmusic-trickle-ice-sip]. 437 Note that in the comprehensive protection case, the use of Connected 438 Identity [RFC4916] with ICE entails that the answer containing the 439 key fingerprints, and thus the STIR signature, will come in an UPDATE 440 sent in the backwards direction, a provisional response, and a 441 provisional acknowledgment (PRACK), rather than in any earlier SDP 442 body. Only at such a time as that UPDATE is received will the media 443 keys be considered exchanged in this case. 445 Similarly, in order to prevent, or at least mitigate, the denial-of- 446 service attack described in Section 19.5.1 of [RFC8445], this 447 specification incorporates best practices for ensuring that 448 recipients of media flows have consented to receive such flows. 449 Implementations of this specification MUST implement the STUN usage 450 for consent freshness defined in [RFC7675]. 452 8. Best Current Practices 454 The following are the best practices for SIP user agents to provide 455 media confidentiality for SIP sessions. 457 Implementations MUST support the STIR endpoint profile given in 458 Section 4, and signal that in PASSporT with the "msec" header 459 element. 461 Implementations MUST follow the authorization decision behavior in 462 Section 4.4. 464 Implementations MUST support DTLS-SRTP for key-management, as 465 described in Section 5. 467 Implementations MUST support the ICE, and the STUN consent freshness 468 mechanism, as specified in Section 7. 470 9. IANA Considerations 472 This specification defines a new value for the Personal Assertion 473 Token (PASSporT) Extensions registry called "msec," and the IANA is 474 requested to add that entry to the registry with a value pointing to 475 [RFCThis]. 477 10. Security Considerations 479 This document describes the security features that provide media 480 sessions established with SIP with confidentiality, integrity, and 481 authentication. 483 11. Acknowledgments 485 We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell 486 for contributions to this problem statement and framework. We thank 487 Liang Xia and Alissa Cooper for their careful review. 489 12. References 491 12.1. Normative References 493 [I-D.ietf-mmusic-trickle-ice-sip] 494 Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 495 Session Initiation Protocol (SIP) Usage for Incremental 496 Provisioning of Candidates for the Interactive 497 Connectivity Establishment (Trickle ICE)", draft-ietf- 498 mmusic-trickle-ice-sip-18 (work in progress), June 2018. 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, 502 DOI 10.17487/RFC2119, March 1997, 503 . 505 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 506 A., Peterson, J., Sparks, R., Handley, M., and E. 507 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 508 DOI 10.17487/RFC3261, June 2002, 509 . 511 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 512 with Session Description Protocol (SDP)", RFC 3264, 513 DOI 10.17487/RFC3264, June 2002, 514 . 516 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 517 Initiation Protocol (SIP)", RFC 3323, 518 DOI 10.17487/RFC3323, November 2002, 519 . 521 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 522 Jacobson, "RTP: A Transport Protocol for Real-Time 523 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 524 July 2003, . 526 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 527 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 528 RFC 3711, DOI 10.17487/RFC3711, March 2004, 529 . 531 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 532 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 533 July 2006, . 535 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 536 Description Protocol (SDP) Security Descriptions for Media 537 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 538 . 540 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 541 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 542 2007, . 544 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 545 for Establishing a Secure Real-time Transport Protocol 546 (SRTP) Security Context Using Datagram Transport Layer 547 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 548 2010, . 550 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 551 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 552 2014, . 554 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 555 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 556 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 557 October 2015, . 559 [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., 560 and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back 561 User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, 562 . 564 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 565 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 566 May 2017, . 568 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 569 "Authenticated Identity Management in the Session 570 Initiation Protocol (SIP)", RFC 8224, 571 DOI 10.17487/RFC8224, February 2018, 572 . 574 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 575 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 576 . 578 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 579 Credentials: Certificates", RFC 8226, 580 DOI 10.17487/RFC8226, February 2018, 581 . 583 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 584 Connectivity Establishment (ICE): A Protocol for Network 585 Address Translator (NAT) Traversal", RFC 8445, 586 DOI 10.17487/RFC8445, July 2018, 587 . 589 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 590 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 591 . 593 12.2. Informative References 595 [I-D.ietf-acme-authority-token] 596 Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME 597 Challenges Using an Authority Token", draft-ietf-acme- 598 authority-token-03 (work in progress), March 2019. 600 [I-D.ietf-sipbrandy-osrtp] 601 Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T. 602 Stach, "An Opportunistic Approach for Secure Real-time 603 Transport Protocol (OSRTP)", draft-ietf-sipbrandy-osrtp-08 604 (work in progress), March 2019. 606 [I-D.kaplan-mmusic-best-effort-srtp] 607 Audet, F. and H. Kaplan, "Session Description Protocol 608 (SDP) Offer/Answer Negotiation For Best-Effort Secure 609 Real-Time Transport Protocol", draft-kaplan-mmusic-best- 610 effort-srtp-01 (work in progress), October 2006. 612 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 613 Authenticated Identity Management in the Session 614 Initiation Protocol (SIP)", RFC 4474, 615 DOI 10.17487/RFC4474, August 2006, 616 . 618 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 619 Media Path Key Agreement for Unicast Secure RTP", 620 RFC 6189, DOI 10.17487/RFC6189, April 2011, 621 . 623 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 624 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 625 . 627 [RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, 628 "An Architecture for Media Recording Using the Session 629 Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 630 2014, . 632 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 633 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 634 December 2014, . 636 Authors' Addresses 638 Jon Peterson 639 Neustar, Inc. 641 Email: jon.peterson@team.neustar 643 Richard Barnes 644 Cisco 646 Email: rlb@ipv.sx 648 Russ Housley 649 Vigil Security, LLC 651 Email: housley@vigilsec.com