File: rfc8862.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (1878 lines) | stat: -rw-r--r-- 91,654 bytes
<!DOCTYPE html>
<html lang="en" class="RFC BCP">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8862: Best Practices for Securing RTP Media Signaled with SIP</title>
<meta content="Jon Peterson" name="author">
<meta content="Richard Barnes" name="author">
<meta content="Russ Housley" name="author">
<meta content="
       
          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. 
       
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="SIP" name="keyword">
<meta content="RTP" name="keyword">
<meta content="security" name="keyword">
<meta content="8862" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8862.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8862" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec-08" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8862</td>
<td class="center">RTP Security</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Peterson, et al.</td>
<td class="center">Best Current Practice</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8862" class="eref">8862</a></dd>
<dt class="label-bcp">BCP:</dt>
<dd class="bcp">228</dd>
<dt class="label-category">Category:</dt>
<dd class="category">Best Current Practice</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-01" class="published">January 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J. Peterson</div>
<div class="org">Neustar</div>
</div>
<div class="author">
      <div class="author-name">R. Barnes</div>
<div class="org">Cisco</div>
</div>
<div class="author">
      <div class="author-name">R. Housley</div>
<div class="org">Vigil Security</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8862</h1>
<h1 id="title">Best Practices for Securing RTP Media Signaled with SIP</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
          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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8862">https://www.rfc-editor.org/info/rfc8862</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-security-at-the-sip-and-sdp" class="xref">Security at the SIP and SDP Layer</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-stir-profile-for-endpoint-a" class="xref">STIR Profile for Endpoint Authentication and Verification Services</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-credentials" class="xref">Credentials</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-anonymous-communications" class="xref">Anonymous Communications</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-connected-identity-usage" class="xref">Connected Identity Usage</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-authorization-decisions" class="xref">Authorization Decisions</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-media-security-protocols" class="xref">Media Security Protocols</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-relayed-media-and-conferenc" class="xref">Relayed Media and Conferencing</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-ice-and-connected-identity" class="xref">ICE and Connected Identity</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-best-current-practices" class="xref">Best Current Practices</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
        The <span><a href="#RFC3261" class="xref">Session Initiation
        Protocol (SIP)</a> [<a href="#RFC3261" class="xref">RFC3261</a>]</span> includes a suite of security services, including
        Digest Authentication <span>[<a href="#RFC7616" class="xref">RFC7616</a>]</span> for authenticating
        entities with a shared secret, TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> for
        transport security, and (optionally) S/MIME <span>[<a href="#RFC8551" class="xref">RFC8551</a>]</span>
        for body security. SIP is frequently used to establish media sessions -- in
        particular, audio or audiovisual sessions, which have their own
        security mechanisms available, such as <span><a href="#RFC3711" class="xref">the Secure Real-time Transport Protocol (SRTP)</a> [<a href="#RFC3711" class="xref">RFC3711</a>]</span>. 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.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
        Revelations about widespread pervasive monitoring of the Internet have led to a greater desire to protect Internet communications <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>. 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 <span>[<a href="#RFC8643" class="xref">RFC8643</a>]</span>, which builds on the prior efforts of <span>[<a href="#I-D.kaplan-mmusic-best-effort-srtp" class="xref">Best-Effort-SRTP</a>]</span>. 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.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
        This document contains the SIP Best-practice Recommendations Against
        Network Dangers to privacY (SIPBRANDY) profile of Secure Telephone
 Identity Revisited (STIR) <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span> 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 <a href="#bcp" class="xref">Section 8</a>.<a href="#section-1-3" class="pilcrow">¶</a></p>
</section>
<div id="sec-2">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
      "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>",
      "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>",
      "<span class="bcp14">SHOULD NOT</span>",
      "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
      "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
      to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all
      capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3">
      <h2 id="name-security-at-the-sip-and-sdp">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-security-at-the-sip-and-sdp" class="section-name selfRef">Security at the SIP and SDP Layer</a>
      </h2>
