<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     category="std" docName="draft-ietf-mmusic-dtls-sdp-32.txt" updates="5763,7345" docName="draft-ietf-mmusic-dtls-sdp-32"
     updates="5763, 7345" submissionType="IETF" xml:lang="en"> xml:lang="en" obsoletes=""
     tocInclude="true" symRefs="true" sortRefs="true" version="3"
     number="8842" consensus="true">

  <!-- xml2rfc v2v3 conversion 2.35.0 -->

  <front>
    <title>
        Session
    <title abbrev="SDP Offer/Answer Considerations for DTLS and TLS">Session
    Description Protocol (SDP) Offer/Answer Considerations for Datagram
    Transport Layer Security (DTLS) and Transport Layer Security (TLS)
    </title> (TLS)</title>
    <seriesInfo name="RFC" value="8842"/>
    <author fullname="Christer Holmberg" initials="C.H." initials="C." surname="Holmberg">
      <organization abbrev="Ericsson">Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <city>Jorvas</city>
                <region></region>
          <region/>
          <code>02420</code>
          <country>Finland</country>
        </postal>
            <phone></phone>
        <phone/>
        <email>christer.holmberg@ericsson.com</email>
      </address>
    </author>
    <author fullname="Roman Shpount" initials="R.S." initials="R." surname="Shpount">
      <organization abbrev="TurboBridge">TurboBridge</organization>
      <address>
        <postal>
          <street>4905 Del Ray Avenue, Suite 300</street>
          <city>Bethesda</city>
          <region>MD</region>
          <code>20814</code>
                <country>USA</country>
          <country>United States of America</country>
        </postal>
            <phone>+1 (240) 292-6632</phone>
        <email>rshpount@turbobridge.com</email>
      </address>
    </author>
    <date year="2017" /> month="January" year="2021"/>
    <area>RAI</area>

   <keyword>SDP</keyword>
   <keyword>DTLS</keyword>
   <keyword>tls-id</keyword>

    <abstract>
      <t>
        This document defines the Session Description Protocol (SDP)
        offer/answer procedures for negotiating and establishing a Datagram
        Transport Layer Security (DTLS) association.  The document also
        defines the criteria for when a new DTLS association must be
        established.  The document updates RFC RFCs 5763 and RFC 7345, 7345 by replacing
        common SDP offer/answer procedures with a reference to this
        specification.
      </t>
      <t>
            This document defines a new SDP media-level attribute, 'tls-id'. "tls-id".
      </t>
      <t>
         This document also defines how the 'tls-id' "tls-id" attribute can be used
         for negotiating and establishing a Transport Layer Security (TLS)
         connection, in conjunction with the procedures in RFC RFCs 4145 and RFC
         8122.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
                <xref format="default" pageno="false" target="RFC5763"/> defines Session
		Description Protocol (SDP)
                offer/answer procedures for Secure Realtime Real-time Transport
		Protocol Using using Datagram Transport Layer Security (DTLS-SRTP).
                <xref format="default" pageno="false" target="RFC7345"/> defines SDP
		offer/answer procedures for
                UDP Transport Layer over Datagram Transport Layer Security
		(UDPTL-DTLS). This specification
                defines general offer/answer procedures for DTLS, based on the
		procedures in <xref format="default" pageno="false" target="RFC5763"/>.
                Other specifications, defining specific DTLS usages, can then
		reference this specification,
                in order to ensure that the DTLS aspects are common among all
		usages. Having common
                procedures is essential when multiple usages share the same
                DTLS association <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>.
                The target="RFC8843" format="default"/>.
                This document updates <xref format="default" pageno="false" target="RFC5763"/>
                and <xref format="default" pageno="false" target="RFC7345"/>, target="RFC7345"/> by replacing common
                SDP offer/answer procedures with a reference to this specification.
      </t>
<aside>
      <t>
                NOTE: Since the publication of <xref format="default" pageno="false" target="RFC5763"/>,
                <xref format="default" pageno="false" target="RFC4474"/> has been obsoleted by
                <xref format="default" pageno="false" target="I-D.ietf-stir-rfc4474bis"/>. target="RFC8224"/>. The updating
                of the references (and the associated procedures) within <xref
		format="default" pageno="false" target="RFC5763"/> is outside the scope of
		this document. However, implementers of
                <xref format="default" pageno="false" target="RFC5763"/> applications are encouraged to
                implement <xref format="default" pageno="false" target="I-D.ietf-stir-rfc4474bis"/> target="RFC8224"/> instead
                of <xref format="default" pageno="false" target="RFC4474"/>.
      </t>
</aside>
      <t>
        As defined in <xref format="default" pageno="false" target="RFC5763"/>, a new DTLS association
                MUST
        <bcp14>MUST</bcp14> be established when transport parameters are
	changed. Transport parameter change is not
        well defined when Interactive Connectivity Establishment (ICE)
	<xref format="default"
                pageno="false" target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445"/> is
	used. One possible way to determine a transport change is
        based on ufrag <xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445"/> change,
        but the ufrag value is changed both when ICE is negotiated
        and when ICE restart <xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445"/> occurs. These events
        do not always require a new DTLS association to be established, but
	previously there was no way
        to explicitly indicate in an SDP offer or answer whether a new DTLS
	association is was required.
        To solve that problem, this document defines a new SDP attribute, 'tls-id'.
	"tls-id". The pair of
        SDP 'tls-id' "tls-id" attribute values (the attribute values of the offerer and the answerer)
        uniquely identifies the DTLS association. Providing a new value of the 'tls-id'
	"tls-id" attribute in an SDP offer
        or answers answer can be used to indicate whether a new DTLS association is
	to be established.
      </t>
      <t>
        The SDP 'tls-id' "tls-id" attribute can be specified when negotiating a
	Transport Layer Security (TLS) connection, using
        the procedures in this document in conjunction with the procedures in
	<xref format="default"
                pageno="false" target="RFC5763"/> and <xref format="default" pageno="false"
	target="RFC8122"/>.
        The unique combination of SDP 'tls-id' "tls-id" attribute values can be used to identity
	identify the negotiated
        TLS connection. The unique value can be used, for example, within TLS
	protocol extensions to
        differentiate between multiple TLS connections and correlate those
	connections with specific
        offer/answer exchanges.  The TLS specific TLS-specific considerations are described
	in <xref format="default"
                pageno="false" target="sec-tls-cons"/>.
      </t>
    </section>
    <section title="Conventions"> numbered="true" toc="default">
      <name>Conventions</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
            "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
            "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in
            BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>
    </section>
    <section title="Establishing numbered="true" toc="default">
      <name>Establishing a new New DTLS Association"> Association</name>
      <section title="General" anchor="sec-dtls-gen"> anchor="sec-dtls-gen" numbered="true" toc="default">
        <name>General</name>
        <t>
                A new DTLS association must be established between two endpoints after a
                successful SDP offer/answer exchange in the following cases:
                <list style="symbols">
                        <t>
        </t>
        <ul spacing="normal">
          <li>
            The negotiated DTLS setup roles change; or
                        </t>
                        <t>
          </li>
          <li>
            One or more fingerprint values are modified, added added,
            or removed in either an SDP offer or answer; or
                        </t>
                        <t>
          </li>
          <li>
            The intent to establish a new DTLS association is
            explicitly signaled using SDP, by changing the value of the
            SDP 'tls-id' "tls-id" attribute defined in this document;
                        </t>
                </list>
            </t>
          </li>
        </ul>
