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