<p id="section-3-1">
        There are two approaches to providing confidentiality for media sessions set up with SIP: comprehensive protection and opportunistic security (as defined in <span>[<a href="#RFC7435" class="xref">RFC7435</a>]</span>). This document only addresses comprehensive protection.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
        Comprehensive protection for media sessions established by SIP
        requires the interaction of three protocols: the <span><a href="#RFC3261" class="xref">Session Initiation
   Protocol (SIP)</a> [<a href="#RFC3261" class="xref">RFC3261</a>]</span>, the <span><a href="#RFC4566" class="xref">Session Description Protocol (SDP)</a> [<a href="#RFC4566" class="xref">RFC4566</a>]</span>, and the
        <span><a href="#RFC3550" class="xref">Real-time Transport Protocol
        (RTP)</a> [<a href="#RFC3550" class="xref">RFC3550</a>]</span> -- in particular, its secure profile <span><a href="#RFC3711" class="xref">SRTP</a> [<a href="#RFC3711" class="xref">RFC3711</a>]</span>. 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.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
        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 <span class="bcp14">MUST NOT</span> be used in conjunction with this profile.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
        In that way, once SIP and SDP have exchanged the necessary information to initiate a session, media endpoints will have a strong assurance that the keys they exchange have not been tampered with by third parties and that end-to-end confidentiality is available.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
        To establish the identity of the endpoints of a SIP session, this
        specification uses <span><a href="#RFC8224" class="xref">STIR</a> [<a href="#RFC8224" class="xref">RFC8224</a>]</span>. The STIR Identity header has been
        designed to prevent a class of impersonation attacks that are commonly
        used in robocalling, voicemail hacking, and related threats. STIR
        generates a signature over certain features of SIP requests, including
        header field values that contain an identity for the originator of the
        request, such as the From header field or P‑Asserted-Identity
        field, and also over the media keys in SDP if they are present. As
        currently defined, STIR provides a signature over the "a=fingerprint"
        attribute, which is a fingerprint of the key used by <span><a href="#RFC5763" class="xref">DTLS-SRTP</a> [<a href="#RFC5763" class="xref">RFC5763</a>]</span>; 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 <span><a href="#RFC8225" class="xref">Personal Assertion
   Token (PASSporT) object</a> [<a href="#RFC8225" class="xref">RFC8225</a>]</span> 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 <a href="#stirprof" class="xref">Section 4</a>.<a href="#section-3-5" class="pilcrow">¶</a></p>
</section>
<div id="stirprof">
<section id="section-4">
      <h2 id="name-stir-profile-for-endpoint-a">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-stir-profile-for-endpoint-a" class="section-name selfRef">STIR Profile for Endpoint Authentication and Verification Services</a>
      </h2>
<p id="section-4-1">
        <span><a href="#RFC8224" class="xref">STIR</a> [<a href="#RFC8224" class="xref">RFC8224</a>]</span> 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.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
        The SIPBRANDY profile for media confidentiality thus shifts these responsibilities to the endpoints rather than the intermediaries. While intermediaries <span class="bcp14">MAY</span> 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 <span class="bcp14">MUST NOT</span> 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.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
        In order to be compliant with best practices for SIP media confidentiality with comprehensive protection, UA implementations <span class="bcp14">MUST</span> implement both the authentication service and verification service roles described in <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span>. STIR authentication services <span class="bcp14">MUST</span> signal their compliance with this specification by including the "msec" claim defined in this specification to the PASSporT payload. Implementations <span class="bcp14">MUST</span> provide key fingerprints in SDP and the appropriate signatures over them as specified in <span>[<a href="#RFC8225" class="xref">RFC8225</a>]</span>.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
        When generating either an offer or an answer <span>[<a href="#RFC3264" class="xref">RFC3264</a>]</span>, compliant implementations <span class="bcp14">MUST</span> include an "a=fingerprint" attribute containing the fingerprint of an appropriate key (see <a href="#stircred" class="xref">Section 4.1</a>).<a href="#section-4-4" class="pilcrow">¶</a></p>
<div id="stircred">
<section id="section-4.1">
        <h3 id="name-credentials">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-credentials" class="section-name selfRef">Credentials</a>
        </h3>
