<?xml version="1.0" encoding="US-ASCII"?>
<!--
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
-->
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY I-D.ietf-sipbrandy-osrtp SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-sipbrandy-osrtp.xml">
<!ENTITY I-D.kaplan-mmusic-best-effort-srtp SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kaplan-mmusic-best-effort-srtp.xml">
<!ENTITY I-D.ietf-acme-authority-token SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-acme-authority-token.xml">
<!ENTITY I-D.ietf-mmusic-trickle-ice-sip SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-trickle-ice-sip.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7258 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY RFC3261 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3323 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3323.xml">
<!ENTITY RFC3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY RFC3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC4474 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY RFC4568 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4568.xml">
<!ENTITY RFC4566 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!-- <!ENTITY RFC5124 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"> -->
<!ENTITY RFC5763 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml">
<!ENTITY RFC6189 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6189.xml">
<!ENTITY RFC7245 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7245.xml">
<!ENTITY RFC7435 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml">
<!ENTITY RFC7675 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7675.xml">
<!ENTITY RFC7879 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7879.xml">
<!ENTITY RFC6962 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6962.xml">
<!ENTITY RFC4916 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4916.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8224 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml">
<!ENTITY RFC8225 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml">
<!ENTITY RFC8226 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8226.xml">
<!ENTITY RFC8445 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
<!ENTITY RFC8446 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
]>
<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<!--?rfc strict="yes" ?-->
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc category="bcp" xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     docName="draft-ietf-sipbrandy-rtpsec-08"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" --> number="8862" submissionType="IETF" category="bcp" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
  <!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 2.35.0 -->
  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->
    <title abbrev="RTP Security">Best Practices for Securing RTP Media Signaled with SIP</title>
    <seriesInfo name="RFC" value="8862"/>
    <seriesInfo name="BCP" value="228"/>
    <author initials="J." surname="Peterson" fullname="Jon Peterson">
      <organization abbrev="Neustar">Neustar, Inc.</organization>
      <address>
        <email>jon.peterson@team.neustar</email>
      </address>
    </author>
    <author fullname="Richard Barnes" initials="R." surname="Barnes">
      <organization>Cisco</organization>
      <address>
        <email>rlb@ipv.sx</email>
      </address>
    </author>
    <author fullname="Russ Housley" initials="R." surname="Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date year="2019" month="04" day="25" />

    <!-- <area>ART</area> --> year="2021" month="January"/>

    <keyword>SIP</keyword>
    <keyword>RTP</keyword>
    <keyword>security</keyword>

    <abstract>
      <t>
          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.
      </t>
    </abstract>
  </front>

  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
        The <xref target="RFC3261">Session target="RFC3261" format="default">Session Initiation
        Protocol (SIP)</xref> includes a suite of security services, including
        Digest authentication, Authentication <xref target="RFC7616"/> for authenticating
        entities with a shared secret, TLS <xref target="RFC8446"/> for
        transport security, and S/MIME (optionally) S/MIME <xref target="RFC8551"/>
        for body security. SIP is frequently used to establish media sessions, sessions -- in particular
        particular, audio or audiovisual sessions, which have their own
        security mechanisms available, such as <xref target="RFC3711">Secure RTP</xref>. target="RFC3711"
        format="default">the Secure Real-time Transport Protocol (SRTP)</xref>. 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.
	</t><t>
      </t>
      <t>
        Revelations about widespread pervasive monitoring of the Internet have led to a greater desire to protect Internet communications <xref target="RFC7258"/>. target="RFC7258" format="default"/>. 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 <xref target="I-D.ietf-sipbrandy-osrtp"/>, target="RFC8643" format="default"/>, which builds on the prior efforts of <xref target="I-D.kaplan-mmusic-best-effort-srtp"/>. target="I-D.kaplan-mmusic-best-effort-srtp" format="default"/>. 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.
	</t><t>
      </t>
      <t>
        This document contains the SIPBRANDY SIP Best-practice Recommendations Against
        Network Dangers to privacY (SIPBRANDY) profile of STIR Secure Telephone
 Identity Revisited (STIR) <xref target="RFC8224"/> target="RFC8224" format="default"/> 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 User Agents (UAs) must implement to support media
 confidentiality are given in the sections below; a summary of the best
 current practices appears in <xref target="bcp"/>. target="bcp" format="default"/>.
      </t>
    </section>
    <section anchor="sec-2" title="Terminology">
      <t>
      The numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
      "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
      "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
      "<bcp14>SHOULD NOT</bcp14>",
      "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
      "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
      to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
      <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.
      </t> here.</t>

    </section>
    <section title="Security numbered="true" toc="default">
      <name>Security at the SIP and SDP layer"> Layer</name>
      <t>
        There are two approaches to providing confidentiality for media sessions set up with SIP: comprehensive protection and opportunistic security (as defined in <xref target="RFC7435"/>). target="RFC7435" format="default"/>). This document only addresses comprehensive protection.
	</t><t>
      </t>
      <t>
        Comprehensive protection for media sessions established by SIP
        requires the interaction of three protocols: the <xref target="RFC3261">Session target="RFC3261"
        format="default">Session Initiation
   Protocol (SIP)</xref>, the <xref target="RFC4566">Session target="RFC4566"
        format="default">Session Description Protocol (SDP)</xref>, and the
        <xref target="RFC3550">Real-time target="RFC3550" format="default">Real-time Transport Protocol (RTP)</xref>, in particular
        (RTP)</xref> -- in&nbsp;particular, its secure profile <xref target="RFC3711">Secure RTP (SRTP)</xref>.
        target="RFC3711" format="default">SRTP</xref>. 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.
    </t><t>
      </t>
      <t>
        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 <bcp14>MUST NOT</bcp14> be used in conjunction with this profile.
    </t><t>
      </t>
      <t>
        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, parties and that end-to-end confidentiality is available.
	</t><t>
      </t>
      <t>
        To establishing establish the identity of the endpoints of a SIP session, this
        specification uses <xref target="RFC8224">STIR</xref>. target="RFC8224"
        format="default">STIR</xref>. 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 P&nbhy;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 <xref target="RFC5763">DTLS-SRTP</xref>;
        target="RFC5763" format="default">DTLS-SRTP</xref>; 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 <xref target="RFC8225">PASSporT</xref> object target="RFC8225" format="default">Personal Assertion
   Token (PASSporT) object</xref> 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 <xref target="stirprof"/>. target="stirprof" format="default"/>.
      </t>
    </section>
    <section anchor="stirprof" title="STIR numbered="true" toc="default">
      <name>STIR Profile for Endpoint Authentication and Verification Services"> Services</name>
      <t>
        <xref target="RFC8224">STIR</xref> target="RFC8224" format="default">STIR</xref> 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.
	</t><t>
      </t>
      <t>
        The SIPBRANDY profile for media confidentiality thus shifts these responsibilities to the endpoints rather than the intermediaries. While intermediaries MAY <bcp14>MAY</bcp14> 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 <bcp14>MUST NOT</bcp14> 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.
	</t><t>
      </t>
      <t>
        In order to be compliant with best practices for SIP media confidentiality with comprehensive protection, user agent UA implementations MUST <bcp14>MUST</bcp14> implement both the authentication service and verification service roles described in <xref target="RFC8224"/>. target="RFC8224" format="default"/>. STIR authentication services MUST <bcp14>MUST</bcp14> signal their compliance with this specification by including the "msec" claim defined in this specification to the PASSporT payload. Implementations MUST <bcp14>MUST</bcp14> provide key fingerprints in SDP and the appropriate signatures over them as specified in <xref target="RFC8225"/>.
	</t><t> target="RFC8225" format="default"/>.
      </t>
      <t>
        When generating either an offer or an answer <xref target="RFC3264"/>, target="RFC3264" format="default"/>, compliant implementations MUST <bcp14>MUST</bcp14> include an "a=fingerprint" attribute containing the fingerprint of an appropriate key (see <xref target="stircred"/>). target="stircred" format="default"/>).
      </t>
      <section anchor="stircred" title="Credentials"> numbered="true" toc="default">
        <name>Credentials</name>
        <t>
        In order to implement the authentication service function in the user agent, 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, request and either contains either a greenfield
        SIP URI (e.g. (e.g., "sip:alice@example.com") or a telephone number, which number (which
        can appear in a variety of ways (e.g. ways, e.g., "sip:+17004561212@example.com;user=phone"). Section 8 of <xref target="RFC8224"/> target="RFC8224" sectionFormat="of" section="8"/> contains guidance for separating the two, two and determining what sort of credential is needed to sign for each.
	</t><t>
        </t>
        <t>
        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 <xref target="I-D.ietf-acme-authority-token"/>)
        target="I-D.ietf-acme-authority-token" format="default"/>), 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, either SIP -- for either greenfield identifiers or for telephone numbers,
        numbers -- this specification does not require their use.
	</t><t>
        </t>
        <t>
        For users who do not possess such certificates, <xref target="RFC5763">DTLS-SRTP</xref> target="RFC5763"
        format="default">DTLS-SRTP</xref> permits the use of self-signed
        public keys. This The profile of STIR in this document, called the
        SIPBRANDY profile, employs the more relaxed authority
        requirements of <xref target="RFC8224"/> target="RFC8224" format="default"/> to allow the
        use of self-signed public keys for authentication services that are
        composed with user agents, UAs, by generating a certificate (per the
        guidance in <xref target="RFC8226"/>) target="RFC8226" format="default"/>) 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 <xref target="RFC7435"/>) target="RFC7435" format="default"/>) by relying parties. Note that relying parties SHOULD NOT <bcp14>SHOULD NOT</bcp14> use certificate revocation mechanisms or real-time certificate verification systems for self-signed certificates certificates, as they will not increase confidence in the certificate.
	</t><t>
        </t>
        <t>
        Users who wish to remain anonymous can instead generate self-signed certificates as described in <xref target="anon"/>.
	</t><t> target="anon" format="default"/>.
        </t>
        <t>
        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." "endpoint". Even the term "endpoint" is a problematic one, as SIP user agents 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 <xref target="RFC6962"/> target="RFC6962" format="default"/> or similar practices could help user agents UAs to recognize one another's certificates, those operational systems will need to ramp up with the CAs that issue credentials to end user end-user devices going forward.
        </t>
      </section>
      <section anchor="anon" title="Anonymous Communications"> numbered="true" toc="default">
        <name>Anonymous Communications</name>
        <t>
        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 <xref target="RFC3323"/>, target="RFC3323" format="default"/>, this may involve using an identity such as "anonymous@anonymous.invalid" in the identity fields of a SIP request. <xref target="RFC8224"/> target="RFC8224" format="default"/> does not currently permit authentication services to sign for requests that supply this identity. It does however does, however, permit signing for valid domains, such as "anonymous@example.com," "anonymous@example.com", as a way of implementation implementing an anonymization service as specified in <xref target="RFC3323"/>.
	</t><t> target="RFC3323" format="default"/>.
        </t>
        <t>
        Even for anonymous sessions, providing media confidentiality and
        partial SDP integrity is still desirable. This specification RECOMMENDS using one-time One-time self-signed
        certificates for anonymous communications, with communications <bcp14>SHOULD</bcp14>
        include a subjectAltName of "sip:anonymous@anonymous.invalid".
 After a session is terminated, the
        certificate SHOULD <bcp14>SHOULD</bcp14> be discarded, and a new one, with
        fresh keying material, SHOULD <bcp14>SHOULD</bcp14> be generated before each
        future anonymous call. As with self-signed certificates, relying
        parties SHOULD NOT <bcp14>SHOULD NOT</bcp14> use certificate revocation
        mechanisms or real-time certificate verification systems for anonymous certificates
        certificates, as they will not increase confidence in the
        certificate.
	</t><t>
        </t>
        <t>
        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 "mkey" "mky"
        parameters of PASSporT and any "a=fingerprint" attributes in SDP as it
        chooses. This signature only provides protection against non-Identity aware non&nbhy;Identity-aware entities that might modify SDP without altering the PASSporT conveyed in the Identity header.
        </t>
      </section>
      <section anchor="stirconnect" title="Connected numbered="true" toc="default">
        <name>Connected Identity Usage"> Usage</name>
        <t>
        <xref target="RFC8224">STIR</xref> target="RFC8224" format="default">STIR</xref> provides integrity
        protection for the fingerprint attributes in SIP request bodies, bodies but
        not SIP responses. When a session is established, therefore, any SDP body carried by a 200 class 200&nbhy;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.
	</t><t>
	The
        </t>
        <t>
        <xref target="RFC4916"/> explored the problem of providing "Connected Identity" in "connected
        identity" to implementations of <xref target="RFC4474"/>, which target="RFC4474"
        format="default"/> (which is obsoleted by STIR, was explored in <xref target="RFC4916"/>, which target="RFC8224"/>);
        <xref target="RFC4916" format="default"/> 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 that specification <xref target="RFC4916"/> are largely compatible with the
        revision of the Identity header in STIR <xref target="RFC8224"/>.
        However, the following need to be considered:
	<list>
	<t>
        </t>
        <ul spacing="normal">
          <li>
        The UPDATE carrying signed SDP with a fingerprint in the backwards
        direction needs to be sent during dialog establishment, following the
        receipt of a PRACK Provisional Response Acknowledgement (PRACK) after a provisional 1xx response.
	</t><t>
        </li>
          <li>
        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.
	</t><t>
	The
        </li>
          <li>
        Per the text in Section 4.4.1 of <xref target="RFC4916"/> target="RFC4916" sectionFormat="of"
        section="4.4.1"/> regarding the receipt at a UAC User Agent Client (UAC)
	of error codes code 428, 436, 437 and 437, or 438 in response to a mid-dialog request RECOMMENDS treating
	request, it is <bcp14>RECOMMENDED</bcp14> that the dialog be treated as terminated. However, Section 6.1.1 of <xref target="RFC8224"/> target="RFC8224" sectionFormat="of" section="6.1.1"/>
 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.
	</t><t>
        </li>
          <li>
        Note that the examples in <xref target="RFC4916"/> target="RFC4916" format="default"/>
        are based on the original <xref target="RFC4474"/>, target="RFC4474" format="default"/>
        and will not match signatures using STIR <xref target="RFC8224"/>.
	</t>
    </list>
    </t><t> target="RFC8224"
        format="default"/>.
        </li>
        </ul>
        <t>
        Future work may be done to revise <xref target="RFC4916"/> target="RFC4916"
        format="default"/> for STIR; that work should take into account any
        impacts on the SIPBRANDY profile described in this document. The use
        of <xref target="RFC4916"/> target="RFC4916" format="default"/> has some further
        interactions with ICE; Interactive Connectivity Establishment (ICE) <xref target="RFC8445"/>; see <xref target="ice"/>. target="ice" format="default"/>.
        </t>
      </section>
      <section anchor="authz" title="Authorization Decisions"> numbered="true" toc="default">
        <name>Authorization Decisions</name>
        <t>
        <xref target="RFC8224"/> target="RFC8224" format="default"/> 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.
	</t><t>
        </t>
        <t>
        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 <xref target="RFC8224"/>, MUST target="RFC8224" sectionFormat="of" section="6.2"/>, <bcp14>MUST</bcp14> reject the request if there is any failure in that validation process with the appropriate status code per Section 6.2.2. <xref target="RFC8224" sectionFormat="of" section="6.2.2"/>. If the request is valid, then if a terminating user accepts the request, it MUST <bcp14>MUST</bcp14> then follow the steps in <xref target="stirconnect"/> target="stirconnect" format="default"/> to act as an authentication service and send a signed request with the "msec" PASSPorT PASSporT type in its Identity header as well, in order to enable end-to-end end&nbhy;to-end bidirectional confidentiality.
	</t><t>
        </t>
        <t>
        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, 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 user agent UA receives a signed request in the backwards direction per
        <xref target="stirconnect"/>. target="stirconnect" format="default"/>. If no such requests are
        received, the UA may do one or 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.
        </t>
      </section>
    </section>
    <section anchor="mediasec" title="Media numbered="true" toc="default">
      <name>Media Security Protocols"> Protocols</name>
      <t>
        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 <xref target="I-D.ietf-sipbrandy-osrtp"/>, target="RFC8643" format="default"/>, opportunistic approaches considered include DTLS-SRTP, <xref target="RFC4568">security target="RFC4568" format="default">security descriptions</xref>, and <xref target="RFC6189">ZRTP</xref>.
	</t><t> target="RFC6189" format="default">ZRTP</xref>.
      </t>
      <t>
        Support for DTLS-SRTP is REQUIRED <bcp14>REQUIRED</bcp14> by this specification.
	</t><t>
      </t>
      <t>
        The "mkey" "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.
      </t>
    </section>
    <section anchor="relay" title="Relayed numbered="true" toc="default">
      <name>Relayed Media and Conferencing"> Conferencing</name>
      <t>
        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 re&nbhy;originating media to its destination.
	</t><t>
      </t>
      <t>
        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 the (1)&nbsp;the hop-by-hop media between a user agent UA and a
        centralized server as well as the and (2)&nbsp;the end-to-end media between user agents, UAs,
        but it is not sufficiently mature at this time to make a recommendation for become a best practice here. practice. Those protocols are expected to identify their own best practice best-practice recommendations as they mature.
	</t><t>
      </t>
      <t>
        Another class of entities that might relay SIP media are back-to-back user agents Back-to-Back
        User Agents (B2BUAs). If a B2BUA follows the guidance in <xref target="RFC7879"/>,
        target="RFC7879" format="default"/>, it may be possible for those devices B2BUAs
        to act as media relays while still permitting end-to-end
        confidentiality between user agents.
	</t><t> UAs.
      </t>
      <t>
        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, disclosures or trusted entities against a
        legitimate endpoint that can legitimately decrypt media and then record a copy to be sent
        elsewhere (see <xref target="RFC7245"/>). target="RFC7245" format="default"/>).
      </t>
    </section>
    <section anchor="ice" title="ICE numbered="true" toc="default">
      <name>ICE and Connected Identity"> Identity</name>
      <t>
        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.
	</t><t>
      </t>
      <t>
        In order to best enable end-to-end connectivity between user agents, UAs and to
        avoid media relays as much as possible, implementations of this
        specification MUST <bcp14>MUST</bcp14> support ICE <xref target="RFC8445"/>. target="RFC8445"
        format="default"/> <xref target="RFC8839"/>. To speed up call
        establishment, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that implementations
        support Trickle ICE <xref target="RFC8838"/> <xref target="I-D.ietf-mmusic-trickle-ice-sip">trickle ICE</xref>.
	</t><t> target="RFC8840" format="default"></xref>.
      </t>
      <t>
        Note that in the comprehensive protection case, the use of Connected Identity connected identity <xref target="RFC4916"/> target="RFC4916" format="default"/> with ICE entails 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 provisional acknowledgment (PRACK), 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.
	</t><t>
      </t>
      <t>
        Similarly, in order to prevent, or at least mitigate, the
        denial-of-service attack described in Section 19.5.1 of <xref target="RFC8445"/>, target="RFC8445"
        sectionFormat="of" section="19.5.1"/>, this specification incorporates
        best practices for ensuring that recipients of media flows have
        consented to receive such flows. Implementations of this specification MUST
        <bcp14>MUST</bcp14> implement the STUN Session Traversal Utilities for NAT (STUN) usage for consent freshness defined in <xref target="RFC7675"/>. target="RFC7675" format="default"/>.
      </t>
    </section>
    <section anchor="bcp" title="Best numbered="true" toc="default">
      <name>Best Current Practices"> Practices</name>
      <t>
        The following are the best practices for SIP user agents UAs to provide media confidentiality for SIP sessions.
	</t><t>
	Implementations MUST
      </t>
      <ul spacing="normal">
        <li>Implementations <bcp14>MUST</bcp14> support the STIR endpoint SIPBRANDY
        profile given as defined in <xref target="stirprof"/>, target="stirprof" format="default"/> and
        signal that such support in PASSporT with via the "msec" header element.
	</t><t>
	Implementations MUST
