draft-ietf-mmusic-dtls-sdp-16.txt   draft-ietf-mmusic-dtls-sdp-17.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: July 14, 2017 January 10, 2017 Expires: July 31, 2017 January 27, 2017
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-16.txt draft-ietf-mmusic-dtls-sdp-17.txt
Abstract Abstract
This document defines the SDP offer/answer procedures for negotiating This document defines the SDP offer/answer procedures for negotiating
and establishing a DTLS association. The document also defines the and establishing a DTLS association. The document also defines the
criteria for when a new DTLS association must be established. The criteria for when a new DTLS association must be established. The
document updates RFC 5763 and RFC 7345, by replacing common SDP document updates RFC 5763 and RFC 7345, by replacing common SDP
offer/answer procedures with a reference to this specification. offer/answer procedures with a reference to this specification.
This document defines a new SDP media-level attribute, 'dtls-id'. This document defines a new SDP media-level attribute, 'dtls-id'.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 14, 2017. This Internet-Draft will expire on July 31, 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 38 skipping to change at page 2, line 38
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 11 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 11
9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 20
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
[RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS. [RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS.
[RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This [RFC7345] defines SDP offer/answer procedures for UDPTL-DTLS. This
specification defines general offer/answer procedures for DTLS, based specification defines general offer/answer procedures for DTLS, based
on the procedures in [RFC5763]. Other specifications, defining on the procedures in [RFC5763]. Other specifications, defining
specific DTLS usages, can then reference this specification, in order specific DTLS usages, can then reference this specification, in order
to ensure that the DTLS aspects are common among all usages. Having to ensure that the DTLS aspects are common among all usages. Having
common procedures is essential when multiple usages share the same common procedures is essential when multiple usages share the same
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 change, but the ufrag value is transport change is based on ufrag change, but the ufrag value is
changed both when ICE is negotiated and when ICE restart changed both when ICE is negotiated and when ICE restart
[I-D.ietf-ice-rfc5245bis] occurs. These events do not always require [I-D.ietf-ice-rfc5245bis] occurs. These events do not always require
a new DTLS association to be established, but currently there is no a new DTLS association to be established, but currently there is no
way to explicitly indicate in an SDP offer or answer whether a new way to explicitly indicate in an SDP offer or answer whether a new
DTLS association is required. To solve that problem, this document DTLS association is required. To solve that problem, this document
defines a new SDP attribute, 'dtls-id'. The 'dtls-id' attribute pair defines a new SDP attribute, 'dtls-id'. The pair of SDP 'dtls-id'
in combination with 'fingerprint' attribute values from offer and attribute values (the attribute values of the offerer and the
answer SDP uniquely identifies the DTLS association. Providing a new answerer) uniquely identifies the DTLS association. Providing a new
value of 'dtls-id' attribute in SDP offer or answers can be used to value of 'dtls-id' attribute in an SDP offer or answers can be used
indicate whether a new DTLS association is to be established. to indicate whether a new DTLS association is to be established.
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 after a successfull SDP A new DTLS association MUST be established after a successful SDP
offer/answer transaction in the following cases:: offer/answer transaction in the following cases:
o The negotiated DTLS setup roles change; or o The negotiated DTLS setup roles change; or
o One or more fingerprint values are modified, added or removed in o One or more fingerprint values are modified, added or removed in
either an SDP offer or answer; or either an SDP offer or answer; or
o The intent to establish a new DTLS association is explicitly o The intent to establish a new DTLS association is explicitly
signaled by changing the value of the SDP 'dtls-id' attribute signaled by changing the value of the SDP 'dtls-id' attribute
defined in this document; defined in this document;
skipping to change at page 4, line 41 skipping to change at page 4, line 41
association. association.
Name: dtls-id Name: dtls-id
Value: dtls-id-value Value: dtls-id-value
Usage Level: media Usage Level: media
Charset Dependent: no Charset Dependent: no
Default Value: empty value Default Value: N/A
Syntax: Syntax:
dtls-id-value = 0*256 <alpha-numeric defined in [RFC4566]> dtls-id-value = 0*256 <alpha-numeric defined in [RFC4566]>
Example: Example:
a=dtls-id:abc3dl a=dtls-id:abc3dl
Every time an endpoint requests to establish a new DTLS association, Every time an endpoint requests to establish a new DTLS association,
skipping to change at page 5, line 22 skipping to change at page 5, line 22
MUST guarantee global uniqueness of the value for the lifetime of the MUST guarantee global uniqueness of the value for the lifetime of the
DTLS association associated with the attribute value. DTLS association associated with the attribute value.
No default value is defined for the SDP 'dtls-id' attribute. No default value is defined for the SDP 'dtls-id' attribute.
Implementations that wish to use the attribute MUST explicitly Implementations that wish to use the attribute MUST explicitly
include it in SDP offers and answers. If an offer or answer does not include it in SDP offers and answers. If an offer or answer does not
contain an attribute (this could happen if the offerer or answerer contain an attribute (this could happen if the offerer or answerer
represents an existing implementation that has not been updated to represents an existing implementation that has not been updated to
support the 'dtls-id' attribute), the offer or answer MUST be treated support the 'dtls-id' attribute), the offer or answer MUST be treated
as if no 'dtls-id' attribute is included. Unless there is another as if no 'dtls-id' attribute is included. Unless there is another
mechanism to explicitly indiciate that a new DTLS association is to mechanism to explicitly indicate that a new DTLS association is to be
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; or o local transport parameters; or
o ICE ufrag value o ICE ufrag value
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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., SRTP-DTLS) 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 SRTP-DTLS [RFC5763], with the addition
of usage of the SDP 'dtls-id' attribute. That document is herein of usage of the SDP 'dtls-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.
skipping to change at page 6, line 47 skipping to change at page 6, line 47
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.
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 transport, the answerer MUST allocate a new transport for the
offer in answer a way that it can disambiguate any packets associated answer in such a way that it can disambiguate any packets associated
with new DTLS association from any packets associated with any other with new DTLS association from any packets associated with any other
DTLS association. This typically means using a local address and/or DTLS association. This typically means using a local address and/or
port, or a set of ICE candidates (see Section 6), which were not port, or a set of ICE candidates (see Section 6), which were 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;
skipping to change at page 7, line 28 skipping to change at page 7, line 28
attribute [RFC4145] for negotiating a DTLS connection. However, the attribute [RFC4145] for negotiating a DTLS connection. 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 Endpoints MUST support the cipher suites as defined in
[I-D.ietf-mmusic-4572-update]., [I-D.ietf-mmusic-4572-update].
The certificate received during the DTLS handshake MUST match the The certificate received during the DTLS handshake MUST match the
certificate fingerprints received in SDP 'fingerprint' attributes certificate fingerprints received in SDP 'fingerprint' attributes
according to procedures defined in [I-D.ietf-mmusic-4572-update]. If according to procedures defined in [I-D.ietf-mmusic-4572-update]. 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. Note that it is MUST tear down the media session immediately. Note that it is
permissible to wait until the other side's fingerprint has been permissible to wait until the other side's fingerprint has been
received before establishing the connection; however, this may have received before establishing the connection; however, this may have
undesirable latency effects. undesirable latency effects.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
answer. answer.
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 [I-D.ietf-mmusic-4572-update]. If the answerer the procedures in [I-D.ietf-mmusic-4572-update]. If the answerer
determines, based on the criteria specified in Section 3.1, that a determines, based on the criteria specified in Section 3.1, that a
new DTLS association is to be established, the answerer MUST insert new DTLS association is to be established, the answerer MUST insert
in the associated answer an SDP 'dtls-id' attribute with a unique in the associated answer an SDP 'dtls-id' attribute with a new unique
value. Note that the offerer and answerer generate their own local value. Note that the offerer and answerer generate their own local
'dtls-id' attribute values, and the combination of both values 'dtls-id' attribute values, and the combination of both values
identify the DTLS assocation. identify the DTLS association.
If the answerer receives an offer that requires establishing a new If the answerer receives an offer that requires establishment of a
DTLS association, and if the answerer does not accept the new DTLS association, and if the answerer does not accept the
establishment of a new DTLS association, the answerer MUST reject the establishment of a new DTLS association, the answerer MUST reject the
"m=" lines associated with the suggested DTLS association [RFC3264]. "m=" lines associated with the suggested DTLS association [RFC3264].
If an answerer receives an offer that does not require the If an answerer receives an offer that does not require the
establishment of a new DTLS association, and if the answerer establishment of a new DTLS association, and if the answerer
determines that a new DTLS association is not to be established, the determines that a new DTLS association is not to be established, the
answerer MUST insert an SDP 'dtls-id' attribute with the previously answerer MUST insert an SDP 'dtls-id' attribute with the previously
assigned value in the associated answer. In addition, the answerer assigned value in the associated answer. In addition, the answerer
MUST insert an SDP 'setup' attribute with a value that does not MUST insert an SDP 'setup' attribute with a value that does not
change the previously negotiated DTLS roles, and one or more SDP change the previously negotiated DTLS roles, and one or more SDP
'fingerprint' attributes values that do not change the previously 'fingerprint' attributes values that do not change the previously
sent fingerprint set, in the answer. sent fingerprint set, in the associated answer.
If the answerer receives an offer that does not contain an SDP 'dtls- If the answerer receives an offer that does not contain an SDP 'dtls-
id' attribute, the answerer MUST NOT insert a 'dtls-id' attribute in id' attribute, the answerer MUST NOT insert a 'dtls-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' value in the inserts an SDP 'setup' attribute with an 'active' value in the
answer, the answerer MUST initiate a DTLS handshake by sending a DTLS answer, the answerer MUST initiate a DTLS handshake by sending a DTLS
ClientHello message towards the offerer. ClientHello message towards the offerer.
skipping to change at page 9, line 13 skipping to change at page 9, line 13
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 answer does not establish a new DTLS association, the offerer If the answer does not establish a new DTLS association, the offerer
will continue using the previously established DTLS association. will continue using the previously established DTLS association.
NOTE: A new DTLS association can be established based on changes in NOTE: A new DTLS association can be established based on changes in
either an SDP offer or answer. When communicating with legacy either an SDP offer or answer. When communicating with legacy
endpoints, an offerer can receive an answer that include the same endpoints, an offerer can receive an answer that includes the same
fingerprint set and setup role. A new DTLS association MUST still be fingerprint set and setup role. A new DTLS association MUST still be
established if such an answer was received as a response to an offer established if such an answer was received as a response to an offer
which requested the establishment of a new DTLS association. which requested the establishment of a new DTLS association.
5.5. Modifying the Session 5.5. Modifying the Session
When the offerer sends a subsequent offer, and if the offerer wants When the offerer sends a subsequent offer, and if the offerer wants
to establish a new DTLS association, the offerer MUST insert an SDP to establish a new DTLS association, the offerer MUST insert an SDP
'setup' attribute according to the procedures in [RFC4145], and one 'setup' attribute according to the procedures in [RFC4145], and one
or more SDP 'fingerprint' attributes according to the procedures in or more SDP 'fingerprint' attributes according to the procedures in
[I-D.ietf-mmusic-4572-update]. In addition, the offerer MUST insert [I-D.ietf-mmusic-4572-update]. In addition, the offerer MUST insert
in the offer an SDP 'dtls-id' attribute with a new unique value. in the offer an SDP 'dtls-id' attribute with a new unique value.
When the offerer sends a subsequent offer, and the offerer does not When the offerer sends a subsequent offer, and the offerer does not
want to establish a new DTLS association, and if a previously want to establish a new DTLS association, and if a previously
established DTLS association exists, the offerer MUST insert an SDP established DTLS association exists, the offerer MUST insert an SDP
'dtls-id' attribute with the previously assigned value in the offer. 'dtls-id' attribute with the previously assigned value in the offer.
In addition, the offerer MUST insert an SDP 'setup' attribute with a In addition, the offerer MUST insert an SDP 'setup' attribute, and
value that does not change the previously negotiated DTLS roles, and
one or more SDP 'fingerprint' attributes with values that do not one or more SDP 'fingerprint' attributes with values that do not
change the previously sent fingerprint set, in the offer. change the previously sent fingerprint set, in the offer. The value
of the 'setup' attribute SHOULD be set to 'actpass', in order to
allow the answerer to establish a new DTLS association with a
different role, but MAY be set to the current negotiated role
('active' or 'passive'). It MUST NOT be set to a value that changes
the current negotiated role.
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.
6. ICE Considerations 6. ICE Considerations
When the Interactive Connectivity Establishment (ICE) mechansim 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.
When new DTLS association is established over an unordered transport, When new DTLS association is established over an unordered transport,
in order to disambiguate any packets associated with the newly in order to disambiguate any packets associated with the newly
skipping to change at page 11, line 27 skipping to change at page 11, line 30
9.2. Update to RFC 5763 9.2. Update to RFC 5763
Update to section 5: Update to section 5:
-------------------- --------------------
OLD TEXT: OLD TEXT:
5. Establishing a Secure Channel 5. Establishing a Secure Channel
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)" [RFC4572]. the Session Description Protocol (SDP)" [RFC4572].
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. This is useful for debugging resource identifier (URI) of the user. This is useful for debugging
purposes only and is not required to bind the certificate to one of purposes only and is not required to bind the certificate to one of
the communication endpoints. The integrity of the certificate is the communication endpoints. The integrity of the certificate is
ensured through the fingerprint attribute in the SDP. The ensured through the fingerprint attribute in the SDP. The
subjectAltName is not an important component of the certificate subjectAltName is not an important component of the certificate
verification. verification.
The generation of public/private key pairs is relatively expensive. The generation of public/private key pairs is relatively expensive.
Endpoints are not required to generate certificates for each session. Endpoints are not required to generate certificates for each session.
The offer/answer model, defined in [RFC3264], is used by protocols The offer/answer model, defined in [RFC3264], is used by protocols
like the Session Initiation Protocol (SIP) [RFC3261] to set up like the Session Initiation Protocol (SIP) [RFC3261] to set up
multimedia sessions. In addition to the usual contents of an SDP multimedia sessions. In addition to the usual contents of an SDP
[RFC4566] message, each media description ("m=" line and associated [RFC4566] message, each media description ("m=" line and associated
parameters) will also contain several attributes as specified in parameters) will also contain several attributes as specified in
[RFC5764], [RFC4145], and [RFC4572]. [RFC5764], [RFC4145], and [RFC4572].
When an endpoint wishes to set up a secure media session with another When an endpoint wishes to set up a secure media session with another
endpoint, it sends an offer in a SIP message to the other endpoint. endpoint, it sends an offer in a SIP message to the other endpoint.
This offer includes, as part of the SDP payload, the fingerprint of This offer includes, as part of the SDP payload, the fingerprint of
the certificate that the endpoint wants to use. The endpoint SHOULD the certificate that the endpoint wants to use. The endpoint SHOULD
send the SIP message containing the offer to the offerer's SIP proxy send the SIP message containing the offer to the offerer's SIP proxy
over an integrity protected channel. The proxy SHOULD add an over an integrity protected channel. The proxy SHOULD add an
Identity header field according to the procedures outlined in Identity header field according to the procedures outlined in
[RFC4474]. The SIP message containing the offer SHOULD be sent to [RFC4474]. The SIP message containing the offer SHOULD be sent to
the offerer's SIP proxy over an integrity protected channel. When the offerer's SIP proxy over an integrity protected channel. When
the far endpoint receives the SIP message, it can verify the identity the far endpoint receives the SIP message, it can verify the identity
of the sender using the Identity header field. Since the Identity of the sender using the Identity header field. Since the Identity
header field is a digital signature across several SIP header fields, header field is a digital signature across several SIP header fields,
in addition to the body of the SIP message, the receiver can also be in addition to the body of the SIP message, the receiver can also be
certain that the message has not been tampered with after the digital certain that the message has not been tampered with after the digital
signature was applied and added to the SIP message. signature was applied and added to the SIP 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 TLS association. In either case, mutual offerer is to initiate the TLS association. In either case, mutual
DTLS certificate-based authentication will be used. After completing DTLS certificate-based authentication will be used. After completing
the DTLS handshake, information about the authenticated identities, the DTLS handshake, information about the authenticated identities,
including the certificates, are made available to the endpoint including the certificates, 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 the certificate fingerprint contained in the offer in associated to the 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.
When the answerer accepts the offer, it provides an answer back to When the answerer accepts the offer, it provides an answer back to
the offerer containing the answerer's certificate fingerprint. At the offerer containing the answerer's certificate fingerprint. At
this point, the offerer can accept or reject the peer's certificate this point, the offerer can accept or reject the peer's certificate
and the offerer can indicate to the end user that the media is and the offerer can indicate to the end user that the media is
secured. secured.
Note that the entire authentication and key exchange for securing the Note that the entire authentication and key exchange for securing the
media traffic is handled in the media path through DTLS. 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 offer and answer MUST conform to the following requirements. The offer and answer MUST conform to the following requirements.
o The endpoint MUST use the setup attribute defined in [RFC4145]. o The endpoint MUST use the setup attribute defined in [RFC4145].
The endpoint that is the offerer MUST use the setup attribute The endpoint that is the offerer MUST use the setup attribute
value of setup:actpass and be prepared to receive a client_hello value of setup:actpass and be prepared to receive a client_hello
before it receives the answer. The answerer MUST use either a before it receives the answer. The answerer MUST use either a
setup attribute value of setup:active or setup:passive. Note that setup attribute value of setup:active or setup:passive. Note that
if the answerer uses setup:passive, then the DTLS handshake will if the answerer uses setup:passive, then the DTLS handshake will
not begin until the answerer is received, which adds additional not begin until the answerer is received, which adds additional
latency. setup:active allows the answer and the DTLS handshake to latency. setup:active allows the answer and the DTLS handshake to
occur in parallel. Thus, setup:active is RECOMMENDED. Whichever occur in parallel. Thus, setup:active is RECOMMENDED. Whichever
party is active MUST initiate a DTLS handshake by sending a party is active MUST initiate a DTLS handshake by sending a
ClientHello over each flow (host/port quartet). ClientHello over each flow (host/port quartet).
o The endpoint MUST NOT use the connection attribute defined in o The endpoint MUST NOT use the connection attribute defined in
[RFC4145]. [RFC4145].
o The endpoint MUST use the certificate fingerprint attribute as o The endpoint MUST use the certificate fingerprint attribute as
specified in [RFC4572]. specified in [RFC4572].
o The certificate presented during the DTLS handshake MUST match the o The certificate presented during the DTLS handshake MUST match the
fingerprint exchanged via the signaling path in the SDP. The fingerprint exchanged via the signaling path in the SDP. The
security properties of this mechanism are described in Section 8. security properties of this mechanism are described in Section 8.
o If the fingerprint does not match the hashed certificate, then the o If the fingerprint does not match the hashed certificate, then the
endpoint MUST tear down the media session immediately. Note that endpoint MUST tear down the media session immediately. Note that
it is permissible to wait until the other side's fingerprint has it is permissible to wait until the other side's fingerprint has
been received before establishing the connection; however, this been received before establishing the connection; however, this
may have undesirable latency effects. may have undesirable latency effects.
NEW TEXT: NEW TEXT:
5. Establishing a Secure Channel 5. Establishing a Secure Channel
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 TLS in SDP" [I-D.ietf-mmusic-4572-update].
the Session Description Protocol (SDP)" [RFC4572].
If self-signed certificates are used, the content of the If self-signed certificates are used, the content of the
subjectAltName attribute inside the certificate MAY use the uniform subjectAltName attribute inside the certificate MAY use the uniform
resource identifier (URI) of the user. This is useful for debugging resource identifier (URI) of the user. This is useful for debugging
purposes only and is not required to bind the certificate to one of purposes only and is not required to bind the certificate to one of
the communication endpoints. The integrity of the certificate is the communication endpoints. The integrity of the certificate is
ensured through the fingerprint attribute in the SDP. ensured through the fingerprint attribute in the SDP.
The generation of public/private key pairs is relatively expensive. The generation of public/private key pairs is relatively expensive.
Endpoints are not required to generate certificates for each session. Endpoints are not required to generate certificates for each session.
The offer/answer model, defined in [RFC3264], is used by protocols The offer/answer model, defined in [RFC3264], is used by protocols
like the Session Initiation Protocol (SIP) [RFC3261] to set up like the Session Initiation Protocol (SIP) [RFC3261] to set up
multimedia sessions. multimedia sessions.
When an endpoint wishes to set up a secure media session with another When an endpoint wishes to set up a secure media session with another
endpoint, it sends an offer in a SIP message to the other endpoint. endpoint, it sends an offer in a SIP message to the other endpoint.
This offer includes, as part of the SDP payload, a fingerprint of This offer includes, as part of the SDP payload, a fingerprint of
a certificate that the endpoint wants to use. The endpoint SHOULD a certificate that the endpoint wants to use. The endpoint SHOULD
send the SIP message containing the offer to the offerer's SIP proxy send the SIP message containing the offer to the offerer's SIP proxy
over an integrity protected channel. The proxy SHOULD add an over an integrity protected channel. The proxy SHOULD add an
Identity header field according to the procedures outlined in Identity header field according to the procedures outlined in
[RFC4474]. The SIP message containing the offer SHOULD be sent to [RFC4474]. The SIP message containing the offer SHOULD be sent to
the offerer's SIP proxy over an integrity protected channel. When the offerer's SIP proxy over an integrity protected channel. When
the far endpoint receives the SIP message, it can verify the identity the far endpoint receives the SIP message, it can verify the identity
of the sender using the Identity header field. Since the Identity of the sender using the Identity header field. Since the Identity
header field is a digital signature across several SIP header fields, header field is a digital signature across several SIP header fields,
in addition to the body of the SIP message, the receiver can also be in addition to the body of the SIP message, the receiver can also be
certain that the message has not been tampered with after the digital certain that the message has not been tampered with after the digital
signature was applied and added to the SIP message. signature was applied and added to the SIP 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
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 the certificate fingerprint contained in the offer in associated to the 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.
When the answerer accepts the offer, it provides an answer back to When the answerer accepts the offer, it provides an answer back to
the offerer containing the answerer's certificate fingerprint. At the offerer containing the answerer's certificate fingerprint. At
this point, the offerer can accept or reject the peer's certificate this point, the offerer can accept or reject the peer's certificate
and the offerer can indicate to the end user that the media is and the offerer can indicate to the end user that the media is
secured. secured.
Note that the entire authentication and key exchange for securing the Note that the entire authentication and key exchange for securing
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].
Update to section 6.6: Update to section 6.6:
---------------------- ----------------------
OLD TEXT: OLD TEXT:
6.6. Session Modification 6.6. Session Modification
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 the existing associations if UPDATE request. The peers can reuse the existing associations if
they are compatible (i.e., they have the same key fingerprints and they are compatible (i.e., they have the same key fingerprints and
transport parameters), or establish a new one following the same transport parameters), or establish a new one following the same
rules are for initial exchanges, tearing down the existing rules are for initial exchanges, tearing down the existing
association as soon as the offer/answer exchange is completed. Note association as soon as the offer/answer exchange is completed. Note
that if the active/passive status of the endpoints changes, a new that if the active/passive status of the endpoints changes, a new
connection MUST be established. connection MUST be established.
NEW TEXT: NEW TEXT:
6.6. Session Modification 6.6. Session Modification
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
skipping to change at page 15, line 38 skipping to change at page 15, line 41
Update to section 6.7.1: Update to section 6.7.1:
------------------------ ------------------------
OLD TEXT: OLD TEXT:
6.7.1. ICE Interaction 6.7.1. ICE Interaction
Interactive Connectivity Establishment (ICE), as specified in Interactive Connectivity Establishment (ICE), as specified in
[RFC5245], provides a methodology of allowing participants in [RFC5245], provides a methodology of allowing participants in
multimedia sessions to verify mutual connectivity. When ICE is being multimedia sessions to verify mutual connectivity. When ICE is being
used, the ICE connectivity checks are performed before the DTLS used, the ICE connectivity checks are performed before the DTLS
handshake begins. Note that if aggressive nomination mode is used, handshake begins. Note that if aggressive nomination mode is used,
multiple candidate pairs may be marked valid before ICE finally multiple candidate pairs may be marked valid before ICE finally
converges on a single candidate pair. Implementations MUST treat all converges on a single candidate pair. Implementations MUST treat all
ICE candidate pairs associated with a single component as part of the ICE candidate pairs associated with a single component as part of the
same DTLS association. Thus, there will be only one DTLS handshake same DTLS association. Thus, there will be only one DTLS handshake
even if there are multiple valid candidate pairs. Note that this may even if there are multiple valid candidate pairs. Note that this may
mean adjusting the endpoint IP addresses if the selected candidate mean adjusting the endpoint IP addresses if the selected candidate
pair shifts, just as if the DTLS packets were an ordinary media pair shifts, just as if the DTLS packets were an ordinary media
stream. stream.
Note that Simple Traversal of the UDP Protocol through NAT (STUN) Note that Simple Traversal of the UDP Protocol through NAT (STUN)
packets are sent directly over UDP, not over DTLS. [RFC5764] packets are sent directly over UDP, not over DTLS. [RFC5764]
describes how to demultiplex STUN packets from DTLS packets and SRTP describes how to demultiplex STUN packets from DTLS packets and SRTP
packets. packets.
NEW TEXT: NEW TEXT:
6.7.1. ICE Interaction 6.7.1. ICE Interaction
The Interactive Connectivity Establishment (ICE) [RFC5245] The Interactive Connectivity Establishment (ICE)
considerations for DTLS-protected media are described in [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
[RFCXXXX]. are described in [RFCXXXX].
9.3. Update to RFC 7345 9.3. Update to RFC 7345
Update to section 4: Update to section 4:
-------------------- --------------------
OLD TEXT: OLD TEXT:
4. SDP Offerer/Answerer Procedures 4. SDP Offerer/Answerer Procedures
skipping to change at page 17, line 4 skipping to change at page 17, line 7
described in this section. described in this section.
The endpoint MUST NOT use the SDP "connection" attribute [RFC4145]. The endpoint MUST NOT use the SDP "connection" attribute [RFC4145].
In order to negotiate the TLS roles for the UDPTL-over-DTLS transport In order to negotiate the TLS roles for the UDPTL-over-DTLS transport
connection, the endpoint MUST use the SDP "setup" attribute connection, the endpoint MUST use the SDP "setup" attribute
[RFC4145]. [RFC4145].
If the endpoint supports, and is willing to use, a cipher suite with If the endpoint supports, and is willing to use, a cipher suite with
an associated certificate, the endpoint MUST include an SDP an associated certificate, the endpoint MUST include an SDP
"fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256 "fingerprint" attribute [RFC4572]. The endpoint MUST support SHA-256
for generating and verifying the SDP "fingerprint" attribute value. for generating and verifying the SDP "fingerprint" attribute value.
The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST The use of SHA-256 is preferred. UDPTL over DTLS, at a minimum, MUST
support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. UDPTL over DTLS MUST prefer
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward
Secrecy (PFS) cipher suites over non-PFS cipher suites. Secrecy (PFS) cipher suites over non-PFS cipher suites.
Implementations SHOULD disable TLS-level compression. Implementations SHOULD disable TLS-level compression.
If a cipher suite with an associated certificate is selected during If a cipher suite with an associated certificate is selected during
the DTLS handshake, the certificate received during the DTLS the DTLS handshake, the certificate received during the DTLS
handshake MUST match the fingerprint received in the SDP handshake MUST match the fingerprint received in the SDP
"fingerprint" attribute. If the fingerprint does not match the "fingerprint" attribute. If the fingerprint does not match the
hashed certificate, then the endpoint MUST tear down the media hashed certificate, then the endpoint MUST tear down the media
session immediately. Note that it is permissible to wait until the session immediately. Note that it is permissible to wait until the
other side's fingerprint has been received before establishing the other side's fingerprint has been received before establishing the
connection; however, this may have undesirable latency effects. connection; however, this may have undesirable latency effects.
4.2. Generating the Initial Offer 4.2. Generating the Initial Offer
The offerer SHOULD assign the SDP "setup" attribute with a value of The offerer SHOULD assign the SDP "setup" attribute with a value of
"actpass", unless the offerer insists on being either the sender or "actpass", unless the offerer insists on being either the sender or
receiver of the DTLS ClientHello message, in which case the offerer receiver of the DTLS ClientHello message, in which case the offerer
can use either a value of "active" (the offerer will be the sender of can use either a value of "active" (the offerer will be the sender of
ClientHello) or "passive" (the offerer will be the receiver of ClientHello) or "passive" (the offerer will be the receiver of
skipping to change at page 17, line 41 skipping to change at page 17, line 44
If the offerer assigns the SDP "setup" attribute with a value of If the offerer assigns the SDP "setup" attribute with a value of
"actpass" or "passive", the offerer MUST be prepared to receive a "actpass" or "passive", the offerer MUST be prepared to receive a
DTLS ClientHello message before it receives the SDP answer. DTLS ClientHello message before it receives the SDP answer.
4.3. Generating the Answer 4.3. Generating the Answer
If the answerer accepts the offered UDPTL-over-DTLS transport If the answerer accepts the offered UDPTL-over-DTLS transport
connection, in the associated SDP answer, the answerer MUST assign an connection, in the associated SDP answer, the answerer MUST assign an
SDP "setup" attribute with a value of either "active" or "passive", SDP "setup" attribute with a value of either "active" or "passive",
according to the procedures in [RFC4145]. The answerer MUST NOT according to the procedures in [RFC4145]. The answerer MUST NOT
assign an SDP "setup" attribute with a value of "holdconn". assign an SDP "setup" attribute with a value of "holdconn".
If the answerer assigns an SDP "setup" attribute with a value of If the answerer assigns an SDP "setup" attribute with a value of
"active" value, the answerer MUST initiate a DTLS handshake by "active" value, the answerer MUST initiate a DTLS handshake by
sending a DTLS ClientHello message on the negotiated media stream, sending a DTLS ClientHello message on the negotiated media stream,
towards the IP address and port of the offerer. towards the IP address and port of the offerer.
4.4. Offerer Processing of the Answer 4.4. Offerer Processing of the Answer
When the offerer receives an SDP answer, if the offerer ends up being When the offerer receives an SDP answer, if the offerer ends up being
active it MUST initiate a DTLS handshake by sending a DTLS active it MUST initiate a DTLS handshake by sending a DTLS
ClientHello message on the negotiated media stream, towards the IP ClientHello message on the negotiated media stream, towards the IP
address and port of the answerer. address and port of the answerer.
4.5. Modifying the Session 4.5. Modifying the Session
Once an offer/answer exchange has been completed, either endpoint MAY Once an offer/answer exchange has been completed, either endpoint MAY
send a new offer in order to modify the session. The endpoints can send a new offer in order to modify the session. The endpoints can
reuse the existing DTLS association if the key fingerprint values and reuse the existing DTLS association if the key fingerprint values and
transport parameters indicated by each endpoint are unchanged. transport parameters indicated by each endpoint are unchanged.
Otherwise, following the rules for the initial offer/answer exchange, Otherwise, following the rules for the initial offer/answer exchange,
the endpoints can negotiate and create a new DTLS association and, the endpoints can negotiate and create a new DTLS association and,
once created, delete the previous DTLS association, following the once created, delete the previous DTLS association, following the
same rules for the initial offer/answer exchange. Each endpoint same rules for the initial offer/answer exchange. 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.
NEW TEXT: NEW TEXT:
4. SDP Offerer/Answerer Procedures 4. SDP Offerer/Answerer Procedures
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
skipping to change at page 18, line 45 skipping to change at page 18, line 46
Update to section 5.2.1: Update to section 5.2.1:
------------------------ ------------------------
OLD TEXT: OLD TEXT:
5.2.1. ICE Usage 5.2.1. ICE Usage
When Interactive Connectivity Establishment (ICE) [RFC5245] is being When Interactive Connectivity Establishment (ICE) [RFC5245] is being
used, the ICE connectivity checks are performed before the DTLS used, the ICE connectivity checks are performed before the DTLS
handshake begins. Note that if aggressive nomination mode is used, handshake begins. Note that if aggressive nomination mode is used,
multiple candidate pairs may be marked valid before ICE finally multiple candidate pairs may be marked valid before ICE finally
converges on a single candidate pair. User Agents (UAs) MUST treat converges on a single candidate pair. User Agents (UAs) MUST treat
all ICE candidate pairs associated with a single component as part of all ICE candidate pairs associated with a single component as part
the same DTLS association. Thus, there will be only one DTLS of the same DTLS association. Thus, there will be only one DTLS
handshake even if there are multiple valid candidate pairs. Note handshake even if there are multiple valid candidate pairs. Note
that this may mean adjusting the endpoint IP addresses if the that this may mean adjusting the endpoint IP addresses if the
selected candidate pair shifts, just as if the DTLS packets were an selected candidate pair shifts, just as if the DTLS packets were an
ordinary media stream. In the case of an ICE restart, the DTLS ordinary media stream. In the case of an ICE restart, the DTLS
handshake procedure is repeated, and a new DTLS association is handshake procedure is repeated, and a new DTLS association is
created. Once the DTLS handshake is completed and the new DTLS created. Once the DTLS handshake is completed and the new DTLS
association has been created, the previous DTLS association is association has been created, the previous DTLS association is
deleted. deleted.
NEW TEXT: NEW TEXT:
5.2.1. ICE Usage 5.2.1. ICE Usage
The Interactive Connectivity Establishment (ICE) [RFC5245] The Interactive Connectivity Establishment (ICE)
considerations for DTLS-protected media are described in [I-D.ietf-ice-rfc5245bis] considerations for DTLS-protected media
[RFCXXXX]. are described in [RFCXXXX].
10. 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 'dtls-id' attribute, the specification to the introduction of the SDP 'dtls-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.
11. IANA Considerations 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 dtls-id attribute to the table for SDP media level it adds the SDP 'dtls-id' attribute to the table for SDP media level
attributes. attributes.
Attribute name: dtls-id Attribute name: dtls-id
Type of attribute: media-level Type of attribute: media-level
Subject to charset: no Subject to charset: no
Purpose: Indicate whether a new DTLS association is to be Purpose: Indicates whether a new DTLS association is to be
established/re-established. 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
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 and Gonzalo Salgueiro for providing comments and Charles Eckel and Gonzalo Salgueiro for providing comments and
suggestions on the document. suggestions on the document.
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-16
o Editorial changes based on 2nd WGLC comments from Christian Groves
and Nevenka Biondic.
Changes from draft-ietf-mmusic-sdp-dtls-15 Changes from draft-ietf-mmusic-sdp-dtls-15
o dtls-id attribute value made globally unique o dtls-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
skipping to change at page 23, line 48 skipping to change at page 23, line 52
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://www.rfc-editor.org/info/rfc5763>.
[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, <http://www.rfc-editor.org/info/rfc7345>.
[I-D.ietf-mmusic-4572-update] [I-D.ietf-mmusic-4572-update]
Lennox, J. and C. Holmberg, "Connection-Oriented Media Lennox, J. and C. Holmberg, "Connection-Oriented Media
Transport over TLS in SDP", draft-ietf-mmusic- Transport over TLS in SDP", draft-ietf-mmusic-
4572-update-10 (work in progress), January 2017. 4572-update-12 (work in progress), January 2017.
14.2. Informative References 14.2. Informative References
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<http://www.rfc-editor.org/info/rfc4474>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006,
<http://www.rfc-editor.org/info/rfc4572>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[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>. <http://www.rfc-editor.org/info/rfc5576>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010, DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <http://www.rfc-editor.org/info/rfc5764>.
skipping to change at page 24, line 41 skipping to change at page 25, line 11
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-36 (work in progress), October 2016. negotiation-36 (work in progress), October 2016.
[ITU.T38.2010]
International Telecommunications Union, "Procedures for
real-time Group 3 facsimile communication over IP
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
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. 79 change blocks. 
100 lines changed or deleted 133 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/