RFC 8862

RFC 8862: Best Practices for Securing RTP Media Signaled with SIP 🎀

Okay bestie, let's start with the ID card 🪪. RFC 8862 was written by J. Peterson (Neustar), R. Barnes (Cisco), and R. Housley (Vigil Security). It's a Best Current Practice, so it's BCP 228 💅, with ISSN 2070-1721, and it came out in January 2021 ✨. The title block doesn't list anything it obsoletes or updates, so it's not replacing or amending any other RFC 🦋.

Abstract 🌸

SIP has a whole buffet of security services, and it's been expanded by tons of specs over the years 🍓. The problem is there's no single place that explains how to use SIP to set up confidential media sessions 🙈. On top of that, the existing mechanisms have some feature gaps that need to get identified and fixed so they can handle the pervasive monitoring threat model 😭. This spec is the best-practices guide for negotiating confidential media with SIP. It includes a full protection solution that ties the media layer to SIP-layer identities 🔥.

Status of This Memo 🧚

This memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑. If you want more on BCPs, check Section 2 of RFC 7841 💜.

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8862 🌈.

Copyright Notice 💖

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes ⭐.

Table of Contents 🦋

1.  Introduction
2.  Terminology
3.  Security at the SIP and SDP Layer
4.  STIR Profile for Endpoint Authentication and Verification
        Services
  4.1.  Credentials
  4.2.  Anonymous Communications
  4.3.  Connected Identity Usage
  4.4.  Authorization Decisions
5.  Media Security Protocols
6.  Relayed Media and Conferencing
7.  ICE and Connected Identity
8.  Best Current Practices
9.  IANA Considerations
10. Security Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

Okay so, SIP [RFC3261] comes with a whole security suite 🔐. That includes Digest Authentication [RFC7616] for checking entities against a shared secret, TLS [RFC8446] for transport security, and (optionally) S/MIME [RFC8551] for body security. SIP is often used to set up media sessions, especially audio or audiovisual ones, and those have their own security tools too, like the Secure Real-time Transport Protocol (SRTP) [RFC3711] 🎧. The catch is that tying media-layer security to SIP-layer security, so you know protection is in place all the way up the stack, depends on a huge pile of outside security mechanisms and practices 😵‍💫. This document is the explainer for how to use all of that in the best way 💅.

Revelations about widespread pervasive monitoring of the Internet have made people want to protect their communications way more [RFC7258] 😭. To get the most out of security features, especially media confidentiality, opportunistic measures act as a stopgap when the full suite can't be negotiated all the way up the stack 🫶. Opportunistic media security for SIP is described in [RFC8643], which builds on the earlier work in [Best-Effort-SRTP] 🌸. With opportunistic encryption, the system tries to negotiate encryption, but if that fails, it falls back to cleartext 🙈. Opportunistic encryption approaches usually have no integrity protection for the keying material, which is a real gap 💀.

This document describes the SIP Best-practice Recommendations Against Network Dangers to privacY (SIPBRANDY) profile of Secure Telephone Identity Revisited (STIR) [RFC8224] for media confidentiality 🍓. It gives you a full security solution for SIP media that includes integrity protection for keying material and offers application-layer assurance that media confidentiality is in place 👑. The sections below cover the various specs that User Agents (UAs) must implement to support media confidentiality, and Section 8 has a summary of the best current practices 🧚.

2. Terminology 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖.

3. Security at the SIP and SDP Layer 🌈

There are two ways to get confidentiality for media sessions set up with SIP: comprehensive protection and opportunistic security (as defined in [RFC7435]) ⭐. This document only covers comprehensive protection 💖.

Comprehensive protection for media sessions set up by SIP needs three protocols working together: SIP [RFC3261], the Session Description Protocol (SDP) [RFC4566], and the Real-time Transport Protocol (RTP) [RFC3550], especially its secure profile, SRTP [RFC3711] 🤝. In broad strokes, SIP is responsible for giving integrity protection to the media keying attributes carried in SDP, and those attributes then identify the keys the endpoints use in the RTP media session(s) that SDP negotiates 🔑.