</li>
        <li>Implementations <bcp14>MUST</bcp14> follow the authorization
        decision behavior described in <xref target="authz"/>.
	</t><t>
	Implementations MUST target="authz" format="default"/>.</li>
        <li>Implementations <bcp14>MUST</bcp14> support DTLS-SRTP for key-management,
        management of keys, as described in <xref target="mediasec"/>.
	</t><t>
	Implementations MUST target="mediasec" format="default"/>.</li>
        <li>Implementations <bcp14>MUST</bcp14> support the ICE, ICE and the STUN
        consent freshness mechanism, as specified in <xref target="ice"/>.
	</t> target="ice"
        format="default"/>.</li>
      </ul>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
    This specification defines a new value for the Personal "Personal Assertion Token
    (PASSporT) Extensions Extensions" registry called "msec," and the "msec". IANA is requested to add that has added
    the entry to the registry with a value pointing to [RFCThis]. this document.
      </t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
    This document describes the security features that provide media sessions established with SIP with confidentiality, integrity, and authentication.
      </t>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-acme-authority-token" to="ACME-Auth-Token"/>
<displayreference target="I-D.kaplan-mmusic-best-effort-srtp" to="Best-Effort-SRTP"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3323.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4568.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7675.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7879.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4916.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8225.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8226.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

