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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Conventions
. Establishing a New DTLS Association
. General
. Change of Local Transport Parameters
. Change of ICE ufrag Value
. SDP "tls-id" Attribute
. SDP Offer/Answer Procedures
. General
. Generating the Initial SDP Offer
. Generating the Answer
. Offerer Processing of the SDP Answer
. Modifying the Session
. ICE Considerations
. TLS Considerations
. SIP Considerations
. RFC Updates
. General
. Update to RFC 5763
. Update to Section 1
. Update to Section 5
. Update to Section 6.6
. Update to Section 6.7.1
. Update to RFC 7345
. Update to Section 4
. Update to Section 5.2.1
. Update to Section 9.1
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
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 ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]An Offer/Answer Model with Session Description Protocol (SDP)This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]TCP-Based Media Transport in the Session Description Protocol (SDP)This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK]Datagram Transport Layer Security Version 1.2This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session Description Protocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP).Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) TraversalThis document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).This document obsoletes RFC 5245.Negotiating Media Multiplexing Using the Session Description Protocol (SDP)A Framework for Session Description Protocol (SDP) Attributes When MultiplexingInformative ReferencesProcedures for real-time Group 3 facsimile communication over IP networksITU-TEnhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK]Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.This document extends and updates RFC 4145. [STANDARDS-TRACK]Source-Specific Media Attributes in the Session Description Protocol (SDP)The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, in SDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. [STANDARDS-TRACK]Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. [STANDARDS-TRACK]Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document.This document updates RFC 5764.Authenticated Identity Management in the Session Initiation Protocol (SIP)The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.This document obsoletes RFC 4474.Session 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)Acknowledgements
Thanks to , , ,
, , , and for providing comments and suggestions on
the document. performed an Area
Director review. performed a
Gen-ART review.
Authors' AddressesEricssonHirsalantie 11Jorvas02420Finlandchrister.holmberg@ericsson.comTurboBridge4905 Del Ray Avenue, Suite 300BethesdaMD20814United States of Americarshpount@turbobridge.com