Note that this framework does not apply to keys that also need confidentiality protection in the signaling layer, like the SDP k= line, which MUST NOT be used with this profile 🚫.

So once SIP and SDP have swapped the info they need to start a session, the media endpoints get strong assurance that the keys they exchanged haven't been messed with by third parties, and that end-to-end confidentiality is available 🦋.

To establish the identity of the endpoints in a SIP session, this spec uses STIR [RFC8224] 🪪. The STIR Identity header was designed to stop a class of impersonation attacks that show up in robocalling, voicemail hacking, and related threats 📞. STIR signs certain parts of SIP requests, including header field values that hold the identity of the request's originator, like the From header field or the P-Asserted-Identity field, and it also signs the media keys in SDP if they're there ✍️. As currently defined, STIR gives a signature over the a=fingerprint attribute, which is a fingerprint of the key used by DTLS-SRTP [RFC5763]. That means STIR only gives comprehensive protection for SIP sessions alongside SDP and SRTP when DTLS-SRTP is the media security service 🔐. The Personal Assertion Token (PASSporT) object [RFC8225] that STIR uses is extensible, though, so it would be possible to sign other SDP attributes that carry alternate keying material 🧩. A profile for using STIR to provide media confidentiality is in Section 4 🎀.

4. STIR Profile for Endpoint Authentication and Verification Services 💅

STIR [RFC8224] defines the Identity header field for SIP, which gives a cryptographic attestation of where the communication came from ✨. This document includes a profile of STIR called the SIPBRANDY profile. In it, the STIR verification service works together with an SRTP media endpoint to make sure the key fingerprints in SDP match the keys exchanged to set up DTLS-SRTP 🔍. To meet that condition, the verification service function would be implemented in the SIP User Agent Server (UAS), which gets composed with the media endpoint 🧱. If the STIR authentication service or verification service functions are implemented at an intermediary rather than an endpoint, the intermediary could act as a man in the middle and alter the key fingerprints 😱. STIR's core threat model focuses on impersonation rather than man-in-the-middle attacks, so STIR offers no specific protection against that kind of interference 🙅‍♀️.

The SIPBRANDY profile for media confidentiality shifts these responsibilities over to the endpoints instead of the intermediaries 🫶. Intermediaries MAY provide the verification service function of STIR for SIPBRANDY transactions, but the verification needs to be repeated at the endpoint to get end-to-end assurance 🔁. Intermediaries supporting this specification MUST NOT block or otherwise redirect calls if they don't trust the signing credential 🚫. The SIPBRANDY profile is built on an end-to-end trust model, so it's up to the endpoints to decide whether they support signing credentials, not the intermediaries 👑.

To be compliant with best practices for SIP media confidentiality with comprehensive protection, UA implementations MUST implement both the authentication service and verification service roles described in [RFC8224] 🎀. STIR authentication services MUST signal their compliance with this specification by including the "msec" claim defined in this specification in the PASSporT payload 🏷️. Implementations MUST provide key fingerprints in SDP and the appropriate signatures over them, as specified in [RFC8225] 🔏.

When generating either an offer or an answer [RFC3264], compliant implementations MUST include an a=fingerprint attribute containing the fingerprint of an appropriate key (see Section 4.1) 🌸.

4.1. Credentials 🔑

okay so first things first, SIP endpoints need credentials to sign for their own identity 🫶. That identity usually lives in the From header field of a SIP request, and it's either a greenfield SIP URI (like "sip:alice@example.com") or a telephone number (which can show up in lots of looks, like "sip:+17004561212@example.com;user=phone"). Section 8 of [RFC8224] has the guidance for telling those two apart and figuring out what kind of credential you need to sign for each one 💜.

ngl, very few commercial certification authorities (CAs) actually issue certificates for SIP URIs or telephone numbers 💀. There's work happening on systems for this (like [ACME-Auth-Token]), but it isn't mature enough to be recommended as a best practice yet 🌸. That's one reason STIR lets intermediaries act as an authentication service on behalf of a whole domain, the same way a SIP proxy server can provide domain-level SIP service ✨. CAs that offer proof-of-possession certificates, like the ones used for email, could be offered for SIP for greenfield identifiers or telephone numbers, but this specification does not require their use 🦋.