<aside>
 <t>
          NOTE: The first two items above are based on the procedures
          in <xref format="default" pageno="false" target="RFC5763"/>.
          This specification adds the support for explicit signaling using the
	  SDP 'tls-id' "tls-id" attribute.
        </t>
</aside>
        <t>
          A new DTLS association can only be established as a result of the
	  successful SDP offer/answer exchange.
          Whenever an entity determines that a new DTLS association is
	  required, the entity MUST <bcp14>MUST</bcp14> initiate an
          SDP offer/answer exchange, following the procedures in <xref target="sec-oa"/>.
	  target="sec-oa" format="default"/>.
        </t>
        <t>
          The sections below describe typical cases where a new DTLS
	  association needs to be established.
        </t>
        <t>
          In this document, a "new DTLS association" between two endpoints refers to either
          an initial DTLS association (when no DTLS association is currently
	  established between
          the endpoints) or an a DTLS association replacing a previously
	  established DTLS association. one.
        </t>
      </section>
      <section title="Change anchor="sec-dtls-transport" numbered="true" toc="default">
        <name>Change of Local Transport Parameters" anchor="sec-dtls-transport"> Parameters</name>
        <t>
                If an endpoint modifies its local transport parameters
		(address and/or port), and if the modification
                requires a new DTLS association, the endpoint MUST
		<bcp14>MUST</bcp14> change its local SDP 'tls-id' "tls-id"
                attribute value (see <xref target="sec-dcon-attr"/>). target="sec-dcon-attr" format="default"/>).
        </t>
        <t>
                If the underlying transport protocol prohibits a DTLS association from spanning multiple 5-tuples
                (transport/source address/source port/destination address/destination port),
                and if the 5-tuple is changed, the endpoint MUST <bcp14>MUST</bcp14> change its local SDP 'tls-id' "tls-id" attribute value (see <xref target="sec-dcon-attr"/>). target="sec-dcon-attr" format="default"/>).
                An example of such a case is when DTLS is carried over the Stream Control Transmission Protocol (SCTP),
                as described in <xref format="default" pageno="false" target="RFC6083"/>.
        </t>
      </section>
      <section title="Change anchor="sec-dtls-ufrag" numbered="true" toc="default">
        <name>Change of ICE ufrag value" anchor="sec-dtls-ufrag"> Value</name>
        <t>
          If an endpoint uses ICE, ICE and modifies a local ufrag value, and if the modification
          requires a new DTLS association, the endpoint MUST
	  <bcp14>MUST</bcp14> change its local SDP 'tls-id' "tls-id"
          attribute value (see <xref target="sec-dcon-attr"/>). target="sec-dcon-attr" format="default"/>).
        </t>
      </section>
    </section>

    <section title="SDP tls-id Attribute" anchor="sec-dcon-attr"> anchor="sec-dcon-attr" numbered="true" toc="default">
      <name>SDP "tls-id" Attribute</name>
      <t>
        The pair of SDP 'tls-id' "tls-id" attribute values (the attribute values of the
	offerer and the answerer)
        uniquely identifies the DTLS association or TLS connection.
      </t>
        <figure>
            <artwork align="left"><![CDATA[

       Name: tls-id

       Value: tls-id-value

       Usage Level: media

       Charset Dependent: no

       Default Value: N/A

       Syntax:

<dl newline="false">

      <dt>Name:</dt>
      <dd>tls-id</dd>

      <dt>Value:</dt>
      <dd>tls-id-value</dd>

      <dt>Usage Level:</dt>
      <dd>media</dd>

      <dt>Charset Dependent:</dt>
      <dd>no</dd>

      <dt>Default Value:</dt>
      <dd>N/A</dd>

      <dt>Syntax:</dt>
      <dd>
	<sourcecode type="abnf">
tls-id-value = 20*255(tls-id-char)
tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_"

           <ALPHA
	</sourcecode>
	<t>&lt;ALPHA and DIGIT defined in [RFC4566]>

       Example: RFC 4566&gt;</t>
      </dd>

    <dt>Example:</dt>
    <dd>
      <sourcecode type="sdp">
a=tls-id:abc3de65cddef001be82

            ]]></artwork>
        </figure>
      </sourcecode>
    </dd>
  </dl>

      <t>
            Every time an endpoint requests to establish a new DTLS
	    association, the endpoint MUST <bcp14>MUST</bcp14>
            generate a new local 'tls-id' "tls-id" attribute value. A non-changed An unchanged local 'tls-id'
	    "tls-id" attribute
            value, in combination with non-changed fingerprints, indicates
	    that the endpoint
            intends to reuse the existing DTLS association.
      </t>
      <t>
            The 'tls-id' "tls-id" attribute value MUST <bcp14>MUST</bcp14> be generated using a strong random function
            and include at least 120 bits of randomness.
      </t>
      <t>
            No default value is defined for the SDP 'tls-id' "tls-id" attribute.
            Implementations that wish to use the attribute MUST <bcp14>MUST</bcp14> explicitly
            include it in SDP offers and answers. If an offer or answer does not
            contain a 'tls-id' "tls-id" attribute (this could happen if the offerer or
            answerer represents an existing implementation that has not been
            updated to support the 'tls-id' "tls-id" attribute), unless there is
            another mechanism to explicitly indicate that a new DTLS association
            is to be established, a modification of one
	    or more of the following characteristics MUST <bcp14>MUST</bcp14> be
	    treated as an indication that an endpoint
            wants to establish a new DTLS association:
            <list style="symbols">
                    <t> association, unless there is
            another mechanism to explicitly indicate that a new DTLS association
            is to be established:
      </t>
      <ul spacing="normal">
        <li>
          DTLS setup role; or
                    </t>
                    <t>
        </li>
        <li>
          fingerprint set; or
                    </t>
                    <t>
        </li>
        <li>
          local transport parameters
                    </t>
            </list>
        </t>
        </li>
      </ul>
<aside>
      <t>
            NOTE: A modification of the ufrag value is not treated as an indication
            that an endpoint wants to establish a new DTLS assocation. association. In order to
            indicate that a new DTLS association is to be established, one or more
            of the characteristics listed above have to be modified.
      </t>
</aside>
      <t>
            The mux category <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> target="RFC8859" format="default"/>
            for the 'tls-id' "tls-id" attribute is 'IDENTICAL', "IDENTICAL", which means that
            the attribute value applies to all media descriptions
            being multiplexed <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>. target="RFC8843" format="default"/>.
            However, as described in <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>, target="RFC8843" format="default"/>,
            in order to avoid duplication duplication, the attribute is only associated with the "m=" line
            representing the offerer/answerer BUNDLE-tag. BUNDLE tag.
      </t>
      <t>
            For RTP-based media, the 'tls-id' "tls-id" attribute applies to the whole associated
            media description. The attribute MUST NOT <bcp14>MUST NOT</bcp14> be defined per source (using the
            SDP 'ssrc' "ssrc" attribute <xref format="default" pageno="false" target="RFC5576"/>).
      </t>
      <t>
            The SDP offer/answer procedures <xref format="default" pageno="false" target="RFC3264"/>
            procedures
            associated with the attribute are defined in <xref target="sec-oa"/>. target="sec-oa" format="default"/>.
      </t>
    </section>
    <section title="SDP anchor="sec-oa" numbered="true" toc="default">
      <name>SDP Offer/Answer Procedures" anchor="sec-oa"> Procedures</name>
      <section title="General"> numbered="true" toc="default">
        <name>General</name>
        <t>
                This section defines the generic SDP offer/answer procedures
		for negotiating
                a DTLS association. Additional procedures (e.g., regarding
		usage of specific SDP
                attributes etc.)
                attributes) for individual DTLS usages (e.g., DTLS-SRTP)
		are outside the scope
                of this specification, specification and need to be specified in a usage specific specification.
		usage-specific document.
        </t>
