draft-ietf-mmusic-4572-update-10.txt   draft-ietf-mmusic-4572-update-11.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 9, 2017 January 5, 2017 Expires: July 16, 2017 January 12, 2017
Connection-Oriented Media Transport over TLS in SDP Connection-Oriented Media Transport over TLS in SDP
draft-ietf-mmusic-4572-update-10 draft-ietf-mmusic-4572-update-11
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 a
new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax new 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
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 9, 2017. This Internet-Draft will expire on July 16, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
1.1. Changes From RFC 4572 . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. SDP Operational Modes . . . . . . . . . . . . . . . . . . 4 3.1. SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 5
3.3. The Need for Self-Signed Certificates . . . . . . . . . . 5 3.3. The Need for Self-Signed Certificates . . . . . . . . . . 5
3.4. Example SDP Description for TLS Connection . . . . . . . 6 3.4. Example SDP Description for TLS Connection . . . . . . . 6
4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . 6
5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7 5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7
5.1. Multiple Fingerprints . . . . . . . . . . . . . . . . . . 8 5.1. Multiple Fingerprints . . . . . . . . . . . . . . . . . . 8
6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 9 6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 9
6.1. Certificate Choice . . . . . . . . . . . . . . . . . . . 9 6.1. Certificate Choice . . . . . . . . . . . . . . . . . . . 9
6.2. Certificate Presentation . . . . . . . . . . . . . . . . 10 6.2. Certificate Presentation . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 5 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 t TLS protocol allows applications to communicate over a channel that
provides confidentiality and data integrity. The TLS specification, provides confidentiality and data integrity. The TLS specification,
however, does not specify how specific protocols establish and use however, does not specify how specific protocols establish and use
this secure channel; particularly, TLS leaves the question of how to this secure channel; particularly, TLS leaves the question of how to
interpret and validate authentication certificates as an issue for interpret and validate authentication certificates as an issue for
the protocols that run over TLS. This document specifies such usage the protocols that run over TLS. This document specifies such usage
for the case of connection-oriented media transport. 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
skipping to change at page 3, line 42 skipping to change at page 3, line 44
The rest of this document is laid out as follows. An overview of the The rest of this document is laid out as follows. An overview of the
problem and threat model is given in Section 3. Section 4 gives the problem and threat model is given in Section 3. Section 4 gives the
basic mechanism for establishing TLS-based connected-oriented media basic mechanism for establishing TLS-based connected-oriented media
in SDP. Section 5 describes the SDP fingerprint attribute, which, in SDP. Section 5 describes the SDP fingerprint attribute, which,
assuming that the integrity of SDP content is assured, allows the assuming that the integrity of SDP content is assured, allows the
secure use of self-signed certificates. Section 6 describes which secure use of self-signed certificates. Section 6 describes which
X.509 certificates are presented, and how they are used in TLS. X.509 certificates are presented, and how they are used in TLS.
Section 7 discusses additional security considerations. Section 7 discusses additional security considerations.
This document obsoletes [21] but remains backwards compatible with 1.1. Changes From RFC 4572
older implementations. The changes from [21] are that it clarified
that multiple 'fingerprint' attributes can be used to carry This document obsoletes RFC 4572 [20] but remains backwards
fingerprints, calculated using different hash functions, associated compatible with older implementations. The changes from [20] are
with a given certificate, and to carry fingerprints associated with that it clarifies that multiple 'fingerprint' attributes can be used
multiple certificates. The fingerprint matching procedure, when to carry fingerprints, calculated using different hash functions,
multiple fingerprints are provided, are also clarified. The document associated with a given certificate, and to carry fingerprints
also updates the preferred cipher suite with a stronger cipher suite, associated with multiple certificates. The fingerprint matching
and removes the requirement to use the same hash function for procedure, when multiple fingerprints are provided, are also
calculating a certificate fingerprint and certificate signature. clarified. The document also updates the preferred hash function
with a stronger cipher suite, and removes the requirement to use the
same hash function for calculating a certificate fingerprint and
certificate signature.
2. Terminology 2. Terminology
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 RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
3. Overview 3. Overview
This section discusses the threat model that motivates TLS transport This section discusses the threat model that motivates TLS transport
skipping to change at page 5, line 30 skipping to change at page 5, line 41
(most commonly, a mutually-trusted certification authority) to (most commonly, a mutually-trusted certification authority) to
validate certificates, and the endpoints know what certificate validate certificates, and the endpoints know what certificate
identity to expect, endpoints can be certain that such an attack has identity to expect, endpoints can be certain that such an attack has
not taken place. not taken place.
Finally, the most serious type of attacker is one who can modify or Finally, the most serious type of attacker is one who can modify or
redirect session descriptions: for example, a compromised or redirect session descriptions: for example, a compromised or
malicious SIP proxy server. Neither TLS itself nor any mechanisms malicious SIP proxy server. Neither TLS itself nor any mechanisms
that use it can protect an SDP session against such an attacker. that use it can protect an SDP session against such an attacker.
Instead, the SDP description itself must be secured through some Instead, the SDP description itself must be secured through some
mechanism; SIP, for example, defines how S/MIME [23] can be used to mechanism; SIP, for example, defines how S/MIME [22] can be used to
secure session descriptions. secure session descriptions.
3.3. The Need for Self-Signed Certificates 3.3. The Need for Self-Signed Certificates
SDP session descriptions are created by any endpoint that needs to SDP session descriptions are created by any endpoint that needs to
participate in a multimedia session. In many cases, such as SIP participate in a multimedia session. In many cases, such as SIP
phones, such endpoints have dynamically-configured IP addresses and phones, such endpoints have dynamically-configured IP addresses and
host names and must be deployed with nearly zero configuration. For host names and must be deployed with nearly zero configuration. For
such an endpoint, it is for practical purposes impossible to obtain a such an endpoint, it is for practical purposes impossible to obtain a
certificate signed by a well-known certification authority. certificate signed by a well-known certification authority.
skipping to change at page 6, line 21 skipping to change at page 6, line 31
the first one in RFC 4145 [7], except for the proto parameter and the the first one in RFC 4145 [7], except for the proto parameter and the
fingerprint attribute.) See the subsequent sections for explanations fingerprint attribute.) See the subsequent sections for explanations
of the example's TLS-specific attributes. of the example's TLS-specific attributes.
(Note: due to RFC formatting conventions, this document splits SDP (Note: due to RFC formatting conventions, this document splits SDP
across lines whose content would exceed 72 characters. A backslash across lines whose content would exceed 72 characters. A backslash
character marks where this line folding has taken place. This character marks where this line folding has taken place. This
backslash and its trailing CRLF and whitespace would not appear in backslash and its trailing CRLF and whitespace would not appear in
actual SDP content.) actual SDP content.)
m=image 54111 TCP/TLS t38 m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2 c=IN IP4 192.0.2.2
a=setup:passive a=setup:passive
a=connection:new a=connection:new
a=fingerprint:SHA-1 \ a=fingerprint:SHA-256 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \
3E:5D:49:6B:19:E5:7C:AB:4A:AD
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
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.
skipping to change at page 7, line 35 skipping to change at page 7, line 44
Internet Explorer display them when viewing the details of a Internet Explorer display them when viewing the details of a
certificate.) certificate.)
A fingerprint is represented in SDP as an attribute (an 'a' line). A fingerprint is represented in SDP as an attribute (an 'a' line).
It consists of the name of the hash function used, followed by the It consists of the name of the hash function used, followed by the
hash value itself. The hash value is represented as a sequence of hash value itself. The hash value is represented as a sequence of
uppercase hexadecimal bytes, separated by colons. The number of uppercase hexadecimal bytes, separated by colons. The number of
bytes is defined by the hash function. (This is the syntax used by bytes is defined by the hash function. (This is the syntax used by
openssl and by the browsers' certificate managers. It is different openssl and by the browsers' certificate managers. It is different
from the syntax used to represent hash values in, e.g., HTTP digest from the syntax used to represent hash values in, e.g., HTTP digest
authentication [25], which uses unseparated lowercase hexadecimal authentication [24], which uses unseparated lowercase hexadecimal
bytes. It was felt that consistency with other applications of bytes. It was felt that consistency with other applications of
fingerprints was more important.) fingerprints was more important.)
The formal syntax of the fingerprint attribute is given in Augmented The formal syntax of the fingerprint attribute is given in Augmented
Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax
of SDP [8]. of SDP [8].
attribute =/ fingerprint-attribute attribute =/ fingerprint-attribute
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
skipping to change at page 8, line 25 skipping to change at page 8, line 25
fingerprint = 2UHEX *(":" 2UHEX) fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated ; Each byte in upper-case hex, separated
; by colons. ; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercase UHEX = DIGIT / %x41-46 ; A-F uppercase
Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
Following RFC 3279 [5] as updated by RFC 4055 [6], therefore, the Following RFC 3279 [5] as updated by RFC 4055 [6], therefore, the
defined hash functions are 'SHA-1' [1] [16], 'SHA-224' [1], 'SHA-256' defined hash functions are 'SHA-1' [1] [16], 'SHA-224' [1], 'SHA-256'
[1], 'SHA-384'[1], 'SHA-512' [1], 'MD5' [13] and 'MD2' [24], with [1], 'SHA-384'[1], 'SHA-512' [1], 'MD5' [13] and 'MD2' [23], with
'SHA-256' preferred. A new IANA registry of Hash Function Textual 'SHA-256' preferred. A new IANA registry of Hash Function Textual
Names, specified in Section 8, allows for addition of future tokens, Names, specified in Section 8, allows for addition of future tokens,
but they may only be added if they are included in RFCs that update but they may only be added if they are included in RFCs that update
or obsolete RFC 3279 [5]. or obsolete RFC 3279 [5].
For backward compatibility with implementations compliant with RFC Implementations compliant to this specification MUST NOT use the MD2
4572 [21], the MD2 and MD5 cipher suites are still listed in the and MD5 hash functions to calculate fingerprints, or to verify
syntax. However, implementations compliant to this specification received fingerprints that have been calculated using them.
MUST NOT use them.
NOTE: The MD2 and MD5 hash functions are listed in this specification
so that implementations can recognize them. Implementations that log
unused hash functions might log occurrences of these 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
skipping to change at page 9, line 9 skipping to change at page 9, line 13
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 [21]. 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.
For each used certificate, an endpoint MUST be able to match at least An endpoint MUST select the set of fingerprints which use its most
one fingerprint, calculated using the hash function that the endpoint preferred hash function (out of those offered by the peer) and verify
supports and considers most secure, with the used certificate. If that each used certificate matches one fingerprint out of that set.
the checked fingerprint does not match the used certificate, the If a certificate does not match any such fingerprint, the endpoint
endpoint MUST NOT establish the TLS connection. In addition, the MUST NOT establish the TLS connection
endpoint MAY also check fingerprints calculated using other hash
functions that it has received for a match. For each hash function An endpoint MAY, in addition to its more preferred hash function,
checked, one of the received fingerprints calculated using the hash also verify that each used certificate matches fingerprints
function MUST match the used certificate. calculated using other hash functions. Unless there is a matching
fingerprint for each tested hash function, the endpoint MUST NOT
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
6.1. Certificate Choice 6.1. Certificate Choice
An X.509 certificate binds an identity and a public key. If SDP An X.509 certificate binds an identity and a public key. If SDP
describing a TLS session is transmitted over a mechanism that describing a TLS session is transmitted over a mechanism that
provides integrity protection, a certificate asserting any provides integrity protection, a certificate asserting any
syntactically valid identity MAY be used. For example, an SDP syntactically valid identity MAY be used. For example, an SDP
description sent over HTTP/TLS [14] or secured by S/MIME [23] MAY description sent over HTTP/TLS [14] or secured by S/MIME [22] MAY
assert any identity in the certificate securing the media connection. assert any identity in the certificate securing the media connection.
Security protocols that provide only hop-by-hop integrity protection Security protocols that provide only hop-by-hop integrity protection
(e.g., the sips protocol [17], SIP over TLS) are considered (e.g., the sips protocol [17], SIP over TLS) are considered
sufficiently secure to allow the mode in which any valid identity is sufficiently secure to allow the mode in which any valid identity is
accepted. However, see Section 7 for a discussion of some security accepted. However, see Section 7 for a discussion of some security
implications of this fact. implications of this fact.
In situations where the SDP is not integrity-protected, however, the In situations where the SDP is not integrity-protected, however, the
certificate provided for a TLS connection MUST certify an appropriate certificate provided for a TLS connection MUST certify an appropriate
skipping to change at page 10, line 48 skipping to change at page 11, line 9
the 'setup:passive' role, in the terminology of connection-oriented the 'setup:passive' role, in the terminology of connection-oriented
media) MUST present a certificate during TLS initiation, following media) MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, the client endpoint MUST terminate match the original fingerprint, the client endpoint MUST terminate
the media connection with a bad_certificate error. the media connection with a bad_certificate error.
If the SDP offer/answer model [4] is being used, the client (the If the SDP offer/answer model [4] is being used, the client (the
endpoint with the 'setup:active' role) MUST also present a endpoint with the 'setup:active' role) MUST also present a
certificate following the rules of Section 6.1. The server MUST certificate following the rules of Section 6.1. The server MUST
request a certificate, and if the client does not provide one, or if request a certificate, and if the client does not provide one, or if
the certificate does not match the provided fingerprint, the server the certificate does not match a provided fingerprint, the server
endpoint MUST terminate the media connection with a bad_certificate endpoint MUST terminate the media connection with a bad_certificate
error. error.
Note that when the offer/answer model is being used, it is possible Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer. for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [7]) begin listening for an role, it MUST (as specified in RFC 4145 [7]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If until it has received a matching fingerprint in an SDP answer. If
skipping to change at page 12, line 9 skipping to change at page 12, line 17
However, such integrity protection is not always possible. For these However, such integrity protection is not always possible. For these
cases, end systems SHOULD maintain a cache of certificates that other cases, end systems SHOULD maintain a cache of certificates that other
parties have previously presented using this mechanism. If possible, parties have previously presented using this mechanism. If possible,
users SHOULD be notified when an unsecured certificate associated users SHOULD be notified when an unsecured certificate associated
with a previously unknown end system is presented and SHOULD be with a previously unknown end system is presented and SHOULD be
strongly warned if a different unsecured certificate is presented by strongly warned if a different unsecured certificate is presented by
a party with which they have communicated in the past. In this way, a party with which they have communicated in the past. In this way,
even in the absence of integrity protection for SDP, the security of even in the absence of integrity protection for SDP, the security of
this document's mechanism is equivalent to that of the Secure Shell this document's mechanism is equivalent to that of the Secure Shell
(ssh) protocol [19], which is vulnerable to man-in-the-middle attacks (ssh) protocol [18], which is vulnerable to man-in-the-middle attacks
when two parties first communicate, but can detect ones that occur when two parties first communicate, but can detect ones that occur
subsequently. (Note that a precise definition of the "other party" subsequently. (Note that a precise definition of the "other party"
depends on the application protocol carrying the SDP message.) Users depends on the application protocol carrying the SDP message.) Users
SHOULD NOT, however, in any circumstances be notified about SHOULD NOT, however, in any circumstances be notified about
certificates described in SDP descriptions sent over an integrity- certificates described in SDP descriptions sent over an integrity-
protected channel. protected channel.
To aid interoperability and deployment, security protocols that To aid interoperability and deployment, security protocols that
provide only hop-by-hop integrity protection (e.g., the sips protocol provide only hop-by-hop integrity protection (e.g., the sips protocol
[17], SIP over TLS) are considered sufficiently secure to allow the [17], SIP over TLS) are considered sufficiently secure to allow the
skipping to change at page 12, line 35 skipping to change at page 12, line 43
SIP proxy servers. End systems MAY warn users about SDP sessions SIP proxy servers. End systems MAY warn users about SDP sessions
that are secured in only a hop-by-hop manner, and definitions of that are secured in only a hop-by-hop manner, and definitions of
media formats running over TCP/TLS MAY specify that only end-to-end media formats running over TCP/TLS MAY specify that only end-to-end
integrity mechanisms be used. integrity mechanisms be used.
Depending on how SDP messages are transmitted, it is not always Depending on how SDP messages are transmitted, it is not always
possible to determine whether or not a subjectAltName presented in a possible to determine whether or not a subjectAltName presented in a
remote certificate is expected for the remote party. In particular, remote certificate is expected for the remote party. In particular,
given call forwarding, third-party call control, or session given call forwarding, third-party call control, or session
descriptions generated by endpoints controlled by the Gateway Control descriptions generated by endpoints controlled by the Gateway Control
Protocol [22], it is not always possible in SIP to determine what Protocol [21], it is not always possible in SIP to determine what
entity ought to have generated a remote SDP response. In general, entity ought to have generated a remote SDP response. In general,
when not using authenticity and integrity protection of SDP when not using authenticity and integrity protection of SDP
descriptions, a certificate transmitted over SIP SHOULD assert the descriptions, a certificate transmitted over SIP SHOULD assert the
endpoint's SIP Address of Record as a uniformResourceIndicator endpoint's SIP Address of Record as a uniformResourceIndicator
subjectAltName. When an endpoint receives a certificate over SIP subjectAltName. When an endpoint receives a certificate over SIP
asserting an identity (including an iPAddress or dNSName identity) asserting an identity (including an iPAddress or dNSName identity)
other than the one to which it placed or received the call, it SHOULD other than the one to which it placed or received the call, it SHOULD
alert the user and ask for confirmation. This applies whether alert the user and ask for confirmation. This applies whether
certificates are self-signed, or signed by certification authorities; certificates are self-signed, or signed by certification authorities;
a certificate for "sip:bob@example.com" may be legitimately signed by a certificate for "sip:bob@example.com" may be legitimately signed by
a certification authority, but may still not be acceptable for a call a certification authority, but may still not be acceptable for a call
to "sip:alice@example.com". (This issue is not one specific to this to "sip:alice@example.com". (This issue is not one specific to this
specification; the same consideration applies for S/MIME-signed SDP specification; the same consideration applies for S/MIME-signed SDP
carried over SIP.) carried over SIP.)
This document does not define any mechanism for securely transporting
This document does not define a mechanism for securely transporting
RTP and RTP Control Protocol (RTCP) packets over a connection- RTP and RTP Control Protocol (RTCP) packets over a connection-
oriented channel. There was no consensus in the working group as to oriented channel. Please see RFC 7850 [19] for more details.
whether it would be better to send Secure RTP packets [18] over a
connection-oriented transport [20], or whether it would be better to
send standard unsecured RTP packets over TLS using the mechanisms
described in this document. The group consensus was to wait until a
use-case requiring secure connection-oriented RTP was presented.
TLS is not always the most appropriate choice for secure connection- TLS is not always the most appropriate choice for secure connection-
oriented media; in some cases, a higher- or lower-level security oriented media; in some cases, a higher- or lower-level security
protocol may be appropriate. protocol may be appropriate.
This document improves security from the RFC 4572 [21]. It updates This document improves security from the RFC 4572 [20]. It updates
the preferred hash function cipher suite from SHA-1 to SHA-256, and the preferred hash function from SHA-1 to SHA-256, and deprecates the
deprecates the usage of the MD2 and MD5 cipher suites. usage of the MD2 and MD5 hash functions.
By clarifying the usage and handling of multiple fingerprints, the By clarifying the usage and handling of multiple fingerprints, the
document also enables hash agility, and incremental deployment of document also enables hash agility, and incremental deployment of
newer, and more secure, cipher suites. newer, and more secure, hash functions.
8. IANA Considerations 8. IANA Considerations
Note to IANA. No IANA considerations are changed from RFC4572 [21] Note to IANA. No IANA considerations are changed from RFC4572 [20]
so the only actions required are to update the registries to point at so the only actions required are to update the registries to point at
this specification. this specification.
This document defines an SDP proto value: 'TCP/TLS'. Its format is This document defines an SDP proto value: 'TCP/TLS'. Its format is
defined in Section 4. This proto value has been registered by IANA defined in Section 4. This proto value has been registered by IANA
under "Session Description Protocol (SDP) Parameters" under "proto". under "Session Description Protocol (SDP) Parameters" under "proto".
This document defines an SDP session and media-level attribute: This document defines an SDP session and media-level attribute:
'fingerprint'. Its format is defined in Section 5. This attribute 'fingerprint'. Its format is defined in Section 5. This attribute
has been registered by IANA under "Session Description Protocol (SDP) has been registered by IANA under "Session Description Protocol (SDP)
skipping to change at page 16, line 34 skipping to change at page 16, line 40
[16] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 [16] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001, (SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<http://www.rfc-editor.org/info/rfc3174>. <http://www.rfc-editor.org/info/rfc3174>.
[17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[18] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [18] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[19] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <http://www.rfc-editor.org/info/rfc4251>. January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[20] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [19] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
2006, <http://www.rfc-editor.org/info/rfc4571>. 2006, <http://www.rfc-editor.org/info/rfc4571>.
[21] Lennox, J., "Connection-Oriented Media Transport over the [20] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, Description Protocol (SDP)", RFC 4572,
DOI 10.17487/RFC4572, July 2006, DOI 10.17487/RFC4572, July 2006,
<http://www.rfc-editor.org/info/rfc4572>. <http://www.rfc-editor.org/info/rfc4572>.
[22] Taylor, T., "Reclassification of RFC 3525 to Historic", [21] Taylor, T., "Reclassification of RFC 3525 to Historic",
RFC 5125, DOI 10.17487/RFC5125, February 2008, RFC 5125, DOI 10.17487/RFC5125, February 2008,
<http://www.rfc-editor.org/info/rfc5125>. <http://www.rfc-editor.org/info/rfc5125>.
[23] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [22] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>. 2010, <http://www.rfc-editor.org/info/rfc5751>.
[24] Turner, S. and L. Chen, "MD2 to Historic Status", [23] Turner, S. and L. Chen, "MD2 to Historic Status",
RFC 6149, DOI 10.17487/RFC6149, March 2011, RFC 6149, DOI 10.17487/RFC6149, March 2011,
<http://www.rfc-editor.org/info/rfc6149>. <http://www.rfc-editor.org/info/rfc6149>.
[25] 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.
Authors' Addresses Authors' Addresses
 End of changes. 30 change blocks. 
66 lines changed or deleted 70 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/