<!-- draft-ietf-ice-trickle (RFC 8838)  -->
<reference anchor="RFC8838" target="https://www.rfc-editor.org/info/rfc8838">
  <front>
    <title>Trickle ICE: Incremental Provisioning of Candidates for the
    Interactive Connectivity Establishment (ICE) Protocol</title>
    <author initials="E" surname="Ivov" fullname="Emil Ivov">
      <organization />
    </author>
    <author initials="J" surname="Uberti" fullname="Justin Uberti">
      <organization />
    </author>
    <author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization />
    </author>
    <date month="January" year="2021" />
  </front>
  <seriesInfo name="RFC" value="8838" />
  <seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>

<!-- draft-ietf-mmusic-ice-sip-sdp (RFC 8839) -->
<reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)</title>
<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
    <organization />
</author>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
    <organization />
</author>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
</author>
<author initials='A' surname='Keränen' fullname='Ari Keränen'>
    <organization />
</author>
<author initials='R' surname='Shpount' fullname='Roman Shpount'>
    <organization />
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
</reference>

<!-- draft-ietf-mmusic-trickle-ice-sip (RFC 8840) -->
 <reference anchor="RFC8840" target="https://www.rfc-editor.org/info/rfc8840">
   <front>
     <title>A Session Initiation Protocol (SIP) Usage for Incremental
     Provisioning of Candidates for the Interactive Connectivity
     Establishment (Trickle ICE)</title>
     <author initials="E" surname="Ivov" fullname="Emil Ivov">
       <organization/>
     </author>
     <author initials="T" surname="Stach" fullname="Thomas Stach">
       <organization/>
     </author>
     <author initials="E" surname="Marocco" fullname="Enrico Marocco">
       <organization/>
     </author>
     <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
       <organization/>
     </author>
     <date month="January" year="2021"/>
   </front>
   <seriesInfo name="RFC" value="8840"/>
   <seriesInfo name="DOI" value="10.17487/RFC8840"/>
 </reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4474.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6189.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6962.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7245.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>