<aside>
        <t>
          NOTE: The procedures in this section are generalizations of procedures first
          specified in the DTLS-SRTP document <xref format="default" pageno="false" target="RFC5763"/>,
          with the addition of usage of the SDP 'tls-id' "tls-id" attribute. That document is
          herein updated to make use of these new procedures.
        </t>
</aside>
        <t>
          The procedures in this section apply to an SDP media description
	  ("m=" line) associated
          with DTLS-protected media/data.
        </t>
        <t>
          When an offerer or answerer indicates that it wants to establish a
	  new DTLS association, it needs to make sure that
          media packets associated with any previously established DTLS
	  association and the new DTLS association can be de-multiplexed. demultiplexed. In
	  the case
          of an ordered transport (e.g., SCTP) SCTP), this can be done simply by
	  sending packets for the new DTLS association
          after all packets associated with a previously established DTLS
	  association has have been sent. In the case of an unordered transport, such
	  as
          UDP, packets associated with a previously established DTLS
	  association can arrive after the answer SDP was received and after
	  the first packets associated with the new DTLS association were have been
	  received. The
	  only way to de-multiplex demultiplex packets associated with
                with
          a previously established DTLS association and the new DTLS
	  association is on the basis of the 5-tuple. Because of this, if an
	  unordered transport
          is used for the DTLS association, a new 3-tuple (transport/source
	  address/source port) MUST <bcp14>MUST</bcp14> be allocated by at least
	  one of the endpoints so that DTLS packets can be de-multiplexed. demultiplexed.
        </t>
        <t>
          When an offerer needs to establish a new DTLS association, and if an
	  unordered transport (e.g., UDP)
          is used, the offerer MUST <bcp14>MUST</bcp14> allocate a new 3-tuple for
	  the offer in such a way that the offerer can
          disambiguate any packets associated with the new DTLS association
	  from any packets associated with
          any other DTLS association. This typically means using a local
	  address and/or port, or a set of
          ICE candidates (see <xref format="default" pageno="false"
	  target="sec-dtls-reest-ice"/>), which were
          not recently used for any other DTLS association.
        </t>
        <t>
          When an answerer needs to establish a new DTLS association, if an
	  unordered transport is used, and if
          the offerer did not allocate a new 3-tuple, the answerer MUST
	  <bcp14>MUST</bcp14> allocate a new 3-tuple for the
          answer in such a way that it can disambiguate any packets associated
	  with the new DTLS association from any
          packets associated with any other DTLS association. This typically
	  means using a local address and/or
          port, or a set of ICE candidates (see <xref format="default" pageno="false"
	  target="sec-dtls-reest-ice"/>),
          which were not recently used for any other DTLS association.
        </t>
        <t>
                In order to negotiate a DTLS association, the following SDP attributes are used:
                <list style="symbols">
                    <t>
        </t>
        <ul spacing="normal">
          <li>
                        The SDP 'setup' "setup" attribute, defined in <xref target="RFC4145" pageno="false"
                        format="default" />, format="default"/>, is used to negotiate the DTLS roles;
                    </t>
                    <t>
                    </li>
          <li>
                        The SDP 'fingerprint' "fingerprint" attribute, defined in <xref format="default"
                        pageno="false" target="RFC8122"/>, is used to
                        provide one or more fingerprint values; and
                    </t>
                    <t>
                    </li>
          <li>
                        The SDP 'tls-id' "tls-id" attribute, defined in this specification, is used to identity
                        the DTLS association.
                    </t>
                </list>
            </t>
                    </li>
        </ul>
        <t>
                This specification does not define the usage of the SDP 'connection' "connection" attribute
                <xref target="RFC4145" pageno="false" format="default" /> format="default"/> for negotiating a DTLS
                association. However, the attribute MAY <bcp14>MAY</bcp14> be used if the DTLS association is used
                together with another protocol (e.g., SCTP or TCP) for which the usage of the
                attribute has been defined.
        </t>
        <t>
                Unlike for TCP and TLS connections, endpoints MUST NOT <bcp14>MUST NOT</bcp14> use the
                SDP 'setup' "setup" attribute 'holdconn' "holdconn" value when negotiating a DTLS association.
        </t>
        <t>
                Endpoints MUST <bcp14>MUST</bcp14> support the hash functions as defined in
                <xref format="default" pageno="false" target="RFC8122"/>.
        </t>
        <t>
                The certificate received during the DTLS handshake <xref format="default"
                pageno="false" target="RFC6347"/> MUST <bcp14>MUST</bcp14> match a certificate
                fingerprint received in SDP 'fingerprint' "fingerprint" attributes according to the procedures
                defined in <xref format="default" pageno="false" target="RFC8122"/>.
                If fingerprints do not match the hashed certificate, then an endpoint MUST <bcp14>MUST</bcp14> tear
                down the media session immediately (see <xref format="default" pageno="false" target="RFC8122"/>).
        </t>
        <t>
                SDP offerers and answerers might reuse certificates across multiple DTLS
                associations, and provide identical fingerprint values for each DTLS
                association. The combination of the SDP 'tls-id' "tls-id" attribute values of the SDP
                offerer and answerer identifies each individual DTLS association.
        </t>
<aside>
        <t>
          NOTE: There are cases where the SDP 'tls-id' "tls-id" attribute value generated by the
          offerer will end up being used for multiple DTLS associations. For that reason reason,
          the combination of the attribute values of the offerer and answerer is needed
          in order to identity a DTLS association. An example of such a case is where the
          offerer sends an updated offer (<xref target="sec-oa-mod"/>), target="sec-oa-mod"
	  format="default"/>) without modifying its
          attribute value, but the answerer determines that a new DTLS association is to
          be created. The answerer will generate a new local attribute value for the new
          DTLS association (<xref target="sec-oa-answer"/>), target="sec-oa-answer" format="default"/>), while the offerer will use the
          same attribute value that it used for the current association. Another example is
          when the Session Initiation Protocol (SIP) <xref format="default" pageno="false"
	  target="RFC3261"/> is used for signalling, signaling, and an offer is forked to
	  multiple answerers.
          The attribute value generated by the offerer will be used for DTLS associations
          established by each answerer.
        </t>
