Session
Description Protocol (SDP) Offer/Answer Considerations for Datagram
Transport Layer Security (DTLS) and Transport Layer Security (TLS)EricssonHirsalantie 11Jorvas02420Finlandchrister.holmberg@ericsson.comTurboBridge4905 Del Ray Avenue, Suite 300BethesdaMD20814United States of Americarshpount@turbobridge.com
RAI
SDPDTLStls-id
This document defines the Session Description Protocol (SDP)
offer/answer procedures for negotiating and establishing a Datagram
Transport Layer Security (DTLS) association. The document also
defines the criteria for when a new DTLS association must be
established. The document updates RFCs 5763 and 7345 by replacing
common SDP offer/answer procedures with a reference to this
specification.
This document defines a new SDP media-level attribute, "tls-id".
This document also defines how the "tls-id" attribute can be used
for negotiating and establishing a Transport Layer Security (TLS)
connection, in conjunction with the procedures in RFCs 4145 and
8122.
Introduction defines Session
Description Protocol (SDP)
offer/answer procedures for Secure Real-time Transport
Protocol using Datagram Transport Layer Security (DTLS-SRTP).
defines SDP
offer/answer procedures for
UDP Transport Layer over Datagram Transport Layer Security
(UDPTL-DTLS). This specification
defines general offer/answer procedures for DTLS, based on the
procedures in .
Other specifications, defining specific DTLS usages, can then
reference this specification,
in order to ensure that the DTLS aspects are common among all
usages. Having common
procedures is essential when multiple usages share the same
DTLS association .
This document updates
and by replacing common
SDP offer/answer procedures with a reference to this specification.
As defined in , a new DTLS association
MUST be established when transport parameters are
changed. Transport parameter change is not
well defined when Interactive Connectivity Establishment (ICE)
is
used. One possible way to determine a transport change is
based on ufrag change,
but the ufrag value is changed both when ICE is negotiated
and when ICE restart occurs. These events
do not always require a new DTLS association to be established, but
previously there was no way
to explicitly indicate in an SDP offer or answer whether a new DTLS
association was required.
To solve that problem, this document defines a new SDP attribute,
"tls-id". The pair of
SDP "tls-id" attribute values (the attribute values of the offerer and the answerer)
uniquely identifies the DTLS association. Providing a new value of the
"tls-id" attribute in an SDP offer
or answer can be used to indicate whether a new DTLS association is
to be established.
The SDP "tls-id" attribute can be specified when negotiating a
Transport Layer Security (TLS) connection, using
the procedures in this document in conjunction with the procedures in
and .
The unique combination of SDP "tls-id" attribute values can be used to
identify the negotiated
TLS connection. The unique value can be used, for example, within TLS
protocol extensions to
differentiate between multiple TLS connections and correlate those
connections with specific
offer/answer exchanges. The TLS-specific considerations are described
in .
Conventions
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as described in BCP 14 when, and only when, they appear in all capitals,
as shown here.
Establishing a New DTLS AssociationGeneral
A new DTLS association must be established between two endpoints after a
successful SDP offer/answer exchange in the following cases:
The negotiated DTLS setup roles change; or
One or more fingerprint values are modified, added,
or removed in either an SDP offer or answer; or
The intent to establish a new DTLS association is
explicitly signaled using SDP, by changing the value of the
SDP "tls-id" attribute defined in this document;
A new DTLS association can only be established as a result of the
successful SDP offer/answer exchange.
Whenever an entity determines that a new DTLS association is
required, the entity MUST initiate an
SDP offer/answer exchange, following the procedures in .
The sections below describe typical cases where a new DTLS
association needs to be established.
In this document, a "new DTLS association" between two endpoints refers to either
an initial DTLS association (when no DTLS association is currently
established between
the endpoints) or a DTLS association replacing a previously
established one.
Change of Local Transport Parameters
If an endpoint modifies its local transport parameters
(address and/or port), and if the modification
requires a new DTLS association, the endpoint
MUST change its local SDP "tls-id"
attribute value (see ).
If the underlying transport protocol prohibits a DTLS association from spanning multiple 5-tuples
(transport/source address/source port/destination address/destination port),
and if the 5-tuple is changed, the endpoint MUST change its local SDP "tls-id" attribute value (see ).
An example of such a case is when DTLS is carried over the Stream Control Transmission Protocol (SCTP),
as described in .
Change of ICE ufrag Value
If an endpoint uses ICE and modifies a local ufrag value, and if the modification
requires a new DTLS association, the endpoint
MUST change its local SDP "tls-id"
attribute value (see ).
SDP "tls-id" Attribute
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.
Name:
tls-id
Value:
tls-id-value
Usage Level:
media
Charset Dependent:
no
Default Value:
N/A
Syntax:
tls-id-value = 20*255(tls-id-char)
tls-id-char = ALPHA / DIGIT / "+" / "/" / "-" / "_"
<ALPHA and DIGIT defined in RFC 4566>
Example:
a=tls-id:abc3de65cddef001be82
Every time an endpoint requests to establish a new DTLS
association, the endpoint MUST
generate a new local "tls-id" attribute value. An unchanged local
"tls-id" attribute
value, in combination with non-changed fingerprints, indicates
that the endpoint
intends to reuse the existing DTLS association.
The "tls-id" attribute value MUST be generated using a strong random function
and include at least 120 bits of randomness.
No default value is defined for the SDP "tls-id" attribute.
Implementations that wish to use the attribute MUST explicitly
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
answerer represents an existing implementation that has not been
updated to support the "tls-id" attribute), a modification of one
or more of the following characteristics MUST 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
is to be established:
DTLS setup role; or
fingerprint set; or
local transport parameters
The mux category
for the "tls-id" attribute is "IDENTICAL", which means that
the attribute value applies to all media descriptions
being multiplexed .
However, as described in ,
in order to avoid duplication, the attribute is only associated with the "m=" line
representing the offerer/answerer BUNDLE tag.
For RTP-based media, the "tls-id" attribute applies to the whole associated
media description. The attribute MUST NOT be defined per source (using the
SDP "ssrc" attribute ).
The SDP offer/answer procedures
associated with the attribute are defined in .
SDP Offer/Answer ProceduresGeneral
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.
The procedures in this section apply to an SDP media description
("m=" line) associated
with DTLS-protected media/data.
When an offerer or answerer indicates that it wants to establish a
new DTLS association, it needs to make sure that
media packets associated with any previously established DTLS
association and the new DTLS association can be 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) MUST be allocated by at least
one of the endpoints so that DTLS packets can be demultiplexed.
When an offerer needs to establish a new DTLS association, and if an
unordered transport (e.g., UDP)
is used, the offerer MUST allocate a new 3-tuple for
the offer in such a way that the offerer can
disambiguate any packets associated with the new DTLS association
from any packets associated with
any other DTLS association. This typically means using a local
address and/or port, or a set of
ICE candidates (see ), which were
not recently used for any other DTLS association.
When an answerer needs to establish a new DTLS association, if an
unordered transport is used, and
the offerer did not allocate a new 3-tuple, the answerer
MUST allocate a new 3-tuple for the
answer in such a way that it can disambiguate any packets associated
with the new DTLS association from any
packets associated with any other DTLS association. This typically
means using a local address and/or
port, or a set of ICE candidates (see ),
which were not recently used for any other DTLS association.
In order to negotiate a DTLS association, the following SDP attributes are used:
The SDP "setup" attribute, defined in , is used to negotiate the DTLS roles;
The SDP "fingerprint" attribute, defined in , is used to
provide one or more fingerprint values; and
The SDP "tls-id" attribute, defined in this specification, is used to identity
the DTLS association.
This specification does not define the usage of the SDP "connection" attribute
for negotiating a DTLS
association. However, the attribute MAY be used if the DTLS association is used
together with another protocol (e.g., SCTP or TCP) for which the usage of the
attribute has been defined.
Unlike for TCP and TLS connections, endpoints MUST NOT use the
SDP "setup" attribute "holdconn" value when negotiating a DTLS association.
Endpoints MUST support the hash functions as defined in
.
The certificate received during the DTLS handshake MUST match a certificate
fingerprint received in SDP "fingerprint" attributes according to the procedures
defined in .
If fingerprints do not match the hashed certificate, then an endpoint MUST tear
down the media session immediately (see ).
SDP offerers and answerers might reuse certificates across multiple DTLS
associations, and provide identical fingerprint values for each DTLS
association. The combination of the SDP "tls-id" attribute values of the SDP
offerer and answerer identifies each individual DTLS association.
Generating the Initial SDP Offer
When an offerer sends the initial offer, the offerer
MUST insert an SDP "setup" attribute
with an "actpass"
attribute value, as well as
one or more SDP "fingerprint" attributes according to the procedures
in . In addition, the
offerer MUST insert in the offer an SDP
"tls-id" attribute with a unique attribute value.
As the offerer inserts the SDP "setup" attribute with an
"actpass" attribute value, the
offerer MUST be prepared to receive a DTLS
ClientHello message
from the answerer
(if a new DTLS association is established by the answerer)
before the offerer receives the SDP answer.
If the offerer receives a DTLS ClientHello message, and a DTLS
association is established
before the offerer receives the SDP answer carrying the
fingerprint associated with the DTLS
association, any data received on the DTLS association before
the fingerprint MUST be
considered to be coming from an unverified source. The processing of
such data and sending of data
by the offerer to the unverified source is outside the scope
of this document.
Generating the Answer
When an answerer sends an answer, the answerer
MUST insert in the answer an SDP "setup"
attribute
according to the procedures in and one
or more SDP "fingerprint" attributes according to the
procedures in .
If the answerer determines, based on the criteria specified in
,
that a new DTLS association is to be established, the answerer
MUST insert in the associated answer
an SDP "tls-id" attribute with a new unique attribute
value. Note that the offerer and answerer generate
their own local "tls-id" attribute values, and the combination
of both values identifies the
DTLS association.
If the answerer receives an offer that requires establishment of a new DTLS association, and if the
answerer does not accept the establishment of a new DTLS association, the answerer MUST reject
the "m=" lines associated with the suggested DTLS association
.
If an answerer receives an offer that does not require the establishment of a new DTLS association,
and if the answerer determines that a new DTLS association is not to be established,
the answerer MUST insert in the associated
answer an SDP "tls-id"
attribute with the previously assigned attribute value. In
addition, the answerer
MUST insert an SDP "setup" attribute with an
attribute value that does not change the previously negotiated
DTLS roles, as well as one or more SDP "fingerprint"
attributes values that do not change the previously sent
fingerprint set, in the associated answer.
If the answerer receives an offer that does not contain an SDP "tls-id" attribute,
the answerer MUST NOT insert a "tls-id" attribute in the answer.
If a new DTLS association is to be established, and if the
answerer inserts an SDP "setup"
attribute with an "active" attribute value in the answer, the
answerer MUST initiate a DTLS handshake
by sending a DTLS
ClientHello message towards the offerer.
Even though an offerer is required to insert an "SDP" setup attribute with an "actpass" attribute value
in initial offers () and subsequent offers (),
the answerer MUST be able to receive initial and subsequent offers with other attribute values, in order
to be backward compatible with older implementations that might insert other attribute values in initial and
subsequent offers.
Offerer Processing of the SDP Answer
When an offerer receives an answer that establishes a new DTLS
association based on
criteria defined in , if the offerer
becomes DTLS client (based on the value of the SDP "setup" attribute value
), the offerer MUST
establish a DTLS association. If the offerer becomes DTLS server, it MUST wait for the answerer
to establish the DTLS association.
If the offerer indicated a desire to reuse an existing DTLS
association, and the
answerer does not request the establishment of a new DTLS
association, the offerer will
continue to use the previously established DTLS association.
A new DTLS association can be established based on changes in either
an SDP offer or answer.
When communicating with legacy endpoints, an offerer can receive an
answer that includes the same
fingerprint set and setup role. A new DTLS association will still be
established if such an answer
is received as a response to an offer that requested the
establishment of a new DTLS association,
as the transport parameters would have been changed in the offer.
Modifying the Session
When an offerer sends a subsequent offer, if the offerer
wants to establish a new
DTLS association, the offerer MUST insert an
SDP "setup" attribute with an "actpass" attribute value, as well as
or more SDP "fingerprint"
attributes according to the procedures in .
In addition, the offerer MUST insert in the offer an SDP "tls-id" attribute with a new unique
attribute value.
When an offerer sends a subsequent offer and does
not want to establish
a new DTLS association, if a previously established DTLS
association exists,
the offerer MUST insert in the offer an SDP "setup"
attribute with an "actpass" attribute value, and
one or more SDP "fingerprint" attributes with attribute values
that do not change the previously
sent fingerprint set. In addition, the offerer
MUST insert an SDP "tls-id"
attribute with the previously assigned attribute value in the offer.
ICE Considerations
When the Interactive Connectivity Establishment (ICE) mechanism
is used, the
ICE connectivity checks are performed before the DTLS
handshake begins. Note that if aggressive nomination mode is used,
multiple candidate pairs may be marked valid before ICE finally
converges on a single candidate pair.
When a new DTLS association is established over an unordered
transport, in order to
disambiguate any packets associated with the newly established
DTLS association, at least
one of the endpoints MUST allocate a completely new
set of ICE candidates that
were not recently used for any other DTLS association. This means the answerer
cannot initiate a new DTLS association unless the offerer initiated ICE restart
. If the answerer wants
to initiate a new DTLS association, it needs to initiate an ICE restart
and a new offer/answer exchange on its own. However, an ICE restart does not by
default require a new DTLS association
to be established.
Each ICE candidate associated with a component is treated as being part of the
same DTLS association. Therefore, from a DTLS perspective, it is not considered
a change of local transport parameters when an endpoint switches between those
ICE candidates.
TLS Considerations
The procedures in this document can also be used for negotiating and
establishing a TLS connection, with the restriction described below.
As specified in ,
the SDP "connection" attribute is used to indicate whether to establish a new
TLS connection. An offerer and answerer MUST ensure
that the "connection"
attribute value and the "tls-id" attribute value do not cause a conflict
regarding whether a new TLS connection is to be established or not.
If an offerer or answerer inserts an SDP "connection" attribute with a "new"
value in the offer/answer and also inserts an SDP "tls-id" attribute,
the value of the "tls-id" attribute MUST be new and unique.
If an offerer or answerer inserts an SDP "connection" attribute with an "existing"
value in the offer/answer, if a previously established TLS connection exists, and
if the offerer/answerer previously inserted an SDP "tls-id" attribute associated with
the same TLS connection in an offer/answer, the offerer/answerer
MUST also insert
an SDP "tls-id" attribute with the previously assigned value in the offer/answer.
If an offerer or answerer receives an offer/answer with conflicting attribute values,
the offerer/answerer MUST process the offer/answer as misformed.
An endpoint MUST NOT make assumptions regarding the
support of the SDP "tls-id"
attribute by the peer. Therefore, to avoid ambiguity, both
offerers and answerers
MUST always use the "connection" attribute in
conjunction with the "tls-id" attribute.
The SDP example below is based on the example in
, with the addition of
the SDP "tls-id" attribute.
m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=tls-id:abc3de65cddef001be82
a=setup:passive
a=connection:new
a=fingerprint:SHA-256 \
12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
SIP Considerations
When the Session Initiation Protocol (SIP) is used as the signal protocol for establishing
a multimedia
session, dialogs might be
established between the caller and multiple callees. This is referred to as forking.
If forking occurs, separate DTLS associations will be established between the caller
and each callee.
When forking occurs, an SDP offerer can receive DTLS ClientHello
messages and SDP
answers from multiple remote locations. Because of this, the
offerer might have to
wait for multiple SDP answers (from different remote locations)
until it receives
a certificate fingerprint that matches the certificate associated
with a specific
DTLS handshake. The offerer MUST NOT declare a
fingerprint mismatch until it
determines that it will not receive SDP answers from any
additional remote locations.
It is possible to send an INVITE request that does not contain an SDP offer. Such
an INVITE request is often referred to as an "empty INVITE" or an
"offerless INVITE".
The receiving endpoint will include the SDP offer in a response to the request.
When the endpoint generates such an SDP offer, if a previously established
DTLS association exists, the offerer MUST insert an SDP "tls-id"
attribute and one or more SDP "fingerprint" attributes, with previously assigned
attribute values. If a previously established DTLS association does not exist,
the offer MUST be generated based on the same rules as a new offer (see ).
Regardless of the previous existence of a DTLS association, the
SDP "setup" attribute
MUST be included according to the rules defined in
. Furthermore, if ICE is
used, ICE restart MUST be initiated, according to
the third-party call-control
considerations described in .
RFC UpdatesGeneral
This section updates specifications that use DTLS-protected media, in
order to reflect the procedures defined in this specification.
Update to RFC 5763Update to Section 1The reference to is replaced
with a reference to .Update to Section 5The text in ("Establishing a Secure Channel") is modified
by replacing generic
SDP offer/answer procedures for DTLS with a reference to this
specification:
NEW TEXT:
The two endpoints in the exchange present their identities as part of
the DTLS handshake procedure using certificates. This document uses
certificates in the same style as described in "Connection-Oriented
Media Transport over the Transport Layer Security (TLS) Protocol in
the Session Description Protocol (SDP)" .
If self-signed certificates are used, the content of the
"subjectAltName" attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. This is useful for debugging
purposes only and is not required to bind the certificate to one of
the communication endpoints. The integrity of the certificate is
ensured through the "fingerprint" attribute in the SDP.
The generation of public/private key pairs is relatively expensive.
Endpoints are not required to generate certificates for each session.
The offer/answer model, defined in , is used by protocols
like the Session Initiation Protocol (SIP) to set up
multimedia sessions.
When an endpoint wishes to set up a secure media session with another
endpoint, it sends an offer in a SIP message to the other endpoint.
This offer includes, as part of the SDP payload, a fingerprint of
a certificate that the endpoint wants to use. The endpoint SHOULD
send the SIP message containing the offer to the offerer's SIP proxy
over an integrity-protected channel. The proxy SHOULD add an
Identity header field according to the procedures outlined in
. When the far endpoint receives the SIP message, it can
verify the identity of the sender using the Identity header field.
Since the Identity header field is a digital signature across several
SIP header fields, in addition to the body of the SIP message, the
receiver can also be certain that the message has not been tampered
with after the digital signature was applied and added to the SIP
message.
The far endpoint (answerer) may now establish a DTLS association with
the offerer. Alternately, it can indicate in its answer that the
offerer is to initiate the DTLS association. In either case, mutual
DTLS certificate-based authentication will be used. After completing
the DTLS handshake, information about the authenticated identities,
including the certificates, is made available to the endpoint
application. The answerer is then able to verify that the offerer's
certificate used for authentication in the DTLS handshake can be
associated with a certificate fingerprint contained in the offer in
the SDP. At this point, the answerer may indicate to the end user
that the media is secured. The offerer may only tentatively accept
the answerer's certificate, since it may not yet have the answerer's
certificate fingerprint
When the answerer accepts the offer, it provides an answer back to
the offerer containing the answerer's certificate fingerprint. At
this point, the offerer can accept or reject the peer's certificate,
and the offerer can indicate to the end user that the media is
secured.
Note that the entire authentication and key exchange for securing
the media traffic is handled in the media path through DTLS. The
signaling path is only used to verify the peers' certificate
fingerprints.
The offerer and answerer MUST follow the SDP offer/answer procedures
defined in RFC 8842.
Update to Section 6.6The text in ("Session Modification") is modified by replacing generic
SDP offer/answer procedures for DTLS with a reference to this specification:
NEW TEXT:
Once an answer is provided to the offerer, either endpoint MAY
request a session modification that MAY include an updated offer.
This session modification can be carried in either an INVITE or
UPDATE request. The peers can reuse an existing DTLS association
or establish a new one, following the procedures in RFC 8842.
Update to Section 6.7.1The text in ("ICE Interaction") is modified by
replacing the ICE procedures with
a reference to this specification:
NEW TEXT:
The Interactive Connectivity Establishment (ICE)
considerations for DTLS-protected media
are described in RFC 8842.
Update to RFC 7345Update to Section 4The subsections (4.1 - 4.5) in ("SDP Offerer/Answerer
Procedures") are removed and replaced with the new text below:NEW TEXT:
An endpoint (i.e., both the offerer and the answerer) MUST create an
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
"proto" field of the "m=" line.
The offerer and answerer MUST follow the SDP offer/answer procedures
defined in RFC 8842 in order to negotiate the DTLS association
associated with the UDPTL-over-DTLS media stream. In addition,
the offerer and answerer MUST use the SDP attributes defined for
UDPTL over UDP, as defined in .
Update to Section 5.2.1The text in ("ICE Usage") is modified by replacing the
ICE procedures with a reference to this specification:
NEW TEXT:
The Interactive Connectivity Establishment (ICE)
considerations for DTLS-protected media
are described in RFC 8842.
Update to Section 9.1A reference to is added
to ("Normative References"):
NEW TEXT:
[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,
.
Security Considerations
This specification does not modify the security considerations
associated with DTLS or
the SDP offer/answer mechanism. In addition to the introduction of the SDP
"tls-id" attribute, this document simply clarifies the procedures for
negotiating and establishing a DTLS association.
This specification does not modify the actual TLS connection setup procedures. The
SDP "tls-is" attribute as such cannot be used to correlate an SDP
offer/answer exchange with a
TLS connection setup. Thus, this document does not introduce new
security considerations
related to correlating an SDP offer/answer exchange with a TLS connection setup.
IANA Considerations
This document updates the "Session Description Protocol Parameters" registry
as specified in .
Specifically, it adds the SDP "tls-id" attribute to the table for SDP
media-level attributes as follows.
Attribute name:
tls-id
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
Contact name:
Christer Holmberg
Mux Category:
IDENTICAL
ReferencesNormative ReferencesA Framework for Session Description Protocol (SDP)
Attributes When MultiplexingNegotiating Media Multiplexing Using the Session Description Protocol (SDP)Informative ReferencesSession Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP)Procedures for real-time Group 3 facsimile communication over IP networksITU-TAcknowledgements
Thanks to , , ,
, , , and for providing comments and suggestions on
the document. performed an Area
Director review. performed a
Gen-ART review.