<p id="section-4.1-1">
        In order to implement the authentication service function in the UA,
        SIP endpoints will need to acquire the credentials needed to
        sign for their own identity. That identity is typically carried in the
        From header field of a SIP request and contains either a greenfield
        SIP URI (e.g., "sip:alice@example.com") or a telephone number (which
        can appear in a variety of ways, e.g., "sip:+17004561212@example.com;user=phone"). <span><a href="https://www.rfc-editor.org/rfc/rfc8224#section-8" class="relref">Section 8</a> of [<a href="#RFC8224" class="xref">RFC8224</a>]</span> contains guidance for separating the two and determining what sort of credential is needed to sign for each.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
        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 <span>[<a href="#I-D.ietf-acme-authority-token" class="xref">ACME-Auth-Token</a>]</span>), 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.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">
        For users who do not possess such certificates, <span><a href="#RFC5763" class="xref">DTLS-SRTP</a> [<a href="#RFC5763" class="xref">RFC5763</a>]</span> 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 <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span> 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 <span>[<a href="#RFC8226" class="xref">RFC8226</a>]</span>) 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 <span>[<a href="#RFC7435" class="xref">RFC7435</a>]</span>) by relying parties. Note that relying parties <span class="bcp14">SHOULD NOT</span> use certificate revocation mechanisms or real-time certificate verification systems for self-signed certificates, as they will not increase confidence in the certificate.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">
        Users who wish to remain anonymous can instead generate self-signed certificates as described in <a href="#anon" class="xref">Section 4.2</a>.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">
        Generally speaking, without access to out-of-band information about which certificates were issued to whom, it will be very difficult for relying parties to ascertain whether or not the signer of a SIP request is genuinely an "endpoint". Even the term "endpoint" is a problematic one, as SIP UAs can be composed in a variety of architectures and may not be devices under direct user control. While it is possible that techniques based on certificate transparency <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span> or similar practices could help UAs to recognize one another's certificates, those operational systems will need to ramp up with the CAs that issue credentials to end-user devices going forward.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="anon">
<section id="section-4.2">
        <h3 id="name-anonymous-communications">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-anonymous-communications" class="section-name selfRef">Anonymous Communications</a>
        </h3>
<p id="section-4.2-1">
        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 <span>[<a href="#RFC3323" class="xref">RFC3323</a>]</span>, this may involve using an identity such as "anonymous@anonymous.invalid" in the identity fields of a SIP request. <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span> 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 <span>[<a href="#RFC3323" class="xref">RFC3323</a>]</span>.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
        Even for anonymous sessions, providing media confidentiality and
        partial SDP integrity is still desirable. One-time self-signed
        certificates for anonymous communications <span class="bcp14">SHOULD</span>
        include a subjectAltName of "sip:anonymous@anonymous.invalid".
 After a session is terminated, the
        certificate <span class="bcp14">SHOULD</span> be discarded, and a new one, with
        fresh keying material, <span class="bcp14">SHOULD</span> be generated before each
        future anonymous call. As with self-signed certificates, relying
        parties <span class="bcp14">SHOULD NOT</span> use certificate revocation
        mechanisms or real-time certificate verification systems for anonymous
        certificates, as they will not increase confidence in the
        certificate.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">
        Note that when using one-time anonymous self-signed certificates, any
        man in the middle could strip the Identity header and replace it with
        one signed by its own one-time certificate, changing the "mky"
        parameters of PASSporT and any "a=fingerprint" attributes in SDP as it
        chooses. This signature only provides protection against non‑Identity-aware entities that might modify SDP without altering the PASSporT conveyed in the Identity header.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stirconnect">
<section id="section-4.3">
        <h3 id="name-connected-identity-usage">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-connected-identity-usage" class="section-name selfRef">Connected Identity Usage</a>
        </h3>
<p id="section-4.3-1">
        <span><a href="#RFC8224" class="xref">STIR</a> [<a href="#RFC8224" class="xref">RFC8224</a>]</span> provides integrity
        protection for the fingerprint attributes in SIP request bodies but
        not SIP responses. When a session is established, therefore, any SDP body carried by a 200‑class response in the backwards direction will not be protected by an authentication service and cannot be verified. Thus, sending a secured SDP body in the backwards direction will require an extra RTT, typically a request sent in the backwards direction.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
        <span>[<a href="#RFC4916" class="xref">RFC4916</a>]</span> explored the problem of providing "connected
        identity" to implementations of <span>[<a href="#RFC4474" class="xref">RFC4474</a>]</span> (which is obsoleted by <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span>);
        <span>[<a href="#RFC4916" class="xref">RFC4916</a>]</span> 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 <span>[<a href="#RFC4916" class="xref">RFC4916</a>]</span> are largely compatible with the
        revision of the Identity header in <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span>.
        However, the following need to be considered:<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3-3.1">
        The UPDATE carrying signed SDP with a fingerprint in the backwards
        direction needs to be sent during dialog establishment, following the
        receipt of a Provisional Response Acknowledgement (PRACK) after a provisional 1xx response.<a href="#section-4.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.2">
        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.<a href="#section-4.3-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.3">
        Per the text in <span><a href="https://www.rfc-editor.org/rfc/rfc4916#section-4.4.1" class="relref">Section 4.4.1</a> of [<a href="#RFC4916" class="xref">RFC4916</a>]</span> 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 <span class="bcp14">RECOMMENDED</span> that the dialog be treated as terminated. However, <span><a href="https://www.rfc-editor.org/rfc/rfc8224#section-6.1.1" class="relref">Section 6.1.1</a> of [<a href="#RFC8224" class="xref">RFC8224</a>]</span>
 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.<a href="#section-4.3-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.3-3.4">
        Note that the examples in <span>[<a href="#RFC4916" class="xref">RFC4916</a>]</span>
        are based on <span>[<a href="#RFC4474" class="xref">RFC4474</a>]</span>
        and will not match signatures using <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span>.<a href="#section-4.3-3.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.3-4">
        Future work may be done to revise <span>[<a href="#RFC4916" class="xref">RFC4916</a>]</span> for STIR; that work should take into account any
        impacts on the SIPBRANDY profile described in this document. The use
        of <span>[<a href="#RFC4916" class="xref">RFC4916</a>]</span> has some further
        interactions with Interactive Connectivity Establishment (ICE) <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span>; see <a href="#ice" class="xref">Section 7</a>.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authz">