</aside>
      </section>
      <section title="Generating anchor="sec-oa-offer" numbered="true" toc="default">
        <name>Generating the Initial SDP Offer" anchor="sec-oa-offer"> Offer</name>
        <t>
          When an offerer sends the initial offer, the offerer MUST
	  <bcp14>MUST</bcp14> insert an SDP 'setup' "setup" attribute
          <xref format="default" pageno="false" target="RFC4145"/> with an 'actpass' "actpass"
	  attribute value, and as well as
          one or more SDP 'fingerprint' "fingerprint" attributes according to the procedures
	  in <xref format="default"
                pageno="false" target="RFC8122"/>. In addition, the
	  offerer MUST <bcp14>MUST</bcp14> insert in the offer an SDP
                'tls-id'
          "tls-id" attribute with a unique attribute value.
        </t>
        <t>
          As the offerer inserts the SDP 'setup' "setup" attribute with an 'actpass'
	  "actpass" attribute value, the
          offerer MUST <bcp14>MUST</bcp14> be prepared to receive a DTLS
	  ClientHello message <xref format="default" pageno="false" target="RFC6347"/>
	  from the answerer
	  (if a new DTLS association is established by the answerer) from the answerer
	  before the offerer receives the SDP answer.
        </t>
        <t>
          If the offerer receives a DTLS ClientHello message, and a DTLS
	  association is established, established
          before the offerer receives the SDP Answer answer carrying the
	  fingerprint associated with the DTLS
          association, any data received on the DTLS association before
	  the fingerprint MUST <bcp14>MUST</bcp14> be
          considered to be coming from an unverified source. The processing of
	  such data, data and sending of data
          by the offerer to the unverified source, source is outside the scope
	  of this document.
        </t>
      </section>
      <section title="Generating anchor="sec-oa-answer" numbered="true" toc="default">
        <name>Generating the Answer" anchor="sec-oa-answer"> Answer</name>
        <t>
                When an answerer sends an answer, the answerer MUST
		<bcp14>MUST</bcp14> insert in the answer an SDP 'setup' "setup"
		attribute
                according to the procedures in <xref format="default" pageno="false" target="RFC4145"/>,
		target="RFC4145"/> and one
                or more SDP 'fingerprint' "fingerprint" attributes according to the
		procedures in <xref format="default"
                pageno="false" target="RFC8122"/>.
                If the answerer determines, based on the criteria specified in
		<xref target="sec-dtls-gen"/>, target="sec-dtls-gen" format="default"/>,
                that a new DTLS association is to be established, the answerer MUST
		<bcp14>MUST</bcp14> insert in the associated answer
                an SDP 'tls-id' "tls-id" attribute with a new unique attribute
		value. Note that the offerer and answerer generate
                their own local 'tls-id' "tls-id" attribute values, and the combination
		of both values identify identifies the
                DTLS association.
        </t>
        <t>
                If the answerer receives an offer that requires establishment of a new DTLS association, and if the
                answerer does not accept the establishment of a new DTLS association, the answerer MUST <bcp14>MUST</bcp14> reject
                the "m=" lines associated with the suggested DTLS association
                <xref format="default" pageno="false" target="RFC3264"/>.
        </t>
        <t>
                If an answerer receives an offer that does not require the establishment of a new DTLS association,
                and if the answerer determines that a new DTLS association is not to be established,
                the answerer MUST <bcp14>MUST</bcp14> insert in the associated
		answer an SDP 'tls-id' "tls-id"
		attribute with the previously assigned attribute value in the
                associated answer. value. In
		addition, the answerer MUST
		<bcp14>MUST</bcp14> insert an SDP 'setup' "setup" attribute with an
                attribute value that does not change the previously negotiated
		DTLS roles, and as well as one or more SDP 'fingerprint' "fingerprint"
                attributes values that do not change the previously sent
		fingerprint set, in the associated answer.
        </t>
        <t>
          If the answerer receives an offer that does not contain an SDP 'tls-id' "tls-id" attribute,
          the answerer MUST NOT <bcp14>MUST NOT</bcp14> insert a 'tls-id' "tls-id" attribute in the answer.
        </t>
        <t>
          If a new DTLS association is to be established, and if the
	  answerer inserts an SDP 'setup' "setup"
          attribute with an 'active' "active" attribute value in the answer, the
	  answerer MUST <bcp14>MUST</bcp14> initiate a DTLS handshake
          <xref format="default" pageno="false" target="RFC6347"/>) target="RFC6347"/> by sending a DTLS
	  ClientHello message towards the offerer.
        </t>
        <t>
                Even though an offerer is required to insert an 'SDP' "SDP" setup attribute with an 'actpass' "actpass" attribute value
                in initial offers (<xref target="sec-oa-offer"/>) target="sec-oa-offer" format="default"/>) and subsequent offers (<xref target="sec-oa-mod"/>), target="sec-oa-mod" format="default"/>),
                the answerer MUST <bcp14>MUST</bcp14> be able to receive initial and subsequent offers with other attribute values, in order
                to be backward compatible with older implementations that might insert other attribute values in initial and
                subsequent offers.
        </t>
      </section>
      <section title="Offerer numbered="true" toc="default">
        <name>Offerer Processing of the SDP Answer"> Answer</name>
        <t>
                When an offerer receives an answer that establishes a new DTLS
		association based on
                criteria defined in <xref target="sec-dtls-gen"/>, and target="sec-dtls-gen"
		format="default"/>, if the offerer
                becomes DTLS client (based on the value of the SDP 'setup' "setup" attribute value
                <xref format="default" pageno="false" target="RFC4145"/>), the offerer MUST <bcp14>MUST</bcp14>
                establish a DTLS association. If the offerer becomes DTLS server, it MUST <bcp14>MUST</bcp14> wait for the answerer
                to establish the DTLS association.
        </t>
        <t>
                If the offerer indicated a desire to reuse an existing DTLS association
		association, and the
                answerer does not request the establishment of a new DTLS
		association, the offerer will
                continue to use the previously established DTLS association.
        </t>
        <t>
          A new DTLS association can be established based on changes in either
	  an SDP offer or answer.
          When communicating with legacy endpoints, an offerer can receive an
	  answer that includes the same
          fingerprint set and setup role. A new DTLS association will still be
	  established if such an answer
                was
          is received as a response to an offer which that requested the
	  establishment of a new DTLS association,
          as the transport parameters would have been changed in the offer.
        </t>
      </section>
      <section title="Modifying anchor="sec-oa-mod" numbered="true" toc="default">
        <name>Modifying the Session" anchor="sec-oa-mod"> Session</name>
        <t>
                When an offerer sends a subsequent offer, and if the offerer
		wants to establish a new
                DTLS association, the offerer MUST <bcp14>MUST</bcp14> insert an
		SDP 'setup' "setup" attribute <xref format="default"
                pageno="false"
		target="RFC4145"/> with an 'actpass' "actpass" attribute value, and one as well as
		or more SDP 'fingerprint' "fingerprint"
                attributes according to the procedures in <xref
		format="default" pageno="false" target="RFC8122"/>.
                In addition, the offerer MUST <bcp14>MUST</bcp14> insert in the offer an SDP 'tls-id' "tls-id" attribute with a new unique
                attribute value.
        </t>
        <t>
                When an offerer sends a subsequent offer, offer and the offerer does
		not want to establish
                a new DTLS association, and if a previously established DTLS
		association exists,
                the offerer MUST <bcp14>MUST</bcp14> insert in the offer an SDP 'setup' "setup"
		attribute with an 'actpass' "actpass" attribute value, and
                one or more SDP 'fingerprint' "fingerprint" attributes with attribute values
		that do not change the previously
                sent fingerprint set, in the offer. set. In addition, the offerer MUST
		<bcp14>MUST</bcp14> insert an SDP 'tls-id' "tls-id"
                attribute with the previously assigned attribute value in the offer.
        </t>
<aside>
        <t>
          NOTE: When a new DTLS association is being established, each
	  endpoint needs to be prepared to receive
          data on both the new and old DTLS associations as long as both are
	  alive.
        </t>
</aside>
      </section>
    </section>
    <section title="ICE Considerations" anchor="sec-dtls-reest-ice"> anchor="sec-dtls-reest-ice" numbered="true" toc="default">
      <name>ICE Considerations</name>
      <t>
            When the Interactive Connectivity Establishment (ICE) mechanism
            <xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> target="RFC8445"/> is used, the
            ICE connectivity checks are performed before the DTLS
            handshake begins. Note that if aggressive nomination mode is used,
            multiple candidate pairs may be marked valid before ICE finally
            converges on a single candidate pair.
      </t>
