rfc8842xml2.original.xml   rfc8842.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='utf-8'?>
<!-- comment --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<?rfc compact="yes" ?> category="std" docName="draft-ietf-mmusic-dtls-sdp-32"
<?rfc sortrefs="no" ?> updates="5763, 7345" submissionType="IETF" xml:lang="en" obsoletes=""
<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-dtls-sdp-32.txt tocInclude="true" symRefs="true" sortRefs="true" version="3"
" updates="5763,7345" submissionType="IETF" xml:lang="en"> number="8842" consensus="true">
<!-- xml2rfc v2v3 conversion 2.35.0 -->
<front> <front>
<title> <title abbrev="SDP Offer/Answer Considerations for DTLS and TLS">Session
Session Description Protocol (SDP) Offer/Answer Considerations for Datag Description Protocol (SDP) Offer/Answer Considerations for Datagram
ram Transport Layer Security (DTLS) Transport Layer Security (DTLS) and Transport Layer Security (TLS)</title>
and Transport Layer Security (TLS) <seriesInfo name="RFC" value="8842"/>
</title> <author fullname="Christer Holmberg" initials="C." surname="Holmberg">
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg"> <organization abbrev="Ericsson">Ericsson</organization>
<organization abbrev="Ericsson">Ericsson</organization> <address>
<address> <postal>
<postal> <street>Hirsalantie 11</street>
<street>Hirsalantie 11</street> <city>Jorvas</city>
<city>Jorvas</city> <region/>
<region></region> <code>02420</code>
<code>02420</code> <country>Finland</country>
<country>Finland</country> </postal>
</postal> <phone/>
<phone></phone> <email>christer.holmberg@ericsson.com</email>
<email>christer.holmberg@ericsson.com</email> </address>
</address>
</author> </author>
<author fullname="Roman Shpount" initials="R.S." surname="Shpount"> <author fullname="Roman Shpount" initials="R." surname="Shpount">
<organization abbrev="TurboBridge">TurboBridge</organization> <organization abbrev="TurboBridge">TurboBridge</organization>
<address> <address>
<postal> <postal>
<street>4905 Del Ray Avenue, Suite 300</street> <street>4905 Del Ray Avenue, Suite 300</street>
<city>Bethesda</city> <city>Bethesda</city>
<region>MD</region> <region>MD</region>
<code>20814</code> <code>20814</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 (240) 292-6632</phone> <email>rshpount@turbobridge.com</email>
<email>rshpount@turbobridge.com</email> </address>
</address>
</author> </author>
<date month="January" year="2021"/>
<date year="2017" />
<area>RAI</area> <area>RAI</area>
<keyword>SDP</keyword>
<keyword>DTLS</keyword>
<keyword>tls-id</keyword>
<abstract> <abstract>
<t> <t>
This document defines the Session Description Protocol (SDP) offer/a This document defines the Session Description Protocol (SDP)
nswer procedures for offer/answer procedures for negotiating and establishing a Datagram
negotiating and establishing a Datagram Transport Layer Security (DT Transport Layer Security (DTLS) association. The document also
LS) association. defines the criteria for when a new DTLS association must be
The document also defines the criteria for when a new DTLS associati established. The document updates RFCs 5763 and 7345 by replacing
on must be established. common SDP offer/answer procedures with a reference to this
The document updates RFC 5763 and RFC 7345, by replacing common SDP specification.
offer/answer procedures </t>
with a reference to this specification. <t>
</t> This document defines a new SDP media-level attribute, "tls-id".
<t> </t>
This document defines a new SDP media-level attribute, 'tls-id'. <t>
</t> This document also defines how the "tls-id" attribute can be used
<t> for negotiating and establishing a Transport Layer Security (TLS)
This document also defines how the 'tls-id' attribute can be used fo connection, in conjunction with the procedures in RFCs 4145 and
r negotiating 8122.
and establishing a Transport Layer Security (TLS) connection, in con </t>
junction with
the procedures in RFC 4145 and RFC 8122.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t> <name>Introduction</name>
<xref format="default" pageno="false" target="RFC5763"/> defines <t>
Session Description Protocol (SDP) <xref format="default" target="RFC5763"/> defines Session
offer/answer procedures for Secure Realtime Transport Protocol U Description Protocol (SDP)
sing Datagram Transport Layer Security (DTLS-SRTP). offer/answer procedures for Secure Real-time Transport
<xref format="default" pageno="false" target="RFC7345"/> defines Protocol using Datagram Transport Layer Security (DTLS-SRTP).
SDP offer/answer procedures for <xref format="default" target="RFC7345"/> defines SDP
UDP Transport Layer over Datagram Transport Layer Security (UDPT offer/answer procedures for
L-DTLS). This specification UDP Transport Layer over Datagram Transport Layer Security
defines general offer/answer procedures for DTLS, based on the p (UDPTL-DTLS). This specification
rocedures in <xref format="default" pageno="false" target="RFC5763"/>. defines general offer/answer procedures for DTLS, based on the
Other specifications, defining specific DTLS usages, can then re procedures in <xref format="default" target="RFC5763"/>.
ference this specification, Other specifications, defining specific DTLS usages, can then
in order to ensure that the DTLS aspects are common among all us reference this specification,
ages. Having common in order to ensure that the DTLS aspects are common among all
usages. Having common
procedures is essential when multiple usages share the same procedures is essential when multiple usages share the same
DTLS association <xref target="I-D.ietf-mmusic-sdp-bundle-negoti DTLS association <xref target="RFC8843" format="default"/>.
ation"/>. This document updates <xref format="default" target="RFC5763"/>
The document updates <xref format="default" pageno="false" targe and <xref format="default" target="RFC7345"/> by replacing commo
t="RFC5763"/> n
and <xref format="default" pageno="false" target="RFC7345"/>, by
replacing common
SDP offer/answer procedures with a reference to this specificati on. SDP offer/answer procedures with a reference to this specificati on.
</t> </t>
<t> <aside>
NOTE: Since the publication of <xref format="default" pageno="fa <t>
lse" target="RFC5763"/>, NOTE: Since the publication of <xref format="default" target="RF
<xref format="default" pageno="false" target="RFC4474"/> has bee C5763"/>,
n obsoleted by <xref format="default" target="RFC4474"/> has been obsoleted by
<xref format="default" pageno="false" target="I-D.ietf-stir-rfc4 <xref format="default" target="RFC8224"/>. The updating
474bis"/>. The updating of the references (and the associated procedures) within <xref
of the references (and the associated procedures) within <xref f format="default" target="RFC5763"/> is outside the scope of
ormat="default" pageno="false" this document. However, implementers of
target="RFC5763"/> is outside the scope of this document. Howeve <xref format="default" target="RFC5763"/> applications are encou
r, implementers of raged to
<xref format="default" pageno="false" target="RFC5763"/> applica implement <xref format="default" target="RFC8224"/> instead
tions are encouraged to of <xref format="default" target="RFC4474"/>.
implement <xref format="default" pageno="false" target="I-D.ietf </t>
-stir-rfc4474bis"/> instead </aside>
of <xref format="default" pageno="false" target="RFC4474"/>. <t>
</t> As defined in <xref format="default" target="RFC5763"/>, a new DTLS asso
<t> ciation
As defined in <xref format="default" pageno="false" target="RFC5 <bcp14>MUST</bcp14> be established when transport parameters are
763"/>, a new DTLS association changed. Transport parameter change is not
MUST be established when transport parameters are changed. Trans well defined when Interactive Connectivity Establishment (ICE)
port parameter change is not <xref format="default" target="RFC8445"/> is
well defined when Interactive Connectivity Establishment (ICE) < used. One possible way to determine a transport change is
xref format="default" based on ufrag <xref format="default" target="RFC8445"/> change,
pageno="false" target="I-D.ietf-ice-rfc5245bis"/> is used. One p but the ufrag value is changed both when ICE is negotiated
ossible way to determine a transport change is and when ICE restart <xref format="default" target="RFC8445"/> occurs. T
based on ufrag <xref format="default" pageno="false" target="I-D hese events
.ietf-ice-rfc5245bis"/> change, do not always require a new DTLS association to be established, but
but the ufrag value is changed both when ICE is negotiated previously there was no way
and when ICE restart <xref format="default" pageno="false" targe to explicitly indicate in an SDP offer or answer whether a new DTLS
t="I-D.ietf-ice-rfc5245bis"/> occurs. These events association was required.
do not always require a new DTLS association to be established, To solve that problem, this document defines a new SDP attribute,
but previously there was no way "tls-id". The pair of
to explicitly indicate in an SDP offer or answer whether a new D SDP "tls-id" attribute values (the attribute values of the offerer and t
TLS association is required. he answerer)
To solve that problem, this document defines a new SDP attribute uniquely identifies the DTLS association. Providing a new value of the
, 'tls-id'. The pair of "tls-id" attribute in an SDP offer
SDP 'tls-id' attribute values (the attribute values of the offer or answer can be used to indicate whether a new DTLS association is
er and the answerer) to be established.
uniquely identifies the DTLS association. Providing a new value </t>
of the 'tls-id' attribute in an SDP offer <t>
or answers can be used to indicate whether a new DTLS associatio The SDP "tls-id" attribute can be specified when negotiating a
n is to be established. Transport Layer Security (TLS) connection, using
</t> the procedures in this document in conjunction with the procedures in
<t> <xref format="default" target="RFC5763"/> and <xref format="default"
The SDP 'tls-id' attribute can be specified when negotiating a T target="RFC8122"/>.
ransport Layer Security (TLS) connection, using The unique combination of SDP "tls-id" attribute values can be used to
the procedures in this document in conjunction with the procedur identify the negotiated
es in <xref format="default" TLS connection. The unique value can be used, for example, within TLS
pageno="false" target="RFC5763"/> and <xref format="default" pag protocol extensions to
eno="false" target="RFC8122"/>. differentiate between multiple TLS connections and correlate those
The unique combination of SDP 'tls-id' attribute values can be u connections with specific
sed to identity the negotiated offer/answer exchanges. The TLS-specific considerations are described
TLS connection. The unique value can be used, for example, withi in <xref format="default" target="sec-tls-cons"/>.
n TLS protocol extensions to </t>
differentiate between multiple TLS connections and correlate tho
se connections with specific
offer/answer exchanges. The TLS specific considerations are des
cribed in <xref format="default"
pageno="false" target="sec-tls-cons"/>.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Conventions"> <name>Conventions</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and o "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nly "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
when, they appear in all capitals, as shown here. to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Establishing a new DTLS Association"> <name>Establishing a New DTLS Association</name>
<section title="General" anchor="sec-dtls-gen"> <section anchor="sec-dtls-gen" numbered="true" toc="default">
<t> <name>General</name>
<t>
A new DTLS association must be established between two endpoints after a A new DTLS association must be established between two endpoints after a
successful SDP offer/answer exchange in the following cases: successful SDP offer/answer exchange in the following cases:
<list style="symbols"> </t>
<t> <ul spacing="normal">
The negotiated DTLS setup roles change; or <li>
</t> The negotiated DTLS setup roles change; or
<t> </li>
One or more fingerprint values are modified, added <li>
or removed in either an SDP offer or answer; or One or more fingerprint values are modified, added,
</t> or removed in either an SDP offer or answer; or
<t> </li>
The intent to establish a new DTLS association is <li>
explicitly signaled using SDP, by changing the value The intent to establish a new DTLS association is
of the explicitly signaled using SDP, by changing the value of the
SDP 'tls-id' attribute defined in this document; SDP "tls-id" attribute defined in this document;
</t> </li>
</list> </ul>
</t> <aside>
<t> <t>
NOTE: The first two items above are based on the procedures NOTE: The first two items above are based on the procedures
in <xref format="default" pageno="false" target="RFC5763"/>. in <xref format="default" target="RFC5763"/>.
This specification adds the support for explicit signaling using This specification adds the support for explicit signaling using the
the SDP 'tls-id' attribute. SDP "tls-id" attribute.
</t> </t>
<t> </aside>
A new DTLS association can only be established as a result of th <t>
e successful SDP offer/answer exchange. A new DTLS association can only be established as a result of the
Whenever an entity determines that a new DTLS association is req successful SDP offer/answer exchange.
uired, the entity MUST initiate an Whenever an entity determines that a new DTLS association is
SDP offer/answer exchange, following the procedures in <xref tar required, the entity <bcp14>MUST</bcp14> initiate an
get="sec-oa"/>. SDP offer/answer exchange, following the procedures in <xref
</t> target="sec-oa" format="default"/>.
<t> </t>
The sections below describe typical cases where a new DTLS assoc <t>
iation needs to be established. The sections below describe typical cases where a new DTLS
</t> association needs to be established.
<t> </t>
In this document, a "new DTLS association" between two endpoints <t>
refers to either In this document, a "new DTLS association" between two endpoints refer
an initial DTLS association (when no DTLS association is current s to either
ly established between an initial DTLS association (when no DTLS association is currently
the endpoints) or an DTLS association replacing a previously est established between
ablished DTLS association. the endpoints) or a DTLS association replacing a previously
</t> established one.
</section> </t>
<section title="Change of Local Transport Parameters" anchor="sec-dtls-t </section>
ransport"> <section anchor="sec-dtls-transport" numbered="true" toc="default">
<t> <name>Change of Local Transport Parameters</name>
If an endpoint modifies its local transport parameters (address <t>
and/or port), and if the modification If an endpoint modifies its local transport parameters
requires a new DTLS association, the endpoint MUST change its lo (address and/or port), and if the modification
cal SDP 'tls-id' requires a new DTLS association, the endpoint
attribute value (see <xref target="sec-dcon-attr"/>). <bcp14>MUST</bcp14> change its local SDP "tls-id"
</t> attribute value (see <xref target="sec-dcon-attr" format="defaul
<t> t"/>).
</t>
<t>
If the underlying transport protocol prohibits a DTLS associatio n from spanning multiple 5-tuples If the underlying transport protocol prohibits a DTLS associatio n from spanning multiple 5-tuples
(transport/source address/source port/destination address/destin ation port), (transport/source address/source port/destination address/destin ation port),
and if the 5-tuple is changed, the endpoint MUST change its loca l SDP 'tls-id' attribute value (see <xref target="sec-dcon-attr"/>). and if the 5-tuple is changed, the endpoint <bcp14>MUST</bcp14> change its local SDP "tls-id" attribute value (see <xref target="sec-dcon-attr" format="default"/>).
An example of such a case is when DTLS is carried over the Strea m Control Transmission Protocol (SCTP), An example of such a case is when DTLS is carried over the Strea m Control Transmission Protocol (SCTP),
as described in <xref format="default" pageno="false" target="RF as described in <xref format="default" target="RFC6083"/>.
C6083"/>. </t>
</t> </section>
</section> <section anchor="sec-dtls-ufrag" numbered="true" toc="default">
<section title="Change of ICE ufrag value" anchor="sec-dtls-ufrag"> <name>Change of ICE ufrag Value</name>
<t>
If an endpoint uses ICE, and modifies a local ufrag value, and i
f the modification
requires a new DTLS association, the endpoint MUST change its lo
cal SDP 'tls-id'
attribute value (see <xref target="sec-dcon-attr"/>).
</t>
</section>
</section>
<section title="SDP tls-id Attribute" anchor="sec-dcon-attr">
<t> <t>
The pair of SDP 'tls-id' attribute values (the attribute values of t If an endpoint uses ICE and modifies a local ufrag value, and if the m
he offerer and the answerer) odification
uniquely identifies the DTLS association or TLS connection. requires a new DTLS association, the endpoint
<bcp14>MUST</bcp14> change its local SDP "tls-id"
attribute value (see <xref target="sec-dcon-attr" format="default"/>).
</t> </t>
<figure> </section>
<artwork align="left"><![CDATA[ </section>
Name: tls-id
Value: tls-id-value <section anchor="sec-dcon-attr" numbered="true" toc="default">
<name>SDP "tls-id" Attribute</name>
<t>
The pair of SDP "tls-id" attribute values (the attribute values of the
offerer and the answerer)
uniquely identifies the DTLS association or TLS connection.
</t>
Usage Level: media <dl newline="false">
Charset Dependent: no <dt>Name:</dt>
<dd>tls-id</dd>
Default Value: N/A <dt>Value:</dt>
<dd>tls-id-value</dd>
Syntax: <dt>Usage Level:</dt>
<dd>media</dd>
tls-id-value = 20*255(tls-id-char) <dt>Charset Dependent:</dt>
tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_" <dd>no</dd>
<ALPHA and DIGIT defined in [RFC4566]> <dt>Default Value:</dt>
<dd>N/A</dd>
Example: <dt>Syntax:</dt>
<dd>
<sourcecode type="abnf">
tls-id-value = 20*255(tls-id-char)
tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_"
</sourcecode>
<t>&lt;ALPHA and DIGIT defined in RFC 4566&gt;</t>
</dd>
a=tls-id:abc3de65cddef001be82 <dt>Example:</dt>
<dd>
<sourcecode type="sdp">
a=tls-id:abc3de65cddef001be82
</sourcecode>
</dd>
</dl>
]]></artwork> <t>
</figure> Every time an endpoint requests to establish a new DTLS
<t> association, the endpoint <bcp14>MUST</bcp14>
Every time an endpoint requests to establish a new DTLS association, generate a new local "tls-id" attribute value. An unchanged local
the endpoint MUST "tls-id" attribute
generate a new local 'tls-id' attribute value. A non-changed local ' value, in combination with non-changed fingerprints, indicates
tls-id' attribute that the endpoint
value, in combination with non-changed fingerprints, indicates that
the endpoint
intends to reuse the existing DTLS association. intends to reuse the existing DTLS association.
</t> </t>
<t> <t>
The 'tls-id' attribute value MUST be generated using a strong random The "tls-id" attribute value <bcp14>MUST</bcp14> be generated using
function a strong random function
and include at least 120 bits of randomness. and include at least 120 bits of randomness.
</t> </t>
<t> <t>
No default value is defined for the SDP 'tls-id' attribute. No default value is defined for the SDP "tls-id" attribute.
Implementations that wish to use the attribute MUST explicitly Implementations that wish to use the attribute <bcp14>MUST</bcp14> e
xplicitly
include it in SDP offers and answers. If an offer or answer does not include it in SDP offers and answers. If an offer or answer does not
contain a 'tls-id' attribute (this could happen if the offerer or contain a "tls-id" attribute (this could happen if the offerer or
answerer represents an existing implementation that has not been answerer represents an existing implementation that has not been
updated to support the 'tls-id' attribute), unless there is updated to support the "tls-id" attribute), a modification of one
or more of the following characteristics <bcp14>MUST</bcp14> be
treated as an indication that an endpoint
wants to establish a new DTLS association, unless there is
another mechanism to explicitly indicate that a new DTLS association another mechanism to explicitly indicate that a new DTLS association
is to be established, a modification of one or more of the following is to be established:
characteristics MUST be treated as an indication that an endpoint </t>
wants to establish a new DTLS association: <ul spacing="normal">
<list style="symbols"> <li>
<t> DTLS setup role; or
DTLS setup role; or </li>
</t> <li>
<t> fingerprint set; or
fingerprint set; or </li>
</t> <li>
<t> local transport parameters
local transport parameters </li>
</t> </ul>
</list> <aside>
</t> <t>
<t>
NOTE: A modification of the ufrag value is not treated as an indicat ion NOTE: A modification of the ufrag value is not treated as an indicat ion
that an endpoint wants to establish a new DTLS assocation. In order to that an endpoint wants to establish a new DTLS association. In order to
indicate that a new DTLS association is to be established, one or mo re indicate that a new DTLS association is to be established, one or mo re
of the characteristics listed above have to be modified. of the characteristics listed above have to be modified.
</t>
</aside>
<t>
The mux category <xref target="RFC8859" format="default"/>
for the "tls-id" attribute is "IDENTICAL", which means that
the attribute value applies to all media descriptions
being multiplexed <xref target="RFC8843" format="default"/>.
However, as described in <xref target="RFC8843" format="default"/>,
in order to avoid duplication, the attribute is only associated with
the "m=" line
representing the offerer/answerer BUNDLE tag.
</t>
<t>
For RTP-based media, the "tls-id" attribute applies to the whole ass
ociated
media description. The attribute <bcp14>MUST NOT</bcp14> be defined
per source (using the
SDP "ssrc" attribute <xref format="default" target="RFC5576"/>).
</t>
<t>
The SDP offer/answer procedures <xref format="default" target="RFC32
64"/>
associated with the attribute are defined in <xref target="sec-oa" f
ormat="default"/>.
</t>
</section>
<section anchor="sec-oa" numbered="true" toc="default">
<name>SDP Offer/Answer Procedures</name>
<section 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) for individual DTLS usages (e.g., DTLS-SRTP)
are outside the scope
of this specification and need to be specified in a
usage-specific document.
</t> </t>
<aside>
<t> <t>
The mux category <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> NOTE: The procedures in this section are generalizations of procedures
for the 'tls-id' attribute is 'IDENTICAL', which means that first
the attribute value applies to all media descriptions specified in the DTLS-SRTP document <xref format="default" target="RFC
being multiplexed <xref target="I-D.ietf-mmusic-sdp-bundle-negotiati 5763"/>,
on"/>. with the addition of usage of the SDP "tls-id" attribute. That documen
However, as described in <xref target="I-D.ietf-mmusic-sdp-bundle-ne t is
gotiation"/>, herein updated to make use of these new procedures.
in order to avoid duplication the attribute is only associated with
the "m=" line
representing the offerer/answerer BUNDLE-tag.
</t> </t>
</aside>
<t> <t>
For RTP-based media, the 'tls-id' attribute applies to the whole ass The procedures in this section apply to an SDP media description
ociated ("m=" line) associated
media description. The attribute MUST NOT be defined per source (usi with DTLS-protected media/data.
ng the
SDP 'ssrc' attribute <xref format="default" pageno="false" target="R
FC5576"/>).
</t> </t>
<t> <t>
The SDP offer/answer <xref format="default" pageno="false" target="R When an offerer or answerer indicates that it wants to establish a
FC3264"/> new DTLS association, it needs to make sure that
procedures associated with the attribute are defined in <xref target media packets associated with any previously established DTLS
="sec-oa"/>. association and the new DTLS association can be demultiplexed. In
the case
of an ordered transport (e.g., SCTP), this can be done simply by
sending packets for the new DTLS association
after all packets associated with a previously established DTLS
association 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 and
the first packets associated with the new DTLS association have been
received. The
only way to demultiplex packets associated 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) <bcp14>MUST</bcp14> be allocated by at least
one of the endpoints so that DTLS packets can be demultiplexed.
</t> </t>
</section> <t>
When an offerer needs to establish a new DTLS association, and if an
<section title="SDP Offer/Answer Procedures" anchor="sec-oa"> unordered transport (e.g., UDP)
<section title="General"> is used, the offerer <bcp14>MUST</bcp14> allocate a new 3-tuple for
<t> the offer in such a way that the offerer can
This section defines the generic SDP offer/answer procedures for disambiguate any packets associated with the new DTLS association
negotiating from any packets associated with
a DTLS association. Additional procedures (e.g., regarding usage any other DTLS association. This typically means using a local
of specific SDP address and/or port, or a set of
attributes etc.) for individual DTLS usages (e.g., DTLS-SRTP) ar ICE candidates (see <xref format="default"
e outside the scope target="sec-dtls-reest-ice"/>), which were
of this specification, and need to be specified in a usage speci not recently used for any other DTLS association.
fic specification. </t>
</t> <t>
<t> When an answerer needs to establish a new DTLS association, if an
NOTE: The procedures in this section are generalizations of proc unordered transport is used, and
edures first the offerer did not allocate a new 3-tuple, the answerer
specified in DTLS-SRTP <xref format="default" pageno="false" tar <bcp14>MUST</bcp14> allocate a new 3-tuple for the
get="RFC5763"/>, answer in such a way that it can disambiguate any packets associated
with the addition of usage of the SDP 'tls-id' attribute. That d with the new DTLS association from any
ocument is packets associated with any other DTLS association. This typically
herein updated to make use of these new procedures. means using a local address and/or
</t> port, or a set of ICE candidates (see <xref format="default"
<t> target="sec-dtls-reest-ice"/>),
The procedures in this section apply to an SDP media description which were not recently used for any other DTLS association.
("m=" line) associated </t>
with DTLS-protected media/data. <t>
</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 as
sociation and the new DTLS association can be de-multiplexed. In case
of an ordered transport (e.g., 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 been sent. In case of an unordered transport, such as
UDP, packets associated with a previously established DTLS assoc
iation can arrive after the answer SDP was received and after the first
packets associated with the new DTLS association were received.
The only way to de-multiplex 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 tra
nsport
is used for the DTLS association, a new 3-tuple (transport/sourc
e address/source port) MUST be allocated by at least one
of the endpoints so that DTLS packets can be de-multiplexed.
</t>
<t>
When an offerer needs to establish a new DTLS association, and i
f an unordered transport (e.g., UDP)
is used, the offerer MUST allocate a new 3-tuple for the offer i
n such a way that the offerer can
disambiguate any packets associated with the new DTLS associatio
n from any packets associated with
any other DTLS association. This typically means using a local a
ddress 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 a
n unordered transport is used, and if
the offerer did not allocate a new 3-tuple, the answerer MUST al
locate a new 3-tuple for the
answer in such a way that it can disambiguate any packets associ
ated with the new DTLS association from any
packets associated with any other DTLS association. This typical
ly means using a local address and/or
port, or a set of ICE candidates (see <xref format="default" pag
eno="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 attr ibutes are used: In order to negotiate a DTLS association, the following SDP attr ibutes are used:
<list style="symbols"> </t>
<t> <ul spacing="normal">
The SDP 'setup' attribute, defined in <xref target="RFC4 <li>
145" pageno="false" The SDP "setup" attribute, defined in <xref target="RFC4
format="default" />, is used to negotiate the DTLS roles 145" format="default"/>, is used to negotiate the DTLS roles;
; </li>
</t> <li>
<t> The SDP "fingerprint" attribute, defined in <xref format
The SDP 'fingerprint' attribute, defined in <xref format ="default" target="RFC8122"/>, is used to
="default"
pageno="false" target="RFC8122"/>, is used to
provide one or more fingerprint values; and provide one or more fingerprint values; and
</t> </li>
<t> <li>
The SDP 'tls-id' attribute, defined in this specificatio The SDP "tls-id" attribute, defined in this specificatio
n, is used to identity n, is used to identity
the DTLS association. the DTLS association.
</t> </li>
</list> </ul>
</t> <t>
<t> This specification does not define the usage of the SDP "connect
This specification does not define the usage of the SDP 'connect ion" attribute
ion' attribute <xref target="RFC4145" format="default"/> for negotiating a DTLS
<xref target="RFC4145" pageno="false" format="default" /> for ne association. However, the attribute <bcp14>MAY</bcp14> be used i
gotiating a DTLS f the DTLS association is used
association. However, the attribute MAY be used if the DTLS asso
ciation is used
together with another protocol (e.g., SCTP or TCP) for which the usage of the together with another protocol (e.g., SCTP or TCP) for which the usage of the
attribute has been defined. attribute has been defined.
</t> </t>
<t> <t>
Unlike for TCP and TLS connections, endpoints MUST NOT use the Unlike for TCP and TLS connections, endpoints <bcp14>MUST NOT</b
SDP 'setup' attribute 'holdconn' value when negotiating a DTLS a cp14> use the
ssociation. SDP "setup" attribute "holdconn" value when negotiating a DTLS a
</t> ssociation.
<t> </t>
Endpoints MUST support the hash functions as defined in <t>
<xref format="default" pageno="false" target="RFC8122"/>. Endpoints <bcp14>MUST</bcp14> support the hash functions as defi
</t> ned in
<t> <xref format="default" target="RFC8122"/>.
The certificate received during the DTLS handshake <xref format= </t>
"default" <t>
pageno="false" target="RFC6347"/> MUST match a certificate The certificate received during the DTLS handshake <xref format=
fingerprint received in SDP 'fingerprint' attributes according t "default" target="RFC6347"/> <bcp14>MUST</bcp14> match a certificate
o the procedures fingerprint received in SDP "fingerprint" attributes according t
defined in <xref format="default" pageno="false" target="RFC8122 o the procedures
"/>. defined in <xref format="default" target="RFC8122"/>.
If fingerprints do not match the hashed certificate, then an end If fingerprints do not match the hashed certificate, then an end
point MUST tear point <bcp14>MUST</bcp14> tear
down the media session immediately (see <xref format="default" p down the media session immediately (see <xref format="default" t
ageno="false" arget="RFC8122"/>).
target="RFC8122"/>). </t>
</t> <t>
<t>
SDP offerers and answerers might reuse certificates across multi ple DTLS SDP offerers and answerers might reuse certificates across multi ple DTLS
associations, and provide identical fingerprint values for each DTLS associations, and provide identical fingerprint values for each DTLS
association. The combination of the SDP 'tls-id' attribute value s of the SDP association. The combination of the SDP "tls-id" attribute value s of the SDP
offerer and answerer identifies each individual DTLS association . offerer and answerer identifies each individual DTLS association .
</t> </t>
<t> <aside>
NOTE: There are cases where the SDP 'tls-id' attribute value gen <t>
erated by the NOTE: There are cases where the SDP "tls-id" attribute value generated
offerer will end up being used for multiple DTLS associations. F by the
or that reason offerer will end up being used for multiple DTLS associations. For tha
the combination of the attribute values of the offerer and answe t reason,
rer is needed the combination of the attribute values of the offerer and answerer is
in order to identity a DTLS association. An example of such case needed
is where the in order to identity a DTLS association. An example of such a case is
offerer sends an updated offer (<xref target="sec-oa-mod"/>), wi where the
thout modifying its offerer sends an updated offer (<xref target="sec-oa-mod"
attribute value, but the answerer determines that a new DTLS ass format="default"/>) without modifying its
ociation is to attribute value, but the answerer determines that a new DTLS associati
be created. The answerer will generate a new local attribute val on is to
ue for the new be created. The answerer will generate a new local attribute value for
DTLS association (<xref target="sec-oa-answer"/>), while the off the new
erer will use the DTLS association (<xref target="sec-oa-answer" format="default"/>), wh
same attribute value that it used for the current association. A ile the offerer will use the
nother example is same attribute value that it used for the current association. Another
when the Session Initiation Protocol (SIP) <xref format="default example is
" pageno="false" when the Session Initiation Protocol (SIP) <xref format="default"
target="RFC3261"/> is used for signalling, and an offer is forke target="RFC3261"/> is used for signaling, and an offer is forked to
d to multiple answerers. multiple answerers.
The attribute value generated by the offerer will be used for DT The attribute value generated by the offerer will be used for DTLS ass
LS associations ociations
established by each answerer. established by each answerer.
</t> </t>
</section> </aside>
</section>
<section title="Generating the Initial SDP Offer" anchor="sec-oa-offer"> <section anchor="sec-oa-offer" numbered="true" toc="default">
<t> <name>Generating the Initial SDP Offer</name>
When an offerer sends the initial offer, the offerer MUST insert <t>
an SDP 'setup' attribute When an offerer sends the initial offer, the offerer
<xref format="default" pageno="false" target="RFC4145"/> with an <bcp14>MUST</bcp14> insert an SDP "setup" attribute
'actpass' attribute value, and <xref format="default" target="RFC4145"/> with an "actpass"
one or more SDP 'fingerprint' attributes according to the proced attribute value, as well as
ures in <xref format="default" one or more SDP "fingerprint" attributes according to the procedures
pageno="false" target="RFC8122"/>. In addition, the offerer MUST in <xref format="default" target="RFC8122"/>. In addition, the
insert in the offer an SDP offerer <bcp14>MUST</bcp14> insert in the offer an SDP
'tls-id' attribute with a unique attribute value. "tls-id" attribute with a unique attribute value.
</t> </t>
<t> <t>
As the offerer inserts the SDP 'setup' attribute with an 'actpas As the offerer inserts the SDP "setup" attribute with an
s' attribute value, the "actpass" attribute value, the
offerer MUST be prepared to receive a DTLS ClientHello message < offerer <bcp14>MUST</bcp14> be prepared to receive a DTLS
xref format="default" pageno="false" ClientHello message <xref format="default" target="RFC6347"/>
target="RFC6347"/> (if a new DTLS association is established by from the answerer
the answerer) from the answerer (if a new DTLS association is established by the answerer)
before the offerer receives the SDP answer. before the offerer receives the SDP answer.
</t> </t>
<t> <t>
If the offerer receives a DTLS ClientHello message, and a DTLS a If the offerer receives a DTLS ClientHello message, and a DTLS
ssociation is established, association is established
before the offerer receives the SDP Answer carrying the fingerpr before the offerer receives the SDP answer carrying the
int associated with the DTLS fingerprint associated with the DTLS
association, any data received on the DTLS association before th association, any data received on the DTLS association before
e fingerprint MUST be the fingerprint <bcp14>MUST</bcp14> be
considered coming from an unverified source. The processing of s considered to be coming from an unverified source. The processing of
uch data, and sending of data such data and sending of data
by the offerer to the unverified source, is outside the scope of by the offerer to the unverified source is outside the scope
this document. of this document.
</t> </t>
</section> </section>
<section title="Generating the Answer" anchor="sec-oa-answer"> <section anchor="sec-oa-answer" numbered="true" toc="default">
<t> <name>Generating the Answer</name>
When an answerer sends an answer, the answerer MUST insert in th <t>
e answer an SDP 'setup' attribute When an answerer sends an answer, the answerer
according to the procedures in <xref format="default" pageno="fa <bcp14>MUST</bcp14> insert in the answer an SDP "setup"
lse" target="RFC4145"/>, and one attribute
or more SDP 'fingerprint' attributes according to the procedures according to the procedures in <xref format="default"
in <xref format="default" target="RFC4145"/> and one
pageno="false" target="RFC8122"/>. or more SDP "fingerprint" attributes according to the
If the answerer determines, based on the criteria specified in < procedures in <xref format="default" target="RFC8122"/>.
xref target="sec-dtls-gen"/>, If the answerer determines, based on the criteria specified in
that a new DTLS association is to be established, the answerer M <xref target="sec-dtls-gen" format="default"/>,
UST insert in the associated answer that a new DTLS association is to be established, the answerer
an SDP 'tls-id' attribute with a new unique attribute value. Not <bcp14>MUST</bcp14> insert in the associated answer
e that the offerer and answerer generate an SDP "tls-id" attribute with a new unique attribute
their own local 'tls-id' attribute values, and the combination o value. Note that the offerer and answerer generate
f both values identify the their own local "tls-id" attribute values, and the combination
of both values identifies the
DTLS association. DTLS association.
</t> </t>
<t> <t>
If the answerer receives an offer that requires establishment of a new DTLS association, and if the 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 associa tion, the answerer MUST reject answerer does not accept the establishment of a new DTLS associa tion, the answerer <bcp14>MUST</bcp14> reject
the "m=" lines associated with the suggested DTLS association the "m=" lines associated with the suggested DTLS association
<xref format="default" pageno="false" target="RFC3264"/>. <xref format="default" target="RFC3264"/>.
</t> </t>
<t> <t>
If an answerer receives an offer that does not require the estab lishment of a new DTLS association, If an answerer receives an offer that does not require the estab lishment of a new DTLS association,
and if the answerer determines that a new DTLS association is no t to be established, and if the answerer determines that a new DTLS association is no t to be established,
the answerer MUST insert an SDP 'tls-id' attribute with the prev the answerer <bcp14>MUST</bcp14> insert in the associated
iously assigned attribute value in the answer an SDP "tls-id"
associated answer. In addition, the answerer MUST insert an SDP attribute with the previously assigned attribute value. In
'setup' attribute with an addition, the answerer
attribute value that does not change the previously negotiated D <bcp14>MUST</bcp14> insert an SDP "setup" attribute with an
TLS roles, and one or more SDP 'fingerprint' attribute value that does not change the previously negotiated
attributes values that do not change the previously sent fingerp DTLS roles, as well as one or more SDP "fingerprint"
rint set, in the associated answer. attributes values that do not change the previously sent
</t> fingerprint set, in the associated answer.
<t> </t>
If the answerer receives an offer that does not contain an SDP ' <t>
tls-id' attribute, If the answerer receives an offer that does not contain an SDP "tls-id
the answerer MUST NOT insert a 'tls-id' attribute in the answer. " attribute,
</t> the answerer <bcp14>MUST NOT</bcp14> insert a "tls-id" attribute in th
<t> e answer.
If a new DTLS association is to be established, and if the answe </t>
rer inserts an SDP 'setup' <t>
attribute with an 'active' attribute value in the answer, the an If a new DTLS association is to be established, and if the
swerer MUST initiate a DTLS handshake answerer inserts an SDP "setup"
<xref format="default" pageno="false" target="RFC6347"/>) by sen attribute with an "active" attribute value in the answer, the
ding a DTLS ClientHello message towards the offerer. answerer <bcp14>MUST</bcp14> initiate a DTLS handshake
</t> <xref format="default" target="RFC6347"/> by sending a DTLS
<t> ClientHello message towards the offerer.
Even though an offerer is required to insert an 'SDP' setup attr </t>
ibute with an 'actpass' attribute value <t>
in initial offers (<xref target="sec-oa-offer"/>) and subsequent Even though an offerer is required to insert an "SDP" setup attr
offers (<xref target="sec-oa-mod"/>), ibute with an "actpass" attribute value
the answerer MUST be able to receive initial and subsequent offe in initial offers (<xref target="sec-oa-offer" format="default"/
rs with other attribute values, in order >) and subsequent offers (<xref target="sec-oa-mod" format="default"/>),
the answerer <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 to be backward compatible with older implementations that might insert other attribute values in initial and
subsequent offers. subsequent offers.
</t> </t>
</section> </section>
<section title="Offerer Processing of the SDP Answer"> <section numbered="true" toc="default">
<t> <name>Offerer Processing of the SDP Answer</name>
When an offerer receives an answer that establishes a new DTLS a <t>
ssociation based on When an offerer receives an answer that establishes a new DTLS
criteria defined in <xref target="sec-dtls-gen"/>, and if the of association based on
ferer criteria defined in <xref target="sec-dtls-gen"
becomes DTLS client (based on the value of the SDP 'setup' attri format="default"/>, if the offerer
bute value becomes DTLS client (based on the value of the SDP "setup" attri
<xref format="default" pageno="false" target="RFC4145"/>), the o bute value
fferer MUST <xref format="default" target="RFC4145"/>), the offerer <bcp14>M
establish a DTLS association. If the offerer becomes DTLS server UST</bcp14>
, it MUST wait for the answerer establish a DTLS association. If the offerer becomes DTLS server
, it <bcp14>MUST</bcp14> wait for the answerer
to establish the DTLS association. to establish the DTLS association.
</t> </t>
<t> <t>
If the offerer indicated a desire to reuse an existing DTLS asso If the offerer indicated a desire to reuse an existing DTLS
ciation and the association, and the
answerer does not request the establishment of a new DTLS associ answerer does not request the establishment of a new DTLS
ation, the offerer will association, the offerer will
continue to use the previously established DTLS association. continue to use the previously established DTLS association.
</t> </t>
<t> <t>
A new DTLS association can be established based on changes in ei A new DTLS association can be established based on changes in either
ther an SDP offer or answer. an SDP offer or answer.
When communicating with legacy endpoints, an offerer can receive When communicating with legacy endpoints, an offerer can receive an
an answer that includes the same answer that includes the same
fingerprint set and setup role. A new DTLS association will stil fingerprint set and setup role. A new DTLS association will still be
l be established if such an answer established if such an answer
was received as a response to an offer which requested the estab is received as a response to an offer that requested the
lishment of a new DTLS association, establishment of a new DTLS association,
as the transport parameters would have been changed in the offer as the transport parameters would have been changed in the offer.
. </t>
</t> </section>
</section> <section anchor="sec-oa-mod" numbered="true" toc="default">
<section title="Modifying the Session" anchor="sec-oa-mod"> <name>Modifying the Session</name>
<t> <t>
When an offerer sends a subsequent offer, and if the offerer wan When an offerer sends a subsequent offer, if the offerer
ts to establish a new wants to establish a new
DTLS association, the offerer MUST insert an SDP 'setup' attribu DTLS association, the offerer <bcp14>MUST</bcp14> insert an
te <xref format="default" SDP "setup" attribute <xref format="default"
pageno="false" target="RFC4145"/> with an 'actpass' attribute va target="RFC4145"/> with an "actpass" attribute value, as well as
lue, and one or more SDP 'fingerprint' or more SDP "fingerprint"
attributes according to the procedures in <xref format="default" attributes according to the procedures in <xref
pageno="false" target="RFC8122"/>. format="default" target="RFC8122"/>.
In addition, the offerer MUST insert in the offer an SDP 'tls-id In addition, the offerer <bcp14>MUST</bcp14> insert in the offer
' attribute with a new unique an SDP "tls-id" attribute with a new unique
attribute value. attribute value.
</t> </t>
<t> <t>
When an offerer sends a subsequent offer, and the offerer does n When an offerer sends a subsequent offer and does
ot want to establish not want to establish
a new DTLS association, and if a previously established DTLS ass a new DTLS association, if a previously established DTLS
ociation exists, association exists,
the offerer MUST insert an SDP 'setup' attribute with an 'actpas the offerer <bcp14>MUST</bcp14> insert in the offer an SDP "setu
s' attribute value, and p"
one or more SDP 'fingerprint' attributes with attribute values t attribute with an "actpass" attribute value, and
hat do not change the previously one or more SDP "fingerprint" attributes with attribute values
sent fingerprint set, in the offer. In addition, the offerer MUS that do not change the previously
T insert an SDP 'tls-id' sent fingerprint set. In addition, the offerer
<bcp14>MUST</bcp14> insert an SDP "tls-id"
attribute with the previously assigned attribute value in the of fer. attribute with the previously assigned attribute value in the of fer.
</t> </t>
<t> <aside>
NOTE: When a new DTLS association is being established, each end
point needs to be prepared to receive
data on both the new and old DTLS associations as long as both a
re alive.
</t>
</section>
</section>
<section title="ICE Considerations" anchor="sec-dtls-reest-ice">
<t> <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 anchor="sec-dtls-reest-ice" numbered="true" toc="default">
<name>ICE Considerations</name>
<t>
When the Interactive Connectivity Establishment (ICE) mechanism When the Interactive Connectivity Establishment (ICE) mechanism
<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bi s"/> is used, the <xref format="default" target="RFC8445"/> is used, the
ICE connectivity checks are performed before the DTLS ICE connectivity checks are performed before the DTLS
handshake begins. Note that if aggressive nomination mode is used, handshake begins. Note that if aggressive nomination mode is used,
multiple candidate pairs may be marked valid before ICE finally multiple candidate pairs may be marked valid before ICE finally
converges on a single candidate pair. converges on a single candidate pair.
</t> </t>
<t> <aside>
NOTE: Aggressive nomination has been deprecated from ICE, but must s <t>
till be NOTE: Aggressive nomination has been deprecated from ICE but must still
supported for backwards compatibility reasons <xref format="default" be
pageno="false" supported for backwards compatibility reasons <xref format="default"
target="I-D.ietf-ice-rfc5245bis"/>. target="RFC8445"/>.
</t> </t>
<t> </aside>
When a new DTLS association is established over an unordered transpo <t>
rt, in order to When a new DTLS association is established over an unordered
disambiguate any packets associated with the newly established DTLS transport, in order to
association, at least disambiguate any packets associated with the newly established
one of the endpoints MUST allocate a completely new set of ICE candi DTLS association, at least
dates which one of the endpoints <bcp14>MUST</bcp14> allocate a completely new
set of ICE candidates that
were not recently used for any other DTLS association. This means th e answerer were not recently used for any other DTLS association. This means th e answerer
cannot initiate a new DTLS association unless the offerer initiated ICE restart cannot initiate a new DTLS association unless the offerer initiated ICE restart
<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bi s"/>. If the answerer wants <xref format="default" target="RFC8445"/>. If the answerer wants
to initiate a new DTLS association, it needs to initiate an ICE rest art to initiate a new DTLS association, it needs to initiate an ICE rest art
and a new offer/answer exchange on its own. However, an ICE restart does not by and a new offer/answer exchange on its own. However, an ICE restart does not by
default require a new DTLS association default require a new DTLS association
to be established. to be established.
</t> </t>
<t> <aside>
NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packet <t>
s are sent directly NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets
over UDP, not over DTLS. <xref format="default" pageno="false" targe are sent directly
t="RFC7983"/> describes over UDP, not over DTLS. <xref format="default" target="RFC7983"/> descr
how to demultiplex STUN packets from DTLS packets and SRTP packets. ibes
</t> how to demultiplex STUN packets from DTLS packets and SRTP packets.
<t> </t>
</aside>
<t>
Each ICE candidate associated with a component is treated as being p art of the Each ICE candidate associated with a component is treated as being p art of the
same DTLS association. Therefore, from a DTLS perspective it is not considered same DTLS association. Therefore, from a DTLS perspective, it is not considered
a change of local transport parameters when an endpoint switches bet ween those a change of local transport parameters when an endpoint switches bet ween those
ICE candidates. ICE candidates.
</t> </t>
</section> </section>
<section anchor="sec-tls-cons" numbered="true" toc="default">
<section title="TLS Considerations" anchor="sec-tls-cons"> <name>TLS Considerations</name>
<t> <t>
The procedures in this document can also be used for negotiating and The procedures in this document can also be used for negotiating and
establishing a TLS connection, with the restriction described below. establishing a TLS connection, with the restriction described below.
</t> </t>
<t> <t>
As specified in <xref format="default" pageno="false" target="RFC414 As specified in <xref format="default" target="RFC4145"/>,
5"/>, the SDP "connection" attribute is used to indicate whether to establ
the SDP 'connection' attribute is used to indicate whether to establ ish a new
ish a new TLS connection. An offerer and answerer <bcp14>MUST</bcp14> ensure
TLS connection. An offerer and answerer MUST ensure that the 'connec that the "connection"
tion' attribute value and the "tls-id" attribute value do not cause a conf
attribute value and the 'tls-id' attribute value does not cause a co lict
nflict
regarding whether a new TLS connection is to be established or not. regarding whether a new TLS connection is to be established or not.
</t> </t>
<t> <aside>
NOTE: Even though the SDP 'connection' attribute can be used to indi <t>
cate NOTE: Even though the SDP "connection" attribute can be used to indi
cate
whether a new TLS connection is to be established, the unique combin ation whether a new TLS connection is to be established, the unique combin ation
of SDP 'tls-id' attribute values can be used to identity a TLS conne ction. of SDP "tls-id" attribute values can be used to identity a TLS conne ction.
The unique value can be used e.g., within TLS protocol extensions to differentiate The unique value can be used e.g., within TLS protocol extensions to differentiate
between multiple TLS connections and correlate those connections wit h specific between multiple TLS connections and correlate those connections wit h specific
offer/answer exchanges. One such extension is defined in offer/answer exchanges. One such extension is defined in
<xref format="default" pageno="false" target="I-D.ietf-mmusic-sdp-uk <xref format="default" target="RFC8844"/>.
s"/>. </t>
</aside>
</t> <t>
<t> If an offerer or answerer inserts an SDP "connection" attribute with
If an offerer or answerer inserts an SDP 'connection' attribute with a "new"
a 'new' value in the offer/answer and also inserts an SDP "tls-id" attribute
value in the offer/answer and also inserts an SDP 'tls-id' attribute ,
, the value of the "tls-id" attribute <bcp14>MUST</bcp14> be new and u
the value of tls-id' attribute MUST be new and unique. nique.
</t> </t>
<t> <t>
If an offerer or answerer inserts an SDP 'connection' attribute with If an offerer or answerer inserts an SDP "connection" attribute with an
a 'existing' "existing"
value in the offer/answer, if a previously established TLS connectio value in the offer/answer, if a previously established TLS connection ex
n exists, and ists, and
if the offerer/answerer previously inserted an SDP 'tls-id' attribut if the offerer/answerer previously inserted an SDP "tls-id" attribute as
e associated with sociated with
the same TLS connection in an offer/answer, the offerer/answerer MUS the same TLS connection in an offer/answer, the offerer/answerer
T also insert <bcp14>MUST</bcp14> also insert
an SDP 'tls-id' attribute with the previously assigned value in the an SDP "tls-id" attribute with the previously assigned value in the offe
offer/answer. r/answer.
</t> </t>
<t> <t>
If an offerer or answerer receives an offer/answer with conflicting attribute values, If an offerer or answerer receives an offer/answer with conflicting attribute values,
the offerer/answerer MUST process the offer/answer as misformed. the offerer/answerer <bcp14>MUST</bcp14> process the offer/answer as
</t> misformed.
<t> </t>
An endpoint MUST NOT make assumptions regarding the support of the S <t>
DP 'tls-id' An endpoint <bcp14>MUST NOT</bcp14> make assumptions regarding the
attribute by the peer. Therefore, to avoid ambiguity, both offerers support of the SDP "tls-id"
and answerers attribute by the peer. Therefore, to avoid ambiguity, both
MUST always use the 'connection' attribute in conjunction with the ' offerers and answerers
tls-id' attribute. <bcp14>MUST</bcp14> always use the "connection" attribute in
</t> conjunction with the "tls-id" attribute.
<t> </t>
NOTE: As defined in <xref format="default" pageno="false" target="RF <aside>
C4145"/>, if the <t>
SDP 'connection' attribute is not explicitly present, the implicit d NOTE: As defined in <xref format="default" target="RFC4145"/>, if th
efault value is 'new'. e
</t> SDP "connection" attribute is not explicitly present, the implicit
<t> default value is "new".
The SDP example below is based on the example in section 3.4 of </t>
<xref format="default" pageno="false" target="RFC8122"/>, with the a </aside>
ddition of <t>
the SDP 'tls-id' attribute. The SDP example below is based on the example in
</t> <xref format="default" target="RFC8122" sectionFormat="of"
<figure> section="3.4"/>, with the addition of
<artwork align="left"><![CDATA[ the SDP "tls-id" attribute.
</t>
m=image 54111 TCP/TLS t38 <sourcecode type="sdp" >
c=IN IP4 192.0.2.2 m=image 54111 TCP/TLS t38
a=tls-id:abc3de65cddef001be82 c=IN IP4 192.0.2.2
a=setup:passive a=tls-id:abc3de65cddef001be82
a=connection:new a=setup:passive
a=fingerprint:SHA-256 \ a=connection:new
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ a=fingerprint:SHA-256 \
3E:5D:49:6B:19:E5:7C:AB:4A:AD 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
a=fingerprint:SHA-1 \ 3E:5D:49:6B:19:E5:7C:AB:4A:AD
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
</sourcecode>
]]></artwork>
</figure>
</section> </section>
<section numbered="true" toc="default">
<section title="SIP Considerations"> <name>SIP Considerations</name>
<t> <t>
When the Session Initiation Protocol (SIP) <xref format="default" pa When the Session Initiation Protocol (SIP) <xref format="default"
geno="false" target="RFC3261"/> is used as the signal protocol for establishing
target="RFC3261"/> is used as the signal protocol for establishing a a multimedia
multimedia session, dialogs <xref format="default" target="RFC3261"/> might be
session, dialogs <xref format="default" pageno="false" target="RFC32 established between the caller and multiple callees. This is referred to
61"/> might be as forking.
established between the caller and multiple callees. This is referre If forking occurs, separate DTLS associations will be established betwee
d to as forking. n the caller
If forking occurs, separate DTLS associations will be established be and each callee.
tween the caller </t>
and each callee. <t>
</t> When forking occurs, an SDP offerer can receive DTLS ClientHello
<t> messages and SDP
When forking occurs, an SDP offerer can receive DTLS ClientHello mes answers from multiple remote locations. Because of this, the
sages and SDP offerer might have to
answerers from multiple remote locations. Because of this, the offer wait for multiple SDP answers (from different remote locations)
er might have to until it receives
wait for multiple SDP answers (from different remote locations) unti a certificate fingerprint that matches the certificate associated
l it receives with a specific
a certificate fingerprint that matches the certificate associated wi DTLS handshake. The offerer <bcp14>MUST NOT</bcp14> declare a
th a specific fingerprint mismatch until it
DTLS handshake. The offerer MUST NOT declare a fingerprint mismatch determines that it will not receive SDP answers from any
until it additional remote locations.
determines that it will not receive SDP answers from any additional </t>
remote locations. <t>
</t> It is possible to send an INVITE request that does not contain an SD
<t> P offer. Such
It is possible to send an INVITE request which does not contain an S an INVITE request is often referred to as an "empty INVITE" or an
DP offer. Such "offerless INVITE".
an INVITE request is often referred to as an 'empty INVITE', or an '
offer-less INVITE'.
The receiving endpoint will include the SDP offer in a response to t he request. The receiving endpoint will include the SDP offer in a response to t he request.
When the endpoint generates such SDP offer, if a previously establis When the endpoint generates such an SDP offer, if a previously estab
hed lished
DTLS association exists, the offerer MUST insert an SDP 'tls-id' DTLS association exists, the offerer <bcp14>MUST</bcp14> insert an S
attribute, and one or more SDP 'fingerprint' attributes, with previo DP "tls-id"
usly assigned attribute and one or more SDP "fingerprint" attributes, with previou
attribute values. If a previously established DTLS association did n sly assigned
ot exist, attribute values. If a previously established DTLS association does
the offer MUST be generated based on the same rules as a new offer ( not exist,
see <xref target="sec-oa-offer"/>). the offer <bcp14>MUST</bcp14> be generated based on the same rules a
Regardless of the previous existence of a DTLS association, the SDP s a new offer (see <xref target="sec-oa-offer" format="default"/>).
'setup' attribute Regardless of the previous existence of a DTLS association, the
MUST be included according to the rules defined in <xref format="def SDP "setup" attribute
ault" pageno="false" <bcp14>MUST</bcp14> be included according to the rules defined in
target="RFC4145"/>. Furthermore, if ICE is used, according to the th <xref format="default" target="RFC4145"/>. Furthermore, if ICE is
ird party call control used, ICE restart <bcp14>MUST</bcp14> be initiated, according to
considerations described in <xref target="I-D.ietf-mmusic-ice-sip-sd the third-party call-control
p"/>, ICE restart considerations described in <xref
MUST be initiated. target="RFC8839" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="RFC Updates"> <name>RFC Updates</name>
<section title="General"> <section numbered="true" toc="default">
<t> <name>General</name>
<t>
This section updates specifications that use DTLS-protected medi a, in This section updates specifications that use DTLS-protected medi a, in
order to reflect the procedures defined in this specification. order to reflect the procedures defined in this specification.
</t> </t>
</section>
<section numbered="true" toc="default">
<name>Update to RFC 5763</name>
<section numbered="true" toc="default">
<name>Update to Section 1</name>
<t>The reference to <xref format="default" target="RFC4572"/> is repla
ced
with a reference to <xref format="default" target="RFC8122"/>.</t>
</section> </section>
<section title="Update to RFC 5763"> <section numbered="true" toc="default">
<section title="Update to section 1"> <name>Update to Section 5</name>
<t>The reference to <xref format="default" pageno="false" target="RF <t>The text in <xref target="RFC5763" section="5" sectionFormat="comma
C4572"/> is replaced "/> ("Establishing a Secure Channel") is modified
with a reference to <xref format="default" pageno="false" target="RF by replacing generic
C8122"/>.</t> SDP offer/answer procedures for DTLS with a reference to this
</section> specification:
<section title="Update to section 5"> </t>
<t>The text in section 5 (Establishing a Secure Channel) is modified
by replacing generic
SDP offer/answer procedures for DTLS with a reference to this specif
ication:
</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 two endpoints in the exchange present their identities as part of
the DTLS handshake procedure using certificates. This document uses the DTLS handshake procedure using certificates. This document uses
certificates in the same style as described in "Connection-Oriented certificates in the same style as described in "Connection-Oriented
Media Transport over the Transport Layer Security (TLS) Protocol in Media Transport over the Transport Layer Security (TLS) Protocol in
the Session Description Protocol (SDP)" [RFC8122]. the Session Description Protocol (SDP)" <xref target="RFC8122" />.
</t>
<t>
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform "subjectAltName" attribute inside the certificate <bcp14>MAY</bcp14> use the uniform
resource identifier (URI) of the user. This is useful for debugging resource identifier (URI) of the user. This is useful for debugging
purposes only and is not required to bind the certificate to one of purposes only and is not required to bind the certificate to one of
the communication endpoints. The integrity of the certificate is the communication endpoints. The integrity of the certificate is
ensured through the fingerprint attribute in the SDP. ensured through the "fingerprint" attribute in the SDP.
</t>
<t>
The generation of public/private key pairs is relatively expensive. The generation of public/private key pairs is relatively expensive.
Endpoints are not required to generate certificates for each session. Endpoints are not required to generate certificates for each session.
</t>
The offer/answer model, defined in [RFC3264], is used by protocols <t>
like the Session Initiation Protocol (SIP) [RFC3261] to set up The offer/answer model, defined in <xref target="RFC3264"/>, is used by proto
cols
like the Session Initiation Protocol (SIP) <xref target="RFC3261" /> to set u
p
multimedia sessions. multimedia sessions.
</t>
<t>
When an endpoint wishes to set up a secure media session with another 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. 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 This offer includes, as part of the SDP payload, a fingerprint of
a certificate that the endpoint wants to use. The endpoint SHOULD a certificate that the endpoint wants to use. The endpoint <bcp14>SHOULD</bcp 14>
send the SIP message containing the offer to the offerer's SIP proxy send the SIP message containing the offer to the offerer's SIP proxy
over an integrity protected channel. The proxy SHOULD add an over an integrity-protected channel. The proxy <bcp14>SHOULD</bcp14> add an
Identity header field according to the procedures outlined in Identity header field according to the procedures outlined in
[RFC4474]. When the far endpoint receives the SIP message, it can <xref target="RFC4474" />. When the far endpoint receives the SIP message, it can
verify the identity of the sender using the Identity header field. verify the identity of the sender using the Identity header field.
Since the Identity header field is a digital signature across several Since the Identity header field is a digital signature across several
SIP header fields, in addition to the body of the SIP message, the 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 receiver can also be certain that the message has not been tampered
with after the digital signature was applied and added to the SIP with after the digital signature was applied and added to the SIP
message. message.
</t>
<t>
The far endpoint (answerer) may now establish a DTLS association with The far endpoint (answerer) may now establish a DTLS association with
the offerer. Alternately, it can indicate in its answer that the the offerer. Alternately, it can indicate in its answer that the
offerer is to initiate the DTLS association. In either case, mutual offerer is to initiate the DTLS association. In either case, mutual
DTLS certificate-based authentication will be used. After completing DTLS certificate-based authentication will be used. After completing
the DTLS handshake, information about the authenticated identities, the DTLS handshake, information about the authenticated identities,
including the certificates, are made available to the endpoint including the certificates, is made available to the endpoint
application. The answerer is then able to verify that the offerer's application. The answerer is then able to verify that the offerer's
certificate used for authentication in the DTLS handshake can be certificate used for authentication in the DTLS handshake can be
associated to a certificate fingerprint contained in the offer in associated with a certificate fingerprint contained in the offer in
the SDP. At this point, the answerer may indicate to the end user the SDP. At this point, the answerer may indicate to the end user
that the media is secured. The offerer may only tentatively accept that the media is secured. The offerer may only tentatively accept
the answerer's certificate since it may not yet have the answerer's the answerer's certificate, since it may not yet have the answerer's
certificate fingerprint. certificate fingerprint
</t>
<t>
When the answerer accepts the offer, it provides an answer back to When the answerer accepts the offer, it provides an answer back to
the offerer containing the answerer's certificate fingerprint. At the offerer containing the answerer's certificate fingerprint. At
this point, the offerer can accept or reject the peer's certificate this point, the offerer can accept or reject the peer's certificate,
and the offerer can indicate to the end user that the media is and the offerer can indicate to the end user that the media is
secured. secured.
</t>
<t>
Note that the entire authentication and key exchange for securing Note that the entire authentication and key exchange for securing
the media traffic is handled in the media path through DTLS. The the media traffic is handled in the media path through DTLS. The
signaling path is only used to verify the peers' certificate signaling path is only used to verify the peers' certificate
fingerprints. fingerprints.
</t>
The offerer and answerer MUST follow the SDP offer/answer procedures <t>
defined in [RFCXXXX]. The offerer and answerer <bcp14>MUST</bcp14> follow the SDP offer/answer proc
edures
]]></artwork> defined in RFC 8842.
</figure> </t>
</section> </blockquote>
<section title="Update to section 6.6"> </section>
<t>The text in section 6.6 (Session Modification) is modified by replac <section numbered="true" toc="default">
ing generic <name>Update to Section 6.6</name>
<t>The text in <xref target="RFC5763" section="6.6" sectionFormat="com
ma"/> ("Session Modification") is modified by replacing generic
SDP offer/answer procedures for DTLS with a reference to this specif ication: SDP offer/answer procedures for DTLS with a reference to this specif ication:
</t> </t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:s
pace="preserve"><![CDATA[
<t>
NEW TEXT: NEW TEXT:
</t>
Once an answer is provided to the offerer, either endpoint MAY <blockquote>
request a session modification that MAY include an updated offer. <t>
Once an answer is provided to the offerer, either endpoint <bcp14>MAY</bcp14>
request a session modification that <bcp14>MAY</bcp14> include an updated off
er.
This session modification can be carried in either an INVITE or This session modification can be carried in either an INVITE or
UPDATE request. The peers can reuse an existing DTLS association, UPDATE request. The peers can reuse an existing DTLS association
or establish a new one, following the procedures in [RFCXXXX]. or establish a new one, following the procedures in RFC 8842.
</t></blockquote>
]]></artwork> </section>
</figure> <section numbered="true" toc="default">
</section> <name>Update to Section 6.7.1</name>
<section title="Update to section 6.7.1"> <t>The text in <xref target="RFC5763" section="6.7.1" sectionFormat="c
<t>The text in section 6.7.1 (ICE Interaction) is modified by replacing the omma"/> ("ICE Interaction") is modified by
ICE procedures with replacing the ICE procedures with
a reference to this specification: a reference to this specification:
</t> </t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="p
reserve"><![CDATA[
<t>
NEW TEXT: NEW TEXT:
</t>
<blockquote>
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media <xref target="RFC8445" /> considerations for DTLS-protected media
are described in [RFCXXXX]. are described in RFC 8842.
]]></artwork> </blockquote>
</figure>
</section>
</section> </section>
<section title="Update to RFC 7345"> </section>
<section title="Update to section 4"> <section numbered="true" toc="default">
<t>The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer <name>Update to RFC 7345</name>
Procedures) are removed, and replaced with the new text below:</t> <section numbered="true" toc="default">
<figure> <name>Update to Section 4</name>
<artwork align="left" alt="" height="" name="" type="" width="" <t>The subsections (4.1 - 4.5) in <xref target="RFC7345" section="4"
xml:space="preserve"><![CDATA[ sectionFormat="comma"/> ("SDP Offerer/Answerer
Procedures") are removed and replaced with the new text below:</t>
NEW TEXT: <t>NEW TEXT:</t>
<blockquote>
An endpoint (i.e., both the offerer and the answerer) MUST create an <t>
An endpoint (i.e., both the offerer and the answerer) <bcp14>MUST</bcp14> cre
ate an
SDP media description ("m=" line) for each UDPTL-over-DTLS media SDP media description ("m=" line) for each UDPTL-over-DTLS media
stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the stream and <bcp14>MUST</bcp14> assign a UDP/TLS/UDPTL value (see Table 1) to the
"proto" field of the "m=" line. "proto" field of the "m=" line.
</t>
The offerer and answerer MUST follow the SDP offer/answer procedures <t>
defined in [RFCXXXX] in order to negotiate the DTLS association The offerer and answerer <bcp14>MUST</bcp14> follow the SDP offer/answer proc
edures
defined in RFC 8842 in order to negotiate the DTLS association
associated with the UDPTL-over-DTLS media stream. In addition, associated with the UDPTL-over-DTLS media stream. In addition,
the offerer and answerer MUST use the SDP attributes defined for the offerer and answerer <bcp14>MUST</bcp14> use the SDP attributes defined f
UDPTL over UDP, as defined in [ITU.T38.2010]. or
UDPTL over UDP, as defined in <xref target="ITU.T38" />.
</t>
</blockquote>
]]></artwork> </section>
</figure> <section numbered="true" toc="default">
</section> <name>Update to Section 5.2.1</name>
<section title="Update to section 5.2.1"> <t>The text in <xref target="RFC7345" section="5.2.1"
<t>The text in section 5.2.1 (ICE Usage) is modified by replacing the ICE pr sectionFormat="comma"/> ("ICE Usage") is modified by replacing the
ocedures with ICE procedures with a reference to this specification:
a reference to this specification: </t>
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="p
reserve"><![CDATA[
<t>
NEW TEXT: NEW TEXT:
</t>
<blockquote>
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media <xref target="RFC8445" /> considerations for DTLS-protected media
are described in [RFCXXXX]. are described in RFC 8842.
</blockquote>
[RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX
with the RFC number of this document.]
]]></artwork> </section>
</figure> <section numbered="true" toc="default">
</section> <name>Update to Section 9.1</name>
<section title="Update to section 10.1"> <t>A reference to <xref format="default" target="RFC8122"/> is added
<t>A reference to <xref format="default" pageno="false" target="RF to <xref target="RFC7345" section="9.1"
C8122"/> is added to section 10.1 (Normative References):</t> sectionFormat="comma"/> ("Normative References"):</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
<t>
NEW TEXT: NEW TEXT:
</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,
<eref brackets="angle" target="https://www.rfc-editor.org/info/rfc8122"/>.
</dd>
</dl>
</blockquote>
[RFC8122] 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>
</section>
</section> </section>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
This specification does not modify the security considerations assoc This specification does not modify the security considerations
iated with DTLS, or associated with DTLS or
the SDP offer/answer mechanism. In addition to the introduction of t he SDP the SDP offer/answer mechanism. In addition to the introduction of t he SDP
'tls-id' attribute, the specification simply clarifies the procedure s for "tls-id" attribute, this document simply clarifies the procedures fo r
negotiating and establishing a DTLS association. negotiating and establishing a DTLS association.
</t> </t>
<t> <t>
This specification does not modify the actual TLS connection setup p rocedures. The This specification does not modify the actual TLS connection setup p rocedures. The
SDP 'tls-is' attribute as such cannot be used to correlate an SDP Of SDP "tls-is" attribute as such cannot be used to correlate an SDP
fer/Answer exchange with a offer/answer exchange with a
TLS connection setup. Thus, this draft does not introduce new securi TLS connection setup. Thus, this document does not introduce new
ty considerations security considerations
related to correlating an SDP Offer/Answer exchange with a TLS conne related to correlating an SDP offer/answer exchange with a TLS conne
ction setup. ction setup.
</t> </t>
</section> </section>
<section anchor="section.iana" numbered="true" toc="default">
<section anchor="section.iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
This document updates the "Session Description Protocol Parameters" registry This document updates the "Session Description Protocol Parameters" registry
as specified in Section 8.2.2 of <xref target="RFC4566" pageno="fals as specified in <xref target="RFC4566"
e" format="default"/>. format="default" sectionFormat="of" section="8.2.2" />.
Specifically, it adds the SDP 'tls-id' attribute to the table for SD Specifically, it adds the SDP "tls-id" attribute to the table for SD
P P
media level attributes. media-level attributes as follows.
</t> </t>
<figure>
<artwork align="left"><![CDATA[
Attribute name: tls-id <dl>
Type of attribute: media-level
Subject to charset: no
Purpose: 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> <dt>Attribute name:</dt>
</figure> <dd>tls-id</dd>
</section>
<section title="Acknowledgements"> <dt>Type of attribute:</dt>
<t> <dd>Media-level</dd>
Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing commen <dt>Subject to charset:</dt>
ts and <dd>No</dd>
suggestions on the document. Ben Campbell performed an AD review. Pa
ul <dt>Purpose:</dt>
Kyzivat performed a gen-art review. <dd>Indicates whether a new DTLS association or TLS connection is to be
</t> established/re-established.</dd>
</section>
<section title="Change Log"> <dt>Appropriate Values:</dt>
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t> <dd>See <xref target="sec-dcon-attr" /></dd>
<t>Changes from draft-ietf-mmusic-sdp-dtls-31
<list style="symbols"> <dt>Contact name:</dt>
<t>Changes based on IESG comments from Eric R</t> <dd>Christer Holmberg</dd>
</list>
</t> <dt>Mux Category:</dt>
<t>Changes from draft-ietf-mmusic-sdp-dtls-30 <dd>IDENTICAL</dd>
<list style="symbols">
<t>Changes based on IESG comments from Mirja K</t> </dl>
</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 ass
ociation</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, Al
exey 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 subseq
uent 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/msg1770
7.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 Introductio
n</t>
<t>Reference to RFC 5763 removed from section 6 (ICE Considerati
ons)</t>
<t>Reference to RFC 5763 removed from section 8 (SIP Considerati
ons)</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 Uber
ti, 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 mu
ltiple 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 ov
er multiple transports added.</t>
<t>Mux category added to IANA Considerations.</t>
<t>Normative text regarding mux category and source-specific app
licability 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 Eck
el.</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 tran
saction.</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 certific
ates, 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' attri
bute.</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 collis
ion with another expired draft.</t>
<t>- Clarify that if ufrag in offer is unchanged, it must be unc
hanged 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> </section>
</middle> </middle>
<back>
<back> <references>
<references title="Normative References"> <name>References</name>
<?rfc include="reference.RFC.2119"?> <references>
<?rfc include="reference.RFC.3261"?> <name>Normative References</name>
<?rfc include="reference.RFC.3264"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.4145"?> ence.RFC.2119.xml"/>
<?rfc include="reference.RFC.4566"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.5763"?> ence.RFC.3261.xml"/>
<?rfc include="reference.RFC.6347"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.7345"?> ence.RFC.3264.xml"/>
<?rfc include="reference.RFC.8122"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.8174"?> ence.RFC.4145.xml"/>
<?rfc include="reference.I-D.draft-ietf-ice-rfc5245bis-13"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?> ence.RFC.4566.xml"/>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-39 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
"?> ence.RFC.5763.xml"/>
</references> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<references title="Informative References"> ence.RFC.6347.xml"/>
<?rfc include="reference.RFC.4474"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.4572"?> ence.RFC.7345.xml"/>
<?rfc include="reference.RFC.5576"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.6083"?> ence.RFC.8122.xml"/>
<?rfc include="reference.RFC.7983"?> <xi:include
<?rfc include="reference.I-D.draft-ietf-stir-rfc4474bis-16"?> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
<?rfc include="reference.I-D.draft-ietf-mmusic-ice-sip-sdp-14"?> 8174.xml"/>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-uks-00"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<reference anchor="ITU.T38.2010"> ence.RFC.8445.xml"/>
<!-- draft-ietf-mmusic-sdp-mux-attributes-17 (RFC 8859) -->
<reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
859">
<front> <front>
<title>Procedures for real-time Group 3 facsimile communication over I <title>A Framework for Session Description Protocol (SDP)
P networks</title> Attributes When Multiplexing</title>
<author> <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
<organization>International Telecommunications Union</organization> ">
</author> <organization/>
<date year="2010" month="September"/> </author>
<date month="January" year="2021"/>
</front> </front>
<seriesInfo value="Recommendation T.38" name="ITU-T"/> <seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
</reference> </reference>
</references>
</back> <!-- 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 Prot
ocol (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/refer
ence.RFC.4474.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4572.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5576.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.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 Interactiv
e 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 Pro
tocol (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/e
n">
<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 numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
Thanks to <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. <contact fullname="Ben Campbell"/> performed an Area
Director review. <contact fullname="Paul Kyzivat"/> performed a
Gen-ART review.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 128 change blocks. 
1225 lines changed or deleted 1151 lines changed or added

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