<section id="section-4.4">
        <h3 id="name-authorization-decisions">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-authorization-decisions" class="section-name selfRef">Authorization Decisions</a>
        </h3>
<p id="section-4.4-1">
        <span>[<a href="#RFC8224" class="xref">RFC8224</a>]</span> 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.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
        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 <span><a href="https://www.rfc-editor.org/rfc/rfc8224#section-6.2" class="relref">Section 6.2</a> of [<a href="#RFC8224" class="xref">RFC8224</a>]</span>, <span class="bcp14">MUST</span> reject the request if there is any failure in that validation process with the appropriate status code per <span><a href="https://www.rfc-editor.org/rfc/rfc8224#section-6.2.2" class="relref">Section 6.2.2</a> of [<a href="#RFC8224" class="xref">RFC8224</a>]</span>. If the request is valid, then if a terminating user accepts the request, it <span class="bcp14">MUST</span> then follow the steps in <a href="#stirconnect" class="xref">Section 4.3</a> to act as an authentication service and send a signed request with the "msec" PASSporT type in its Identity header as well, in order to enable end‑to-end bidirectional confidentiality.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">
        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
        <a href="#stirconnect" class="xref">Section 4.3</a>. 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.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="mediasec">
<section id="section-5">
      <h2 id="name-media-security-protocols">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-media-security-protocols" class="section-name selfRef">Media Security Protocols</a>
      </h2>