For users who don't have those certificates, DTLS-SRTP [RFC5763] allows self-signed public keys 🎀. The SIPBRANDY profile (the flavor of STIR this document describes) uses the more relaxed authority requirements of [RFC8224], so self-signed public keys can be used for authentication services that are composed with UAs. You generate a certificate (following the guidance in [RFC8226]) with a subject matching the user's identity 💅. To get comprehensive protection with a self-signed certificate, you also need some out-of-band verification 👑. A credential like that could be used for trust on first use (see [RFC7435]) by relying parties. Heads up: relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for self-signed certificates, because they won't increase confidence in the certificate 🙈.

Users who want to stay anonymous can instead generate self-signed certificates as described in Section 4.2 🧚.

Generally speaking, without out-of-band info about which certificates were issued to whom, it's going to be really hard for relying parties to tell whether the signer of a SIP request is genuinely an "endpoint" 😭. Even the word "endpoint" is tricky, since SIP UAs can be built in all sorts of architectures and might not be devices under direct user control 🌈. Certificate transparency [RFC6962] or similar practices could help UAs recognize one another's certificates, but those systems will need to ramp up with the CAs that issue credentials to end-user devices going forward ⭐.

4.2. Anonymous Communications 🎭

In some cases, the identity of the initiator of a SIP session may be withheld due to user or provider policy 🫥. Following the recommendations of [RFC3323], this may involve using an identity like "anonymous@anonymous.invalid" in the identity fields of a SIP request. [RFC8224] doesn't currently permit authentication services to sign for requests that supply this identity. It does, however, permit signing for valid domains, like "anonymous@example.com", as a way of implementing an anonymization service as specified in [RFC3323] 🌸.

Even for anonymous sessions, providing media confidentiality and partial SDP integrity is still desirable 🔒. One-time self-signed certificates for anonymous communications SHOULD include a subjectAltName of "sip:anonymous@anonymous.invalid". After a session is terminated, the certificate SHOULD be discarded, and a new one, with fresh keying material, SHOULD be generated before each future anonymous call 🧚. As with self-signed certificates, relying parties SHOULD NOT use certificate revocation mechanisms or real-time certificate verification systems for anonymous certificates, as they will not increase confidence in the certificate.

Watch out: when using one-time anonymous self-signed certificates, any man in the middle could strip the Identity header and replace it with one signed by its own one-time certificate, changing the "mky" parameters of PASSporT and any "a=fingerprint" attributes in SDP as it chooses. This signature only provides protection against non-Identity-aware entities that might modify SDP without altering the PASSporT conveyed in the Identity header. 😱

4.3. Connected Identity Usage 🤝

STIR [RFC8224] provides integrity protection for the fingerprint attributes in SIP request bodies, but not SIP responses 🙃. So when a session is established, any SDP body carried by a 200-class response in the backwards direction won't be protected by an authentication service and can't be verified. That means sending a secured SDP body in the backwards direction takes an extra RTT, typically a request sent in the backwards direction ⏳.

[RFC4916] explored the problem of providing "connected identity" to implementations of [RFC4474] (which is obsoleted by [RFC8224]) 🧩. [RFC4916] uses a provisional or mid-dialog UPDATE request in the backwards (reverse) direction to convey an Identity header field for the recipient of an INVITE. The procedures in [RFC4916] are largely compatible with the revision of the Identity header in [RFC8224]. However, the following need to be considered:

• The UPDATE carrying signed SDP with a fingerprint in the backwards direction needs to be sent during dialog establishment, following the receipt of a Provisional Response Acknowledgement (PRACK) after a provisional 1xx response. 📮
• For use with this SIPBRANDY profile for media confidentiality, the UAS that responds to the INVITE request needs to act as an authentication service for the UPDATE sent in the backwards direction. 🔁
• Per the text in Section 4.4.1 of [RFC4916] regarding the receipt at a User Agent Client (UAC) of error code 428, 436, 437, or 438 in response to a mid-dialog request, it is RECOMMENDED that the dialog be treated as terminated. However, Section 6.1.1 of [RFC8224] allows the retransmission of requests with repairable error conditions. In particular, an authentication service might retry a mid-dialog request rather than treating the dialog as terminated, although only one such retry is permitted. 🔄
• Note that the examples in [RFC4916] are based on [RFC4474] and will not match signatures using [RFC8224]. 📝