<!-- draft-ietf-sipbrandy-osrtp (Published; RFC 8643) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8643.xml"/>

<!-- draft-kaplan-mmusic-best-effort-srtp (Expired)
     Correct author order is "Kaplan, H. and F. Audet".
     Last checked 1/5/2021 -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kaplan-mmusic-best-effort-srtp.xml"/>

<!-- draft-ietf-acme-authority-token (AD Eval.::Revised I-D Needed)
     Note:  Only the numbered iteration is supplied in the repository,
     so you have to check it manually (e.g., updated from "04" to "05" on
     4/15/2020).
     Last checked 1/5/2021 -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-acme-authority-token-05.xml"/>

      </references>
    </references>
    <section anchor="Acknowledgments" title="Acknowledgments"> anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
    We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell <contact fullname="Eric Rescorla"/>, <contact fullname="Adam
    Roach"/>, <contact fullname="Andrew Hutton"/>, and <contact fullname="Ben
    Campbell"/> for contributions to this problem statement and framework.  We
    thank Liang Xia and Alissa Cooper <contact fullname="Liang Xia"/> and <contact fullname="Alissa Cooper"/> for their careful review.
      </t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
&RFC2119;
&RFC7258;
&RFC3261;
&RFC3264;
&RFC3323;
&RFC3711;
&RFC4568;
&RFC4566;
<!-- &RFC5124; -->
&RFC5763;
&RFC3550;
&RFC7675;
&RFC7879;
&RFC4916;
&RFC8174;
&RFC8224;
&RFC8225;
&RFC8226;
&RFC8445;
&RFC8446;
&I-D.ietf-mmusic-trickle-ice-sip;
    </references>
    <references title="Informative References">
&RFC4474;
&RFC6189;
&RFC6962;
&RFC7245;
&RFC7435;
&I-D.ietf-sipbrandy-osrtp;
&I-D.kaplan-mmusic-best-effort-srtp;
&I-D.ietf-acme-authority-token;
    </references>
  </back>
</rfc>