draft-ietf-mmusic-dtls-sdp-30.txt   draft-ietf-mmusic-dtls-sdp-31.txt 
Network Working Group C. Holmberg Network Working Group C. Holmberg
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 5763,7345 (if approved) R. Shpount Updates: 5763,7345 (if approved) R. Shpount
Intended status: Standards Track TurboBridge Intended status: Standards Track TurboBridge
Expires: March 12, 2018 September 8, 2017 Expires: April 10, 2018 October 7, 2017
Session Description Protocol (SDP) Offer/Answer Considerations for Session Description Protocol (SDP) Offer/Answer Considerations for
Datagram Transport Layer Security (DTLS) and Transport Layer Security Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS) (TLS)
draft-ietf-mmusic-dtls-sdp-30.txt draft-ietf-mmusic-dtls-sdp-31.txt
Abstract Abstract
This document defines the Session Description Protocol (SDP) offer/ This document defines the Session Description Protocol (SDP) offer/
answer procedures for negotiating and establishing a Datagram answer procedures for negotiating and establishing a Datagram
Transport Layer Security (DTLS) association. The document also Transport Layer Security (DTLS) association. The document also
defines the criteria for when a new DTLS association must be defines the criteria for when a new DTLS association must be
established. The document updates RFC 5763 and RFC 7345, by established. The document updates RFC 5763 and RFC 7345, by
replacing common SDP offer/answer procedures with a reference to this replacing common SDP offer/answer procedures with a reference to this
specification. specification.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2018. This Internet-Draft will expire on April 10, 2018.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16 9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16
9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16 9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16
9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17
9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17 9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17
9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17 9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17
9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18 9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
[RFC5763] defines Session Description Protocol (SDP) offer/answer [RFC5763] defines Session Description Protocol (SDP) offer/answer
procedures for Secure Realtime Transport Protocol Using Datagram procedures for Secure Realtime Transport Protocol Using Datagram
Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/ Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/
skipping to change at page 4, line 5 skipping to change at page 4, line 5
pair of SDP 'tls-id' attribute values (the attribute values of the pair of SDP 'tls-id' attribute values (the attribute values of the
offerer and the answerer) uniquely identifies the DTLS association. offerer and the answerer) uniquely identifies the DTLS association.
Providing a new value of the 'tls-id' attribute in an SDP offer or Providing a new value of the 'tls-id' attribute in an SDP offer or
answers can be used to indicate whether a new DTLS association is to answers can be used to indicate whether a new DTLS association is to
be established. be established.
The SDP 'tls-id' attribute can be specified when negotiating a The SDP 'tls-id' attribute can be specified when negotiating a
Transport Layer Security (TLS) connection, using the procedures in Transport Layer Security (TLS) connection, using the procedures in
this document in conjunction with the procedures in [RFC5763] and this document in conjunction with the procedures in [RFC5763] and
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
[RFC8122]. The unique combination of SDP 'tls-id' attribute values [RFC8122]. The unique combination of SDP 'tls-id' attribute values
can be used to identity the negotiated TLS connection. The unique can be used to identity the negotiated TLS connection. The unique
value can be used, for example, within TLS protocol extensions to value can be used, for example, within TLS protocol extensions to
differentiate between multiple TLS connections and correlate those differentiate between multiple TLS connections and correlate those
connections with specific offer/answer exchanges. The TLS specific connections with specific offer/answer exchanges. The TLS specific
considerations are described in Section 7. considerations are described in Section 7.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 5, line 5 skipping to change at page 5, line 5
SDP offer/answer exchange, following the procedures in Section 5. SDP offer/answer exchange, following the procedures in Section 5.
The sections below describe typical cases where a new DTLS The sections below describe typical cases where a new DTLS
association needs to be established. association needs to be established.
In this document, a "new DTLS association" between two endpoints In this document, a "new DTLS association" between two endpoints
refers to either an initial DTLS association (when no DTLS refers to either an initial DTLS association (when no DTLS
association is currently established between the endpoints) or an association is currently established between the endpoints) or an
DTLS association replacing a previously established DTLS association. DTLS association replacing a previously established DTLS association.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
3.2. Change of Local Transport Parameters 3.2. Change of Local Transport Parameters
If an endpoint modifies its local transport parameters (address and/ If an endpoint modifies its local transport parameters (address and/
or port), and if the modification requires a new DTLS association, or port), and if the modification requires a new DTLS association,
the endpoint must change its local SDP 'tls-id' attribute value (see the endpoint MUST change its local SDP 'tls-id' attribute value (see
Section 4). Section 4).
If the underlying transport prohibits a DTLS association from If the underlying transport protocol prohibits a DTLS association
spanning multiple transports, and if the transport is changed, the from spanning multiple 5-tuples (transport/source address/source
endpoint must change its local SDP 'tls-id' attribute value (see port/destination address/destination port), and if the 5-tuple is
Section 4). An example of such a case is when DTLS is carried over changed, the endpoint MUST change its local SDP 'tls-id' attribute
the Stream Control Transmission Protocol (SCTP), as described in value (see Section 4). An example of such a case is when DTLS is
[RFC6083]. carried over the Stream Control Transmission Protocol (SCTP), as
described in [RFC6083].
3.3. Change of ICE ufrag value 3.3. Change of ICE ufrag value
If an endpoint uses ICE, and modifies a local ufrag value, and if the If an endpoint uses ICE, and modifies a local ufrag value, and if the
modification requires a new DTLS association, the endpoint MUST modification requires a new DTLS association, the endpoint MUST
change its local SDP 'tls-id' attribute value (see Section 4). change its local SDP 'tls-id' attribute value (see Section 4).
4. SDP tls-id Attribute 4. SDP tls-id Attribute
The pair of SDP 'tls-id' attribute values (the attribute values of The pair of SDP 'tls-id' attribute values (the attribute values of
the offerer and the answerer) uniquely identifies the DTLS the offerer and the answerer) uniquely identifies the DTLS
association or TLS connection. association or TLS connection.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Name: tls-id Name: tls-id
Value: tls-id-value Value: tls-id-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Default Value: N/A Default Value: N/A
skipping to change at page 7, line 4 skipping to change at page 7, line 4
mechanism to explicitly indicate that a new DTLS association is to be mechanism to explicitly indicate that a new DTLS association is to be
established, a modification of one or more of the following established, a modification of one or more of the following
characteristics MUST be treated as an indication that an endpoint characteristics MUST be treated as an indication that an endpoint
wants to establish a new DTLS association: wants to establish a new DTLS association:
o DTLS setup role; or o DTLS setup role; or
o fingerprint set; or o fingerprint set; or
o local transport parameters o local transport parameters
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
NOTE: A modification of the ufrag value is not treated as an NOTE: A modification of the ufrag value is not treated as an
indication that an endpoint wants to establish a new DTLS assocation. indication that an endpoint wants to establish a new DTLS assocation.
In order to indicate that a new DTLS association is to be In order to indicate that a new DTLS association is to be
established, one or more of the characteristics listed above have to established, one or more of the characteristics listed above have to
be modified. be modified.
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls-
id' attribute is 'IDENTICAL', which means that the attribute value id' attribute is 'IDENTICAL', which means that the attribute value
applies to all media descriptions being multiplexed applies to all media descriptions being multiplexed
[I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in
skipping to change at page 8, line 4 skipping to change at page 8, line 4
When an offerer or answerer indicates that it wants to establish a When an offerer or answerer indicates that it wants to establish a
new DTLS association, it needs to make sure that media packets new DTLS association, it needs to make sure that media packets
associated with any previously established DTLS association and the associated with any previously established DTLS association and the
new DTLS association can be de-multiplexed. In case of an ordered 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 transport (e.g., SCTP) this can be done simply by sending packets for
the new DTLS association after all packets associated with a the new DTLS association after all packets associated with a
previously established DTLS association has been sent. In case of an previously established DTLS association has been sent. In case of an
unordered transport, such as UDP, packets associated with a unordered transport, such as UDP, packets associated with a
previously established DTLS association can arrive after the answer previously established DTLS association can arrive after the answer
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
SDP was received and after the first packets associated with the new SDP was received and after the first packets associated with the new
DTLS association were received. The only way to de-multiplex packets DTLS association were received. The only way to de-multiplex packets
associated with with a previously established DTLS association and associated with with a previously established DTLS association and
the new DTLS association is on the basis of transport 5-tuple. the new DTLS association is on the basis of the 5-tuple. Because of
Because of this, if an unordered transport is used for the DTLS this, if an unordered transport is used for the DTLS association, a
association, a new transport (3-tuple) must be allocated by at least new 3-tuple (transport/source address/source port) MUST be allocated
one of the endpoints so that DTLS packets can be de-multiplexed. by at least one of the endpoints so that DTLS packets can be de-
multiplexed.
When an offerer needs to establish a new DTLS association, and if an 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 unordered transport (e.g., UDP) is used, the offerer MUST allocate a
new transport (3-tuple) for the offer in such a way that the offerer new 3-tuple for the offer in such a way that the offerer can
can disambiguate any packets associated with the new DTLS association disambiguate any packets associated with the new DTLS association
from any packets associated with any other DTLS association. This from any packets associated with any other DTLS association. This
typically means using a local address and/or port, or a set of ICE typically means using a local address and/or port, or a set of ICE
candidates (see Section 6), which were not recently used for any candidates (see Section 6), which were not recently used for any
other DTLS association. other DTLS association.
When an answerer needs to establish a new DTLS association, if an When an answerer needs to establish a new DTLS association, if an
unordered transport is used, and if the offerer did not allocate a unordered transport is used, and if the offerer did not allocate a
new transport, the answerer MUST allocate a new transport for the new 3-tuple, the answerer MUST allocate a new 3-tuple for the answer
answer in such a way that it can disambiguate any packets associated in such a way that it can disambiguate any packets associated with
with the new DTLS association from any packets associated with any the new DTLS association from any packets associated with any other
other DTLS association. This typically means using a local address DTLS association. This typically means using a local address and/or
and/or port, or a set of ICE candidates (see Section 6), which were port, or a set of ICE candidates (see Section 6), which were not
not recently used for any other DTLS association. recently used for any other DTLS association.
In order to negotiate a DTLS association, the following SDP In order to negotiate a DTLS association, the following SDP
attributes are used: attributes are used:
o The SDP 'setup' attribute, defined in [RFC4145], is used to o The SDP 'setup' attribute, defined in [RFC4145], is used to
negotiate the DTLS roles; negotiate the DTLS roles;
o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to o The SDP 'fingerprint' attribute, defined in [RFC8122], is used to
provide one or more fingerprint values; and provide one or more fingerprint values; and
skipping to change at page 9, line 5 skipping to change at page 9, line 5
This specification does not define the usage of the SDP 'connection' This specification does not define the usage of the SDP 'connection'
attribute [RFC4145] for negotiating a DTLS association. However, the attribute [RFC4145] for negotiating a DTLS association. However, the
attribute MAY be used if the DTLS association is used together with 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 another protocol (e.g., SCTP or TCP) for which the usage of the
attribute has been defined. attribute has been defined.
Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP Unlike for TCP and TLS connections, endpoints MUST NOT use the SDP
'setup' attribute 'holdconn' value when negotiating a DTLS 'setup' attribute 'holdconn' value when negotiating a DTLS
association. association.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Endpoints MUST support the hash functions as defined in [RFC8122]. Endpoints MUST support the hash functions as defined in [RFC8122].
The certificate received during the DTLS handshake [RFC6347] MUST The certificate received during the DTLS handshake [RFC6347] MUST
match a certificate fingerprint received in SDP 'fingerprint' match a certificate fingerprint received in SDP 'fingerprint'
attributes according to the procedures defined in [RFC8122]. If attributes according to the procedures defined in [RFC8122]. If
fingerprints do not match the hashed certificate, then an endpoint fingerprints do not match the hashed certificate, then an endpoint
MUST tear down the media session immediately (see [RFC8122]). Note MUST tear down the media session immediately (see [RFC8122]). Note
that it is permissible to wait until the other side's fingerprint(s) that it is permissible to wait until the other side's fingerprint(s)
has been received before establishing the connection; however, this has been received before establishing the connection; however, this
may have undesirable latency effects. may have undesirable latency effects.
skipping to change at page 10, line 4 skipping to change at page 10, line 4
offer an SDP 'tls-id' attribute with a unique attribute value. offer an SDP 'tls-id' attribute with a unique attribute value.
As the offerer inserts the SDP 'setup' attribute with an 'actpass' As the offerer inserts the SDP 'setup' attribute with an 'actpass'
attribute value, the offerer MUST be prepared to receive a DTLS attribute value, the offerer MUST be prepared to receive a DTLS
ClientHello message [RFC6347] (if a new DTLS association is ClientHello message [RFC6347] (if a new DTLS association is
established by the answerer) from the answerer before the offerer established by the answerer) from the answerer before the offerer
receives the SDP answer. receives the SDP answer.
If the offerer receives a DTLS ClientHello message, and a DTLS If the offerer receives a DTLS ClientHello message, and a DTLS
association is established, before the offerer receives the SDP association is established, before the offerer receives the SDP
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Answer carrying the fingerprint associated with the DTLS association, Answer carrying the fingerprint associated with the DTLS association,
any data received on the DTLS association before the fingerprint MUST any data received on the DTLS association before the fingerprint MUST
be considered coming from an unverified source. The processing of be considered coming from an unverified source. The processing of
such data, and sending of data by the offerer to the unverified such data, and sending of data by the offerer to the unverified
source, is outside the scope of this document. source, is outside the scope of this document.
5.3. Generating the Answer 5.3. Generating the Answer
When an answerer sends an answer, the answerer MUST insert in the When an answerer sends an answer, the answerer MUST insert in the
answer an SDP 'setup' attribute according to the procedures in answer an SDP 'setup' attribute according to the procedures in
skipping to change at page 10, line 44 skipping to change at page 10, line 47
that does not change the previously negotiated DTLS roles, and one or that does not change the previously negotiated DTLS roles, and one or
more SDP 'fingerprint' attributes values that do not change the more SDP 'fingerprint' attributes values that do not change the
previously sent fingerprint set, in the associated answer. previously sent fingerprint set, in the associated answer.
If the answerer receives an offer that does not contain an SDP 'tls- 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 id' attribute, the answerer MUST NOT insert a 'tls-id' attribute in
the answer. the answer.
If a new DTLS association is to be established, and if the answerer If a new DTLS association is to be established, and if the answerer
inserts an SDP 'setup' attribute with an 'active' attribute value in inserts an SDP 'setup' attribute with an 'active' attribute value in
the answer, the answerer MUST initiate a DTLS handshake by sending a the answer, the answerer MUST initiate a DTLS handshake [RFC6347]) by
DTLS ClientHello message towards the offerer. sending a DTLS ClientHello message towards the offerer.
Even though an offerer is required to insert an 'SDP' setup attribute Even though an offerer is required to insert an 'SDP' setup attribute
with an 'actpass' attribute value in initial offers (Section 5.2) and with an 'actpass' attribute value in initial offers (Section 5.2) and
subsequent offers (Section 5.5), the answerer MUST be able to receive subsequent offers (Section 5.5), the answerer MUST be able to receive
initial and subsequent offers with other attribute values, in order initial and subsequent offers with other attribute values, in order
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
to be backward compatible with older implementations that might to be backward compatible with older implementations that might
insert other attribute values in initial and subsequent offers. insert other attribute values in initial and subsequent offers.
5.4. Offerer Processing of the SDP Answer 5.4. Offerer Processing of the SDP Answer
When an offerer receives an answer that establishes a new DTLS When an offerer receives an answer that establishes a new DTLS
association based on criteria defined in Section 3.1, and if the association based on criteria defined in Section 3.1, and if the
offerer becomes DTLS client (based on the value of the SDP 'setup' offerer becomes DTLS client (based on the value of the SDP 'setup'
attribute value [RFC4145]), the offerer MUST establish a DTLS attribute value [RFC4145]), the offerer MUST establish a DTLS
association. If the offerer becomes DTLS server, it MUST wait for association. If the offerer becomes DTLS server, it MUST wait for
skipping to change at page 12, line 5 skipping to change at page 12, line 5
'setup' attribute with an 'actpass' attribute value, and one or more 'setup' attribute with an 'actpass' attribute value, and one or more
SDP 'fingerprint' attributes with attribute values that do not change SDP 'fingerprint' attributes with attribute values that do not change
the previously sent fingerprint set, in the offer. In addition, the the previously sent fingerprint set, in the offer. In addition, the
offerer MUST insert an SDP 'tls-id' attribute with the previously offerer MUST insert an SDP 'tls-id' attribute with the previously
assigned attribute value in the offer. assigned attribute value in the offer.
NOTE: When a new DTLS association is being established, each endpoint 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 needs to be prepared to receive data on both the new and old DTLS
associations as long as both are alive. associations as long as both are alive.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
6. ICE Considerations 6. ICE Considerations
When the Interactive Connectivity Establishment (ICE) mechanism When the Interactive Connectivity Establishment (ICE) mechanism
[I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are [I-D.ietf-ice-rfc5245bis] is used, the ICE connectivity checks are
performed before the DTLS handshake begins. Note that if aggressive performed before the DTLS handshake begins. Note that if aggressive
nomination mode is used, multiple candidate pairs may be marked valid nomination mode is used, multiple candidate pairs may be marked valid
before ICE finally converges on a single candidate pair. before ICE finally converges on a single candidate pair.
NOTE: Aggressive nomination has been deprecated from ICE, but must NOTE: Aggressive nomination has been deprecated from ICE, but must
still be supported for backwards compatibility reasons still be supported for backwards compatibility reasons
skipping to change at page 13, line 4 skipping to change at page 13, line 4
As specified in [RFC4145], the SDP 'connection' attribute is used to As specified in [RFC4145], the SDP 'connection' attribute is used to
indicate whether to establish a new TLS connection. An offerer and indicate whether to establish a new TLS connection. An offerer and
answerer MUST ensure that the 'connection' attribute value and the answerer MUST ensure that the 'connection' attribute value and the
'tls-id' attribute value does not cause a conflict regarding whether 'tls-id' attribute value does not cause a conflict regarding whether
a new TLS connection is to be established or not. a new TLS connection is to be established or not.
NOTE: Even though the SDP 'connection' attribute can be used to NOTE: Even though the SDP 'connection' attribute can be used to
indicate whether a new TLS connection is to be established, the indicate whether a new TLS connection is to be established, the
unique combination of SDP 'tls-id' attribute values can be used to unique combination of SDP 'tls-id' attribute values can be used to
identity a TLS connection. The unique value can be used e.g., within identity a TLS connection. The unique value can be used e.g., within
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
TLS protocol extensions to differentiate between multiple TLS TLS protocol extensions to differentiate between multiple TLS
connections and correlate those connections with specific offer/ connections and correlate those connections with specific offer/
answer exchanges. One such extension is defined in answer exchanges. One such extension is defined in
[I-D.ietf-mmusic-sdp-uks]. [I-D.ietf-mmusic-sdp-uks].
If an offerer or answerer inserts an SDP 'connection' attribute with 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' a 'new' value in the offer/answer and also inserts an SDP 'tls-id'
attribute, the value of tls-id' attribute MUST be new and unique. attribute, the value of tls-id' attribute MUST be new and unique.
If an offerer or answerer inserts an SDP 'connection' attribute with If an offerer or answerer inserts an SDP 'connection' attribute with
skipping to change at page 13, line 25 skipping to change at page 13, line 28
TLS connection exists, and if the offerer/answerer previously TLS connection exists, and if the offerer/answerer previously
inserted an SDP 'tls-id' attribute associated with the same TLS inserted an SDP 'tls-id' attribute associated with the same TLS
connection in an offer/answer, the offerer/answerer MUST also insert connection in an offer/answer, the offerer/answerer MUST 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
offer/answer. offer/answer.
If an offerer or answerer receives an offer/answer with conflicting If an offerer or answerer receives an offer/answer with conflicting
attribute values, the offerer/answerer MUST process the offer/answer attribute values, the offerer/answerer MUST process the offer/answer
as misformed. as misformed.
An endpoint must not make assumptions regarding the support of the An endpoint MUST NOT make assumptions regarding the support of the
SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity, SDP 'tls-id' attribute by the peer. Therefore, to avoid ambiguity,
both offerers and answerers MUST always use the 'connection' both offerers and answerers MUST always use the 'connection'
attribute in conjunction with the 'tls-id' attribute. attribute in conjunction with the 'tls-id' attribute.
NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is
not explicitly present, the implicit default value is 'new'. not explicitly present, the implicit default value is 'new'.
The SDP example below is based on the example in section 3.4 of The SDP example below is based on the example in section 3.4 of
[RFC8122], with the addition of the SDP 'tls-id' attribute. [RFC8122], with the addition of the SDP 'tls-id' attribute.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=tls-id:abc3de65cddef001be82 a=tls-id:abc3de65cddef001be82
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=fingerprint:SHA-256 \ 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: \ 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 3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \ a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02: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
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
8. SIP Considerations 8. SIP Considerations
When the Session Initiation Protocol (SIP) [RFC3261] is used as the When the Session Initiation Protocol (SIP) [RFC3261] is used as the
signal protocol for establishing a multimedia session, dialogs signal protocol for establishing a multimedia session, dialogs
[RFC3261] might be established between the caller and multiple [RFC3261] might be established between the caller and multiple
callees. This is referred to as forking. If forking occurs, callees. This is referred to as forking. If forking occurs,
separate DTLS associations will be established between the caller and separate DTLS associations will be established between the caller and
each callee. each callee.
When forking occurs, an SDP offerer can receive DTLS ClientHello When forking occurs, an SDP offerer can receive DTLS ClientHello
skipping to change at page 15, line 5 skipping to change at page 15, line 5
This section updates specifications that use DTLS-protected media, in This section updates specifications that use DTLS-protected media, in
order to reflect the procedures defined in this specification. order to reflect the procedures defined in this specification.
9.2. Update to RFC 5763 9.2. Update to RFC 5763
9.2.1. Update to section 1 9.2.1. Update to section 1
The reference to [RFC4572] is replaced with a reference to [RFC8122]. The reference to [RFC4572] is replaced with a reference to [RFC8122].
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
9.2.2. Update to section 5 9.2.2. Update to section 5
The text in section 5 (Establishing a Secure Channel) is modified by The text in section 5 (Establishing a Secure Channel) is modified by
replacing generic SDP offer/answer procedures for DTLS with a replacing generic SDP offer/answer procedures for DTLS with a
reference to this specification: reference to this specification:
NEW TEXT: NEW TEXT:
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
skipping to change at page 16, line 4 skipping to change at page 16, line 4
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.
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
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
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, are 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 to 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.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
request a session modification that MAY include an updated offer. request a session modification that MAY include an updated offer.
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 [RFCXXXX].
9.2.4. Update to section 6.7.1 9.2.4. Update to section 6.7.1
The text in section 6.7.1 (ICE Interaction) is modified by replacing The text in section 6.7.1 (ICE Interaction) is modified by replacing
the ICE procedures with a reference to this specification: the ICE procedures with a reference to this specification:
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
NEW TEXT: NEW TEXT:
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
are described in [RFCXXXX]. are described in [RFCXXXX].
9.3. Update to RFC 7345 9.3. Update to RFC 7345
9.3.1. Update to section 4 9.3.1. Update to section 4
skipping to change at page 18, line 5 skipping to change at page 18, line 5
NEW TEXT: NEW TEXT:
The Interactive Connectivity Establishment (ICE) The Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
are described in [RFCXXXX]. are described in [RFCXXXX].
[RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX [RFC EDITOR NOTE: Throughout the document, please replace RFCXXXX
with the RFC number of this document.] with the RFC number of this document.]
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
9.3.3. Update to section 10.1 9.3.3. Update to section 10.1
A reference to [RFC8122] is added to section 10.1 (Normative A reference to [RFC8122] is added to section 10.1 (Normative
References): References):
NEW TEXT: NEW TEXT:
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Attribute name: tls-id Attribute name: tls-id
Type of attribute: media-level Type of attribute: media-level
Subject to charset: no Subject to charset: no
Purpose: Indicates whether a new DTLS association or TLS connection Purpose: Indicates whether a new DTLS association or TLS connection
is to be established/re-established. is to be established/re-established.
Appropriate Values: see Section 4 Appropriate Values: see Section 4
Contact name: Christer Holmberg Contact name: Christer Holmberg
Mux Category: IDENTICAL Mux Category: IDENTICAL
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
12. Acknowledgements 12. Acknowledgements
Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa, Thanks to Justin Uberti, Martin Thomson, Paul Kyzivat, Jens Guballa,
Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing Charles Eckel, Gonzalo Salgueiro and Paul Jones for providing
comments and suggestions on the document. Ben Campbell performed an comments and suggestions on the document. Ben Campbell performed an
AD review. Paul Kyzivat performed a gen-art review. AD review. Paul Kyzivat performed a gen-art review.
13. Change Log 13. Change Log
[RFC EDITOR NOTE: Please remove this section when publishing] [RFC EDITOR NOTE: Please remove this section when publishing]
Changes from draft-ietf-mmusic-sdp-dtls-30
o Changes based on IESG comments from Mirja K
Changes from draft-ietf-mmusic-sdp-dtls-29 Changes from draft-ietf-mmusic-sdp-dtls-29
o Removal of ufrag value change as a trigger for a new DTLS o Removal of ufrag value change as a trigger for a new DTLS
association association
Changes from draft-ietf-mmusic-sdp-dtls-28 Changes from draft-ietf-mmusic-sdp-dtls-28
o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey
Melnikov and Mirja Kuhlewind: Melnikov and Mirja Kuhlewind:
skipping to change at page 19, line 50 skipping to change at page 20, line 5
o Editorial fixes based on Gen-ART review by Paul Kyzivat. o Editorial fixes based on Gen-ART review by Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-25 Changes from draft-ietf-mmusic-sdp-dtls-25
o Minor editorial nits. o Minor editorial nits.
Changes from draft-ietf-mmusic-sdp-dtls-24 Changes from draft-ietf-mmusic-sdp-dtls-24
o Changes based on 2nd WGLC comments from Roman S and Martin T: o Changes based on 2nd WGLC comments from Roman S and Martin T:
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o - RFC update structure shortened (old text removed). o - RFC update structure shortened (old text removed).
o - Guidance regarding receiving ClientHello before SDP answer o - Guidance regarding receiving ClientHello before SDP answer
added. added.
o - Additional SIP condierations regarding forking. o - Additional SIP condierations regarding forking.
o - SDP setup attribute value restriction in initial and subsequent o - SDP setup attribute value restriction in initial and subsequent
offers based on comment from Ekr. offers based on comment from Ekr.
skipping to change at page 20, line 51 skipping to change at page 21, line 5
o Change based on comment from Roman. o Change based on comment from Roman.
Changes from draft-ietf-mmusic-sdp-dtls-18 Changes from draft-ietf-mmusic-sdp-dtls-18
o Changes based on comments from Flemming. o Changes based on comments from Flemming.
o - Change in tls-id value definition. o - Change in tls-id value definition.
o - Editorial fixes. o - Editorial fixes.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Changes from draft-ietf-mmusic-sdp-dtls-17 Changes from draft-ietf-mmusic-sdp-dtls-17
o Reference fix. o Reference fix.
Changes from draft-ietf-mmusic-sdp-dtls-16 Changes from draft-ietf-mmusic-sdp-dtls-16
o Editorial changes based on 2nd WGLC comments from Christian Groves o Editorial changes based on 2nd WGLC comments from Christian Groves
and Nevenka Biondic. and Nevenka Biondic.
Changes from draft-ietf-mmusic-sdp-dtls-15 Changes from draft-ietf-mmusic-sdp-dtls-15
o tls-id attribute value made globally unique o tls-id attribute value made globally unique
skipping to change at page 21, line 50 skipping to change at page 22, line 5
Changes from draft-ietf-mmusic-sdp-dtls-10 Changes from draft-ietf-mmusic-sdp-dtls-10
o Modified document to use tls-id instead of dtls-connection o Modified document to use tls-id instead of dtls-connection
o Changes are based on comments from Eric Rescorla, Justin Uberti, o Changes are based on comments from Eric Rescorla, Justin Uberti,
and Paul Kyzivat. and Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-08 Changes from draft-ietf-mmusic-sdp-dtls-08
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o Offer/Answer section modified in order to allow sending of o Offer/Answer section modified in order to allow sending of
multiple SDP 'fingerprint' attributes. multiple SDP 'fingerprint' attributes.
o Terminology made consistent: 'DTLS connection' replaced with 'DTLS o Terminology made consistent: 'DTLS connection' replaced with 'DTLS
association'. association'.
o Editorial changes based on comments from Paul Kyzivat. o Editorial changes based on comments from Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-07 Changes from draft-ietf-mmusic-sdp-dtls-07
skipping to change at page 22, line 50 skipping to change at page 23, line 5
Changes from draft-ietf-mmusic-sdp-dtls-03 Changes from draft-ietf-mmusic-sdp-dtls-03
o Changes based on comments from Paul Kyzivat: o Changes based on comments from Paul Kyzivat:
o - Modification of tls-id attribute section. o - Modification of tls-id attribute section.
o - Removal of IANA considerations subsection. o - Removal of IANA considerations subsection.
o - Making note into normative text in o/a section. o - Making note into normative text in o/a section.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
o Changes based on comments from Martin Thompson: o Changes based on comments from Martin Thompson:
o - Abbreviations section removed. o - Abbreviations section removed.
o - Clarify that a new DTLS association requires a new o/a o - Clarify that a new DTLS association requires a new o/a
transaction. transaction.
Changes from draft-ietf-mmusic-sdp-dtls-02 Changes from draft-ietf-mmusic-sdp-dtls-02
o - Updated RFCs added to boilerplate. o - Updated RFCs added to boilerplate.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
unchanged in associated answer. unchanged in associated answer.
o - SIP Considerations section added. o - SIP Considerations section added.
o - Section about multiple SDP fingerprint attributes added. o - Section about multiple SDP fingerprint attributes added.
Changes from draft-holmberg-mmusic-sdp-dtls-00 Changes from draft-holmberg-mmusic-sdp-dtls-00
o - Editorial changes and clarifications. o - Editorial changes and clarifications.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 25, line 5 skipping to change at page 25, line 5
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP [RFC7345] Holmberg, C., Sedlacek, I., and G. Salgueiro, "UDP
Transport Layer (UDPTL) over Datagram Transport Layer Transport Layer (UDPTL) over Datagram Transport Layer
Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August Security (DTLS)", RFC 7345, DOI 10.17487/RFC7345, August
2014, <https://www.rfc-editor.org/info/rfc7345>. 2014, <https://www.rfc-editor.org/info/rfc7345>.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
[RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over the Transport Layer Security (TLS) Protocol Transport over the Transport Layer Security (TLS) Protocol
in the Session Description Protocol (SDP)", RFC 8122, in the Session Description Protocol (SDP)", RFC 8122,
DOI 10.17487/RFC8122, March 2017, DOI 10.17487/RFC8122, March 2017,
<https://www.rfc-editor.org/info/rfc8122>. <https://www.rfc-editor.org/info/rfc8122>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006, DOI 10.17487/RFC4572, July 2006,
<https://www.rfc-editor.org/info/rfc4572>. <https://www.rfc-editor.org/info/rfc4572>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<https://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, Transmission Protocol (SCTP)", RFC 6083,
DOI 10.17487/RFC6083, January 2011, DOI 10.17487/RFC6083, January 2011,
<https://www.rfc-editor.org/info/rfc6083>. <https://www.rfc-editor.org/info/rfc6083>.
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme [RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP) Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)", Extension for Datagram Transport Layer Security (DTLS)",
RFC 7983, DOI 10.17487/RFC7983, September 2016, RFC 7983, DOI 10.17487/RFC7983, September 2016,
skipping to change at page 27, line 4 skipping to change at page 27, line 4
Authors' Addresses Authors' Addresses
Christer Holmberg Christer Holmberg
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
Internet-DrafSession Description Protocol (SDP) Offer/Answe October 2017
Roman Shpount Roman Shpount
TurboBridge TurboBridge
4905 Del Ray Avenue, Suite 300 4905 Del Ray Avenue, Suite 300
Bethesda, MD 20814 Bethesda, MD 20814
USA USA
Phone: +1 (240) 292-6632 Phone: +1 (240) 292-6632
Email: rshpount@turbobridge.com Email: rshpount@turbobridge.com
 End of changes. 37 change blocks. 
25 lines changed or deleted 92 lines changed or added

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