rfc8862xml2.original.xml   rfc8862.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!--
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. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-sipbrandy-osrtp SYSTEM "http://xml2rfc.tools.ietf.org/public/r
fc/bibxml3/reference.I-D.ietf-sipbrandy-osrtp.xml">
<!ENTITY I-D.kaplan-mmusic-best-effort-srtp SYSTEM "http://xml2rfc.tools.ietf.or
g/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/pub
lic/rfc/bibxml3/reference.I-D.ietf-acme-authority-token.xml">
<!ENTITY I-D.ietf-mmusic-trickle-ice-sip SYSTEM "http://xml2rfc.tools.ietf.org/p
ublic/rfc/bibxml3/reference.I-D.ietf-mmusic-trickle-ice-sip.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2119.xml">
<!ENTITY RFC7258 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7258.xml">
<!ENTITY RFC3261 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3261.xml">
<!ENTITY RFC3323 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3323.xml">
<!ENTITY RFC3264 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3264.xml">
<!ENTITY RFC3550 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3550.xml">
<!ENTITY RFC3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3711.xml">
<!ENTITY RFC4474 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4474.xml">
<!ENTITY RFC4568 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4568.xml">
<!ENTITY RFC4566 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4566.xml">
<!-- <!ENTITY RFC5124 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/re
ference.RFC.5124.xml"> -->
<!ENTITY RFC5763 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5763.xml">
<!ENTITY RFC6189 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6189.xml">
<!ENTITY RFC7245 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7245.xml">
<!ENTITY RFC7435 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7435.xml">
<!ENTITY RFC7675 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7675.xml">
<!ENTITY RFC7879 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7879.xml">
<!ENTITY RFC6962 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.6962.xml">
<!ENTITY RFC4916 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4916.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC8224 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8224.xml">
<!ENTITY RFC8225 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8225.xml">
<!ENTITY RFC8226 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8226.xml">
<!ENTITY RFC8445 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8445.xml">
<!ENTITY RFC8446 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.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 -->
<rfc category="bcp" 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)" -->
<!-- ***** FRONT MATTER ***** --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-sipbrandy-rtpsec-08" number="8862" submissionType="IETF
" category="bcp" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclu
de="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.35.0 -->
<front> <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> <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"> <author initials="J." surname="Peterson" fullname="Jon Peterson">
<organization abbrev="Neustar">Neustar, Inc.</organization> <organization abbrev="Neustar">Neustar, Inc.</organization>
<address> <address>
<email>jon.peterson@team.neustar</email> <email>jon.peterson@team.neustar</email>
</address> </address>
</author> </author>
<author fullname="Richard Barnes" initials="R." surname="Barnes"> <author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>rlb@ipv.sx</email> <email>rlb@ipv.sx</email>
</address> </address>
</author> </author>
<author fullname="Russ Housley" initials="R." surname="Housley"> <author fullname="Russ Housley" initials="R." surname="Housley">
<organization abbrev="Vigil Security">Vigil Security, LLC</organization> <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
<address> <address>
<email>housley@vigilsec.com</email> <email>housley@vigilsec.com</email>
</address> </address>
</author> </author>
<date year="2021" month="January"/>
<date year="2019" month="04" day="25" />
<!-- <area>ART</area> -->
<keyword>SIP</keyword> <keyword>SIP</keyword>
<keyword>RTP</keyword> <keyword>RTP</keyword>
<keyword>security</keyword> <keyword>security</keyword>
<abstract> <abstract>
<t> <t>
Although the Session Initiation Protocol (SIP) includes a suite of secu Although the Session Initiation Protocol (SIP) includes a suite of sec
rity services that has been expanded by numerous specifications over the years, urity 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 there is no single place that explains how to use SIP to establish confidential
media sessions. Additionally, existing mechanisms have some feature gaps that ne media sessions. Additionally, existing mechanisms have some feature gaps that n
ed to be identified and resolved in order for them to address the pervasive moni eed to be identified and resolved in order for them to address the pervasive mon
toring threat model. This specification describes best practices for negotiating itoring threat model. This specification describes best practices for negotiatin
confidential media with SIP, including a comprehensive protection solution that g confidential media with SIP, including a comprehensive protection solution tha
binds the media layer to SIP layer identities. t binds the media layer to SIP layer identities.
</t> </t>
</abstract> </abstract>
</front> </front>
<!-- ***** MIDDLE MATTER ***** -->
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t> <name>Introduction</name>
The <xref target="RFC3261">Session Initiation Protocol (SIP)</xref> inclu <t>
des a suite of security services, including Digest authentication, for authentic The <xref target="RFC3261" format="default">Session Initiation
ating entities with a shared secret, TLS for transport security, and S/MIME (opt Protocol (SIP)</xref> includes a suite of security services, including
ionally) for body security. SIP is frequently used to establish media sessions, Digest Authentication <xref target="RFC7616"/> for authenticating
in particular audio or audiovisual sessions, which have their own security mecha entities with a shared secret, TLS <xref target="RFC8446"/> for
nisms available, such as <xref target="RFC3711">Secure RTP</xref>. However, the transport security, and (optionally) S/MIME <xref target="RFC8551"/>
practices needed to bind security at the media layer to security at the SIP laye for body security. SIP is frequently used to establish media sessions --
r, to provide an assurance that protection is in place all the way up the stack, in
rely on a great many external security mechanisms and practices. This document particular, audio or audiovisual sessions, which have their own
provides documentation to explain their optimal use as a best practice. security mechanisms available, such as <xref target="RFC3711"
</t><t> format="default">the Secure Real-time Transport Protocol (SRTP)</xref>.
Revelations about widespread pervasive monitoring of the Internet have le However, the practices needed to bind security at the media layer to security at
d to a greater desire to protect Internet communications <xref target="RFC7258"/ the SIP layer, to provide an assurance that protection is in place all the way
>. In order to maximize the use of security features, especially of media confid up the stack, rely on a great many external security mechanisms and practices. T
entiality, opportunistic measures serve as a stopgap when a full suite of servic his document provides documentation to explain their optimal use as a best pract
es cannot be negotiated all the way up the stack. Opportunistic media security f ice.
or SIP is described in <xref target="I-D.ietf-sipbrandy-osrtp"/>, which builds o </t>
n the prior efforts of <xref target="I-D.kaplan-mmusic-best-effort-srtp"/>. With <t>
opportunistic encryption, there is an attempt to negotiate the use of encryptio Revelations about widespread pervasive monitoring of the Internet have l
n, but if the negotiation fails, then cleartext is used. Opportunistic encryptio ed to a greater desire to protect Internet communications <xref target="RFC7258"
n approaches typically have no integrity protection for the keying material. format="default"/>. In order to maximize the use of security features, especial
</t><t> ly of media confidentiality, opportunistic measures serve as a stopgap when a fu
This document contains the SIPBRANDY profile of STIR <xref target="RFC822 ll suite of services cannot be negotiated all the way up the stack. Opportunisti
4"/> for media confidentiality, providing a comprehensive security solution for c media security for SIP is described in <xref target="RFC8643" format="default"
SIP media that includes integrity protection for keying material and offers appl />, which builds on the prior efforts of <xref target="I-D.kaplan-mmusic-best-ef
ication-layer assurance that media confidentiality is place. Various specificati fort-srtp" format="default"/>. With opportunistic encryption, there is an attemp
ons that user agents must implement to support media confidentiality are given i t to negotiate the use of encryption, but if the negotiation fails, then clearte
n the sections below; a summary of the best current practices appears in <xref t xt is used. Opportunistic encryption approaches typically have no integrity prot
arget="bcp"/>. ection for the keying material.
</t> </t>
<t>
This document contains the SIP Best-practice Recommendations Against
Network Dangers to privacY (SIPBRANDY) profile of Secure Telephone
Identity Revisited (STIR) <xref 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 (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" format="default"/>.
</t>
</section> </section>
<section anchor="sec-2" numbered="true" toc="default">
<name>Terminology</name>
<t>The key words "<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 "<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>
<section anchor="sec-2" title="Terminology"> </section>
<section numbered="true" toc="default">
<name>Security at the SIP and SDP Layer</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOUL There are two approaches to providing confidentiality for media sessions
D", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in thi set up with SIP: comprehensive protection and opportunistic security (as define
s document are to be interpreted as described in BCP&nbsp;14 <xref target="RFC21 d in <xref target="RFC7435" format="default"/>). This document only addresses co
19"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, mprehensive protection.
as shown here. </t>
<t>
Comprehensive protection for media sessions established by SIP
requires the interaction of three protocols: the <xref target="RFC3261"
format="default">Session Initiation
Protocol (SIP)</xref>, the <xref target="RFC4566"
format="default">Session Description Protocol (SDP)</xref>, and the
<xref target="RFC3550" format="default">Real-time Transport Protocol
(RTP)</xref> -- in&nbsp;particular, its secure profile <xref
target="RFC3711" format="default">SRTP</xref>. Broadly, it is the respon
sibility 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 end
points in the RTP media session(s) that SDP negotiates.
</t>
<t>
Note that this framework does not apply to keys that also require confid
entiality protection in the signaling layer, such as the SDP "k=" line, which <b
cp14>MUST NOT</bcp14> be used in conjunction with this profile.
</t>
<t>
In that way, once SIP and SDP have exchanged the necessary information t
o 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.
</t>
<t>
To establish the identity of the endpoints of a SIP session, this
specification uses <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&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" 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" format="default">Personal Assertion
Token (PASSporT) object</xref> used by STIR is extensible, however, and it wo
uld be possible to provide signatures over other SDP attributes that contain alt
ernate keying material. A profile for using STIR to provide media confidentialit
y is given in <xref target="stirprof" format="default"/>.
</t> </t>
</section> </section>
<section anchor="stirprof" numbered="true" toc="default">
<section title="Security at the SIP and SDP layer"> <name>STIR Profile for Endpoint Authentication and Verification Services</
<t> name>
There are two approaches to providing confidentiality for media sessions <t>
set up with SIP: comprehensive protection and opportunistic security (as defined <xref target="RFC8224" format="default">STIR</xref> defines the Identity
in <xref target="RFC7435"/>). This document only addresses comprehensive protec header field for SIP, which provides a cryptographic attestation of the source
tion. of communications. This document includes a profile of STIR, called the SIPBRAND
</t><t> Y profile, where the STIR verification service will act in concert with an SRTP
Comprehensive protection for media sessions established by SIP requires t media endpoint to ensure that the key fingerprints, as given in SDP, match the k
he interaction of three protocols: <xref target="RFC3261">Session Initiation Pro eys exchanged to establish DTLS-SRTP. To satisfy this condition, the verificatio
tocol (SIP)</xref>, the <xref target="RFC4566">Session Description Protocol (SDP n service function would in this case be implemented in the SIP User Agent Serve
)</xref>, and the <xref target="RFC3550">Real-time Protocol (RTP)</xref>, in par r (UAS), which would be composed with the media endpoint. If the STIR authentica
ticular its secure profile <xref target="RFC3711">Secure RTP (SRTP)</xref>. Broa tion service or verification service functions are implemented at an intermediar
dly, it is the responsibility of SIP to provide integrity protection for the med y rather than an endpoint, this introduces the possibility that the intermediary
ia keying attributes conveyed by SDP, and those attributes will in turn identify could act as a man in the middle, altering key fingerprints. As this attack is
the keys used by endpoints in the RTP media session(s) that SDP negotiates. not in STIR's core threat model, which focuses on impersonation rather than man-
</t><t> in-the-middle attacks, STIR offers no specific protections against such interfer
Note that this framework does not apply to keys that also require confide ence.
ntiality protection in the signaling layer, such as the SDP "k=" line, which MUS </t>
T NOT be used in conjunction with this profile. <t>
</t><t> The SIPBRANDY profile for media confidentiality thus shifts these respon
In that way, once SIP and SDP have exchanged the necessary information to sibilities to the endpoints rather than the intermediaries. While intermediaries
initiate a session, media endpoints will have a strong assurance that the keys <bcp14>MAY</bcp14> provide the verification service function of STIR for SIPBRA
they exchange have not been tampered with by third parties, and that end-to-end NDY transactions, the verification needs to be repeated at the endpoint to obtai
confidentiality is available. n end-to-end assurance. Intermediaries supporting this specification <bcp14>MUST
</t><t> NOT</bcp14> block or otherwise redirect calls if they do not trust the signing
To establishing the identity of the endpoints of a SIP session, this spec credential. The SIPBRANDY profile is based on an end-to-end trust model, so it i
ification uses <xref target="RFC8224">STIR</xref>. The STIR Identity header has s up to the endpoints to determine if they support signing credentials, not inte
been designed to prevent a class of impersonation attacks that are commonly used rmediaries.
in robocalling, voicemail hacking, and related threats. STIR generates a signat </t>
ure over certain features of SIP requests, including header field values that co <t>
ntain an identity for the originator of the request, such as the From header fie In order to be compliant with best practices for SIP media confidentiali
ld or P-Asserted-Identity field, and also over the media keys in SDP if they are ty with comprehensive protection, UA implementations <bcp14>MUST</bcp14> impleme
present. As currently defined, STIR provides a signature over the "a=fingerprin nt both the authentication service and verification service roles described in <
t" attribute, which is a fingerprint of the key used by <xref target="RFC5763">D xref target="RFC8224" format="default"/>. STIR authentication services <bcp14>MU
TLS-SRTP</xref>; consequently, STIR only offers comprehensive protection for SIP ST</bcp14> signal their compliance with this specification by including the "mse
sessions in concert with SDP and SRTP when DTLS-SRTP is the media security serv c" claim defined in this specification to the PASSporT payload. Implementations
ice. The underlying <xref target="RFC8225">PASSporT</xref> object used by STIR i <bcp14>MUST</bcp14> provide key fingerprints in SDP and the appropriate signatur
s extensible, however, and it would be possible to provide signatures over other es over them as specified in <xref target="RFC8225" format="default"/>.
SDP attributes that contain alternate keying material. A profile for using STIR </t>
to provide media confidentiality is given in <xref target="stirprof"/>. <t>
</t> When generating either an offer or an answer <xref target="RFC3264" form
at="default"/>, compliant implementations <bcp14>MUST</bcp14> include an "a=fing
erprint" attribute containing the fingerprint of an appropriate key (see <xref t
arget="stircred" format="default"/>).
</t>
<section anchor="stircred" numbered="true" toc="default">
<name>Credentials</name>
<t>
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;use
r=phone"). <xref target="RFC8224" sectionFormat="of" section="8"/> contains guid
ance for separating the two and determining what sort of credential is needed to
sign for each.
</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" 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 -- for either greenfield identifiers or telephone
numbers -- this specification does not require their use.
</t>
<t>
For users who do not possess such certificates, <xref target="RFC5763"
format="default">DTLS-SRTP</xref> 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 <xref target="RFC8224" format="default"/> 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 <xref 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="RFC7
435" format="default"/>) by relying parties. Note that relying parties <bcp14>SH
OULD NOT</bcp14> use certificate revocation mechanisms or real-time certificate
verification systems for self-signed certificates, as they will not increase con
fidence in the certificate.
</t>
<t>
Users who wish to remain anonymous can instead generate self-signed cert
ificates as described in <xref target="anon" format="default"/>.
</t>
<t>
Generally speaking, without access to out-of-band information about whic
h certificates were issued to whom, it will be very difficult for relying partie
s to ascertain whether or not the signer of a SIP request is genuinely an "endpo
int". 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 <xref tar
get="RFC6962" format="default"/> or similar practices could help UAs to recogniz
e one another's certificates, those operational systems will need to ramp up wit
h the CAs that issue credentials to end-user devices going forward.
</t>
</section>
<section anchor="anon" numbered="true" toc="default">
<name>Anonymous Communications</name>
<t>
In some cases, the identity of the initiator of a SIP session may be wit
hheld due to user or provider policy. Following the recommendations of <xref tar
get="RFC3323" format="default"/>, this may involve using an identity such as "an
onymous@anonymous.invalid" in the identity fields of a SIP request. <xref target
="RFC8224" format="default"/> 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 <xref target="RFC3323" format="default"/>
.
</t>
<t>
Even for anonymous sessions, providing media confidentiality and
partial SDP integrity is still desirable. One-time self-signed
certificates for anonymous communications <bcp14>SHOULD</bcp14>
include a subjectAltName of "sip:anonymous@anonymous.invalid".
After a session is terminated, the
certificate <bcp14>SHOULD</bcp14> be discarded, and a new one, with
fresh keying material, <bcp14>SHOULD</bcp14> be generated before each
future anonymous call. As with self-signed certificates, relying
parties <bcp14>SHOULD NOT</bcp14> use certificate revocation
mechanisms or real-time certificate verification systems for anonymous
certificates, as they will not increase confidence in the
certificate.
</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 "mky"
parameters of PASSporT and any "a=fingerprint" attributes in SDP as it
chooses. This signature only provides protection against non&nbhy;Identi
ty-aware entities that might modify SDP without altering the PASSporT conveyed i
n the Identity header.
</t>
</section>
<section anchor="stirconnect" numbered="true" toc="default">
<name>Connected Identity Usage</name>
<t>
<xref target="RFC8224" format="default">STIR</xref> provides integrity
protection for the fingerprint attributes in SIP request bodies but
not SIP responses. When a session is established, therefore, any SDP bod
y carried by a 200&nbhy;class response in the backwards direction will not be pr
otected by an authentication service and cannot be verified. Thus, sending a sec
ured SDP body in the backwards direction will require an extra RTT, typically a
request sent in the backwards direction.
</t>
<t>
<xref target="RFC4916"/> explored the problem of providing "connected
identity" to implementations of <xref target="RFC4474"
format="default"/> (which is obsoleted by <xref 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 <xref target="RFC4916"/> are largely compatible with the
revision of the Identity header in <xref target="RFC8224"/>.
However, the following need to be considered:
</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 Provisional Response Acknowledgement (PRACK) after a provis
ional 1xx response.
</li>
<li>
For use with this SIPBRANDY profile for media confidentiality, the UAS t
hat responds to the INVITE request needs to act as an authentication service for
the UPDATE sent in the backwards direction.
</li>
<li>
Per the text in <xref target="RFC4916" sectionFormat="of"
section="4.4.1"/> 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 <bcp14>RECOMMENDED</bcp14> that the dialog be treated as t
erminated. However, <xref target="RFC8224" sectionFormat="of" section="6.1.1"/>
allows the retransmission of requests with repairable error conditions. In part
icular, an authentication service might retry a mid-dialog rather than treating
the dialog as terminated, although only one such retry is permitted.
</li>
<li>
Note that the examples in <xref target="RFC4916" format="default"/>
are based on <xref target="RFC4474" format="default"/>
and will not match signatures using <xref target="RFC8224"
format="default"/>.
</li>
</ul>
<t>
Future work may be done to revise <xref 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" format="default"/> has some further
interactions with Interactive Connectivity Establishment (ICE) <xref tar
get="RFC8445"/>; see <xref target="ice" format="default"/>.
</t>
</section>
<section anchor="authz" numbered="true" toc="default">
<name>Authorization Decisions</name>
<t>
<xref 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 th
at fails an integrity check against the request.
</t>
<t>
For this SIPBRANDY profile of STIR, however, a compliant verification se
rvice that receives a dialog-forming SIP request containing an Identity header w
ith a PASSporT type of "msec", after validating the request per the steps descri
bed in <xref target="RFC8224" sectionFormat="of" section="6.2"/>, <bcp14>MUST</b
cp14> reject the request if there is any failure in that validation process with
the appropriate status code per <xref target="RFC8224" sectionFormat="of" secti
on="6.2.2"/>. If the request is valid, then if a terminating user accepts the re
quest, it <bcp14>MUST</bcp14> then follow the steps in <xref target="stirconnect
" format="default"/> to act as an authentication service and send a signed reque
st with the "msec" PASSporT type in its Identity header as well, in order to ena
ble end&nbhy;to-end bidirectional confidentiality.
</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 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
<xref target="stirconnect" format="default"/>. 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.
</t>
</section>
</section> </section>
<section anchor="mediasec" numbered="true" toc="default">
<name>Media Security Protocols</name>
<t>
As there are several ways to negotiate media security with SDP, any of w
hich might be used with either opportunistic or comprehensive protection, furthe
r guidance to implementers is needed. In <xref target="RFC8643" format="default"
/>, opportunistic approaches considered include DTLS-SRTP, <xref target="RFC4568
" format="default">security descriptions</xref>, and <xref target="RFC6189" form
at="default">ZRTP</xref>.
</t>
<t>
Support for DTLS-SRTP is <bcp14>REQUIRED</bcp14> by this specification.
</t>
<t>
The "mky" claim of PASSporT provides integrity protection for "a=fingerp
rint" attributes in SDP, including cases where multiple "a=fingerprint" attribut
es appear in the same SDP.
</t>
</section>
<section anchor="relay" numbered="true" toc="default">
<name>Relayed Media and 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 me
dia to a destination, others present themselves as media endpoints and terminate
security associations before re&nbhy;originating media to its destination.
</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 (1)&nbsp;the hop-by-hop media between a UA and a
centralized server and (2)&nbsp;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 recommendatio
ns as they mature.
</t>
<t>
Another class of entities that might relay SIP media are Back-to-Back
User Agents (B2BUAs). If a B2BUA follows the guidance in <xref
target="RFC7879" format="default"/>, it may be possible for B2BUAs
to act as media relays while still permitting end-to-end
confidentiality between 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 or against a
legitimate endpoint that can legitimately decrypt media and record a cop
y to be sent
elsewhere (see <xref target="RFC7245" format="default"/>).
</t>
</section>
<section anchor="ice" numbered="true" toc="default">
<name>ICE and Connected Identity</name>
<t>
Providing confidentiality for media with comprehensive protection requir
es careful timing of when media streams should be sent and when a user interface
should signify that confidentiality is in place.
</t>
<t>
In order to best enable end-to-end connectivity between UAs and to
avoid media relays as much as possible, implementations of this
specification <bcp14>MUST</bcp14> support ICE <xref target="RFC8445"
format="default"/> <xref target="RFC8839"/>. To speed up call
establishment, it is <bcp14>RECOMMENDED</bcp14> that implementations
support Trickle ICE <xref target="RFC8838"/> <xref target="RFC8840" form
at="default"></xref>.
</t>
<t>
Note that in the comprehensive protection case, the use of connected ide
ntity <xref target="RFC4916" format="default"/> with ICE implies that the answer
containing the key fingerprints, and thus the STIR signature, will come in an U
PDATE sent in the backwards direction, a provisional response, and a PRACK, rath
er 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>
Similarly, in order to prevent, or at least mitigate, the
denial-of-service attack described in <xref 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
<bcp14>MUST</bcp14> implement the Session Traversal Utilities for NAT (S
TUN) usage for consent freshness defined in <xref target="RFC7675" format="defau
lt"/>.
</t>
</section>
<section anchor="bcp" numbered="true" toc="default">
<name>Best Current Practices</name>
<t>
The following are the best practices for SIP UAs to provide media confid
entiality for SIP sessions.
</t>
<ul spacing="normal">
<li>Implementations <bcp14>MUST</bcp14> support the SIPBRANDY
profile as defined in <xref target="stirprof" format="default"/> and
signal such support in PASSporT via the "msec" header element.
</li>
<li>Implementations <bcp14>MUST</bcp14> follow the authorization
decision behavior described in <xref target="authz" format="default"/>.<
/li>
<li>Implementations <bcp14>MUST</bcp14> support DTLS-SRTP for
management of keys, as described in <xref target="mediasec" format="defa
ult"/>.</li>
<li>Implementations <bcp14>MUST</bcp14> support ICE and the STUN
consent freshness mechanism, as specified in <xref target="ice"
format="default"/>.</li>
</ul>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
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.
</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
This document describes the security features that provide media sessions es
tablished with SIP with confidentiality, integrity, and authentication.
</t>
</section>
</middle>
<back>
<section anchor="stirprof" title="STIR Profile for Endpoint Authenticatio <displayreference target="I-D.ietf-acme-authority-token" to="ACME-Auth-Token"/>
n and Verification Services"> <displayreference target="I-D.kaplan-mmusic-best-effort-srtp" to="Best-Effort-SR
<t> TP"/>
<xref target="RFC8224">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 t
he 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 e
stablish DTLS-SRTP. To satisfy this condition, the verification service function
would in this case be implemented in the SIP User Agent Server (UAS), which wou
ld be composed with the media endpoint. If the STIR authentication service or ve
rification service functions are implemented at an intermediary rather than an e
ndpoint, this introduces the possibility that the intermediary could act as a ma
n 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 atta
cks, STIR offers no specific protections against such interference.
</t><t>
The SIPBRANDY profile for media confidentiality thus shifts these respons
ibilities 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 ass
urance. Intermediaries supporting this specification MUST NOT block or otherwise
redirect calls if they do not trust the signing credential. The SIPBRANDY profi
le is based on an end-to-end trust model, so it is up to the endpoints to determ
ine if they support signing credentials, not intermediaries.
</t><t>
In order to be compliant with best practices for SIP media confidentialit
y with comprehensive protection, user agent implementations MUST implement both
the authentication service and verification service roles described in <xref tar
get="RFC8224"/>. STIR authentication services MUST signal their compliance with
this specification by including the "msec" claim defined in this specification t
o the PASSporT payload. Implementations MUST provide key fingerprints in SDP and
the appropriate signatures over them as specified in <xref target="RFC8225"/>.
</t><t>
When generating either an offer or an answer <xref target="RFC3264"/>, co
mpliant implementations MUST include an "a=fingerprint" attribute containing the
fingerprint of an appropriate key (see <xref target="stircred"/>).
</t>
<section anchor="stircred" title="Credentials">
<t>
In order to implement the authentication service function in the user age
nt, 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 S
IP request, and either contains a greenfield SIP URI (e.g. "sip:alice@example.co
m") or a telephone number, which can appear in a variety of ways (e.g. "sip:+170
04561212@example.com;user=phone"). Section 8 of <xref target="RFC8224"/> contain
s guidance for separating the two, and determining what sort of credential is ne
eded to sign for each.
</t><t>
To date, few commercial certification authorities (CAs) issue certificate
s 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"/>) it is not yet m
ature enough to be recommended as a best practice. This is one reason why STIR p
ermits 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. Whi
le CAs that offer proof-of-possession certificates similar to those used for ema
il could be offered for SIP, either for greenfield identifiers or for telephone
numbers, this specification does not require their use.
</t><t>
For users who do not possess such certificates, <xref target="RFC5763">DT
LS-SRTP</xref> permits the use of self-signed public keys. This profile of STIR
employs more relaxed authority requirements of <xref target="RFC8224"/> to allow
the use of self-signed public keys for authentication services that are compose
d with user agents, by generating a certificate (per the guidance in <xref targe
t="RFC8226"/>) with a subject corresponding to the user's identity. To obtain co
mprehensive protection with a self-signed certificate, some out-of-band verifica
tion is needed as well. Such a credential could be used for trust on first use (
see <xref target="RFC7435"/>) by relying parties. Note that relying parties SHOU
LD NOT use certificate revocation mechanisms or real-time certificate verificati
on systems for self-signed certificates as they will not increase confidence in
the certificate.
</t><t>
Users who wish to remain anonymous can instead generate self-signed certi
ficates as described in <xref target="anon"/>.
</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 "endpoi
nt." Even the term "endpoint" is a problematic one, as SIP user agents can be co
mposed in a variety of architectures and may not be devices under direct user co
ntrol. While it is possible that techniques based on certificate transparency <x
ref target="RFC6962"/> or similar practices could help user agents 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.
</t>
</section>
<section anchor="anon" title="Anonymous Communications">
<t>
In some cases, the identity of the initiator of a SIP session may be with
held due to user or provider policy. Following the recommendations of <xref targ
et="RFC3323"/>, this may involve using an identity such as "anonymous@anonymous.
invalid" in the identity fields of a SIP request. <xref target="RFC8224"/> does
not currently permit authentication services to sign for requests that supply th
is identity. It does however permit signing for valid domains, such as "anonymou
s@example.com," as a way of implementation an anonymization service as specified
in <xref target="RFC3323"/>.
</t><t>
Even for anonymous sessions, providing media confidentiality and partial
SDP integrity is still desirable. This specification RECOMMENDS using one-time s
elf-signed certificates for anonymous communications, with 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 gener
ated before each future anonymous call. As with self-signed certificates, relyin
g parties SHOULD NOT use certificate revocation mechanisms or real-time certific
ate verification systems for anonymous certificates as they will not increase co
nfidence in the certificate.
</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" parameters of PASSporT and an
y "a=fingerprint" attributes in SDP as it chooses. This signature only provides
protection against non-Identity aware entities that might modify SDP without alt
ering the PASSporT conveyed in the Identity header.
</t>
</section>
<section anchor="stirconnect" title="Connected Identity Usage">
<t>
<xref target="RFC8224">STIR</xref> provides integrity protection for the
fingerprint attributes in SIP request bodies, but not SIP responses. When a sess
ion is established, therefore, any SDP body carried by a 200 class response in t
he backwards direction will not be protected by an authentication service and ca
nnot be verified. Thus, sending a secured SDP body in the backwards direction wi
ll require an extra RTT, typically a request sent in the backwards direction.
</t><t>
The problem of providing "Connected Identity" in <xref target="RFC4474"/>
, which is obsoleted by STIR, was explored in <xref target="RFC4916"/>, which us
es a provisional or mid-dialog UPDATE request in the backwards direction to conv
ey an Identity header field for the recipient of an INVITE. The procedures in th
at specification are largely compatible with the revision of the Identity header
in STIR <xref target="RFC8224"/>. However, the following need to be considered:
<list>
<t>
The UPDATE carrying signed SDP with a fingerprint in the backwards direct
ion needs to be sent during dialog establishment, following the receipt of a PRA
CK after a provisional 1xx response.
</t><t>
For use with this SIPBRANDY profile for media confidentiality, the UAS th
at responds to the INVITE request needs to act as an authentication service for
the UPDATE sent in the backwards direction.
</t><t>
The text in Section 4.4.1 of <xref target="RFC4916"/> regarding the recei
pt at a UAC of error codes 428, 436, 437 and 438 in response to a mid-dialog req
uest RECOMMENDS treating the dialog as terminated. However, Section 6.1.1 of <xr
ef target="RFC8224"/> allows the retransmission of requests with repairable erro
r conditions. In particular, an authentication service might retry a mid-dialog
rather than treating the dialog as terminated, although only one such retry is p
ermitted.
</t><t>
Note that the examples in <xref target="RFC4916"/> are based on the origi
nal <xref target="RFC4474"/>, and will not match signatures using STIR <xref tar
get="RFC8224"/>.
</t>
</list>
</t><t>
Future work may be done to revise <xref target="RFC4916"/> for STIR; that
work should take into account any impacts on the SIPBRANDY profile described in
this document. The use of <xref target="RFC4916"/> has some further interaction
s with ICE; see <xref target="ice"/>.
</t>
</section>
<section anchor="authz" title="Authorization Decisions">
<t>
<xref target="RFC8224"/> grants STIR verification services a great deal o
f latitude when making authorization decisions based on the presence of the Iden
tity header field. It is largely a matter of local policy whether an endpoint re
jects a call based on absence of an Identity header field, or even the presence
of a header that fails an integrity check against the request.
</t><t>
For this SIPBRANDY profile of STIR, however, a compliant verification ser
vice that receives a dialog-forming SIP request containing an Identity header wi
th a PASSporT type of "msec", after validating the request per the steps describ
ed in Section 6.2 of <xref target="RFC8224"/>, MUST reject the request if there
is any failure in that validation process with the appropriate status code per S
ection 6.2.2. If the request is valid, then if a terminating user accepts the re
quest, it MUST then follow the steps in <xref target="stirconnect"/> to act as a
n 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 con
fidentiality.
</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 se
curity, or as a merely opportunistic request for media security. As any verifica
tion service that receives an Identity header field in a SIP request with an unr
ecognized PASSporT type will simply ignore that Identity header, an authenticati
on service will know whether or not the terminating side supports "msec" based o
n whether or not its user agent receives a signed request in the backwards direc
tion per <xref target="stirconnect"/>. If no such requests are received, the UA
may do one or 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 continu
e without media security.
</t>
</section>
</section>
<section anchor="mediasec" title="Media Security Protocols"> <references>
<t> <name>References</name>
As there are several ways to negotiate media security with SDP, any of wh <references>
ich might be used with either opportunistic or comprehensive protection, further <name>Normative References</name>
guidance to implementers is needed. In <xref target="I-D.ietf-sipbrandy-osrtp"/ <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
>, opportunistic approaches considered include DTLS-SRTP, <xref target="RFC4568" FC.2119.xml"/>
>security descriptions</xref>, and <xref target="RFC6189">ZRTP</xref>. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</t><t> FC.7258.xml"/>
Support for DTLS-SRTP is REQUIRED by this specification. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</t><t> FC.3261.xml"/>
The "mkey" claim of PASSporT provides integrity protection for "a=fingerp <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
rint" attributes in SDP, including cases where multiple "a=fingerprint" attribut FC.3264.xml"/>
es appear in the same SDP. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</t> FC.3323.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3711.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4568.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4566.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7675.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7879.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4916.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8224.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8225.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8226.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8445.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<section anchor="relay" title="Relayed Media and Conferencing"> <!-- draft-ietf-ice-trickle (RFC 8838) -->
<t> <reference anchor="RFC8838" target="https://www.rfc-editor.org/info/rfc8838">
Providing end-to-end media confidentiality for SIP is complicated by the <front>
presence of many forms of media relays. While many media relays merely proxy med <title>Trickle ICE: Incremental Provisioning of Candidates for the
ia to a destination, others present themselves as media endpoints and terminate Interactive Connectivity Establishment (ICE) Protocol</title>
security associations before re-originating media to its destination. <author initials="E" surname="Ivov" fullname="Emil Ivov">
</t><t> <organization />
Centralized conference bridges are one type of entity that typically term </author>
inates a media session in order to mux media from multiple sources and then to r <author initials="J" surname="Uberti" fullname="Justin Uberti">
e-originate the muxed media to conference participants. In many such implementat <organization />
ions, only hop-by-hop media confidentiality is possible. Work is ongoing to spec </author>
ify a means to encrypt both the hop-by-hop media between a user agent and a cent <author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
ralized server as well as the end-to-end media between user agents, but is not s <organization />
ufficiently mature at this time to make a recommendation for a best practice her </author>
e. Those protocols are expected to identify their own best practice recommendati <date month="January" year="2021" />
ons as they mature. </front>
</t><t> <seriesInfo name="RFC" value="8838" />
Another class of entities that might relay SIP media are back-to-back use <seriesInfo name="DOI" value="10.17487/RFC8838"/>
r agents (B2BUAs). If a B2BUA follows the guidance in <xref target="RFC7879"/>, </reference>
it may be possible for those devices to act as media relays while still permitti
ng end-to-end confidentiality between user agents.
</t><t>
Ultimately, if an endpoint can decrypt media it receives, then that endpo
int can forward the decrypted media without the knowledge or consent of the medi
a's originator. No media confidentiality mechanism can protect against these sor
ts of relayed disclosures, or trusted entities that can decrypt media and then r
ecord a copy to be sent elsewhere (see <xref target="RFC7245"/>).
</t>
</section>
<section anchor="ice" title="ICE and Connected Identity"> <!-- draft-ietf-mmusic-ice-sip-sdp (RFC 8839) -->
<t> <reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
Providing confidentiality for media with comprehensive protection require <front>
s careful timing of when media streams should be sent and when a user interface <title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactiv
should signify that confidentiality is in place. e Connectivity Establishment (ICE)</title>
</t><t> <author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
In order to best enable end-to-end connectivity between user agents, and <organization />
to avoid media relays as much as possible, implementations of this specification </author>
MUST support ICE <xref target="RFC8445"/>. To speed up call establishment, it i <author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
s RECOMMENDED that implementations support <xref target="I-D.ietf-mmusic-trickle <organization />
-ice-sip">trickle ICE</xref>. </author>
</t><t> <author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
Note that in the comprehensive protection case, the use of Connected Iden <organization />
tity <xref target="RFC4916"/> with ICE entails that the answer containing the ke </author>
y fingerprints, and thus the STIR signature, will come in an UPDATE sent in the <author initials='A' surname='Keränen' fullname='Ari Keränen'>
backwards direction, a provisional response, and a provisional acknowledgment (P <organization />
RACK), rather than in any earlier SDP body. Only at such a time as that UPDATE i </author>
s received will the media keys be considered exchanged in this case. <author initials='R' surname='Shpount' fullname='Roman Shpount'>
</t><t> <organization />
Similarly, in order to prevent, or at least mitigate, the denial-of-servi </author>
ce attack described in Section 19.5.1 of <xref target="RFC8445"/>, this specific <date month="January" year="2021"/>
ation incorporates best practices for ensuring that recipients of media flows ha </front>
ve consented to receive such flows. Implementations of this specification MUST i <seriesInfo name="RFC" value="8839"/>
mplement the STUN usage for consent freshness defined in <xref target="RFC7675"/ <seriesInfo name="DOI" value="10.17487/RFC8839"/>
>. </reference>
</t>
</section>
<section anchor="bcp" title="Best Current Practices"> <!-- draft-ietf-mmusic-trickle-ice-sip (RFC 8840) -->
<t> <reference anchor="RFC8840" target="https://www.rfc-editor.org/info/rfc8840">
The following are the best practices for SIP user agents to provide media <front>
confidentiality for SIP sessions. <title>A Session Initiation Protocol (SIP) Usage for Incremental
</t><t> Provisioning of Candidates for the Interactive Connectivity
Implementations MUST support the STIR endpoint profile given in <xref tar Establishment (Trickle ICE)</title>
get="stirprof"/>, and signal that in PASSporT with the "msec" header element. <author initials="E" surname="Ivov" fullname="Emil Ivov">
</t><t> <organization/>
Implementations MUST follow the authorization decision behavior in <xref </author>
target="authz"/>. <author initials="T" surname="Stach" fullname="Thomas Stach">
</t><t> <organization/>
Implementations MUST support DTLS-SRTP for key-management, as described i </author>
n <xref target="mediasec"/>. <author initials="E" surname="Marocco" fullname="Enrico Marocco">
</t><t> <organization/>
Implementations MUST support the ICE, and the STUN consent freshness mech </author>
anism, as specified in <xref target="ice"/>. <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
</t> <organization/>
</section> </author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8840"/>
<seriesInfo name="DOI" value="10.17487/RFC8840"/>
</reference>
<section anchor="IANA" title="IANA Considerations"> </references>
<t> <references>
This specification defines a new value for the Personal Assertion Token (PAS <name>Informative References</name>
SporT) Extensions registry called "msec," and the IANA is requested to add that <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
entry to the registry with a value pointing to [RFCThis]. FC.4474.xml"/>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</section> FC.6189.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6962.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7245.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7435.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7616.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8551.xml"/>
<section anchor="Security" title="Security Considerations"> <!-- draft-ietf-sipbrandy-osrtp (Published; RFC 8643) -->
<t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8643.
This document describes the security features that provide media sessions es xml"/>
tablished with SIP with confidentiality, integrity, and authentication.
</t>
</section>
<section anchor="Acknowledgments" title="Acknowledgments"> <!-- draft-kaplan-mmusic-best-effort-srtp (Expired)
<t> Correct author order is "Kaplan, H. and F. Audet".
We thank Eric Rescorla, Adam Roach, Andrew Hutton, and Ben Campbell for cont Last checked 1/5/2021 -->
ributions to this problem statement and framework. We thank Liang Xia and Aliss <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-
a Cooper for their careful review. D.kaplan-mmusic-best-effort-srtp.xml"/>
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** --> <!-- 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"/>
<back> </references>
<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> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
We thank <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 <contact fullname="Liang Xia"/> and <contact fullname="Alissa Cooper"/
> for their careful review.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 30 change blocks. 
558 lines changed or deleted 664 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/