draft-ietf-mmusic-4572-update-11.txt   draft-ietf-mmusic-4572-update-12.txt 
Network Working Group J. Lennox Network Working Group J. Lennox
Internet-Draft Vidyo Internet-Draft Vidyo
Obsoletes: 4572 (if approved) C. Holmberg Obsoletes: 4572 (if approved) C. Holmberg
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: July 16, 2017 January 12, 2017 Expires: July 30, 2017 January 26, 2017
Connection-Oriented Media Transport over TLS in SDP Connection-Oriented Media Transport over TLS in SDP
draft-ietf-mmusic-4572-update-11 draft-ietf-mmusic-4572-update-12
Abstract Abstract
This document specifies how to establish secure connection-oriented This document specifies how to establish secure connection-oriented
media transport sessions over the Transport Layer Security (TLS) media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines a protocol using the Session Description Protocol (SDP). It defines
new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax
and semantics for an SDP 'fingerprint' attribute that identifies the and semantics for an SDP 'fingerprint' attribute that identifies the
certificate that will be presented for the TLS session. This certificate that will be presented for the TLS session. This
mechanism allows media transport over TLS connections to be mechanism allows media transport over TLS connections to be
established securely, so long as the integrity of session established securely, so long as the integrity of session
descriptions is assured. descriptions is assured.
This document obsoletes RFC 4572, by clarifying the usage of multiple This document obsoletes RFC 4572, by clarifying the usage of multiple
fingerprints. fingerprints.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 16, 2017. This Internet-Draft will expire on July 30, 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 3, line 7 skipping to change at page 3, line 7
oriented transport. RFC 4145, Connection-Oriented Media Transport in oriented transport. RFC 4145, Connection-Oriented Media Transport in
the Session Description Protocol (SDP) [7], specifies a general the Session Description Protocol (SDP) [7], specifies a general
mechanism for describing and establishing such connection-oriented mechanism for describing and establishing such connection-oriented
streams; however, the only transport protocol it directly supports is streams; however, the only transport protocol it directly supports is
TCP. In many cases, session participants wish to provide TCP. In many cases, session participants wish to provide
confidentiality, data integrity, and authentication for their media confidentiality, data integrity, and authentication for their media
sessions. This document therefore extends the Connection-Oriented sessions. This document therefore extends the Connection-Oriented
Media specification to allow session descriptions to describe media Media specification to allow session descriptions to describe media
sessions that use the Transport Layer Security (TLS) protocol [10]. sessions that use the Transport Layer Security (TLS) protocol [10].
TLS protocol allows applications to communicate over a channel that The TLS protocol allows applications to communicate over a channel
provides confidentiality and data integrity. The TLS specification, that provides confidentiality and data integrity. The TLS
however, does not specify how specific protocols establish and use specification, however, does not specify how specific protocols
this secure channel; particularly, TLS leaves the question of how to establish and use this secure channel; particularly, TLS leaves the
interpret and validate authentication certificates as an issue for question of how to interpret and validate authentication certificates
the protocols that run over TLS. This document specifies such usage as an issue for the protocols that run over TLS. This document
for the case of connection-oriented media transport. specifies such usage for the case of connection-oriented media
transport.
Complicating this issue, endpoints exchanging media will often be Complicating this issue, endpoints exchanging media will often be
unable to obtain authentication certificates signed by a well-known unable to obtain authentication certificates signed by a well-known
root certification authority (CA). Most certificate authorities root certification authority (CA). Most certificate authorities
charge for signed certificates, particularly host-based certificates; charge for signed certificates, particularly host-based certificates;
additionally, there is a substantial administrative overhead to additionally, there is a substantial administrative overhead to
obtaining signed certificates, as certification authorities must be obtaining signed certificates, as certification authorities must be
able to confirm that they are issuing the signed certificates to the able to confirm that they are issuing the signed certificates to the
correct party. Furthermore, in many cases endpoints' IP addresses correct party. Furthermore, in many cases endpoints' IP addresses
and host names are dynamic: they may be obtained from DHCP, for and host names are dynamic: they may be obtained from DHCP, for
skipping to change at page 6, line 50 skipping to change at page 6, line 50
Figure 1: Example SDP Description Offering a TLS Media Stream Figure 1: Example SDP Description Offering a TLS Media Stream
4. Protocol Identifiers 4. Protocol Identifiers
The 'm' line in SDP specifies, among other items, the transport The 'm' line in SDP specifies, among other items, the transport
protocol to be used for the media in the session. See the "Media protocol to be used for the media in the session. See the "Media
Descriptions" section of SDP [8] for a discussion on transport Descriptions" section of SDP [8] for a discussion on transport
protocol identifiers. protocol identifiers.
This specification defines a new protocol identifier, 'TCP/TLS', This specification defines the protocol identifier, 'TCP/TLS', which
which indicates that the media described will use the Transport Layer indicates that the media described will use the Transport Layer
Security protocol [10] over TCP. (Using TLS over other transport Security protocol [10] over TCP. (Using TLS over other transport
protocols is not discussed in this document.) The 'TCP/TLS' protocol protocols is not discussed in this document.) The 'TCP/TLS' protocol
identifier describes only the transport protocol, not the upper-layer identifier describes only the transport protocol, not the upper-layer
protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify
the protocol using a fmt identifier to indicate the application being the protocol using a fmt identifier to indicate the application being
run over TLS. run over TLS.
Media sessions described with this identifier follow the procedures Media sessions described with this identifier follow the procedures
defined in RFC 4145 [7]. They also use the SDP attributes defined in defined in RFC 4145 [7]. They also use the SDP attributes defined in
that specification, 'setup' and 'connection'. that specification, 'setup' and 'connection'.
skipping to change at page 8, line 47 skipping to change at page 8, line 47
unused hash functions might log occurrences of these algorithms unused hash functions might log occurrences of these algorithms
differently to unknown hash algorithms. differently to unknown hash algorithms.
The fingerprint attribute may be either a session-level or a media- The fingerprint attribute may be either a session-level or a media-
level SDP attribute. If it is a session-level attribute, it applies level SDP attribute. If it is a session-level attribute, it applies
to all TLS sessions for which no media-level fingerprint attribute is to all TLS sessions for which no media-level fingerprint attribute is
defined. defined.
5.1. Multiple Fingerprints 5.1. Multiple Fingerprints
Multiple SDP fingerprint attributes can be associated with an m- Multiple SDP fingerprint attributes can be associated with an 'm'
line. This can occur if multiple fingerprints have been calculated line. This can occur if multiple fingerprints have been calculated
for a certificate using different hash functions. It can also occur for a certificate using different hash functions. It can also occur
if one or more fingerprints associated with multiple certificates if one or more fingerprints associated with multiple certificates
have been calculated. This might be needed if multiple certificates have been calculated. This might be needed if multiple certificates
will be used for media associated with an m- line (e.g. if separate will be used for media associated with an 'm' line (e.g., if separate
certificates are used for RTP and RTCP), or where it is not known certificates are used for RTP and RTCP), or where it is not known
which certificate will be used when the fingerprints are exchanged. which certificate will be used when the fingerprints are exchanged.
In such cases, one or more fingerprints MUST be calculated for each In such cases, one or more fingerprints MUST be calculated for each
possible certificate. possible certificate.
An endpoint MUST, as a minimum, calculate a fingerprint using both An endpoint MUST, as a minimum, calculate a fingerprint using both
the 'SHA-256' hash function algorithm and the hash function used to the 'SHA-256' hash function algorithm and the hash function used to
generate the signature on the certificate for each possible generate the signature on the certificate for each possible
certificate. Including the hash from the signature algorithm ensures certificate. Including the hash from the signature algorithm ensures
interoperability with strict implementations of RFC 4572 [20]. interoperability with strict implementations of RFC 4572 [20].
Either of these fingerprints MAY be omitted if the endpoint includes Either of these fingerprints MAY be omitted if the endpoint includes
a hash with a stronger hash algorithm that it knows that the peer a hash with a stronger hash algorithm that it knows that the peer
supports, if it is known that the peer does not support the hash supports, if it is known that the peer does not support the hash
algorithm, or if local policy mandates use of stronger algorithms. algorithm, or if local policy mandates use of stronger algorithms.
If fingerprints associated with multiple certificates are calculated, If fingerprints associated with multiple certificates are calculated,
the same set of hash functions MUST be used to calculate fingerprints the same set of hash functions MUST be used to calculate fingerprints
for each certificate associated with the m- line. for each certificate associated with the 'm' line.
An endpoint MUST select the set of fingerprints which use its most An endpoint MUST select the set of fingerprints which use its most
preferred hash function (out of those offered by the peer) and verify preferred hash function (out of those offered by the peer) and verify
that each used certificate matches one fingerprint out of that set. that each certificate used matches one fingerprint out of that set.
If a certificate does not match any such fingerprint, the endpoint If a certificate does not match any such fingerprint, the endpoint
MUST NOT establish the TLS connection MUST NOT establish the TLS connection
An endpoint MAY, in addition to its more preferred hash function, An endpoint MAY, in addition to its more preferred hash function,
also verify that each used certificate matches fingerprints also verify that each certificate used matches fingerprints
calculated using other hash functions. Unless there is a matching calculated using other hash functions. Unless there is a matching
fingerprint for each tested hash function, the endpoint MUST NOT fingerprint for each tested hash function, the endpoint MUST NOT
establish the TLS connection. establish the TLS connection.
NOTE: The SDP fingerprint attribute does not contain a reference to a NOTE: The SDP fingerprint attribute does not contain a reference to a
specific certificate. Endpoints need to compare the fingerprint with specific certificate. Endpoints need to compare the fingerprint with
a certificate hash in order to look for a match. a certificate hash in order to look for a match.
6. Endpoint Identification 6. Endpoint Identification
skipping to change at page 14, line 5 skipping to change at page 14, line 5
The SDP specification [8] states that specifications defining new The SDP specification [8] states that specifications defining new
proto values, like the 'TCP/TLS' proto value defined in this one, proto values, like the 'TCP/TLS' proto value defined in this one,
must define the rules by which their media format (fmt) namespace is must define the rules by which their media format (fmt) namespace is
managed. For the TCP/TLS protocol, new formats SHOULD have an managed. For the TCP/TLS protocol, new formats SHOULD have an
associated MIME registration. Use of an existing MIME subtype for associated MIME registration. Use of an existing MIME subtype for
the format is encouraged. If no MIME subtype exists, it is the format is encouraged. If no MIME subtype exists, it is
RECOMMENDED that a suitable one be registered through the IETF RECOMMENDED that a suitable one be registered through the IETF
process [12] by production of, or reference to, a standards-track RFC process [12] by production of, or reference to, a standards-track RFC
that defines the transport protocol for the format. that defines the transport protocol for the format.
This specification creates a new IANA registry named "Hash Function This specification takes over the IANA registry named "Hash Function
Textual Names". It will not be part of the SDP Parameters. Textual Names", that was created in [20]. It will not be part of the
SDP Parameters.
The names of hash functions used for certificate fingerprints are The names of hash functions used for certificate fingerprints are
registered by the IANA. Hash functions MUST be defined by standards- registered by the IANA. Hash functions MUST be defined by standards-
track RFCs that update or obsolete RFC 3279 [5]. track RFCs that update or obsolete RFC 3279 [5].
When registering a new hash function textual name, the following When registering a new hash function textual name, the following
information MUST be provided: information MUST be provided:
o The textual name of the hash function. o The textual name of the hash function.
skipping to change at page 17, line 33 skipping to change at page 17, line 33
[24] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [24] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>. <http://www.rfc-editor.org/info/rfc7616>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
This version of the document included significant contributions by This version of the document included significant contributions by
Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson. Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson.
Elwyn Davies performed the Gen-ART review of the document.
Authors' Addresses Authors' Addresses
Jonathan Lennox Jonathan Lennox
Vidyo Vidyo
Email: jonathan@vidyo.com Email: jonathan@vidyo.com
Christer Holmberg Christer Holmberg
Ericsson Ericsson
 End of changes. 13 change blocks. 
21 lines changed or deleted 24 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/