draft-ietf-mmusic-dtls-sdp-28.txt   draft-ietf-mmusic-dtls-sdp-29.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: February 6, 2018 August 5, 2017 Expires: March 4, 2018 August 31, 2017
Using the SDP Offer/Answer Mechanism for DTLS Session Description Protocol (SDP) Offer/Answer Considerations for
draft-ietf-mmusic-dtls-sdp-28.txt Datagram Transport Layer Security (DTLS) and Transport Layer Security
(TLS)
draft-ietf-mmusic-dtls-sdp-29.txt
Abstract Abstract
This document defines the SDP offer/answer procedures for negotiating This document defines the Session Description Protocol (SDP) offer/
and establishing a DTLS association. The document also defines the answer procedures for negotiating and establishing a Datagram
criteria for when a new DTLS association must be established. The Transport Layer Security (DTLS) association. The document also
document updates RFC 5763 and RFC 7345, by replacing common SDP defines the criteria for when a new DTLS association must be
offer/answer procedures with a reference to this specification. established. The document updates RFC 5763 and RFC 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 defines a new SDP media-level attribute, 'tls-id'.
This document also defines how the 'tls-id' attribute can be used for This document also defines how the 'tls-id' attribute can be used for
negotiating and establishing a TLS connection, in conjunction with negotiating and establishing a Transport Layer Security (TLS)
the procedures in RFC 4145 and RFC 8122. connection, in conjunction with the procedures in RFC 4145 and RFC
8122.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 6, 2018. This Internet-Draft will expire on March 4, 2018.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 18 skipping to change at page 2, line 28
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Establishing a new DTLS Association . . . . . . . . . . . . . 4 3. Establishing a new DTLS Association . . . . . . . . . . . . . 4
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Change of Local Transport Parameters . . . . . . . . . . 4 3.2. Change of Local Transport Parameters . . . . . . . . . . 5
3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 5 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 5
4. SDP tls-id Attribute . . . . . . . . . . . . . . . . . . . . 5 4. SDP tls-id Attribute . . . . . . . . . . . . . . . . . . . . 5
5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 6 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 8 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9
5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 9 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 10
5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11
5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11
6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Transport Protocol Considerations . . . . . . . . . . . . . . 11 7. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 11 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. TLS Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2.1. Update to section 1 . . . . . . . . . . . . . . . . . 14
10.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 14 9.2.2. Update to section 5 . . . . . . . . . . . . . . . . . 15
10.2.1. Update to section 1 . . . . . . . . . . . . . . . . 14 9.2.3. Update to section 6.6 . . . . . . . . . . . . . . . . 16
10.2.2. Update to section 5 . . . . . . . . . . . . . . . . 14 9.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . . 16
10.2.3. Update to section 6.6 . . . . . . . . . . . . . . . 15 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 17
10.2.4. Update to section 6.7.1 . . . . . . . . . . . . . . 16 9.3.1. Update to section 4 . . . . . . . . . . . . . . . . . 17
10.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16 9.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . . 17
10.3.1. Update to section 4 . . . . . . . . . . . . . . . . 16 9.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 18
10.3.2. Update to section 5.2.1 . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.3.3. Update to section 10.1 . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
[RFC5763] defines SDP offer/answer procedures for SRTP-DTLS. [RFC5763] defines Session Description Protocol (SDP) offer/answer
[RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This procedures for Secure Realtime Transport Protocol Using Datagram
specification defines general offer/answer procedures for DTLS, based Transport Layer Security (DTLS-SRTP). [RFC7345] defines SDP offer/
on the procedures in [RFC5763]. Other specifications, defining answer procedures for UDP Transport Layer over Datagram Transport
specific DTLS usages, can then reference this specification, in order Layer Security (UDPTL-DTLS). This specification defines general
to ensure that the DTLS aspects are common among all usages. Having offer/answer procedures for DTLS, based on the procedures in
common procedures is essential when multiple usages share the same [RFC5763]. Other specifications, defining specific DTLS usages, can
DTLS association [I-D.ietf-mmusic-sdp-bundle-negotiation]. The then reference this specification, in order to ensure that the DTLS
document updates [RFC5763] and [RFC7345], by replacing common SDP aspects are common among all usages. Having common procedures is
offer/answer procedures with a reference to this specification. essential when multiple usages share the same DTLS association
[I-D.ietf-mmusic-sdp-bundle-negotiation]. The document updates
[RFC5763] and [RFC7345], by replacing common SDP offer/answer
procedures with a reference to this specification.
NOTE: Since the publication of [RFC5763], [RFC4474] has been NOTE: Since the publication of [RFC5763], [RFC4474] has been
obsoleted by [I-D.ietf-stir-rfc4474bis]. The updating of the obsoleted by [I-D.ietf-stir-rfc4474bis]. The updating of the
references (and the associated procedures) within [RFC5763] is references (and the associated procedures) within [RFC5763] is
outside the scope of this document. However, implementers of outside the scope of this document. However, implementers of
[RFC5763] applications are encouraged to implement [RFC5763] applications are encouraged to implement
[I-D.ietf-stir-rfc4474bis] instead of [RFC4474]. [I-D.ietf-stir-rfc4474bis] instead of [RFC4474].
As defined in [RFC5763], a new DTLS association MUST be established As defined in [RFC5763], a new DTLS association MUST be established
when transport parameters are changed. Transport parameter change is when transport parameters are changed. Transport parameter change is
not well defined when Interactive Connectivity Establishment (ICE) not well defined when Interactive Connectivity Establishment (ICE)
[I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a [I-D.ietf-ice-rfc5245bis] is used. One possible way to determine a
transport change is based on ufrag [I-D.ietf-ice-rfc5245bis] change, transport change is based on ufrag [I-D.ietf-ice-rfc5245bis] change,
but the ufrag value is changed both when ICE is negotiated and when but the ufrag value is changed both when ICE is negotiated and when
ICE restart [I-D.ietf-ice-rfc5245bis] occurs. These events do not ICE restart [I-D.ietf-ice-rfc5245bis] occurs. These events do not
always require a new DTLS association to be established, but always require a new DTLS association to be established, but
currently there is no way to explicitly indicate in an SDP offer or previously there was no way to explicitly indicate in an SDP offer or
answer whether a new DTLS association is required. To solve that answer whether a new DTLS association is required. To solve that
problem, this document defines a new SDP attribute, 'tls-id'. The problem, this document defines a new SDP attribute, 'tls-id'. 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 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 TLS The SDP 'tls-id' attribute can be specified when negotiating a
connection, using the procedures in this document in conjunction with Transport Layer Security (TLS) connection, using the procedures in
the procedures in [RFC5763] and [RFC8122]. The unique combination of this document in conjunction with the procedures in [RFC5763] and
SDP 'tls-id' attribute values can be used to identity the negotiated
TLS connection. The unique value can be used, for example, within Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
TLS protocol extensions to differentiate between multiple TLS
connections and correlate those connections with specific offer/ [RFC8122]. The unique combination of SDP 'tls-id' attribute values
answer exchanges. The TLS specific considerations are described in can be used to identity the negotiated TLS connection. The unique
Section 8. 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 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Establishing a new DTLS Association 3. Establishing a new DTLS Association
3.1. General 3.1. General
A new DTLS association must be established between two endpoints A new DTLS association must be established between two endpoints
after a successful SDP offer/answer exchange in the following cases: after a successful SDP offer/answer exchange in the following cases:
o The negotiated DTLS setup roles change; or o The negotiated DTLS setup roles change; or
skipping to change at page 4, line 44 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/Answer August 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 prohibits a DTLS association from
spanning multiple transports, and if the transport is changed, the spanning multiple transports, and if the transport is changed, the
endpoint must change its local SDP 'tls-id' attribute value (see endpoint must change its local SDP 'tls-id' attribute value (see
Section 4). An example of such a case is when DTLS is carried over Section 4). An example of such a case is when DTLS is carried over
SCTP, as described in [RFC6083]. 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/Answer August 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 6, line 22 skipping to change at page 7, line 5
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; or o local transport parameters; or
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
o ICE ufrag value o ICE ufrag value
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
must be identical across all media descriptions being multiplexed applies to all media descriptions being multiplexed
[I-D.ietf-mmusic-sdp-bundle-negotiation]. [I-D.ietf-mmusic-sdp-bundle-negotiation]. However, as described in
[I-D.ietf-mmusic-sdp-bundle-negotiation], 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 For RTP-based media, the 'tls-id' attribute applies to the whole
associated media description. The attribute MUST NOT be defined per associated media description. The attribute MUST NOT be defined per
source (using the SDP 'ssrc' attribute [RFC5576]). source (using the SDP 'ssrc' attribute [RFC5576]).
The SDP offer/answer [RFC3264] procedures associated with the The SDP offer/answer [RFC3264] procedures associated with the
attribute are defined in Section 5. attribute are defined in Section 5.
5. SDP Offer/Answer Procedures 5. SDP Offer/Answer Procedures
5.1. General 5.1. General
This section defines the generic SDP offer/answer procedures for This section defines the generic SDP offer/answer procedures for
negotiating a DTLS association. Additional procedures (e.g., negotiating a DTLS association. Additional procedures (e.g.,
regarding usage of specific SDP attributes etc.) for individual DTLS regarding usage of specific SDP attributes etc.) for individual DTLS
usages (e.g., SRTP-DTLS) are outside the scope of this specification, usages (e.g., DTLS-SRTP) are outside the scope of this specification,
and need to be specified in a usage specific specification. and need to be specified in a usage specific specification.
NOTE: The procedures in this section are generalizations of NOTE: The procedures in this section are generalizations of
procedures first specified in SRTP-DTLS [RFC5763], with the addition procedures first specified in DTLS-SRTP [RFC5763], with the addition
of usage of the SDP 'tls-id' attribute. That document is herein of usage of the SDP 'tls-id' attribute. That document is herein
updated to make use of these new procedures. updated to make use of these new procedures.
The procedures in this section apply to an SDP media description The procedures in this section apply to an SDP media description
("m=" line) associated with DTLS-protected media/data. ("m=" line) associated with DTLS-protected media/data.
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
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 a previously established DTLS association and the new associated with with a previously established DTLS association and
DTLS association is on the basis of transport 5-tuple. Because of the new DTLS association is on the basis of transport 5-tuple.
this, if an unordered transport is used for the DTLS association, a
new transport (3-tuple) must be allocated by at least one of the Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
endpoints so that DTLS packets can be de-multiplexed.
Because of this, if an unordered transport is used for the DTLS
association, a new transport (3-tuple) must be allocated 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 transport (3-tuple) for the offer in such a way that the offerer
can disambiguate any packets associated with the new DTLS association can 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.
skipping to change at page 8, line 15 skipping to change at page 8, line 51
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.
Endpoints MUST support the cipher suites as defined in [RFC8122]. Endpoints MUST support the hash functions as defined in [RFC8122].
The certificate received during the DTLS handshake MUST match a The certificate received during the DTLS handshake [RFC6347] MUST
certificate fingerprint received in SDP 'fingerprint' attributes match a certificate fingerprint received in SDP 'fingerprint'
according to the procedures defined in [RFC8122]. If fingerprints do
not match the hashed certificate, then an endpoint MUST tear down the Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
media session immediately (see [RFC8122]). Note that it is
permissible to wait until the other side's fingerprint(s) has been attributes according to the procedures defined in [RFC8122]. If
received before establishing the connection; however, this may have fingerprints do not match the hashed certificate, then an endpoint
undesirable latency effects. MUST tear down the media session immediately (see [RFC8122]). Note
that it is permissible to wait until the other side's fingerprint(s)
has been received before establishing the connection; however, this
may have undesirable latency effects.
SDP offerers and answerers might reuse certificates across multiple SDP offerers and answerers might reuse certificates across multiple
DTLS associations, and provide identical fingerprint values for each DTLS associations, and provide identical fingerprint values for each
DTLS association. The combination of the SDP 'tls-id' attribute DTLS association. The combination of the SDP 'tls-id' attribute
values of the SDP offerer and answerer identifies each individual values of the SDP offerer and answerer identifies each individual
DTLS association. DTLS association.
NOTE: There are cases where the SDP 'tls-id' attribute value NOTE: There are cases where the SDP 'tls-id' attribute value
generated by the offerer will end up being used for multiple DTLS generated by the offerer will end up being used for multiple DTLS
associations. For that reason the combination of the attribute associations. For that reason the combination of the attribute
skipping to change at page 9, line 9 skipping to change at page 9, line 45
5.2. Generating the Initial SDP Offer 5.2. Generating the Initial SDP Offer
When an offerer sends the initial offer, the offerer MUST insert an When an offerer sends the initial offer, the offerer MUST insert an
SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value, SDP 'setup' attribute [RFC4145] with an 'actpass' attribute value,
and one or more SDP 'fingerprint' attributes according to the and one or more SDP 'fingerprint' attributes according to the
procedures in [RFC8122]. In addition, the offerer MUST insert in the procedures in [RFC8122]. In addition, the offerer MUST insert in the
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 (if a new DTLS association is established by the ClientHello message [RFC6347] (if a new DTLS association is
answerer) from the answerer before the offerer receives the SDP established by the answerer) from the answerer before the offerer
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
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
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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
[RFC4145], and one or more SDP 'fingerprint' attributes according to [RFC4145], and one or more SDP 'fingerprint' attributes according to
the procedures in [RFC8122]. If the answerer determines, based on the procedures in [RFC8122]. If the answerer determines, based on
the criteria specified in Section 3.1, that a new DTLS association is the criteria specified in Section 3.1, that a new DTLS association is
skipping to change at page 10, line 17 skipping to change at page 11, line 5
the answer, the answerer MUST initiate a DTLS handshake by sending a the answer, the answerer MUST initiate a DTLS handshake by sending a
DTLS ClientHello message towards the offerer. 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
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.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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
the answerer to establish the DTLS association. the answerer to establish the DTLS association.
If the offerer indicated a desire to reuse an existing DTLS If the offerer indicated a desire to reuse an existing DTLS
association and the answerer does not request the establishment of a association and the answerer does not request the establishment of a
new DTLS association, the offerer will continue to use the previously new DTLS association, the offerer will continue to use the previously
established DTLS association. established DTLS association.
NOTE: A new DTLS association can be established based on changes in A new DTLS association can be established based on changes in either
either an SDP offer or answer. When communicating with legacy an SDP offer or answer. When communicating with legacy endpoints, an
endpoints, an offerer can receive an answer that includes the same offerer can receive an answer that includes the same fingerprint set
fingerprint set and setup role. A new DTLS association MUST still be and setup role. A new DTLS association will still be established if
established if such an answer was received as a response to an offer such an answer was received as a response to an offer which requested
which requested the establishment of a new DTLS association. the establishment of a new DTLS association, as the transport
parameters would have been changed in the offer.
5.5. Modifying the Session 5.5. Modifying the Session
When an offerer sends a subsequent offer, and if the offerer wants to When an offerer sends a subsequent offer, and if the offerer wants to
establish a new DTLS association, the offerer MUST insert an SDP establish a new DTLS association, the offerer MUST insert an SDP
'setup' attribute [RFC4145] with an 'actpass' attribute value, and 'setup' attribute [RFC4145] with an 'actpass' attribute value, and
one or more SDP 'fingerprint' attributes according to the procedures one or more SDP 'fingerprint' attributes according to the procedures
in [RFC8122]. In addition, the offerer MUST insert in the offer an in [RFC8122]. In addition, the offerer MUST insert in the offer an
SDP 'tls-id' attribute with a new unique attribute value. SDP 'tls-id' attribute with a new unique attribute value.
skipping to change at page 11, line 11 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/Answer August 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 11, line 36 skipping to change at page 12, line 32
MUST allocate a completely new set of ICE candidates which were not MUST allocate a completely new set of ICE candidates which were not
recently used for any other DTLS association. This means the recently used for any other DTLS association. This means the
answerer cannot initiate a new DTLS association unless the offerer answerer cannot initiate a new DTLS association unless the offerer
initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer
wants to initiate a new DTLS association, it needs to initiate an ICE 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 and a new offer/answer exchange on its own. However, an ICE
restart does not by default require a new DTLS association to be restart does not by default require a new DTLS association to be
established. established.
NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets NOTE: Simple Traversal of the UDP Protocol through NAT (STUN) packets
are sent directly over UDP, not over DTLS. [RFC5764] describes how are sent directly over UDP, not over DTLS. [RFC7983] describes how
to demultiplex STUN packets from DTLS packets and SRTP packets. to demultiplex STUN packets from DTLS packets and SRTP packets.
Each ICE candidate associated with a component is treated as being Each ICE candidate associated with a component is treated as being
part of the same DTLS association. Therefore, from a DTLS part of the same DTLS association. Therefore, from a DTLS
perspective it is not considered a change of local transport perspective it is not considered a change of local transport
parameters when an endpoint switches between those ICE candidates. parameters when an endpoint switches between those ICE candidates.
7. Transport Protocol Considerations 7. TLS Considerations
7.1. Transport Re-Usage
If DTLS is transported on top of a connection-oriented transport
protocol (e.g., TCP or SCTP), where all IP packets are acknowledged,
all DTLS packets associated with a previous DTLS association MUST be
acknowledged (or timed out) before a new DTLS association can be
established on the same instance of that transport (5-tuple).
8. TLS Considerations
The procedures in this document can also be used for negotiating and The procedures in this document can also be used for negotiating and
establishing a TLS connection, with the restriction described below. establishing a TLS connection, with the restriction described below.
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/Answer August 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. answer exchanges. One such extension is defined in
[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
a 'existing' value in the offer/answer, if a previously established a 'existing' value in the offer/answer, if a previously established
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
skipping to change at page 13, line 16 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
9. SIP Considerations Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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
messages and SDP answerers from multiple remote locations. Because messages and SDP answerers from multiple remote locations. Because
skipping to change at page 13, line 46 skipping to change at page 14, line 37
INVITE', or an 'offer-less INVITE'. The receiving endpoint will INVITE', or an 'offer-less INVITE'. The receiving endpoint will
include the SDP offer in a response to the request. When the include the SDP offer in a response to the request. When the
endpoint generates such SDP offer, if a previously established DTLS endpoint generates such SDP offer, if a previously established DTLS
association exists, the offerer MUST insert an SDP 'tls-id' association exists, the offerer MUST insert an SDP 'tls-id'
attribute, and one or more SDP 'fingerprint' attributes, with attribute, and one or more SDP 'fingerprint' attributes, with
previously assigned attribute values. If a previously established previously assigned attribute values. If a previously established
DTLS association did not exist, the offer MUST be generated based on DTLS association did not exist, the offer MUST be generated based on
the same rules as a new offer (see Section 5.2). Regardless of the the same rules as a new offer (see Section 5.2). Regardless of the
previous existence of a DTLS association, the SDP 'setup' attribute previous existence of a DTLS association, the SDP 'setup' attribute
MUST be included according to the rules defined in [RFC4145] and if MUST be included according to the rules defined in [RFC4145] and if
ICE is used, ICE restart MUST be initiated. ICE is used, ICE restart MUST be initiated. This is needed in order
to support third party call control, as described in
[I-D.ietf-mmusic-ice-sip-sdp].
10. RFC Updates 9. RFC Updates
10.1. General 9.1. General
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.
10.2. Update to RFC 5763 9.2. Update to RFC 5763
10.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].
10.2.2. Update to section 5 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
The text in section 5 (Establishing a Secure Channel) is replaced 9.2.2. Update to section 5
with the new text below:
The text in section 5 (Establishing a Secure Channel) is modified by
replacing generic SDP offer/answer procedures for DTLS with a
reference to this 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
certificates in the same style as described in "Connection-Oriented certificates in the same style as described in "Connection-Oriented
Media Transport over the Transport Layer Security (TLS) Protocol in Media Transport over the Transport Layer Security (TLS) Protocol in
the Session Description Protocol (SDP)" [RFC8122]. the Session Description Protocol (SDP)" [RFC8122].
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
skipping to change at page 15, line 17 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/Answer August 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 15, line 41 skipping to change at page 16, line 31
secured. secured.
Note that the entire authentication and key exchange for securing Note that the entire authentication and key exchange for securing
the media traffic is handled in the media path through DTLS. The the media traffic is handled in the media path through DTLS. The
signaling path is only used to verify the peers' certificate signaling path is only used to verify the peers' certificate
fingerprints. fingerprints.
The offerer and answerer MUST follow the SDP offer/answer procedures The offerer and answerer MUST follow the SDP offer/answer procedures
defined in [RFCXXXX]. defined in [RFCXXXX].
10.2.3. Update to section 6.6 9.2.3. Update to section 6.6
The text in section 6.6 (Session Modification) is replaced with the The text in section 6.6 (Session Modification) is modified by
new text below: replacing replacing generic SDP offer/answer procedures for DTLS with
a reference to this specification:
NEW TEXT: NEW TEXT:
Once an answer is provided to the offerer, either endpoint MAY Once an answer is provided to the offerer, either endpoint MAY
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].
10.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 replaced with the new The text in section 6.7.1 (ICE Interaction) is modified by replacing
text below: the ICE procedures with a reference to this specification:
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 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].
10.3. Update to RFC 7345 9.3. Update to RFC 7345
10.3.1. Update to section 4 9.3.1. Update to section 4
The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer The subsections (4.1.-4.5.) in section 4 (SDP Offerer/Answerer
Procedures) are removed, and replaced with the new text below: Procedures) are removed, and replaced with the new text below:
NEW TEXT: NEW TEXT:
An endpoint (i.e., both the offerer and the answerer) MUST create an An endpoint (i.e., both the offerer and the answerer) MUST create an
SDP media description ("m=" line) for each UDPTL-over-DTLS media SDP media description ("m=" line) for each UDPTL-over-DTLS media
stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the stream and MUST assign a UDP/TLS/UDPTL value (see Table 1) to the
"proto" field of the "m=" line. "proto" field of the "m=" line.
The offerer and answerer MUST follow the SDP offer/answer procedures The offerer and answerer MUST follow the SDP offer/answer procedures
defined in [RFCXXXX] in order to negotiate the DTLS association defined in [RFCXXXX] in order to negotiate the DTLS association
associated with the UDPTL-over-DTLS media stream. In addition, associated with the UDPTL-over-DTLS media stream. In addition,
the offerer and answerer MUST use the SDP attributes defined for the offerer and answerer MUST use the SDP attributes defined for
UDPTL over UDP, as defined in [ITU.T38.2010]. UDPTL over UDP, as defined in [ITU.T38.2010].
10.3.2. Update to section 5.2.1 9.3.2. Update to section 5.2.1
The text in section 5.2.1 (ICE Usage) is replaced with the new text The text in section 5.2.1 (ICE Usage) is modified by replacing the
below: ICE procedures with a reference to this specification:
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.]
10.3.3. Update to section 10.1 Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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,
DOI 10.17487/RFC8122, March 2017, DOI 10.17487/RFC8122, March 2017,
<http://www.rfc-editor.org/info/rfc8122>. <http://www.rfc-editor.org/info/rfc8122>.
11. Security Considerations 10. Security Considerations
This specification does not modify the security considerations This specification does not modify the security considerations
associated with DTLS, or the SDP offer/answer mechanism. In addition associated with DTLS, or the SDP offer/answer mechanism. In addition
to the introduction of the SDP 'tls-id' attribute, the specification to the introduction of the SDP 'tls-id' attribute, the specification
simply clarifies the procedures for negotiating and establishing a simply clarifies the procedures for negotiating and establishing a
DTLS association. DTLS association.
12. IANA Considerations 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 draft does not introduce new security considerations
related to correlating an SDP Offer/Answer exchange with a TLS
connection setup.
11. IANA Considerations
This document updates the "Session Description Protocol Parameters" This document updates the "Session Description Protocol Parameters"
registry as specified in Section 8.2.2 of [RFC4566]. Specifically, registry as specified in Section 8.2.2 of [RFC4566]. Specifically,
it adds the SDP 'tls-id' attribute to the table for SDP media level it adds the SDP 'tls-id' attribute to the table for SDP media level
attributes. attributes.
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
13. Acknowledgements Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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.
14. 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-28
o Changes based on IESG review by Adam Roach, Eric Rescorla, Alexey
Melnikov and Mirja Kuhlewind:
o - Document title changed
o - Transport Protocol Considerations section removed
o - Additional text to Security Considerations section
o - Editorial changes
Changes from draft-ietf-mmusic-sdp-dtls-27 Changes from draft-ietf-mmusic-sdp-dtls-27
o Reference fixes based on Gen-ART review by Paul Kyzivat. o Reference fixes based on Gen-ART review by Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-26 Changes from draft-ietf-mmusic-sdp-dtls-26
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
skipping to change at page 18, line 48 skipping to change at page 20, line 5
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:
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.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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.
Changes from draft-ietf-mmusic-sdp-dtls-23 Changes from draft-ietf-mmusic-sdp-dtls-23
o Editorial change to make it clear that the document does not
modify the procedures in RFC 8122. o Editrial change to make it clear that the document does not modify
the procedures in RFC 8122.
Changes from draft-ietf-mmusic-sdp-dtls-22 Changes from draft-ietf-mmusic-sdp-dtls-22
o Support for TLS added. o Support for TLS added.
o Editorial changes based on sec-dir review by Rich Salz. o Editorial changes based on sec-dir review by Rich Salz.
o Editorial changes based on gen-art review by Paul Kyzivat. o Editorial changes based on gen-art review by Paul Kyzivat.
o Editorial changes based on ops-dir review by Carlos Pignataro. o Editorial changes based on ops-dir review by Carlos Pignataro.
skipping to change at page 19, line 46 skipping to change at page 21, line 5
o - Change in tls-id value definition. o - Change in tls-id value definition.
o - Editorial fixes. o - Editorial fixes.
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
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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
Changes from draft-ietf-mmusic-sdp-dtls-14 Changes from draft-ietf-mmusic-sdp-dtls-14
o Changes based on comments from Flemming: o Changes based on comments from Flemming:
o - Additional dtls-is clarifiations o - Additional dtls-is clarifiations
o - Editorial fixes o - Editorial fixes
Changes from draft-ietf-mmusic-sdp-dtls-13 Changes from draft-ietf-mmusic-sdp-dtls-13
skipping to change at page 20, line 45 skipping to change at page 22, line 5
and Paul Kyzivat. and Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-08 Changes from draft-ietf-mmusic-sdp-dtls-08
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'.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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
o Reference to RFC 7315 replaced with reference to RFC 7345. o Reference to RFC 7315 replaced with reference to RFC 7345.
Changes from draft-ietf-mmusic-sdp-dtls-06 Changes from draft-ietf-mmusic-sdp-dtls-06
o Text on restrictions regarding spanning a DTLS association over o Text on restrictions regarding spanning a DTLS association over
multiple transports added. multiple transports added.
o Mux category added to IANA Considerations. o Mux category added to IANA Considerations.
o Normative text regarding mux category and source-specific o Normative text regarding mux category and source-specific
applicability added. applicability added.
o Reference to RFC 7315 added. o Reference to RFC 7315 added.
skipping to change at page 21, line 45 skipping to change at page 23, line 5
o - Making note into normative text in o/a section. o - Making note into normative text in o/a section.
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.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
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.
Changes from draft-ietf-mmusic-sdp-dtls-01 Changes from draft-ietf-mmusic-sdp-dtls-01
o - Annex regarding 'tls-id-id' attribute removed. o - Annex regarding 'tls-id-id' attribute removed.
o - Additional SDP offer/answer procedures, related to certificates, o - Additional SDP offer/answer procedures, related to certificates,
added. added.
skipping to change at page 22, line 38 skipping to change at page 23, line 48
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.
15. References 14. References
15.1. Normative References 14.1. Normative References
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
[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-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3264>. editor.org/info/rfc3264>.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
DOI 10.17487/RFC4145, September 2005, DOI 10.17487/RFC4145, September 2005, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4145>. editor.org/info/rfc4145>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <https://www.rfc-editor.org/info/rfc5763>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/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, <http://www.rfc-editor.org/info/rfc7345>. 2014, <https://www.rfc-editor.org/info/rfc7345>.
[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-
<http://www.rfc-editor.org/info/rfc8122>. editor.org/info/rfc8122>.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-10 (work in progress), May 2017. rfc5245bis-10 (work in progress), May 2017.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
(work in progress), December 2016. (work in progress), December 2016.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-38 (work in progress), April 2017. negotiation-38 (work in progress), April 2017.
15.2. Informative References 14.2. Informative References
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006, DOI 10.17487/RFC4474, August 2006, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc4474>. editor.org/info/rfc4474>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
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-
<http://www.rfc-editor.org/info/rfc4572>. 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,
<http://www.rfc-editor.org/info/rfc5576>. <https://www.rfc-editor.org/info/rfc5576>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.
[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-
<http://www.rfc-editor.org/info/rfc6083>. editor.org/info/rfc6083>.
Internet-DrafSession Description Protocol (SDP) Offer/Answer August 2017
[RFC7983] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)",
RFC 7983, DOI 10.17487/RFC7983, September 2016,
<https://www.rfc-editor.org/info/rfc7983>.
[I-D.ietf-stir-rfc4474bis] [I-D.ietf-stir-rfc4474bis]
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), February 2017. (work in progress), February 2017.
[I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Keranen, A., and S. Nandakumar,
"Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-13 (work in
progress), June 2017.
[I-D.ietf-mmusic-sdp-uks]
Thomson, M. and E. Rescorla, "Unknown Key Share Attacks on
uses of Transport Layer Security with the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-uks-00
(work in progress), August 2017.
[ITU.T38.2010] [ITU.T38.2010]
International Telecommunications Union, "Procedures for International Telecommunications Union, "Procedures for
real-time Group 3 facsimile communication over IP real-time Group 3 facsimile communication over IP
networks", ITU-T Recommendation T.38, September 2010. networks", ITU-T Recommendation T.38, September 2010.
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/Answer August 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. 78 change blocks. 
161 lines changed or deleted 272 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/