<aside>
      <t>
        NOTE: Aggressive nomination has been deprecated from ICE, ICE but must still be
        supported for backwards compatibility reasons <xref format="default" pageno="false"
            target="I-D.ietf-ice-rfc5245bis"/>.
	target="RFC8445"/>.
      </t>
</aside>
      <t>
            When a new DTLS association is established over an unordered
	    transport, in order to
            disambiguate any packets associated with the newly established
	    DTLS association, at least
            one of the endpoints MUST <bcp14>MUST</bcp14> allocate a completely new
	    set of ICE candidates which that
            were not recently used for any other DTLS association. This means the answerer
            cannot initiate a new DTLS association unless the offerer initiated ICE restart
            <xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/>. target="RFC8445"/>. If the answerer wants
            to initiate a new DTLS association, it needs to initiate an ICE restart
            and a new offer/answer exchange on its own. However, an ICE restart does not by
            default require a new DTLS association
            to be established.
      </t>
<aside>
      <t>
        NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets
	are sent directly
        over UDP, not over DTLS. <xref format="default" pageno="false" target="RFC7983"/> describes
        how to demultiplex STUN packets from DTLS packets and SRTP packets.
      </t>
</aside>
      <t>
            Each ICE candidate associated with a component is treated as being part of the
            same DTLS association. Therefore, from a DTLS perspective perspective, it is not considered
            a change of local transport parameters when an endpoint switches between those
            ICE candidates.
      </t>
    </section>
    <section title="TLS Considerations" anchor="sec-tls-cons"> anchor="sec-tls-cons" numbered="true" toc="default">
      <name>TLS Considerations</name>
      <t>
            The procedures in this document can also be used for negotiating and
            establishing a TLS connection, with the restriction described below.
      </t>
      <t>
            As specified in <xref format="default" pageno="false" target="RFC4145"/>,
            the SDP 'connection' "connection" attribute is used to indicate whether to establish a new
            TLS connection. An offerer and answerer MUST <bcp14>MUST</bcp14> ensure
	    that the 'connection' "connection"
            attribute value and the 'tls-id' "tls-id" attribute value does do not cause a conflict
            regarding whether a new TLS connection is to be established or not.
      </t>
<aside>
      <t>
            NOTE: Even though the SDP 'connection' "connection" attribute can be used to indicate
            whether a new TLS connection is to be established, the unique combination
            of SDP 'tls-id' "tls-id" attribute values can be used to identity a TLS connection.
            The unique value can be used e.g., within TLS protocol extensions to differentiate
            between multiple TLS connections and correlate those connections with specific
            offer/answer exchanges. One such extension is defined in
            <xref format="default" pageno="false" target="I-D.ietf-mmusic-sdp-uks"/>. target="RFC8844"/>.
      </t>
</aside>
      <t>
            If an offerer or answerer inserts an SDP 'connection' "connection" attribute with a 'new' "new"
            value in the offer/answer and also inserts an SDP 'tls-id' "tls-id" attribute,
            the value of tls-id' the "tls-id" attribute MUST <bcp14>MUST</bcp14> be new and unique.
      </t>
      <t>
        If an offerer or answerer inserts an SDP 'connection' "connection" attribute with a 'existing' an "existing"
        value in the offer/answer, if a previously established TLS connection exists, and
        if the offerer/answerer previously inserted an SDP 'tls-id' "tls-id" attribute associated with
        the same TLS connection in an offer/answer, the offerer/answerer MUST
	<bcp14>MUST</bcp14> also insert
        an SDP 'tls-id' "tls-id" attribute with the previously assigned value in the offer/answer.
      </t>
      <t>
            If an offerer or answerer receives an offer/answer with conflicting attribute values,
            the offerer/answerer MUST <bcp14>MUST</bcp14> process the offer/answer as misformed.
      </t>
      <t>
            An endpoint MUST NOT <bcp14>MUST NOT</bcp14> make assumptions regarding the
	    support of the SDP 'tls-id' "tls-id"
            attribute by the peer. Therefore, to avoid ambiguity, both
	    offerers and answerers
            MUST
            <bcp14>MUST</bcp14> always use the 'connection' "connection" attribute in
	    conjunction with the 'tls-id' "tls-id" attribute.
      </t>
<aside>
      <t>
            NOTE: As defined in <xref format="default" pageno="false" target="RFC4145"/>, if the
            SDP 'connection' "connection" attribute is not explicitly present, the implicit
	    default value is 'new'. "new".
      </t>
</aside>
      <t>
        The SDP example below is based on the example in section 3.4 of
        <xref format="default" pageno="false" target="RFC8122"/>, target="RFC8122" sectionFormat="of"
	      section="3.4"/>, with the addition of
        the SDP 'tls-id' "tls-id" attribute.
      </t>
        <figure>
            <artwork align="left"><![CDATA[

<sourcecode type="sdp" >
m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=tls-id:abc3de65cddef001be82
a=setup:passive
a=connection:new
a=fingerprint:SHA-256 \
 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
 3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \
 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

            ]]></artwork>
        </figure>