Future work may be done to revise [RFC4916] for STIR; that work should take into account any impacts on the SIPBRANDY profile described in this document. The use of [RFC4916] has some further interactions with Interactive Connectivity Establishment (ICE) [RFC8445]; see Section 7 🧭.

4.4. Authorization Decisions 🚦

[RFC8224] gives STIR verification services a great deal of latitude when making authorization decisions based on the presence of the Identity header field. It's largely a matter of local policy whether an endpoint rejects a call based on the absence of an Identity header field, or even the presence of a header that fails an integrity check against the request 🔍.

For this SIPBRANDY profile of STIR, however, a compliant verification service that receives a dialog-forming SIP request containing an Identity header with a PASSporT type of "msec", after validating the request per the steps described in Section 6.2 of [RFC8224], MUST reject the request if there is any failure in that validation process, with the appropriate status code per Section 6.2.2 of [RFC8224]. If the request is valid, then if a terminating user accepts the request, it MUST then follow the steps in Section 4.3 to act as an authentication service and send a signed request with the "msec" PASSporT type in its Identity header as well, in order to enable end-to-end bidirectional confidentiality 🔐.

For the purposes of this profile, the "msec" PASSporT type can be used by authentication services in one of two ways: as a mandatory request for media security, or as a merely opportunistic request for media security 🎚️. As any verification service that receives an Identity header field in a SIP request with an unrecognized PASSporT type will simply ignore that Identity header, an authentication service will know whether or not the terminating side supports "msec" based on whether or not its UA receives a signed request in the backwards direction per Section 4.3. If no such requests are received, the UA may do one of two things: shut down the dialog, if the policy of the UA requires that "msec" be supported by the terminating side for this dialog; or, if policy permits (e.g., an explicit acceptance by the user), allow the dialog to continue without media security 🤷‍♀️.

5. Media Security Protocols 🛡️

As there are several ways to negotiate media security with SDP, any of which might be used with either opportunistic or comprehensive protection, implementers need further guidance 🧠. In [RFC8643], the opportunistic approaches considered include DTLS-SRTP, security descriptions [RFC4568], and ZRTP [RFC6189].

Support for DTLS-SRTP is REQUIRED by this specification 📣.

The "mky" claim of PASSporT provides integrity protection for "a=fingerprint" attributes in SDP, including cases where multiple "a=fingerprint" attributes appear in the same SDP 🔏.

6. Relayed Media and Conferencing 🎙️

Providing end-to-end media confidentiality for SIP is complicated by the presence of many forms of media relays 🌀. While many media relays merely proxy media to a destination, others present themselves as media endpoints and terminate security associations before re-originating media to its destination.

Centralized conference bridges are one type of entity that typically terminates a media session in order to mux media from multiple sources, and then re-originates the muxed media to conference participants 🎶. In many such implementations, only hop-by-hop media confidentiality is possible. Work is ongoing to specify a means to encrypt both (1) the hop-by-hop media between a UA and a centralized server and (2) the end-to-end media between UAs, but it isn't mature enough to become a best practice yet 🥹. Those protocols are expected to identify their own best-practice recommendations as they mature 🌱.

Another class of entities that might relay SIP media are Back-to-Back User Agents (B2BUAs) 🔁. If a B2BUA follows the guidance in [RFC7879], it may be possible for B2BUAs to act as media relays while still permitting end-to-end confidentiality between UAs 💜.

Ultimately, if an endpoint can decrypt media it receives, then that endpoint can forward the decrypted media without the knowledge or consent of the media's originator 😬. No media confidentiality mechanism can protect against these sorts of relayed disclosures, or against a legitimate endpoint that can legitimately decrypt media and record a copy to be sent elsewhere (see [RFC7245]) 🫠.

7. ICE and Connected Identity ✨

