draft-ietf-mmusic-4572-update-07.txt   draft-ietf-mmusic-4572-update-08.txt 
Network Working Group C. Holmberg Network Working Group J. Lennox
Internet-Draft Ericsson Internet-Draft Vidyo
Updates: 4572 (if approved) September 25, 2016 Obsoletes: 4572 (if approved) C. Holmberg
Intended status: Standards Track Intended status: Standards Track Ericsson
Expires: March 29, 2017 Expires: May 7, 2017 November 3, 2016
SDP Fingerprint Attribute Usage Clarifications Connection-Oriented Media Transport over TLS in SDP
draft-ietf-mmusic-4572-update-07.txt draft-ietf-mmusic-4572-update-08
Abstract Abstract
This document updates RFC 4572 by clarifying the usage of multiple This document specifies how to establish secure connection-oriented
SDP 'fingerprint' attributes with a single SDP media description ("m= media transport sessions over the Transport Layer Security (TLS)
line"). The document also updates the preferred cipher suite with a protocol using the Session Description Protocol (SDP). It defines a
stronger cipher suite. new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax
and semantics for an SDP 'fingerprint' attribute that identifies the
certificate that will be presented for the TLS session. This
mechanism allows media transport over TLS connections to be
established securely, so long as the integrity of session
descriptions is assured.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 29, 2017. This Internet-Draft will expire on May 7, 2017.
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
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
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Update to RFC 4572 . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Update to the sixth paragraph of section 5 . . . . . . . 3 3.1. SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
3.2. New paragraphs to the end of section 5 . . . . . . . . . 4 3.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3.3. The Need for Self-Signed Certificates . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 3.4. Example SDP Description for TLS Connection . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . 6
7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7 5.1. Multiple Fingerprints . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 9
6.1. Certificate Choice . . . . . . . . . . . . . . . . . . . 9
6.2. Certificate Presentation . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
RFC 4572 [RFC4572] specifies how to establish Transport Layer The Session Description Protocol (SDP) [14] provides a general-
Security (TLS) connections using the Session Description Protocol purpose format for describing multimedia sessions in announcements or
(SDP) [RFC4566]. invitations. For many applications, it is desirable to establish, as
part of a multimedia session, a media stream that uses a connection-
oriented transport. RFC 4145, Connection-Oriented Media Transport in
the Session Description Protocol (SDP) [10], specifies a general
mechanism for describing and establishing such connection-oriented
streams; however, the only transport protocol it directly supports is
TCP. In many cases, session participants wish to provide
confidentiality, data integrity, and authentication for their media
sessions. This document therefore extends the Connection-Oriented
Media specification to allow session descriptions to describe media
sessions that use the Transport Layer Security (TLS) protocol [13].
RFC 4572 defines the SDP 'fingerprint' attribute, which is used to TLS protocol allows applications to communicate over a channel t
carry a secure hash value (fingerprint) associated with a provides confidentiality and data integrity. The TLS specification,
certificate. However, RFC 4572 is currently unclear on whether however, does not specify how specific protocols establish and use
multiple 'fingerprint' attributes can be associated with a single SDP this secure channel; particularly, TLS leaves the question of how to
media description ("m= line") [RFC4566], and the associated interpret and validate authentication certificates as an issue for
semantics. Multiple fingerprints are needed if an endpoints wants to the protocols that run over TLS. This document specifies such usage
provide fingerprints associated with multiple certificates. For for the case of connection-oriented media transport.
example, with RTP-based media, an endpoint might use different
certificates for RTP and RTCP.
RFC 4572 also specifies a preferred cipher suite. However, the Complicating this issue, endpoints exchanging media will often be
currently preferred cipher suite is considered outdated, and the unable to obtain authentication certificates signed by a well-known
preference needs to be updated. root certification authority (CA). Most certificate authorities
charge for signed certificates, particularly host-based certificates;
additionally, there is a substantial administrative overhead to
obtaining signed certificates, as certification authorities must be
able to confirm that they are issuing the signed certificates to the
correct party. Furthermore, in many cases endpoints' IP addresses
and host names are dynamic: they may be obtained from DHCP, for
example. It is impractical to obtain a CA-signed certificate valid
for the duration of a DHCP lease. For such hosts, self-signed
certificates are usually the only option. This specification defines
a mechanism that allows self-signed certificates can be used
securely, provided that the integrity of the SDP description is
assured. It provides for endpoints to include a secure hash of their
certificate, known as the "certificate fingerprint", within the
session description. Provided that the fingerprint of the offered
certificate matches the one in the session description, end hosts can
trust even self-signed certificates.
RFC 4572 mandates that the hash function used to calculate the The rest of this document is laid out as follows. An overview of the
fingerprint is the same hash function used to calculate the problem and threat model is given in Section 3. Section 4 gives the
certificate signature. That requirement might prevent usage of basic mechanism for establishing TLS-based connected-oriented media
newer, stronger and more collision-safe hash functions for in SDP. Section 5 describes the SDP fingerprint attribute, which,
calculating certificate fingerprints. This change also requires that assuming that the integrity of SDP content is assured, allows the
multiple 'fingerprint' attributes can be associated with a single secure use of self-signed certificates. Section 6 describes which
"m=" line, so that implementations are able to provide fingerprints X.509 certificates are presented, and how they are used in TLS.
calculated using updated hash functions alongside those that are Section 7 discusses additional security considerations.
needed to interoperate with existing implementations.
This document updates RFC 4572 [RFC4572] by clarifying the usage of This document obsoletes [25] but remains backwards compatible with
multiple SDP 'fingerprint' attributes. It is clarified that multiple older implementations. The changes from [25] are that it clarified
'fingerprint' attributes can be used to carry fingerprints, that multiple 'fingerprint' attributes can be used to carry
calculated using different hash functions, associated with a given fingerprints, calculated using different hash functions, associated
certificate, and to carry fingerprints associated with multiple with a given certificate, and to carry fingerprints associated with
certificates. The fingerprint matching procedure, when multiple multiple certificates. The fingerprint matching procedure, when
fingerprints are provided, are also clarified. The document also multiple fingerprints are provided, are also clarified. The document
updates the preferred cipher suite with a stronger cipher suite, and also updates the preferred cipher suite with a stronger cipher suite,
removes the requirement to use the same hash function for calculating and removes the requirement to use the same hash function for
a certificate fingerprint and certificate signature. calculating a certificate fingerprint and certificate signature.
NOTE: Even though this document updates the procedures in RFC 4572, 2. Terminology
it does not make existing implementations non-compliant with RFC
4572. The updated procedures in this document have been defined in
order to be backward compatible with the procedures in RFC 4572.
2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] and
indicate requirement levels for compliant implementations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 3. Overview
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Update to RFC 4572 This section discusses the threat model that motivates TLS transport
for connection-oriented media streams. It also discusses in more
detail the need for end systems to use self-signed certificates.
This section updates section 5 of RFC 4572. 3.1. SDP Operational Modes
3.1. Update to the sixth paragraph of section 5 There are two principal operational modes for multimedia sessions:
OLD TEXT: advertised and offer-answer. Advertised sessions are the simpler
mode. In this mode, a server publishes, in some manner, an SDP
session description of a multimedia session it is making available.
The classic example of this mode of operation is the Session
Announcement Protocol (SAP) [17], in which SDP session descriptions
are periodically transmitted to a well-known multicast group.
Traditionally, these descriptions involve multicast conferences, but
unicast sessions are also possible. (Connection-oriented media,
obviously, cannot use multicast.) Recipients of a session
description connect to the addresses published in the session
description. These recipients may not previously have been known to
the advertiser of the session description.
A certificate fingerprint MUST be computed using the same one-way Alternatively, SDP conferences can operate in offer-answer mode [6].
hash function as is used in the certificate's signature algorithm. This mode allows two participants in a multimedia session to
(This ensures that the security properties required for the negotiate the multimedia session between them. In this model, one
certificate also apply for the fingerprint. It also guarantees that participant offers the other a description of the desired session
the fingerprint will be usable by the other endpoint, so long as the from its perspective, and the other participant answers with the
certificate itself is.) Following RFC 3279 [7] as updated by RFC desired session from its own perspective. In this mode, each of the
4055 [9], therefore, the defined hash functions are 'SHA-1' [11] participants in the session has knowledge of the other one. This is
[19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11] the mode of operation used by the Session Initiation Protocol (SIP)
, 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA [19].
registry of Hash Function Textual 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 or obsolete RFC 3279 [7].
Self-signed certificates (for which legacy certificates are not a
consideration) MUST use one of the FIPS 180 algorithms (SHA-1,
SHA-224, SHA-256, SHA-384, or SHA-512) as their signature algorithm,
and thus also MUST use it to calculate certificate fingerprints.
NEW TEXT: 3.2. Threat Model
Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the Participants in multimedia conferences often wish to guarantee
defined hash functions are 'SHA-1' [11] [19], 'SHA-224' [11], confidentiality, data integrity, and authentication for their media
'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11], 'MD5' [12], and sessions. This section describes various types of attackers and the
'MD2' [13], with 'SHA-256' preferred. A new IANA registry of Hash ways they attempt to violate these guarantees. It then describes how
Function Textual Names, specified in Section 8, allows for addition the TLS protocol can be used to thwart the attackers.
of future tokens, but they may only be added if they are included
in RFCs that update or obsolete RFC 3279 [7].
3.2. New paragraphs to the end of section 5 The simplest type of attacker is one who listens passively to the
NEW TEXT: traffic associated with a multimedia session. This attacker might,
for example, be on the same local-area or wireless network as one of
the participants in a conference. This sort of attacker does not
threaten a connection's data integrity or authentication, and almost
any operational mode of TLS can provide media stream confidentiality.
Multiple SDP fingerprint attributes can be associated with an m- More sophisticated is an attacker who can send his own data traffic
line. This can occur if multiple fingerprints have been calculated over the network, but who cannot modify or redirect valid traffic.
for a certificate using different hash functions. It can also In SDP's 'advertised' operational mode, this can barely be considered
occur if one or more fingerprints associated with multiple an attack; media sessions are expected to be initiated from anywhere
certificates have been calculated. This might be needed if multiple on the network. In SDP's offer-answer mode, however, this type of
certificates will be used for media associated with an m- line attack is more serious. An attacker could initiate a connection to
(e.g. if separate certificates are used for RTP and RTCP), or where one or both of the endpoints of a session, thus impersonating an
it is not known which certificate will be used when the endpoint, or acting as a man in the middle to listen in on their
fingerprints are exchanged. In such cases, one or more fingerprints communications. To thwart these attacks, TLS uses endpoint
MUST be calculated for each possible certificate. An endpoint certificates. So long as the certificates' private keys have not
MUST, as a minimum, calculate a fingerprint using both the 'SHA-256' been compromised, the endpoints have an external trusted mechanism
hash function algorithm and the hash function used to generate the (most commonly, a mutually-trusted certification authority) to
signature on the certificate for each possible certificate. validate certificates, and the endpoints know what certificate
Including the hash from the signature algorithm ensures identity to expect, endpoints can be certain that such an attack has
interoperability with strict implementations of RFC 4572. not taken place.
Either of these fingerprints MAY be omitted if the endpoint includes
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
algorithm, or if local policy mandates use of stronger algorithms.
If fingerprints associated with multiple certificates are Finally, the most serious type of attacker is one who can modify or
calculated, the same set of hash functions MUST be used to redirect session descriptions: for example, a compromised or
calculate fingerprints for each certificate associated with the malicious SIP proxy server. Neither TLS itself nor any mechanisms
m- line. that use it can protect an SDP session against such an attacker.
Instead, the SDP description itself must be secured through some
mechanism; SIP, for example, defines how S/MIME [22] can be used to
secure session descriptions.
For each used certificate, an endpoint MUST be able to match at 3.3. The Need for Self-Signed Certificates
least one fingerprint, calculated using the hash function that the
endpoint supports and considers most secure, with the used
certificate. If the checked fingerprint does not match the used
certificate, the endpoint MUST NOT establish the TLS connection. In
addition, the endpoint MAY also check fingerprints calculated using
other hash functions that it has received for a match. For each
hash function checked, one of the received fingerprints calculated
using the hash function MUST match the used certificate.
NOTE: The SDP fingerprint attribute does not contain a reference to SDP session descriptions are created by any endpoint that needs to
a specific certificate. Endpoints need to compare the fingerprint participate in a multimedia session. In many cases, such as SIP
with a certificate hash in order to look for a match. phones, such endpoints have dynamically-configured IP addresses and
host names and must be deployed with nearly zero configuration. For
such an endpoint, it is for practical purposes impossible to obtain a
certificate signed by a well-known certification authority.
4. Security Considerations If two endpoints have no prior relationship, self-signed certificates
cannot generally be trusted, as there is no guarantee that an
attacker is not launching a man-in-the-middle attack. Fortunately,
however, if the integrity of SDP session descriptions can be assured,
it is possible to consider those SDP descriptions themselves as a
prior relationship: certificates can be securely described in the
session description itself. This is done by providing a secure hash
of a certificate, or "certificate fingerprint", as an SDP attribute;
this mechanism is described in Section 5.
This document improves security. It updates the preferred hash 3.4. Example SDP Description for TLS Connection
function cipher suite from SHA-1 to SHA-256. By clarifying the usage
and handling of multiple fingerprints, the document also enables hash
agility, and incremental deployment of newer, and more secure, cipher
suites.
5. IANA Considerations Figure 1 illustrates an SDP offer that signals the availability of a
T.38 fax session over TLS. For the purpose of brevity, the main
portion of the session description is omitted in the example, showing
only the 'm' line and its attributes. (This example is the same as
the first one in RFC 4145 [10], except for the proto parameter and
the fingerprint attribute.) See the subsequent sections for
explanations of the example's TLS-specific attributes.
IANA is requested to add a reference to this document for the att- (Note: due to RFC formatting conventions, this document splits SDP
field (both session and media level) registration "fingerprint" in across lines whose content would exceed 72 characters. A backslash
Session Description Protocol (SDP) Parameters registry. character marks where this line folding has taken place. This
backslash and its trailing CRLF and whitespace would not appear in
actual SDP content.)
6. Acknowledgements m=image 54111 TCP/TLS t38
c=IN IP4 192.0.2.2
a=setup:passive
a=connection:new
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Martin Thomson, Paul Kyzivat, Jonathan Lennox and Roman Shpount Figure 1: Example SDP Description Offering a TLS Media Stream
provided valuable comments and input on this document.
7. Change Log 4. Protocol Identifiers
[RFC EDITOR NOTE: Please remove this section when publishing] The 'm' line in SDP specifies, among other items, the transport
protocol to be used for the media in the session. See the "Media
Descriptions" section of SDP [14] for a discussion on transport
protocol identifiers.
Changes from draft-ietf-mmusic-4572-update-05 This specification defines a new protocol identifier, 'TCP/TLS',
which indicates that the media described will use the Transport Layer
Security protocol [13] over TCP. (Using TLS over other transport
protocols is not discussed in this document.) The 'TCP/TLS' protocol
identifier describes only the transport protocol, not the upper-layer
protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify
the protocol using a fmt identifier to indicate the application being
run over TLS.
o Change of document title. Media sessions described with this identifier follow the procedures
defined in RFC 4145 [10]. They also use the SDP attributes defined
in that specification, 'setup' and 'connection'.
Changes from draft-ietf-mmusic-4572-update-05 5. Fingerprint Attribute
o Added a requirement to generate a fingerprint that matches the Parties to a TLS session indicate their identities by presenting
signature. authentication certificates as part of the TLS handshake procedure.
Authentication certificates are X.509 [2] certificates, as profiled
by RFC 3279 [7], RFC 3280 [8], and RFC 4055 [9].
o Added text clarifying that updates do not make existing In order to associate media streams with connections and to prevent
implementations non-compliant with RFC 4572. unauthorized barge-in attacks on the media streams, endpoints MUST
provide a certificate fingerprint. If the X.509 certificate
presented for the TLS connection matches the fingerprint presented in
the SDP, the endpoint can be confident that the author of the SDP is
indeed the initiator of the connection.
o IANA Considerations text added. A certificate fingerprint is a secure one-way hash of the DER
(distinguished encoding rules) form of the certificate. (Certificate
fingerprints are widely supported by tools that manipulate X.509
certificates; for instance, the command "openssl x509 -fingerprint"
causes the command-line tool of the openssl package to print a
certificate fingerprint, and the certificate managers for Mozilla and
Internet Explorer display them when viewing the details of a
certificate.)
Changes from draft-ietf-mmusic-4572-update-04 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
hash value itself. The hash value is represented as a sequence of
uppercase hexadecimal bytes, separated by colons. The number of
bytes is defined by the hash function. (This is the syntax used by
openssl and by the browsers' certificate managers. It is different
from the syntax used to represent hash values in, e.g., HTTP digest
authentication [15], which uses unseparated lowercase hexadecimal
bytes. It was felt that consistency with other applications of
fingerprints was more important.)
o Removed prevously added requirement that endpoint must calcuate at The formal syntax of the fingerprint attribute is given in Augmented
least one fingerprint using a hash function that was also used by Backus-Naur Form [11] in Figure 2. This syntax extends the BNF
the peer. syntax of SDP [14].
Changes from draft-ietf-mmusic-4572-update-03 attribute =/ fingerprint-attribute
o Mandatory (except in specific situations) to provide a fingerprint fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
calculated using SHA-256.
o When an endpoint receives fingerprints from its peer, the endpoint hash-func = "sha-1" / "sha-224" / "sha-256" /
must (except in specific situations) calculate at least one "sha-384" / "sha-512" /
fingerpint using a hash function that was also used by the peer. "md5" / "md2" / token
; Additional hash functions can only come
; from updates to RFC 3279
Changes from draft-ietf-mmusic-4572-update-02 fingerprint = 2UHEX *(":" 2UHEX)
o Editorial fixes based on comments from Martin Thomson. ; Each byte in upper-case hex, separated
; by colons.
o Non-used references removed. UHEX = DIGIT / %x41-46 ; A-F uppercase
Changes from draft-ietf-mmusic-4572-update-01 Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
o Changes based on comments from Martin Thomson. Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the
defined hash functions are 'SHA-1' [1] [18], 'SHA-224' [1], 'SHA-256'
[1], 'SHA-384'[1], 'SHA-512' [1], 'MD5' [4], and 'MD2' [3], with
'SHA-256' preferred. A new IANA registry of Hash Function Textual
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
or obsolete RFC 3279 [7].
o - Editorial fixes The fingerprint attribute may be either a session-level or a media-
level SDP attribute. If it is a session-level attribute, it applies
to all TLS sessions for which no media-level fingerprint attribute is
defined.
o Changes in handling of multiple fingerprints. 5.1. Multiple Fingerprints
o - Sender must send same set of hash functions for each offered Multiple SDP fingerprint attributes can be associated with an m-
certificate. line. This can occur if multiple fingerprints have been calculated
for a certificate using different hash functions. It can also occur
if one or more fingerprints associated with 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
certificates are used for RTP and RTCP), or where it is not known
which certificate will be used when the fingerprints are exchanged.
In such cases, one or more fingerprints MUST be calculated for each
possible certificate.
o - Receiver must check the hash function it considers most secure An endpoint MUST, as a minimum, calculate a fingerprint using both
for a match. It may check other hash functions. the 'SHA-256' hash function algorithm and the hash function used to
generate the signature on the certificate for each possible
certificate. Including the hash from the signature algorithm ensures
interoperability with strict implementations of RFC 4572 [25].
Either of these fingerprints MAY be omitted if the endpoint includes
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
algorithm, or if local policy mandates use of stronger algorithms.
Changes from draft-ietf-mmusic-4572-update-00 If fingerprints associated with multiple certificates are calculated,
the same set of hash functions MUST be used to calculate fingerprints
for each certificate associated with the m- line.
o Changes in handling of multiple fingerprints. For each used certificate, an endpoint MUST be able to match at least
one fingerprint, calculated using the hash function that the endpoint
supports and considers most secure, with the used certificate. If
the checked fingerprint does not match the used certificate, the
endpoint MUST NOT establish the TLS connection. In addition, the
endpoint MAY also check fingerprints calculated using other hash
functions that it has received for a match. For each hash function
checked, one of the received fingerprints calculated using the hash
function MUST match the used certificate.
o - Number of fingerprints calculated for each certificate does not NOTE: The SDP fingerprint attribute does not contain a reference to a
have to match. specific certificate. Endpoints need to compare the fingerprint with
a certificate hash in order to look for a match.
o - Clarified that receiver shall check check fingerprints using 6. Endpoint Identification
hash algorithms it considers safe.
o - Additional text added to security considerations section. 6.1. Certificate Choice
Changes from draft-holmberg-mmusic-4572-update-01 An X.509 certificate binds an identity and a public key. If SDP
describing a TLS session is transmitted over a mechanism that
provides integrity protection, a certificate asserting any
syntactically valid identity MAY be used. For example, an SDP
description sent over HTTP/TLS [16] or secured by S/MIME [22] MAY
assert any identity in the certificate securing the media connection.
o Adopted WG document (draft-ietf-mmusic-4572-update-00) submitted. Security protocols that provide only hop-by-hop integrity protection
(e.g., the sips protocol [19], SIP over TLS) are considered
sufficiently secure to allow the mode in which any valid identity is
accepted. However, see Section 7 for a discussion of some security
implications of this fact.
o IANA considerations section added. In situations where the SDP is not integrity-protected, however, the
certificate provided for a TLS connection MUST certify an appropriate
identity for the connection. In these scenarios, the certificate
presented by an endpoint MUST certify either the SDP connection
address, or the identity of the creator of the SDP message, as
follows:
8. Normative References o If the connection address for the media description is specified
as an IP address, the endpoint MAY use a certificate with an
iPAddress subjectAltName that exactly matches the IP in the
connection-address in the session description's 'c' line.
Similarly, if the connection address for the media description is
specified as a fully-qualified domain name, the endpoint MAY use a
certificate with a dNSName subjectAltName matching the specified
'c' line connection-address exactly. (Wildcard patterns MUST NOT
be used.)
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate o Alternately, if the SDP session description of the session was
transmitted over a protocol (such as SIP [19]) for which the
identities of session participants are defined by uniform resource
identifiers (URIs), the endpoint MAY use a certificate with a
uniformResourceIdentifier subjectAltName corresponding to the
identity of the endpoint that generated the SDP. The details of
what URIs are valid are dependent on the transmitting protocol.
(For more details on the validity of URIs, see Section 7.)
Identity matching is performed using the matching rules specified by
RFC 3280 [8]. If more than one identity of a given type is present
in the certificate (e.g., more than one dNSName name), a match in any
one of the set is considered acceptable. To support the use of
certificate caches, as described in Section 7, endpoints SHOULD
consistently provide the same certificate for each identity they
support.
6.2. Certificate Presentation
In all cases, an endpoint acting as the TLS server (i.e., one taking
the 'setup:passive' role, in the terminology of connection-oriented
media) MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, the client endpoint MUST terminate
the media connection with a bad_certificate error.
If the SDP offer/answer model [6] is being used, the client (the
endpoint with the 'setup:active' role) MUST also present a
certificate following the rules of Section 6.1. The server MUST
request a certificate, and if the client does not provide one, or if
the certificate does not match the provided fingerprint, the server
endpoint MUST terminate the media connection with a bad_certificate
error.
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.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [10]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
If offer/answer is not being used (e.g., if the SDP was sent over the
Session Announcement Protocol [17]), there is no secure channel
available for clients to communicate certificate fingerprints to
servers. In this case, servers MAY request client certificates,
which SHOULD be signed by a well-known certification authority, or
MAY allow clients to connect without a certificate.
7. Security Considerations
This entire document concerns itself with security. The problem to
be solved is addressed in Section 1, and a high-level overview is
presented in Section 3. See the SDP specification [14] for security
considerations applicable to SDP in general.
Offering a TCP/TLS connection in SDP (or agreeing to one in SDP
offer/answer mode) does not create an obligation for an endpoint to
accept any TLS connection with the given fingerprint. Instead, the
endpoint must engage in the standard TLS negotiation procedure to
ensure that the TLS stream cipher and MAC algorithm chosen meet the
security needs of the higher-level application. (For example, an
offered stream cipher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected
in almost every application scenario.)
Like all SDP messages, SDP messages describing TLS streams are
conveyed in an encapsulating application protocol (e.g., SIP, Media
Gateway Control Protocol (MGCP), etc.). It is the responsibility of
the encapsulating protocol to ensure the integrity of the SDP
security descriptions. Therefore, the application protocol SHOULD
either invoke its own security mechanisms (e.g., secure multiparts)
or, alternatively, utilize a lower-layer security service (e.g., TLS
or IPsec). This security service SHOULD provide strong message
authentication as well as effective replay protection.
However, such integrity protection is not always possible. For these
cases, end systems SHOULD maintain a cache of certificates that other
parties have previously presented using this mechanism. If possible,
users SHOULD be notified when an unsecured certificate associated
with a previously unknown end system is presented and SHOULD be
strongly warned if a different unsecured certificate is presented by
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
this document's mechanism is equivalent to that of the Secure Shell
(ssh) protocol [23], which is vulnerable to man-in-the-middle attacks
when two parties first communicate, but can detect ones that occur
subsequently. (Note that a precise definition of the "other party"
depends on the application protocol carrying the SDP message.) Users
SHOULD NOT, however, in any circumstances be notified about
certificates described in SDP descriptions sent over an integrity-
protected channel.
To aid interoperability and deployment, security protocols that
provide only hop-by-hop integrity protection (e.g., the sips protocol
[19], SIP over TLS) are considered sufficiently secure to allow the
mode in which any syntactically valid identity is accepted in a
certificate. This decision was made because sips is currently the
integrity mechanism most likely to be used in deployed networks in
the short to medium term. However, in this mode, SDP integrity is
vulnerable to attacks by compromised or malicious middleboxes, e.g.,
SIP proxy servers. End systems MAY warn users about SDP sessions
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
integrity mechanisms be used.
Depending on how SDP messages are transmitted, it is not always
possible to determine whether or not a subjectAltName presented in a
remote certificate is expected for the remote party. In particular,
given call forwarding, third-party call control, or session
descriptions generated by endpoints controlled by the Gateway Control
Protocol [20], it is not always possible in SIP to determine what
entity ought to have generated a remote SDP response. In general,
when not using authenticity and integrity protection of SDP
descriptions, a certificate transmitted over SIP SHOULD assert the
endpoint's SIP Address of Record as a uniformResourceIndicator
subjectAltName. When an endpoint receives a certificate over SIP
asserting an identity (including an iPAddress or dNSName identity)
other than the one to which it placed or received the call, it SHOULD
alert the user and ask for confirmation. This applies whether
certificates are self-signed, or signed by certification authorities;
a certificate for "sip:bob@example.com" may be legitimately signed by
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
specification; the same consideration applies for S/MIME-signed SDP
carried over SIP.)
This document does not define any mechanism for securely transporting
RTP and RTP Control Protocol (RTCP) packets over a connection-
oriented channel. There was no consensus in the working group as to
whether it would be better to send Secure RTP packets [21] over a
connection-oriented transport [24], 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-
oriented media; in some cases, a higher- or lower-level security
protocol may be appropriate.
This document improves security from the RFC 4572 [25]. It updates
the preferred hash function cipher suite from SHA-1 to SHA-256. By
clarifying the usage and handling of multiple fingerprints, the
document also enables hash agility, and incremental deployment of
newer, and more secure, cipher suites.
8. IANA Considerations
Note to IANA. No IANA considerations are changed from RFC4572 [25]
so the only actions required are to update the registreis to point at
this specification.
This document defines an SDP proto value: 'TCP/TLS'. Its format is
defined in Section 4. This proto value has been registered by IANA
under "Session Description Protocol (SDP) Parameters" under "proto".
This document defines an SDP session and media-level attribute:
'fingerprint'. Its format is defined in Section 5. This attribute
has been registered by IANA under "Session Description Protocol (SDP)
Parameters" under "att-field (both session and media level)".
The SDP specification [14] states that specifications defining new
proto values, like the 'TCP/TLS' proto value defined in this one,
must define the rules by which their media format (fmt) namespace is
managed. For the TCP/TLS protocol, new formats SHOULD have an
associated MIME registration. Use of an existing MIME subtype for
the format is encouraged. If no MIME subtype exists, it is
RECOMMENDED that a suitable one be registered through the IETF
process [12] by production of, or reference to, a standards-track RFC
that defines the transport protocol for the format.
This specification creates a new IANA registry named "Hash Function
Textual Names". It will not be part of the SDP Parameters.
The names of hash functions used for certificate fingerprints are
registered by the IANA. Hash functions MUST be defined by standards-
track RFCs that update or obsolete RFC 3279 [7].
When registering a new hash function textual name, the following
information MUST be provided:
o The textual name of the hash function.
o The Object Identifier (OID) of the hash function as used in X.509
certificates.
o A reference to the standards-track RFC, updating or obsoleting RFC
3279 [7], defining the use of the hash function in X.509
certificates.
Table 1 contains the initial values of this registry.
+--------------------+------------------------+-----------+
| Hash Function Name | OID | Reference |
+--------------------+------------------------+-----------+
| "md2" | 1.2.840.113549.2.2 | RFC 3279 |
| "md5" | 1.2.840.113549.2.5 | RFC 3279 |
| "sha-1" | 1.3.14.3.2.26 | RFC 3279 |
| "sha-224" | 2.16.840.1.101.3.4.2.4 | RFC 4055 |
| "sha-256" | 2.16.840.1.101.3.4.2.1 | RFC 4055 |
| "sha-384" | 2.16.840.1.101.3.4.2.2 | RFC 4055 |
| "sha-512" | 2.16.840.1.101.3.4.2.3 | RFC 4055 |
+--------------------+------------------------+-----------+
Table 1: IANA Hash Function Textual Name Registry
9. References
9.1. Normative References
[1] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>.
[2] International Telecommunications Union, "Information
technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks",
ITU-T Recommendation X.509, ISO Standard 9594-8, March
2000.
[3] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
DOI 10.17487/RFC1319, April 1992,
<http://www.rfc-editor.org/info/rfc1319>.
[4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>.
[7] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <http://www.rfc-editor.org/info/rfc3279>.
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002,
<http://www.rfc-editor.org/info/rfc3280>.
[9] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>.
[10] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145,
DOI 10.17487/RFC4145, September 2005,
<http://www.rfc-editor.org/info/rfc4145>.
[11] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, DOI 10.17487/RFC4234,
October 2005, <http://www.rfc-editor.org/info/rfc4234>.
[12] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, DOI 10.17487/RFC4288,
December 2005, <http://www.rfc-editor.org/info/rfc4288>.
[13] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346,
DOI 10.17487/RFC4346, April 2006,
<http://www.rfc-editor.org/info/rfc4346>.
[14] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 9.2. Informative References
[15] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>.
[16] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[17] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974,
October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[18] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, DOI 10.17487/RFC3174, September 2001,
<http://www.rfc-editor.org/info/rfc3174>.
[19] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[20] Groves, C., Ed., Pantaleo, M., Ed., Anderson, T., Ed., and
T. Taylor, Ed., "Gateway Control Protocol Version 1",
RFC 3525, DOI 10.17487/RFC3525, June 2003,
<http://www.rfc-editor.org/info/rfc3525>.
[21] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[22] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004,
<http://www.rfc-editor.org/info/rfc3851>.
[23] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[24] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
2006, <http://www.rfc-editor.org/info/rfc4571>.
[25] 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>.
Author's Address Appendix A. Acknowledgments
Christer Holmberg This version of the document included significant contributions by
Cullen Jennings, Paul Kyzivat, Roman Shpount, and Martin Thomson.
Authors' Addresses
Jonathan Lennox
Vidyo
Email: jonathan@vidyo.com
Christer Holmberg
Ericsson Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com Email: christer.holmberg@ericsson.com
 End of changes. 66 change blocks. 
192 lines changed or deleted 667 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/