</sourcecode>

    </section>
    <section title="SIP Considerations"> numbered="true" toc="default">
      <name>SIP Considerations</name>
      <t>
        When the Session Initiation Protocol (SIP) <xref format="default" pageno="false"
	target="RFC3261"/> is used as the signal protocol for establishing
	a multimedia
        session, dialogs <xref format="default" pageno="false" target="RFC3261"/> might be
        established between the caller and multiple callees. This is referred to as forking.
        If forking occurs, separate DTLS associations will be established between the caller
        and each callee.
      </t>
      <t>
        When forking occurs, an SDP offerer can receive DTLS ClientHello
	messages and SDP
            answerers
        answers from multiple remote locations. Because of this, the
	offerer might have to
        wait for multiple SDP answers (from different remote locations)
	until it receives
        a certificate fingerprint that matches the certificate associated
	with a specific
        DTLS handshake. The offerer MUST NOT <bcp14>MUST NOT</bcp14> declare a
	fingerprint mismatch until it
        determines that it will not receive SDP answers from any
	additional remote locations.
      </t>
      <t>
            It is possible to send an INVITE request which that does not contain an SDP offer. Such
            an INVITE request is often referred to as an 'empty INVITE', "empty INVITE" or an 'offer-less INVITE'.
	    "offerless INVITE".
            The receiving endpoint will include the SDP offer in a response to the request.
            When the endpoint generates such an SDP offer, if a previously established
            DTLS association exists, the offerer MUST <bcp14>MUST</bcp14> insert an SDP 'tls-id'
            attribute, "tls-id"
            attribute and one or more SDP 'fingerprint' "fingerprint" attributes, with previously assigned
            attribute values. If a previously established DTLS association did does not exist,
            the offer MUST <bcp14>MUST</bcp14> be generated based on the same rules as a new offer (see <xref target="sec-oa-offer"/>). target="sec-oa-offer" format="default"/>).
            Regardless of the previous existence of a DTLS association, the
	    SDP 'setup' "setup" attribute
            MUST
            <bcp14>MUST</bcp14> be included according to the rules defined in
	    <xref format="default" pageno="false" target="RFC4145"/>. Furthermore, if ICE is
	    used, ICE restart <bcp14>MUST</bcp14> be initiated, according to
	    the third party call control third-party call-control
            considerations described in <xref target="I-D.ietf-mmusic-ice-sip-sdp"/>, ICE restart
            MUST be initiated.
	    target="RFC8839" format="default"/>.
      </t>
    </section>
    <section title="RFC Updates"> numbered="true" toc="default">
      <name>RFC Updates</name>
      <section title="General"> numbered="true" toc="default">
        <name>General</name>
        <t>
                This section updates specifications that use DTLS-protected media, in
                order to reflect the procedures defined in this specification.
        </t>
      </section>
      <section title="Update numbered="true" toc="default">
        <name>Update to RFC 5763"> 5763</name>
        <section title="Update numbered="true" toc="default">
          <name>Update to section 1"> Section 1</name>
          <t>The reference to <xref format="default" pageno="false" target="RFC4572"/> is replaced
            with a reference to <xref format="default" pageno="false" target="RFC8122"/>.</t>
        </section>
        <section title="Update numbered="true" toc="default">
          <name>Update to section 5"> Section 5</name>
          <t>The text in section 5 (Establishing <xref target="RFC5763" section="5" sectionFormat="comma"/> ("Establishing a Secure Channel) Channel") is modified
	  by replacing generic
          SDP offer/answer procedures for DTLS with a reference to this
	  specification:
          </t>
            <figure>
                <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[

NEW TEXT:

<t>NEW TEXT:</t>
<blockquote>
<t>
   The two endpoints in the exchange present their identities as part of
   the DTLS handshake procedure using certificates. This document uses
   certificates in the same style as described in "Connection-Oriented
   Media Transport over the Transport Layer Security (TLS) Protocol in
   the Session Description Protocol (SDP)" [RFC8122]. <xref target="RFC8122" />.
</t>
<t>
   If self-signed certificates are used, the content of the
   subjectAltName
   "subjectAltName" attribute inside the certificate MAY <bcp14>MAY</bcp14> use the uniform
   resource identifier (URI) of the user. This is useful for debugging
   purposes only and is not required to bind the certificate to one of
   the communication endpoints.  The integrity of the certificate is
   ensured through the fingerprint "fingerprint" attribute in the SDP.
</t>
<t>
   The generation of public/private key pairs is relatively expensive.
   Endpoints are not required to generate certificates for each session.
</t>
<t>
   The offer/answer model, defined in [RFC3264], <xref target="RFC3264"/>, is used by protocols
   like the Session Initiation Protocol (SIP) [RFC3261] <xref target="RFC3261" /> to set up
   multimedia sessions.
</t>
<t>
   When an endpoint wishes to set up a secure media session with another
   endpoint, it sends an offer in a SIP message to the other endpoint.
   This offer includes, as part of the SDP payload, a fingerprint of
   a certificate that the endpoint wants to use. The endpoint SHOULD <bcp14>SHOULD</bcp14>
   send the SIP message containing the offer to the offerer's SIP proxy
   over an integrity protected integrity-protected channel. The proxy SHOULD <bcp14>SHOULD</bcp14> add an
   Identity header field according to the procedures outlined in
   [RFC4474].
   <xref target="RFC4474" />. When the far endpoint receives the SIP message, it can
   verify the identity of the sender using the Identity header field.
   Since the Identity header field is a digital signature across several
   SIP header fields, in addition to the body of the SIP message, the
   receiver can also be certain that the message has not been tampered
   with after the digital signature was applied and added to the SIP
   message.
</t>
<t>
   The far endpoint (answerer) may now establish a DTLS association with
   the offerer. Alternately, it can indicate in its answer that the
   offerer is to initiate the DTLS association. In either case, mutual
   DTLS certificate-based authentication will be used. After completing
   the DTLS handshake, information about the authenticated identities,
   including the certificates, are is made available to the endpoint
   application. The answerer is then able to verify that the offerer's
   certificate used for authentication in the DTLS handshake can be
   associated to with a certificate fingerprint contained in the offer in
   the SDP. At this point, the answerer may indicate to the end user
   that the media is secured. The offerer may only tentatively accept
   the answerer's certificate certificate, since it may not yet have the answerer's
   certificate fingerprint. fingerprint
</t>
<t>
   When the answerer accepts the offer, it provides an answer back to
   the offerer containing the answerer's certificate fingerprint. At
   this point, the offerer can accept or reject the peer's certificate certificate,
   and the offerer can indicate to the end user that the media is
   secured.
</t>
<t>
   Note that the entire authentication and key exchange for securing
   the media traffic is handled in the media path through DTLS. The
   signaling path is only used to verify the peers' certificate
   fingerprints.
</t>
<t>
   The offerer and answerer MUST <bcp14>MUST</bcp14> follow the SDP offer/answer procedures
   defined in [RFCXXXX].

          ]]></artwork>
        </figure> RFC 8842.
</t>
</blockquote>
        </section>
        <section title="Update numbered="true" toc="default">
          <name>Update to section 6.6"> Section 6.6</name>
          <t>The text in section 6.6 (Session Modification) <xref target="RFC5763" section="6.6" sectionFormat="comma"/> ("Session Modification") is modified by replacing generic
            SDP offer/answer procedures for DTLS with a reference to this specification:
          </t>
       <figure>
           <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[

<t>
NEW TEXT:
</t>
<blockquote>
<t>
   Once an answer is provided to the offerer, either endpoint MAY <bcp14>MAY</bcp14>
   request a session modification that MAY <bcp14>MAY</bcp14> include an updated offer.
   This session modification can be carried in either an INVITE or
   UPDATE request. The peers can reuse an existing DTLS association, association
   or establish a new one, following the procedures in [RFCXXXX].

   ]]></artwork>
 </figure> RFC 8842.
</t></blockquote>
        </section>
        <section title="Update numbered="true" toc="default">
          <name>Update to section 6.7.1"> Section 6.7.1</name>
          <t>The text in section 6.7.1 (ICE Interaction) <xref target="RFC5763" section="6.7.1" sectionFormat="comma"/> ("ICE Interaction") is modified by
	  replacing the ICE procedures with
	  a reference to this specification:
          </t>
<figure>
    <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[

<t>
NEW TEXT:
</t>
<blockquote>
   The Interactive Connectivity Establishment (ICE)
   [I-D.ietf-ice-rfc5245bis]
   <xref target="RFC8445" /> considerations for DTLS-protected media
   are described in [RFCXXXX].
                ]]></artwork>
            </figure> RFC 8842.
</blockquote>
        </section>
      </section>
      <section title="Update numbered="true" toc="default">
        <name>Update to RFC 7345"> 7345</name>
        <section title="Update numbered="true" toc="default">
          <name>Update to section 4"> Section 4</name>
          <t>The subsections (4.1.-4.5.) (4.1 - 4.5) in section 4 (SDP <xref target="RFC7345" section="4"
	  sectionFormat="comma"/> ("SDP Offerer/Answerer Procedures)
	  Procedures") are removed, removed and replaced with the new text below:</t>
            <figure>
                <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[

NEW TEXT:

<t>NEW TEXT:</t>
<blockquote>

<t>
   An endpoint (i.e., both the offerer and the answerer) MUST <bcp14>MUST</bcp14> create an
   SDP media description ("m=" line) for each UDPTL-over-DTLS media
   stream and MUST <bcp14>MUST</bcp14> assign a UDP/TLS/UDPTL value (see Table 1) to the
   "proto" field of the "m=" line.
</t>
<t>
   The offerer and answerer MUST <bcp14>MUST</bcp14> follow the SDP offer/answer procedures
   defined in [RFCXXXX] RFC 8842 in order to negotiate the DTLS association
   associated with the UDPTL-over-DTLS media stream. In addition,
   the offerer and answerer MUST <bcp14>MUST</bcp14> use the SDP attributes defined for
   UDPTL over UDP, as defined in [ITU.T38.2010].

   ]]></artwork>
 </figure> <xref target="ITU.T38" />.
</t>
</blockquote>

        </section>
        <section title="Update numbered="true" toc="default">
          <name>Update to section 5.2.1"> Section 5.2.1</name>
          <t>The text in section 5.2.1 (ICE Usage) <xref target="RFC7345" section="5.2.1"
          sectionFormat="comma"/> ("ICE Usage") is modified by replacing the
          ICE procedures with a reference to this specification:
          </t>
<figure>
    <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[

<t>
NEW TEXT:
</t>
<blockquote>
   The Interactive Connectivity Establishment (ICE)
   [I-D.ietf-ice-rfc5245bis]
   <xref target="RFC8445" /> considerations for DTLS-protected media
   are described in [RFCXXXX].

   [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX
   with the RFC number of this document.]

                ]]></artwork>
            </figure> 8842.
