draft-ietf-mmusic-dtls-sdp-09.txt   draft-ietf-mmusic-dtls-sdp-10.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: August 28, 2016 February 25, 2016 Expires: September 4, 2016 March 3, 2016
Using the SDP Offer/Answer Mechanism for DTLS Using the SDP Offer/Answer Mechanism for DTLS
draft-ietf-mmusic-dtls-sdp-09.txt draft-ietf-mmusic-dtls-sdp-10.txt
Abstract Abstract
This draft defines the SDP offer/answer procedures for negotiating This draft defines the SDP offer/answer procedures for negotiating
and establishing a DTLS association. The draft also defines the and establishing a DTLS association. The draft also defines the
criteria for when a new DTLS association must be established. criteria for when a new DTLS association must be established.
This draft defines a new SDP media-level attribute, 'dtls- This draft defines a new SDP media-level attribute, 'dtls-
connection'. connection'.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 August 28, 2016. This Internet-Draft will expire on September 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Establishing a new DTLS Association . . . . . . . . . . . . . 3 3. Establishing a new DTLS Association . . . . . . . . . . . . . 3
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Change of Local Transport Parameters . . . . . . . . . . 4 3.2. Change of Local Transport Parameters . . . . . . . . . . 3
3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4 3.3. Change of ICE ufrag value . . . . . . . . . . . . . . . . 4
3.4. Multiple SDP fingerprint attributes . . . . . . . . . . . 4
4. SDP dtls-connection Attribute . . . . . . . . . . . . . . . . 4 4. SDP dtls-connection Attribute . . . . . . . . . . . . . . . . 4
5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 6 5. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 7 5.2. Generating the Initial SDP Offer . . . . . . . . . . . . 6
5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 7 5.3. Generating the Answer . . . . . . . . . . . . . . . . . . 7
5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 8 5.4. Offerer Processing of the SDP Answer . . . . . . . . . . 7
5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 8 5.5. Modifying the Session . . . . . . . . . . . . . . . . . . 8
6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. ICE Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Transport Protocol Considerations . . . . . . . . . . . . . . 9 7. Transport Protocol Considerations . . . . . . . . . . . . . . 9
7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 9 7.1. Transport Re-Usage . . . . . . . . . . . . . . . . . . . 9
8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. SIP Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 10 9.2. Update to RFC 5763 . . . . . . . . . . . . . . . . . . . 9
9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 15 9.3. Update to RFC 7345 . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . 22 14.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 34 skipping to change at page 3, line 31
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 in the following cases: A new DTLS association MUST be established in the following cases:
o The DTLS roles change; o The DTLS roles change;
o The fingerprint (certificate) value changes; or o A fingerprint (certificate) value changes; or
o The intent to establish of a new DTLS association is explicitly o The intent to establish of a new DTLS association is explicitly
signaled; signaled;
NOTE: The first two items list above are based on the procedures in NOTE: The first two items list above are based on the procedures in
[RFC5763]. This draft adds the support for explicit signaling. [RFC5763]. This draft adds the support for explicit signaling.
Whenever an entity determines, based on the criteria above, that a Whenever an entity determines, based on the criteria above, that a
new DTLS association is required, the entity MUST initiate an new DTLS association is required, the entity MUST initiate an
associated SDP offer/answer transaction, following the procedures in associated SDP offer/answer transaction, following the procedures in
skipping to change at page 4, line 22 skipping to change at page 4, line 16
If the underlying transport explicitly prohibits a DTLS association If the underlying transport explicitly prohibits a DTLS association
to span multiple transports, the SDP 'dtls-connection' attribute MUST to span multiple transports, the SDP 'dtls-connection' attribute MUST
be set to 'new' if the transport is changed. An example of such case be set to 'new' if the transport is changed. An example of such case
is when DTLS is carried over SCTP, as described in [RFC6083]. is when DTLS is carried over 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
either change its DTLS role, its fingerprint value and/or use the SDP either change its DTLS role, a fingerprint value and/or use the SDP
'dtls-connection' attribute with a 'new' value Section 4. 'dtls-connection' attribute with a 'new' value Section 4.
3.4. Multiple SDP fingerprint attributes
It is possible to associate multiple SDP fingerprint attribute values
to an 'm-' line. If any of the attribute values associated with an
'm-' line are removed, or if any new attribute values are added, it
is considered a fingerprint value change.
4. SDP dtls-connection Attribute 4. SDP dtls-connection Attribute
The SDP 'connection' attribute [RFC4145] was originally defined for The SDP 'connection' attribute [RFC4145] was originally defined for
connection-oriented protocols, e.g. TCP and TLS. This section connection-oriented protocols, e.g. TCP and TLS. This section
defines a similar attribute, 'dtls-connection', to be used with DTLS. defines a similar attribute, 'dtls-connection', to be used with DTLS.
Name: dtls-connection Name: dtls-connection
Value: conn-value Value: conn-value
skipping to change at page 6, line 30 skipping to change at page 5, line 48
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 a DTLS-protected media/data stream. ("m=" line) associated a DTLS-protected media/data stream.
In order to negotiate a DTLS association, the following SDP In order to negotiate a DTLS association, the following SDP
attributes are used: attributes are used:
o The SDP 'setup' attribute, defined in [RFC4145], is used to o The SDP 'setup' attribute, defined in [RFC4145], is used to
negotiate the DTLS roles; negotiate the DTLS roles;
o The SDP 'fingerprint' attribute, defined in [RFC4572], is used to o The SDP 'fingerprint' attribute, defined in [RFC4572], is used to
provide the fingerprint value; and provide a fingerprint value; and
o The SDP 'dtls-connection' attribute, defined in this o The SDP 'dtls-connection' attribute, defined in this
specification, is used to explicitly indicate whether a new DTLS specification, is used to explicitly indicate whether a new DTLS
association is to be established or a previous association is to association is to be established or a previous association is to
be used. be used.
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 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 SHA-256 for generating and verifying the Endpoints MUST support SHA-256 for generating and verifying any
fingerprint value associated with the DTLS association. The use of fingerprint value associated with the DTLS association. The use of
SHA-256 is preferred. SHA-256 is preferred.
Endpoints MUST, at a minimum, support Endpoints MUST, at a minimum, support
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST 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.
skipping to change at page 8, line 39 skipping to change at page 8, line 14
If the answer contains an SDP 'dtls-connection' attribute with an If the answer contains an SDP 'dtls-connection' attribute with an
'existing' value, the offerer will continue using the previously 'existing' value, the offerer will continue using the previously
established DTLS association. It is considered an error case if the established DTLS association. It is considered an error case if the
answer contains a 'dtls-connection' attribute with an 'existing' answer contains a 'dtls-connection' attribute with an 'existing'
value, and a DTLS association does not exist. value, and a DTLS association does not exist.
An offerer needs to be able to handle error conditions that can occur An offerer needs to be able to handle error conditions that can occur
during an offer/answer transaction, e.g. if an answer contains an SDP during an offer/answer transaction, e.g. if an answer contains an SDP
'dtls-connection' attribute with an 'existing' value even if no DTLS 'dtls-connection' attribute with an 'existing' value even if no DTLS
association exists, or if the answer contains a new fingerprint value association exists, or if the answer contains one or more new
for an existing DTLS association. If such error case occurs, the fingerprint values for an existing DTLS association. If such error
offerer SHOULD terminate the associated DTLS association (if it case occurs, the offerer SHOULD terminate the associated DTLS
exists) and send a new offer in order to terminate each media stream association (if it exists) and send a new offer in order to terminate
using the DTLS association, by setting the associated port value to each media stream using the DTLS association, by setting the
zero [RFC4145]. associated port value to zero [RFC4145].
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
'dtls-connection' attribute with a 'new' value in the offer. In 'dtls-connection' attribute with a 'new' value in the offer. In
addition, the offerer MUST insert an SDP 'setup' attribute according addition, the offerer MUST insert an SDP 'setup' attribute according
to the procedures in [RFC4145], and one or more SDP 'fingerprint' to the procedures in [RFC4145], and one or more SDP 'fingerprint'
attributes according to the procedures in [RFC4572], in the offer. attributes according to the procedures in [RFC4572], in the offer.
skipping to change at page 13, line 14 skipping to change at page 12, line 34
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, the fingerprint of This offer includes, as part of the SDP payload, a fingerprint of
the 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
skipping to change at page 19, line 28 skipping to change at page 19, line 5
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-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 consistant: 'DTLS connection' replaced with 'DTLS o Terminology made consistent: 'DTLS connection' replaced with 'DTLS
association'. association'.
o Editorial changes based on comments from Paul Kyzivat. o Editorial changes based on comments from Paul Kyzivat.
Changes from draft-ietf-mmusic-sdp-dtls-07 Changes from draft-ietf-mmusic-sdp-dtls-07
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
 End of changes. 19 change blocks. 
36 lines changed or deleted 28 lines changed or added

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