<p id="section-5-1">
        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 <span>[<a href="#RFC8643" class="xref">RFC8643</a>]</span>, opportunistic approaches considered include DTLS-SRTP, <span><a href="#RFC4568" class="xref">security descriptions</a> [<a href="#RFC4568" class="xref">RFC4568</a>]</span>, and <span><a href="#RFC6189" class="xref">ZRTP</a> [<a href="#RFC6189" class="xref">RFC6189</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
        Support for DTLS-SRTP is <span class="bcp14">REQUIRED</span> by this specification.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
        The "mky" claim of PASSporT provides integrity protection for "a=fingerprint" attributes in SDP, including cases where multiple "a=fingerprint" attributes appear in the same SDP.<a href="#section-5-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="relay">
<section id="section-6">
      <h2 id="name-relayed-media-and-conferenc">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-relayed-media-and-conferenc" class="section-name selfRef">Relayed Media and Conferencing</a>
      </h2>
<p id="section-6-1">
        Providing end-to-end media confidentiality for SIP is complicated by the presence of many forms of media relays. While many media relays merely proxy media to a destination, others present themselves as media endpoints and terminate security associations before re‑originating media to its destination.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
        Centralized conference bridges are one type of entity that typically
        terminates a media session in order to mux media from multiple sources
        and then to re-originate the muxed media to conference
        participants. In many such implementations, only hop-by-hop media
        confidentiality is possible. Work is ongoing to specify a means to
        encrypt both (1) the hop-by-hop media between a UA and a
        centralized server and (2) the end-to-end media between UAs,
        but it is not sufficiently mature at this time to become a best practice. Those protocols are expected to identify their own best-practice recommendations as they mature.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
        Another class of entities that might relay SIP media are Back-to-Back
        User Agents (B2BUAs). If a B2BUA follows the guidance in <span>[<a href="#RFC7879" class="xref">RFC7879</a>]</span>, it may be possible for B2BUAs
        to act as media relays while still permitting end-to-end
        confidentiality between UAs.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
        Ultimately, if an endpoint can decrypt media it receives, then that
        endpoint can forward the decrypted media without the knowledge or
        consent of the media's originator. No media confidentiality mechanism
        can protect against these sorts of relayed disclosures or against a
        legitimate endpoint that can legitimately decrypt media and record a copy to be sent
        elsewhere (see <span>[<a href="#RFC7245" class="xref">RFC7245</a>]</span>).<a href="#section-6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ice">
<section id="section-7">
      <h2 id="name-ice-and-connected-identity">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-ice-and-connected-identity" class="section-name selfRef">ICE and Connected Identity</a>
      </h2>
<p id="section-7-1">
        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.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
        In order to best enable end-to-end connectivity between UAs and to
        avoid media relays as much as possible, implementations of this
        specification <span class="bcp14">MUST</span> support ICE <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> <span>[<a href="#RFC8839" class="xref">RFC8839</a>]</span>. To speed up call
        establishment, it is <span class="bcp14">RECOMMENDED</span> that implementations
        support Trickle ICE <span>[<a href="#RFC8838" class="xref">RFC8838</a>]</span> <span>[<a href="#RFC8840" class="xref">RFC8840</a>]</span>.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
        Note that in the comprehensive protection case, the use of connected identity <span>[<a href="#RFC4916" class="xref">RFC4916</a>]</span> with ICE implies that the answer containing the key fingerprints, and thus the STIR signature, will come in an UPDATE sent in the backwards direction, a provisional response, and a PRACK, rather than in any earlier SDP body. Only at such a time as that UPDATE is received will the media keys be considered exchanged in this case.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">
        Similarly, in order to prevent, or at least mitigate, the
        denial-of-service attack described in <span><a href="https://www.rfc-editor.org/rfc/rfc8445#section-19.5.1" class="relref">Section 19.5.1</a> of [<a href="#RFC8445" class="xref">RFC8445</a>]</span>, this specification incorporates
        best practices for ensuring that recipients of media flows have
        consented to receive such flows. Implementations of this specification
        <span class="bcp14">MUST</span> implement the Session Traversal Utilities for NAT (STUN) usage for consent freshness defined in <span>[<a href="#RFC7675" class="xref">RFC7675</a>]</span>.<a href="#section-7-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="bcp">
<section id="section-8">
      <h2 id="name-best-current-practices">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-best-current-practices" class="section-name selfRef">Best Current Practices</a>
      </h2>
<p id="section-8-1">
        The following are the best practices for SIP UAs to provide media confidentiality for SIP sessions.<a href="#section-8-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8-2.1">Implementations <span class="bcp14">MUST</span> support the SIPBRANDY
        profile as defined in <a href="#stirprof" class="xref">Section 4</a> and
        signal such support in PASSporT via the "msec" header element.<a href="#section-8-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-2.2">Implementations <span class="bcp14">MUST</span> follow the authorization
        decision behavior described in <a href="#authz" class="xref">Section 4.4</a>.<a href="#section-8-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-2.3">Implementations <span class="bcp14">MUST</span> support DTLS-SRTP for
        management of keys, as described in <a href="#mediasec" class="xref">Section 5</a>.<a href="#section-8-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-2.4">Implementations <span class="bcp14">MUST</span> support ICE and the STUN
        consent freshness mechanism, as specified in <a href="#ice" class="xref">Section 7</a>.<a href="#section-8-2.4" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="IANA">
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">
    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.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-10">
      <h2 id="name-security-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-10-1">
    This document describes the security features that provide media sessions established with SIP with confidentiality, integrity, and authentication.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3261">[RFC3261]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Schulzrinne, H.</span><span class="refAuthor">, Camarillo, G.</span><span class="refAuthor">, Johnston, A.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Sparks, R.</span><span class="refAuthor">, Handley, M.</span><span class="refAuthor">, and E. Schooler</span>, <span class="refTitle">"SIP: Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 3261</span>, <span class="seriesInfo">DOI 10.17487/RFC3261</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3264">[RFC3264]</dt>
        <dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor"> and H. Schulzrinne</span>, <span class="refTitle">"An Offer/Answer Model with Session Description Protocol (SDP)"</span>, <span class="seriesInfo">RFC 3264</span>, <span class="seriesInfo">DOI 10.17487/RFC3264</span>, <time datetime="2002-06" class="refDate">June 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3264">https://www.rfc-editor.org/info/rfc3264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3323">[RFC3323]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span>, <span class="refTitle">"A Privacy Mechanism for the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 3323</span>, <span class="seriesInfo">DOI 10.17487/RFC3323</span>, <time datetime="2002-11" class="refDate">November 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3323">https://www.rfc-editor.org/info/rfc3323</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3550">[RFC3550]</dt>
        <dd>
<span class="refAuthor">Schulzrinne, H.</span><span class="refAuthor">, Casner, S.</span><span class="refAuthor">, Frederick, R.</span><span class="refAuthor">, and V. Jacobson</span>, <span class="refTitle">"RTP: A Transport Protocol for Real-Time Applications"</span>, <span class="seriesInfo">STD 64</span>, <span class="seriesInfo">RFC 3550</span>, <span class="seriesInfo">DOI 10.17487/RFC3550</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3550">https://www.rfc-editor.org/info/rfc3550</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3711">[RFC3711]</dt>
        <dd>
<span class="refAuthor">Baugher, M.</span><span class="refAuthor">, McGrew, D.</span><span class="refAuthor">, Naslund, M.</span><span class="refAuthor">, Carrara, E.</span><span class="refAuthor">, and K. Norrman</span>, <span class="refTitle">"The Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 3711</span>, <span class="seriesInfo">DOI 10.17487/RFC3711</span>, <time datetime="2004-03" class="refDate">March 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3711">https://www.rfc-editor.org/info/rfc3711</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4566">[RFC4566]</dt>
        <dd>
<span class="refAuthor">Handley, M.</span><span class="refAuthor">, Jacobson, V.</span><span class="refAuthor">, and C. Perkins</span>, <span class="refTitle">"SDP: Session Description Protocol"</span>, <span class="seriesInfo">RFC 4566</span>, <span class="seriesInfo">DOI 10.17487/RFC4566</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4566">https://www.rfc-editor.org/info/rfc4566</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4568">[RFC4568]</dt>
        <dd>
<span class="refAuthor">Andreasen, F.</span><span class="refAuthor">, Baugher, M.</span><span class="refAuthor">, and D. Wing</span>, <span class="refTitle">"Session Description Protocol (SDP) Security Descriptions for Media Streams"</span>, <span class="seriesInfo">RFC 4568</span>, <span class="seriesInfo">DOI 10.17487/RFC4568</span>, <time datetime="2006-07" class="refDate">July 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4568">https://www.rfc-editor.org/info/rfc4568</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4916">[RFC4916]</dt>
        <dd>
<span class="refAuthor">Elwell, J.</span>, <span class="refTitle">"Connected Identity in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 4916</span>, <span class="seriesInfo">DOI 10.17487/RFC4916</span>, <time datetime="2007-06" class="refDate">June 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4916">https://www.rfc-editor.org/info/rfc4916</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5763">[RFC5763]</dt>
        <dd>
<span class="refAuthor">Fischl, J.</span><span class="refAuthor">, Tschofenig, H.</span><span class="refAuthor">, and E. Rescorla</span>, <span class="refTitle">"Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 5763</span>, <span class="seriesInfo">DOI 10.17487/RFC5763</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5763">https://www.rfc-editor.org/info/rfc5763</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7258">[RFC7258]</dt>
        <dd>
<span class="refAuthor">Farrell, S.</span><span class="refAuthor"> and H. Tschofenig</span>, <span class="refTitle">"Pervasive Monitoring Is an Attack"</span>, <span class="seriesInfo">BCP 188</span>, <span class="seriesInfo">RFC 7258</span>, <span class="seriesInfo">DOI 10.17487/RFC7258</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7258">https://www.rfc-editor.org/info/rfc7258</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7675">[RFC7675]</dt>
        <dd>
<span class="refAuthor">Perumal, M.</span><span class="refAuthor">, Wing, D.</span><span class="refAuthor">, Ravindranath, R.</span><span class="refAuthor">, Reddy, T.</span><span class="refAuthor">, and M. Thomson</span>, <span class="refTitle">"Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness"</span>, <span class="seriesInfo">RFC 7675</span>, <span class="seriesInfo">DOI 10.17487/RFC7675</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7675">https://www.rfc-editor.org/info/rfc7675</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7879">[RFC7879]</dt>
        <dd>
<span class="refAuthor">Ravindranath, R.</span><span class="refAuthor">, Reddy, T.</span><span class="refAuthor">, Salgueiro, G.</span><span class="refAuthor">, Pascual, V.</span><span class="refAuthor">, and P. Ravindran</span>, <span class="refTitle">"DTLS-SRTP Handling in SIP Back-to-Back User Agents"</span>, <span class="seriesInfo">RFC 7879</span>, <span class="seriesInfo">DOI 10.17487/RFC7879</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7879">https://www.rfc-editor.org/info/rfc7879</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8224">[RFC8224]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor">, Jennings, C.</span><span class="refAuthor">, Rescorla, E.</span><span class="refAuthor">, and C. Wendt</span>, <span class="refTitle">"Authenticated Identity Management in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 8224</span>, <span class="seriesInfo">DOI 10.17487/RFC8224</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8224">https://www.rfc-editor.org/info/rfc8224</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8225">[RFC8225]</dt>
        <dd>
<span class="refAuthor">Wendt, C.</span><span class="refAuthor"> and J. Peterson</span>, <span class="refTitle">"PASSporT: Personal Assertion Token"</span>, <span class="seriesInfo">RFC 8225</span>, <span class="seriesInfo">DOI 10.17487/RFC8225</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8225">https://www.rfc-editor.org/info/rfc8225</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8226">[RFC8226]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor"> and S. Turner</span>, <span class="refTitle">"Secure Telephone Identity Credentials: Certificates"</span>, <span class="seriesInfo">RFC 8226</span>, <span class="seriesInfo">DOI 10.17487/RFC8226</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8226">https://www.rfc-editor.org/info/rfc8226</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8445">[RFC8445]</dt>
        <dd>
<span class="refAuthor">Keranen, A.</span><span class="refAuthor">, Holmberg, C.</span><span class="refAuthor">, and J. Rosenberg</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal"</span>, <span class="seriesInfo">RFC 8445</span>, <span class="seriesInfo">DOI 10.17487/RFC8445</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8445">https://www.rfc-editor.org/info/rfc8445</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8838">[RFC8838]</dt>
        <dd>
<span class="refAuthor">Ivov, E.</span><span class="refAuthor">, Uberti, J.</span><span class="refAuthor">, and P. Saint-Andre</span>, <span class="refTitle">"Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol"</span>, <span class="seriesInfo">RFC 8838</span>, <span class="seriesInfo">DOI 10.17487/RFC8838</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8838">https://www.rfc-editor.org/info/rfc8838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8839">[RFC8839]</dt>
        <dd>
<span class="refAuthor">Petit-Huguenin, M.</span><span class="refAuthor">, Nandakumar, S.</span><span class="refAuthor">, Holmberg, C.</span><span class="refAuthor">, Keränen, A.</span><span class="refAuthor">, and R. Shpount</span>, <span class="refTitle">"Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)"</span>, <span class="seriesInfo">RFC 8839</span>, <span class="seriesInfo">DOI 10.17487/RFC8839</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8839">https://www.rfc-editor.org/info/rfc8839</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8840">[RFC8840]</dt>
      <dd>
<span class="refAuthor">Ivov, E.</span><span class="refAuthor">, Stach, T.</span><span class="refAuthor">, Marocco, E.</span><span class="refAuthor">, and C. Holmberg</span>, <span class="refTitle">"A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)"</span>, <span class="seriesInfo">RFC 8840</span>, <span class="seriesInfo">DOI 10.17487/RFC8840</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8840">https://www.rfc-editor.org/info/rfc8840</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-acme-authority-token">[ACME-Auth-Token]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor">, Barnes, M.</span><span class="refAuthor">, Hancock, D.</span><span class="refAuthor">, and C. Wendt</span>, <span class="refTitle">"ACME Challenges Using an Authority Token"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-acme-authority-token-05</span>, <time datetime="2020-03-09" class="refDate">9 March 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-acme-authority-token-05">https://tools.ietf.org/html/draft-ietf-acme-authority-token-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.kaplan-mmusic-best-effort-srtp">[Best-Effort-SRTP]</dt>
        <dd>
<span class="refAuthor">Kaplan, H.</span><span class="refAuthor"> and F. Audet</span>, <span class="refTitle">"Session Description Protocol (SDP) Offer/Answer Negotiation For Best-Effort Secure Real-Time Transport Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-kaplan-mmusic-best-effort-srtp-01</span>, <time datetime="2006-10-25" class="refDate">25 October 2006</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01">https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4474">[RFC4474]</dt>
        <dd>
<span class="refAuthor">Peterson, J.</span><span class="refAuthor"> and C. Jennings</span>, <span class="refTitle">"Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)"</span>, <span class="seriesInfo">RFC 4474</span>, <span class="seriesInfo">DOI 10.17487/RFC4474</span>, <time datetime="2006-08" class="refDate">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4474">https://www.rfc-editor.org/info/rfc4474</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6189">[RFC6189]</dt>
        <dd>
<span class="refAuthor">Zimmermann, P.</span><span class="refAuthor">, Johnston, A., Ed.</span><span class="refAuthor">, and J. Callas</span>, <span class="refTitle">"ZRTP: Media Path Key Agreement for Unicast Secure RTP"</span>, <span class="seriesInfo">RFC 6189</span>, <span class="seriesInfo">DOI 10.17487/RFC6189</span>, <time datetime="2011-04" class="refDate">April 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6189">https://www.rfc-editor.org/info/rfc6189</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6962">[RFC6962]</dt>
        <dd>
<span class="refAuthor">Laurie, B.</span><span class="refAuthor">, Langley, A.</span><span class="refAuthor">, and E. Kasper</span>, <span class="refTitle">"Certificate Transparency"</span>, <span class="seriesInfo">RFC 6962</span>, <span class="seriesInfo">DOI 10.17487/RFC6962</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6962">https://www.rfc-editor.org/info/rfc6962</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7245">[RFC7245]</dt>
        <dd>
<span class="refAuthor">Hutton, A., Ed.</span><span class="refAuthor">, Portman, L., Ed.</span><span class="refAuthor">, Jain, R.</span><span class="refAuthor">, and K. Rehor</span>, <span class="refTitle">"An Architecture for Media Recording Using the Session Initiation Protocol"</span>, <span class="seriesInfo">RFC 7245</span>, <span class="seriesInfo">DOI 10.17487/RFC7245</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7245">https://www.rfc-editor.org/info/rfc7245</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7435">[RFC7435]</dt>
        <dd>
<span class="refAuthor">Dukhovni, V.</span>, <span class="refTitle">"Opportunistic Security: Some Protection Most of the Time"</span>, <span class="seriesInfo">RFC 7435</span>, <span class="seriesInfo">DOI 10.17487/RFC7435</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7435">https://www.rfc-editor.org/info/rfc7435</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7616">[RFC7616]</dt>
        <dd>
<span class="refAuthor">Shekh-Yusef, R., Ed.</span><span class="refAuthor">, Ahrens, D.</span><span class="refAuthor">, and S. Bremer</span>, <span class="refTitle">"HTTP Digest Access Authentication"</span>, <span class="seriesInfo">RFC 7616</span>, <span class="seriesInfo">DOI 10.17487/RFC7616</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7616">https://www.rfc-editor.org/info/rfc7616</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8551">[RFC8551]</dt>
        <dd>
<span class="refAuthor">Schaad, J.</span><span class="refAuthor">, Ramsdell, B.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification"</span>, <span class="seriesInfo">RFC 8551</span>, <span class="seriesInfo">DOI 10.17487/RFC8551</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8551">https://www.rfc-editor.org/info/rfc8551</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8643">[RFC8643]</dt>
      <dd>
<span class="refAuthor">Johnston, A.</span><span class="refAuthor">, Aboba, B.</span><span class="refAuthor">, Hutton, A.</span><span class="refAuthor">, Jesske, R.</span><span class="refAuthor">, and T. Stach</span>, <span class="refTitle">"An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)"</span>, <span class="seriesInfo">RFC 8643</span>, <span class="seriesInfo">DOI 10.17487/RFC8643</span>, <time datetime="2019-08" class="refDate">August 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8643">https://www.rfc-editor.org/info/rfc8643</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">
    We thank <span class="contact-name">Eric Rescorla</span>, <span class="contact-name">Adam     Roach</span>, <span class="contact-name">Andrew Hutton</span>, and <span class="contact-name">Ben     Campbell</span> for contributions to this problem statement and framework.  We
    thank <span class="contact-name">Liang Xia</span> and <span class="contact-name">Alissa Cooper</span> for their careful review.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jon Peterson</span></div>
<div dir="auto" class="left"><span class="org">Neustar, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jon.peterson@team.neustar" class="email">jon.peterson@team.neustar</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Richard Barnes</span></div>
<div dir="auto" class="left"><span class="org">Cisco</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rlb@ipv.sx" class="email">rlb@ipv.sx</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Russ Housley</span></div>
<div dir="auto" class="left"><span class="org">Vigil Security, LLC</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:housley@vigilsec.com" class="email">housley@vigilsec.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>