doc: Add RFC documents

1 files changed, 679 insertions, 0 deletions

diff --git a/doc/rfc/rfc8862.txt b/doc/rfc/rfc8862.txt
new file mode 100644
index 0000000..2da7d15
--- /dev/null
+++ b/doc/rfc/rfc8862.txt
@@ -0,0 +1,679 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                       J. Peterson
+Request for Comments: 8862                                       Neustar
+BCP: 228                                                       R. Barnes
+Category: Best Current Practice                                    Cisco
+ISSN: 2070-1721                                               R. Housley
+                                                          Vigil Security
+                                                            January 2021
+
+
+        Best Practices for Securing RTP Media Signaled with SIP
+
+Abstract
+
+   Although the Session Initiation Protocol (SIP) includes a suite of
+   security services that has been expanded by numerous specifications
+   over the years, there is no single place that explains how to use SIP
+   to establish confidential media sessions.  Additionally, existing
+   mechanisms have some feature gaps that need to be identified and
+   resolved in order for them to address the pervasive monitoring threat
+   model.  This specification describes best practices for negotiating
+   confidential media with SIP, including a comprehensive protection
+   solution that binds 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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+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
+
+   The Session Initiation Protocol (SIP) [RFC3261] includes a suite of
+   security services, including Digest Authentication [RFC7616] for
+   authenticating entities with a shared secret, TLS [RFC8446] for
+   transport security, and (optionally) S/MIME [RFC8551] for body
+   security.  SIP is frequently used to establish media sessions -- in
+   particular, audio or audiovisual sessions, which have their own
+   security mechanisms available, such as the Secure Real-time Transport
+   Protocol (SRTP) [RFC3711].  However, the practices needed to bind
+   security at the media layer to security at the SIP layer, to provide
+   an assurance that protection is in place all the way up the stack,
+   rely on a great many external security mechanisms and practices.
+   This document provides documentation to explain their optimal use as
+   a best practice.
+
+   Revelations about widespread pervasive monitoring of the Internet
+   have led to a greater desire to protect Internet communications
+   [RFC7258].  In order to maximize the use of security features,
+   especially of media confidentiality, opportunistic measures serve as
+   a stopgap when a full suite of services cannot be negotiated all the
+   way up the stack.  Opportunistic media security for SIP is described
+   in [RFC8643], which builds on the prior efforts of
+   [Best-Effort-SRTP].  With opportunistic encryption, there is an
+   attempt to negotiate the use of encryption, but if the negotiation
+   fails, then cleartext is used.  Opportunistic encryption approaches
+   typically have no integrity protection for the keying material.
+
+   This document contains the SIP Best-practice Recommendations Against
+   Network Dangers to privacY (SIPBRANDY) profile of Secure Telephone
+   Identity Revisited (STIR) [RFC8224] for media confidentiality,
+   providing a comprehensive security solution for SIP media that
+   includes integrity protection for keying material and offers
+   application-layer assurance that media confidentiality is in place.
+   Various specifications that User Agents (UAs) must implement to
+   support media confidentiality are given in the sections below; a
+   summary of the best current practices appears in Section 8.
+
+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 approaches to providing confidentiality for media
+   sessions set up with SIP: comprehensive protection and opportunistic
+   security (as defined in [RFC7435]).  This document only addresses
+   comprehensive protection.
+
+   Comprehensive protection for media sessions established by SIP
+   requires the interaction of three protocols: the Session Initiation
+   Protocol (SIP) [RFC3261], the Session Description Protocol (SDP)
+   [RFC4566], and the Real-time Transport Protocol (RTP) [RFC3550] --
+   in particular, its secure profile SRTP [RFC3711].  Broadly, it is the
+   responsibility of SIP to provide integrity protection for the media
+   keying attributes conveyed by SDP, and those attributes will in turn
+   identify the keys used by endpoints in the RTP media session(s) that
+   SDP negotiates.
+
+   Note that this framework does not apply to keys that also require
+   confidentiality protection in the signaling layer, such as the SDP
+   "k=" line, which MUST NOT be used in conjunction with this profile.
+
+   In that way, once SIP and SDP have exchanged the necessary
+   information to initiate a session, media endpoints will have a strong
+   assurance that the keys they exchange have not been tampered with by
+   third parties and that end-to-end confidentiality is available.
+
+   To establish the identity of the endpoints of a SIP session, this
+   specification uses STIR [RFC8224].  The STIR Identity header has been
+   designed to prevent a class of impersonation attacks that are
+   commonly used in robocalling, voicemail hacking, and related threats.
+   STIR generates a signature over certain features of SIP requests,
+   including header field values that contain an identity for the
+   originator of the request, such as the From header field or
+   P-Asserted-Identity field, and also over the media keys in SDP if
+   they are present.  As currently defined, STIR provides a signature
+   over the "a=fingerprint" attribute, which is a fingerprint of the key
+   used by DTLS-SRTP [RFC5763]; consequently, STIR only offers
+   comprehensive protection for SIP sessions in concert with SDP and
+   SRTP when DTLS-SRTP is the media security service.  The underlying
+   Personal Assertion Token (PASSporT) object [RFC8225] used by STIR is
+   extensible, however, and it would be possible to provide signatures
+   over other SDP attributes that contain alternate keying material.  A
+   profile for using STIR to provide media confidentiality is given in
+   Section 4.
+
+4.  STIR Profile for Endpoint Authentication and Verification Services
+
+   STIR [RFC8224] defines the Identity header field for SIP, which
+   provides a cryptographic attestation of the source of communications.
+   This document includes a profile of STIR, called the SIPBRANDY
+   profile, where the STIR verification service will act in concert with
+   an SRTP media endpoint to ensure that the key fingerprints, as given
+   in SDP, match the keys exchanged to establish DTLS-SRTP.  To satisfy
+   this condition, the verification service function would in this case
+   be implemented in the SIP User Agent Server (UAS), which would be
+   composed with the media endpoint.  If the STIR authentication service
+   or verification service functions are implemented at an intermediary
+   rather than an endpoint, this introduces the possibility that the
+   intermediary could act as a man in the middle, altering key
+   fingerprints.  As this attack is not in STIR's core threat model,
+   which focuses on impersonation rather than man-in-the-middle attacks,
+   STIR offers no specific protections against such interference.
+
+   The SIPBRANDY profile for media confidentiality thus shifts these
+   responsibilities to the endpoints rather than the intermediaries.
+   While intermediaries MAY provide the verification service function of
+   STIR for SIPBRANDY transactions, the verification needs to be
+   repeated at the endpoint to obtain end-to-end assurance.
+   Intermediaries supporting this specification MUST NOT block or
+   otherwise redirect calls if they do not trust the signing credential.
+   The SIPBRANDY profile is based on an end-to-end trust model, so it is
+   up to the endpoints to determine if they support signing credentials,
+   not intermediaries.
+
+   In order 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 to 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
+
+   In order to implement the authentication service function in the UA,
+   SIP endpoints will need to acquire the credentials needed to sign for
+   their own identity.  That identity is typically carried in the From
+   header field of a SIP request and contains either a greenfield SIP
+   URI (e.g., "sip:alice@example.com") or a telephone number (which can
+   appear in a variety of ways, e.g.,
+   "sip:+17004561212@example.com;user=phone").  Section 8 of [RFC8224]
+   contains guidance for separating the two and determining what sort of
+   credential is needed to sign for each.
+
+   To date, few commercial certification authorities (CAs) issue
+   certificates for SIP URIs or telephone numbers; though work is
+   ongoing on systems for this purpose (such as [ACME-Auth-Token]), it
+   is not yet mature enough to be recommended as a best practice.  This
+   is one reason why STIR permits intermediaries to act as an
+   authentication service on behalf of an entire domain, just as in SIP
+   a proxy server can provide domain-level SIP service.  While CAs that
+   offer proof-of-possession certificates similar to those used for
+   email could be offered for SIP -- for either greenfield identifiers
+   or telephone numbers -- this specification does not require their
+   use.
+
+   For users who do not possess such certificates, DTLS-SRTP [RFC5763]
+   permits the use of self-signed public keys.  The profile of STIR in
+   this document, called the SIPBRANDY profile, employs the more relaxed
+   authority requirements of [RFC8224] to allow the use of self-signed
+   public keys for authentication services that are composed with UAs,
+   by generating a certificate (per the guidance in [RFC8226]) with a
+   subject corresponding to the user's identity.  To obtain
+   comprehensive protection with a self-signed certificate, some out-of-
+   band verification is needed as well.  Such a credential could be used
+   for trust on first use (see [RFC7435]) by relying parties.  Note that
+   relying parties SHOULD NOT use certificate revocation mechanisms or
+   real-time certificate verification systems for self-signed
+   certificates, as they will not increase confidence in the
+   certificate.
+
+   Users who wish to remain anonymous can instead generate self-signed
+   certificates as described in Section 4.2.
+
+   Generally speaking, without access to out-of-band information about
+   which certificates were issued to whom, it will be very difficult for
+   relying parties to ascertain whether or not the signer of a SIP
+   request is genuinely an "endpoint".  Even the term "endpoint" is a
+   problematic one, as SIP UAs can be composed in a variety of
+   architectures and may not be devices under direct user control.
+   While it is possible that techniques based on certificate
+   transparency [RFC6962] or similar practices could help UAs to
+   recognize one another's certificates, those operational 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 such
+   as "anonymous@anonymous.invalid" in the identity fields of a SIP
+   request.  [RFC8224] does not currently permit authentication services
+   to sign for requests that supply this identity.  It does, however,
+   permit signing for valid domains, such as "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.
+
+   Note that 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.  When a
+   session is established, therefore, any SDP body carried by a
+   200-class response in the backwards direction will not be protected
+   by an authentication service and cannot be verified.  Thus, sending a
+   secured SDP body in the backwards direction will require 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 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] grants STIR verification services a great deal of latitude
+   when making authorization decisions based on the presence of the
+   Identity header field.  It is 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, further guidance to implementers is needed.  In
+   [RFC8643], 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 to re-originate 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 is not
+   sufficiently mature at this time to become a best practice.  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
+
+   Providing confidentiality for media with comprehensive protection
+   requires careful timing of when media streams should be sent and when
+   a user interface should signify that confidentiality is in place.
+
+   In order to best enable end-to-end connectivity between UAs and to
+   avoid media relays as much as possible, implementations of this
+   specification MUST support ICE [RFC8445] [RFC8839].  To speed up call
+   establishment, it is RECOMMENDED that implementations support Trickle
+   ICE [RFC8838] [RFC8840].
+
+   Note that in the comprehensive protection case, the use of connected
+   identity [RFC4916] with ICE implies that the answer containing the
+   key fingerprints, and thus the STIR signature, will come in an UPDATE
+   sent in the backwards direction, a provisional response, and a PRACK,
+   rather than in any earlier SDP body.  Only at such a time as that
+   UPDATE is received will the media keys be considered exchanged in
+   this case.
+
+   Similarly, in order to prevent, or at least mitigate, the denial-of-
+   service attack described in Section 19.5.1 of [RFC8445], this
+   specification incorporates best practices for ensuring that
+   recipients of media flows have consented to receive such flows.
+   Implementations of this specification MUST implement the Session
+   Traversal Utilities for NAT (STUN) usage for consent freshness
+   defined in [RFC7675].
+
+8.  Best Current Practices
+
+   The following are the best practices for SIP UAs to provide media
+   confidentiality for 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 defines a new value for the "Personal Assertion
+   Token (PASSporT) Extensions" registry called "msec".  IANA has added
+   the entry to the registry with a value pointing to this document.
+
+10.  Security Considerations
+
+   This document describes the security features that provide media
+   sessions established with SIP with confidentiality, integrity, and
+   authentication.
+
+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
+
+   We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell
+   for contributions to this problem statement and framework.  We thank
+   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