</blockquote>

        </section>
        <section title="Update numbered="true" toc="default">
          <name>Update to section 10.1"> Section 9.1</name>
          <t>A reference to <xref format="default" pageno="false" target="RFC8122"/> is added
	  to section 10.1 (Normative References):</t>
            <figure>
                <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[ <xref target="RFC7345" section="9.1"
          sectionFormat="comma"/> ("Normative References"):</t>

<t>
NEW TEXT:

[RFC8122]  Lennox,
</t>
<blockquote>
<dl indent="12">
<dt>[RFC8122]</dt>
<dd>Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS)
Protocol in the Session Description Protocol (SDP)",
RFC 8122, DOI 10.17487/RFC8122, March 2017,
           <http://www.rfc-editor.org/info/rfc8122>.

          ]]></artwork>
        </figure>
<eref brackets="angle" target="https://www.rfc-editor.org/info/rfc8122"/>.
</dd>
</dl>
</blockquote>

        </section>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
            This specification does not modify the security considerations
	    associated with DTLS, DTLS or
            the SDP offer/answer mechanism. In addition to the introduction of the SDP
            'tls-id'
            "tls-id" attribute, the specification this document simply clarifies the procedures for
            negotiating and establishing a DTLS association.
      </t>
      <t>
            This specification does not modify the actual TLS connection setup procedures. The
            SDP 'tls-is' "tls-is" attribute as such cannot be used to correlate an SDP Offer/Answer
	    offer/answer exchange with a
            TLS connection setup. Thus, this draft document does not introduce new
	    security considerations
            related to correlating an SDP Offer/Answer offer/answer exchange with a TLS connection setup.
      </t>
    </section>
    <section anchor="section.iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
            This document updates the "Session Description Protocol Parameters" registry
            as specified in Section 8.2.2 of <xref target="RFC4566" pageno="false" format="default"/>.
	    format="default" sectionFormat="of" section="8.2.2" />.
            Specifically, it adds the SDP 'tls-id' "tls-id" attribute to the table for SDP
            media level attributes.
        </t>
        <figure>
            <artwork align="left"><![CDATA[

    Attribute name: tls-id
    Type of attribute:
            media-level
    Subject to charset: no
    Purpose: Indicates attributes as follows.
      </t>

      <dl>

      <dt>Attribute name:</dt>
      <dd>tls-id</dd>

      <dt>Type of attribute:</dt>
      <dd>Media-level</dd>

      <dt>Subject to charset:</dt>
      <dd>No</dd>

      <dt>Purpose:</dt>
      <dd>Indicates whether a new DTLS association or TLS connection is to be established/re-established.
    Appropriate Values: see Section 4
    Contact name: Christer Holmberg
    Mux Category: IDENTICAL

            ]]></artwork>
        </figure>
      established/re-established.</dd>

      <dt>Appropriate Values:</dt>
      <dd>See <xref target="sec-dcon-attr" /></dd>

      <dt>Contact name:</dt>
      <dd>Christer Holmberg</dd>

      <dt>Mux Category:</dt>
      <dd>IDENTICAL</dd>

  </dl>

    </section>
  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4145.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7345.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8122.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>

<!-- draft-ietf-mmusic-sdp-mux-attributes-17 (RFC 8859) -->
        <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859">
          <front>
            <title>A Framework for Session Description Protocol (SDP)
            Attributes When Multiplexing</title>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
              <organization/>
            </author>
            <date month="January" year="2021"/>
          </front>
            <seriesInfo name="RFC" value="8859"/>
            <seriesInfo name="DOI" value="10.17487/RFC8859"/>

        </reference>

<!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) C238 -->
    <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843">
      <front>
        <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
        <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
          <organization/>
        </author>
        <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
          <organization/>
        </author>
        <author initials="C" surname="Jennings" fullname="Cullen Jennings">
          <organization/>
        </author>
        <date month="January" year="2021"/>
      </front>
        <seriesInfo name="RFC" value="8843"/>
        <seriesInfo name="DOI" value="10.17487/RFC8843"/>
    </reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4474.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4572.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5576.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6083.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7983.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8224.xml"/>

<!-- draft-ietf-mmusic-ice-sip-sdp-39  RFC-to-be 8839 C238 -->

<reference anchor='RFC8839' target="https://www.rfc-editor.org/info/rfc8839">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)</title>

<author initials='M' surname='Petit-Huguenin' fullname='Marc Petit-Huguenin'>
    <organization />
</author>

<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
    <organization />
</author>

<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
</author>

<author initials='A' surname='Keränen' fullname='Ari Keränen'>
    <organization />
</author>

<author initials='R' surname='Shpount' fullname='Roman Shpount'>
    <organization />
</author>

<date month="January" year="2021"/>

</front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>

</reference>