okay so bestie, confidentiality for media only works if you get the timing right 🕰️💖 You have to know when media can start flowing and when the UI is allowed to flash that little lock 🔒 saying everything is safe.

To get the most direct end-to-end connection between UAs and avoid media relays as much as possible, implementations of this specification MUST support ICE [RFC8445] [RFC8839]. To speed up call setup, it is RECOMMENDED that implementations support Trickle ICE [RFC8838] [RFC8840] ⚡🌸

Now the plot twist 🙈 In the comprehensive protection case, using connected identity [RFC4916] together with ICE means the answer carrying the key fingerprints (and therefore the STIR signature) arrives in an UPDATE sent in the backwards direction, plus a provisional response and a PRACK, instead of in any earlier SDP body. The media keys only count as exchanged once that UPDATE shows up 🔑✨ Not before, no matter how eager everyone is 💅

Also, the denial-of-service attack in Section 19.5.1 of [RFC8445] is a whole thing 😭 This spec bakes in best practices so that recipients of media flows have actually consented to receiving them, which prevents the attack or at least makes it way less of a problem 🛡️ Implementations of this specification MUST implement the Session Traversal Utilities for NAT (STUN) usage for consent freshness defined in [RFC7675] 🫶

8. Best Current Practices 💅

Here's the cheat sheet for SIP UAs that want media confidentiality for their SIP sessions 📝🎀

• Implementations MUST support the SIPBRANDY profile as defined in Section 4 and signal such support in PASSporT via the "msec" header element. 🌈
• Implementations MUST follow the authorization decision behavior described in Section 4.4. 👑
• Implementations MUST support DTLS-SRTP for management of keys, as described in Section 5. 🔐
• Implementations MUST support ICE and the STUN consent freshness mechanism, as specified in Section 7. 🦋

9. IANA Considerations 🍓

This specification adds a brand new value to the "Personal Assertion Token (PASSporT) Extensions" registry, and it's called "msec" ✨ IANA has already added the entry to the registry, and it points right back to this document 📌

10. Security Considerations 🚨

Serious moment, bestie 🥺 This document describes the security features that provide media sessions established with SIP with confidentiality, integrity, and authentication. Like, this is the whole point of the spec, so please give it your full attention 💜🔥

11. References 📚

11.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
           A., Peterson, J., Sparks, R., Handley, M., and E.
           Schooler, "SIP: Session Initiation Protocol", RFC 3261,
           DOI 10.17487/RFC3261, June 2002,
           <https://www.rfc-editor.org/info/rfc3261>.

[RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
           with Session Description Protocol (SDP)", RFC 3264,
           DOI 10.17487/RFC3264, June 2002,
           <https://www.rfc-editor.org/info/rfc3264>.

[RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
           Initiation Protocol (SIP)", RFC 3323,
           DOI 10.17487/RFC3323, November 2002,
           <https://www.rfc-editor.org/info/rfc3323>.

[RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
           Jacobson, "RTP: A Transport Protocol for Real-Time
           Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
           July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
           Norrman, "The Secure Real-time Transport Protocol (SRTP)",
           RFC 3711, DOI 10.17487/RFC3711, March 2004,
           <https://www.rfc-editor.org/info/rfc3711>.

[RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
           Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
           July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
           Description Protocol (SDP) Security Descriptions for Media
           Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
           <https://www.rfc-editor.org/info/rfc4568>.

[RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
           Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
           2007, <https://www.rfc-editor.org/info/rfc4916>.

[RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
           for Establishing a Secure Real-time Transport Protocol
           (SRTP) Security Context Using Datagram Transport Layer
           Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
           2010, <https://www.rfc-editor.org/info/rfc5763>.

[RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
           Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
           2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7675]  Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
           Thomson, "Session Traversal Utilities for NAT (STUN) Usage
           for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
           October 2015, <https://www.rfc-editor.org/info/rfc7675>.

[RFC7879]  Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V.,
           and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back
           User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016,
           <https://www.rfc-editor.org/info/rfc7879>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8224]  Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
           "Authenticated Identity Management in the Session
           Initiation Protocol (SIP)", RFC 8224,
           DOI 10.17487/RFC8224, February 2018,
           <https://www.rfc-editor.org/info/rfc8224>.

[RFC8225]  Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
           Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
           <https://www.rfc-editor.org/info/rfc8225>.

[RFC8226]  Peterson, J. and S. Turner, "Secure Telephone Identity
           Credentials: Certificates", RFC 8226,
           DOI 10.17487/RFC8226, February 2018,
           <https://www.rfc-editor.org/info/rfc8226>.

[RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
           Connectivity Establishment (ICE): A Protocol for Network
           Address Translator (NAT) Traversal", RFC 8445,
           DOI 10.17487/RFC8445, July 2018,
           <https://www.rfc-editor.org/info/rfc8445>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

[RFC8838]  Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
           Incremental Provisioning of Candidates for the Interactive
           Connectivity Establishment (ICE) Protocol", RFC 8838,
           DOI 10.17487/RFC8838, January 2021,
           <https://www.rfc-editor.org/info/rfc8838>.

[RFC8839]  Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
           A., and R. Shpount, "Session Description Protocol (SDP)
           Offer/Answer Procedures for Interactive Connectivity
           Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
           January 2021, <https://www.rfc-editor.org/info/rfc8839>.

[RFC8840]  Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
           Session Initiation Protocol (SIP) Usage for Incremental
           Provisioning of Candidates for the Interactive
           Connectivity Establishment (Trickle ICE)", RFC 8840,
           DOI 10.17487/RFC8840, January 2021,
           <https://www.rfc-editor.org/info/rfc8840>.

11.2. Informative References

[ACME-Auth-Token]
           Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
           Challenges Using an Authority Token", Work in Progress,
           Internet-Draft, draft-ietf-acme-authority-token-05, 9
           March 2020, <https://tools.ietf.org/html/draft-ietf-acme-
           authority-token-05>.

[Best-Effort-SRTP]
           Kaplan, H. and F. Audet, "Session Description Protocol
           (SDP) Offer/Answer Negotiation For Best-Effort Secure
           Real-Time Transport Protocol", Work in Progress, Internet-
           Draft, draft-kaplan-mmusic-best-effort-srtp-01, 25 October
           2006, <https://tools.ietf.org/html/draft-kaplan-mmusic-
           best-effort-srtp-01>.

[RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
           Authenticated Identity Management in the Session
           Initiation Protocol (SIP)", RFC 4474,
           DOI 10.17487/RFC4474, August 2006,
           <https://www.rfc-editor.org/info/rfc4474>.

[RFC6189]  Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
           Media Path Key Agreement for Unicast Secure RTP",
           RFC 6189, DOI 10.17487/RFC6189, April 2011,
           <https://www.rfc-editor.org/info/rfc6189>.

[RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
           Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
           <https://www.rfc-editor.org/info/rfc6962>.

[RFC7245]  Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
           "An Architecture for Media Recording Using the Session
           Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May
           2014, <https://www.rfc-editor.org/info/rfc7245>.

[RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
           Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
           December 2014, <https://www.rfc-editor.org/info/rfc7435>.

[RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
           Digest Access Authentication", RFC 7616,
           DOI 10.17487/RFC7616, September 2015,
           <https://www.rfc-editor.org/info/rfc7616>.

[RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
           Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
           Message Specification", RFC 8551, DOI 10.17487/RFC8551,
           April 2019, <https://www.rfc-editor.org/info/rfc8551>.

[RFC8643]  Johnston, A., Aboba, B., Hutton, A., Jesske, R., and T.
           Stach, "An Opportunistic Approach for Secure Real-time
           Transport Protocol (OSRTP)", RFC 8643,
           DOI 10.17487/RFC8643, August 2019,
           <https://www.rfc-editor.org/info/rfc8643>.

Acknowledgements 🫶

Huge thank-yous to Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell for their contributions to this problem statement and framework 💕 Also a big shoutout to Liang Xia and Alissa Cooper for their careful review 🌟

Authors' Addresses 🦋

Jon Peterson
Neustar, Inc.

Email: jon.peterson@team.neustar


Richard Barnes
Cisco

Email: rlb@ipv.sx


Russ Housley
Vigil Security, LLC

Email: housley@vigilsec.com