<!-- draft-ietf-mmusic-sdp-uks in C238 -->
<reference anchor='RFC8844' target="https://www.rfc-editor.org/info/rfc8844">
<front>
<title>Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)</title>
<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8844"/>
<seriesInfo name="DOI" value="10.17487/RFC8844"/>
</reference>

        <reference anchor="ITU.T38" target="https://www.itu.int/rec/T-REC-T.38/en">
          <front>
            <title>Procedures for real-time Group 3 facsimile communication over IP networks</title>
            <seriesInfo name="Recommendation" value="T.38"/>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date year="2010" month="September"/>
          </front>
        </reference>
      </references>
    </references>
    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
            Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
            Charles Eckel, Gonzalo Salgueiro and Paul Jones <contact fullname="Justin Uberti"/>, <contact
            fullname="Martin Thomson"/>, <contact fullname="Paul Kyzivat"/>,
            <contact fullname="Jens Guballa"/>, <contact fullname="Charles
            Eckel"/>, <contact fullname="Gonzalo Salgueiro"/>, and <contact
            fullname="Paul Jones"/> for providing comments and suggestions on
            the document. Ben Campbell <contact fullname="Ben Campbell"/> performed an AD Area
            Director review. Paul
            Kyzivat <contact fullname="Paul Kyzivat"/> performed a gen-art
            Gen-ART review.
      </t>
    </section>
    <section title="Change Log">
        <t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-31
            <list style="symbols">
                <t>Changes based on IESG comments from Eric R</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-30
            <list style="symbols">
                <t>Changes based on IESG comments from Mirja K</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-29
            <list style="symbols">
                <t>Removal of ufrag value change as a trigger for a new DTLS association</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-28
            <list style="symbols">
                <t>Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey Melnikov and Mirja Kuhlewind:</t>
                <t>- Document title changed</t>
                <t>- Transport Protocol Considerations section removed</t>
                <t>- Additional text to Security Considerations section</t>
                <t>- Editorial changes</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-27
            <list style="symbols">
                <t>Reference fixes based on Gen-ART review by Paul Kyzivat.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-26
            <list style="symbols">
                <t>Editorial fixes based on Gen-ART review by Paul Kyzivat.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-25
            <list style="symbols">
                <t>Minor editorial nits.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-24
            <list style="symbols">
                <t>Changes based on 2nd WGLC comments from Roman S and Martin T:</t>
                <t>- RFC update structure shortened (old text removed).</t>
                <t>- Guidance regarding receiving ClientHello before SDP answer added.</t>
                <t>- Additional SIP considerations regarding forking.</t>
                <t>- SDP setup attribute value restriction in initial and subsequent offers based on comment from Ekr.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-23
            <list style="symbols">
                <t>Editorial change to make it clear that the document does not
                   modify the procedures in RFC 8122.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-22
            <list style="symbols">
                <t>Support for TLS added.</t>
                <t>Editorial changes based on sec-dir review by Rich Salz.</t>
                <t>Editorial changes based on gen-art review by Paul Kyzivat.</t>
                <t>Editorial changes based on ops-dir review by Carlos Pignataro.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-21
            <list style="symbols">
                <t>Changes based on AD review by Ben Campbell.</t>
                <t>(https://www.ietf.org/mail-archive/web/mmusic/current/msg17707.html)</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-20
            <list style="symbols">
                <t>Change to length and randomness of tls-id attribute value.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-19
            <list style="symbols">
                <t>Change based on comment from Roman.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-18
            <list style="symbols">
                <t>Changes based on comments from Flemming.</t>
                <t>- Change in tls-id value definition.</t>
                <t>- Editorial fixes.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-17
            <list style="symbols">
                <t>Reference fix.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-16
            <list style="symbols">
                <t>Editorial changes based on 2nd WGLC comments
                from Christian Groves and Nevenka Biondic.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-15
            <list style="symbols">
                <t>tls-id attribute value made globally unique</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-14
            <list style="symbols">
                <t>Changes based on comments from Flemming:</t>
                <t>- Additional dtls-is clarifications</t>
                <t>- Editorial fixes</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-13
            <list style="symbols">
                <t>Text about the updated RFCs added to Abstract and Introduction</t>
                <t>Reference to RFC 5763 removed from section 6 (ICE Considerations)</t>
                <t>Reference to RFC 5763 removed from section 8 (SIP Considerations)</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-12
            <list style="symbols">
                <t>"unreliable" changed to "unordered"</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-11
            <list style="symbols">
                <t>Attribute name changed to tls-id</t>
                <t>Additional text based on comments from Roman Shpount.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-10
            <list style="symbols">
                <t>Modified document to use tls-id instead of dtls-connection</t>
                <t>Changes are based on comments from Eric Rescorla, Justin Uberti, and Paul Kyzivat.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-08
            <list style="symbols">
                <t>Offer/Answer section modified in order to allow sending of multiple SDP 'fingerprint' attributes.</t>
                <t>Terminology made consistent: 'DTLS connection' replaced with 'DTLS association'.</t>
                <t>Editorial changes based on comments from Paul Kyzivat.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-07
            <list style="symbols">
                <t>Reference to RFC 7315 replaced with reference to RFC 7345.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-06
            <list style="symbols">
                <t>Text on restrictions regarding spanning a DTLS association over multiple transports added.</t>
                <t>Mux category added to IANA Considerations.</t>
                <t>Normative text regarding mux category and source-specific applicability added.</t>
                <t>Reference to RFC 7315 added.</t>
                <t>Clarified that offerer/answerer that has not been updated to support this specification will
                not include the tls-id attribute in offers and answers.</t>
                <t>Editorial corrections based on WGLC comments from Charles Eckel.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-05
            <list style="symbols">
                <t>Text on handling offer/answer error conditions added.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-04
            <list style="symbols">
                <t>Editorial nits fixed based on comments from Paul Kyzivat:</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-03
            <list style="symbols">
                <t>Changes based on comments from Paul Kyzivat:</t>
                <t>- Modification of tls-id attribute section.</t>
                <t>- Removal of IANA considerations subsection.</t>
                <t>- Making note into normative text in o/a section.</t>
                <t>Changes based on comments from Martin Thompson:</t>
                <t>- Abbreviations section removed.</t>
                <t>- Clarify that a new DTLS association requires a new o/a transaction.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-02
            <list style="symbols">
                <t>- Updated RFCs added to boilerplate.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-01
            <list style="symbols">
                <t>- Annex regarding 'tls-id-id' attribute removed.</t>
                <t>- Additional SDP offer/answer procedures, related to certificates, added.</t>
                <t>- Updates to RFC 5763 and RFC 7345 added.</t>
                <t>- Transport protocol considerations added.</t>
            </list>
        </t>
        <t>Changes from draft-ietf-mmusic-sdp-dtls-00
            <list style="symbols">
                <t>- SDP 'connection' attribute replaced with new 'tls-id' attribute.</t>
                <t>- IANA Considerations added.</t>
                <t>- E-mail regarding 'tls-id-id' attribute added as Annex.</t>
            </list>
        </t>
        <t>Changes from draft-holmberg-mmusic-sdp-dtls-01
            <list style="symbols">
                <t>- draft-ietf-mmusic version of draft submitted.</t>
                <t>- Draft file name change (sdp-dtls -> dtls-sdp) due to collision with another expired draft.</t>
                <t>- Clarify that if ufrag in offer is unchanged, it must be unchanged in associated answer.</t>
                <t>- SIP Considerations section added.</t>
                <t>- Section about multiple SDP fingerprint attributes added.</t>
            </list>
        </t>
        <t>Changes from draft-holmberg-mmusic-sdp-dtls-00
            <list style="symbols">
                <t>- Editorial changes and clarifications.</t>
            </list>
        </t>

    </section>
</middle>

<back>
    <references title="Normative References">
        <?rfc include="reference.RFC.2119"?>
        <?rfc include="reference.RFC.3261"?>
        <?rfc include="reference.RFC.3264"?>
        <?rfc include="reference.RFC.4145"?>
        <?rfc include="reference.RFC.4566"?>
        <?rfc include="reference.RFC.5763"?>
        <?rfc include="reference.RFC.6347"?>
        <?rfc include="reference.RFC.7345"?>
        <?rfc include="reference.RFC.8122"?>
        <?rfc include="reference.RFC.8174"?>
        <?rfc include="reference.I-D.draft-ietf-ice-rfc5245bis-13"?>
        <?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?>
        <?rfc include="reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-39"?>
    </references>
    <references title="Informative References">
        <?rfc include="reference.RFC.4474"?>
        <?rfc include="reference.RFC.4572"?>
        <?rfc include="reference.RFC.5576"?>
        <?rfc include="reference.RFC.6083"?>
        <?rfc include="reference.RFC.7983"?>
        <?rfc include="reference.I-D.draft-ietf-stir-rfc4474bis-16"?>
        <?rfc include="reference.I-D.draft-ietf-mmusic-ice-sip-sdp-14"?>
        <?rfc include="reference.I-D.draft-ietf-mmusic-sdp-uks-00"?>
        <reference anchor="ITU.T38.2010">
          <front>
          <title>Procedures for real-time Group 3 facsimile communication over IP networks</title>
          <author>
          <organization>International Telecommunications Union</organization>
          </author>
          <date year="2010" month="September"/>
          </front>
          <seriesInfo value="Recommendation T.38" name="ITU-T"/>
        </reference>
    </references>
  </back>
</rfc>