draft-ietf-mmusic-comedia-tls-00.txt   draft-ietf-mmusic-comedia-tls-01.txt 
Multiparty Multimedia Session J. Lennox Multiparty Multimedia Session J. Lennox
Control Columbia U. Control Columbia U.
Expires: October 25, 2004 Expires: January 14, 2005
Connection-Oriented Media Transport over the Transport Layer Security Connection-Oriented Media Transport over the Transport Layer Security
(TLS) Protocol in the Session Description Protocol (SDP) (TLS) Protocol in the Session Description Protocol (SDP)
draft-ietf-mmusic-comedia-tls-00 draft-ietf-mmusic-comedia-tls-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 25, 2004. This Internet-Draft will expire on January 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes how to express connection-oriented media This document specifies how to establish secure connection-oriented
transport over the Transport Layer Security (TLS) protocol using the media transport sessions over the Transport Layer Security (TLS)
Session Description Protocol. It defines a new protocol identifier, protocol using the Session Description Protocol (SDP). It defines a
TLS. It also defines the syntax and semantics for an SDP new protocol identifier, TCP/TLS. It also defines the syntax and
"fingerprint" attribute that identifies the certificate which will be semantics for an SDP "fingerprint" attribute that identifies the
presented for the TLS session. certificate which 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 4 3.1 SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
5. Endpoint Identification . . . . . . . . . . . . . . . . . . . 5 3.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
5.1 Certificate Choice . . . . . . . . . . . . . . . . . . . . 5 3.3 The Need For Self-Signed Certificates . . . . . . . . . . 5
5.2 Certificate Presentation . . . . . . . . . . . . . . . . . 6 3.4 Example SDP Description For TLS Connection . . . . . . . . 6
6. Example SDP description for TLS connection . . . . . . . . . . 7 4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1 Certificate Choice . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 6.2 Certificate Presentation . . . . . . . . . . . . . . . . . 9
9.2 Informative References . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
9.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
1. Introduction 1. Introduction
The document Connection-Oriented Media Transport in SDP [1] describes The Session Description Protocol (SDP) [1] provides a general purpose
how to express media transport over connection-oriented protocols
using the Session Description Protocol [2]. SDP is a general-purpose
format for describing multimedia sessions in announcements or format for describing multimedia sessions in announcements or
invitations. The Connection-Oriented Media document defines how SDP invitations. For many applications, it is desirable to establish, as
can be used for connection-oriented media, such as TCP, which must be part of a multimedia session, a media stream which uses a
explicitly connected before being used. The connection-oriented connection-oriented transport. The document Connection-Oriented
media draft defines the connection setup procedure for such Media Transport in the Session Description Protocol (SDP) [2]
connections, and defines how SDP descriptions can advertise whether specifies a general mechanism for describing and establishing such
they wish to initiate and/or receive the media connections. connection-oriented streams; however, the only transport protocol it
directly supports is TCP. In many cases, session participants wish
In many cases, session participants wish to provide confidentiality, to provide confidentiality, data integrity, and authentication for
data integrity, and authentication for their media sessions. For their media sessions. This document therefore extends the
connection-oriented media, the Transport Layer Security (TLS) Connection-Oriented Media specification to allow session descriptions
protocol [3] is an obvious and widely-implemented choice which can to describe media sessions that use the Transport Layer Security
provide an encrypted data channel and authenticated client and server (TLS) protocol [3].
identities. However, TLS cannot be used blindly; it is necessary to
specify the appropriate certificates which each end party to a
connection should present, so their counterparties can verify that
they are indeed who they claim to be.
Parties to a TLS session indicate their identities by presenting The TLS protocol allows applications to communicate over a channel
authentication certificates as part of the TLS handshake procedure. which provides privacy and data integrity. The TLS specification,
Authentication certificates are X.509 [4] certificates, as profiled however, does not specify how specific protocols establish and use
by RFC 3279 [5] and RFC 3280 [6]. TLS leaves the issue of how to this secure channel; particularly, TLS leaves the question of how to
interpret these certificates as an issue for the protocols which run interpret and validate authentication certificates as an issue for
atop TLS. Certificate interpretation is a critical issue, however; the protocols which run over TLS. This document specifies such usage
it does an endpoint no good to know only that its peer has a valid for the case of connection-oriented media transport.
certificate, without also having some way of judging whether the
identity that it certifies is indeed a correct one for its
counterparty.
Further complicating this issue, endpoints exchanging media will Complicating this issue, endpoints exchanging media will often be
often be unable to afford to obtain certificates signed by a unable to obtain authentication certificates signed by a well-known
well-known root certificate authority. Most certificate authorities root certificate authority (CA). Most certificate authorities charge
charge for signed certificates, particularly host-based certificates; 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 certificate authorities must be obtaining signed certificates, as certificate 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. 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 which 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 the fingerprint of the offered
certificate matches the one in the session description, end hosts can
trust even self-signed certificates.
This specification, therefore, defines how to signal TLS-based media The rest of this document is laid out as follows. An overview of the
sessions in SDP. It describes what identities endpoints should problem and threat model is given in Section 3. Section 4 gives the
present in certificates, and, assuming the integrity of SDP content basic use of SDP. Section 5 describes the SDP fingerprint attribute,
is assured, allows the secure use of self-signed certificates. which, assuming the integrity of SDP content is assured, allows the
secure use of self-signed certificates. Section 6 describes which
X.509 certificates are presented, and how they are used in TLS.
Section 7 discusses additional security considerations.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
and indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Protocol Identifiers 3. Overview
The m= line in SDP is where an endpoint specifies the protocol used This section discusses the threat model which motivates TLS transport
for the media in the session. See the "Media Announcements" section for connection-oriented media streams. It also discusses in more
of SDP [2] for a discussion on protocol identifiers. detail the need for end systems to use self-signed certificates.
The protocol identifier "TLS" in a media description specifies that 3.1 SDP Operational Modes
the media being described will use the Transport Layer Security
protocol [3] with an implied transport protocol of TCP. An m= line There are two principal operational modes for multimedia sessions:
that specifies TLS MUST further qualify the protocol using a fmt advertised and offer-answer. Advertised sessions are the simpler
identifier. mode. In this mode, a server publishes, in some manner, an SDP
session description describing a multimedia session it is making
available. The classic example of this mode of operation is the
Session Announcment Protocol (SAP) [13], 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.
Alternatively, SDP conferences can operate in offer-answer mode [5].
This mode allows two participants in a multimedia session to
negotiate the multimedia session between them. In this model, one
participant offers the other a description of the desired session
from its perspective, and the other participant answers with the
desired session from its own perspective. In this mode, each of the
participants in the session has knowledge of the other one. This is
the mode of operation used by the Session Initiation Protocol (SIP)
[14].
3.2 Threat Model
Participants in multimedia conferences often wish to guarantee
confidentiality, data integrity, and authentication for their media
sessions. This section describes various types of attackers and the
ways they attempt to violate these guarantees. It then describes how
the TLS protocol can be used to thwart the attackers.
The simplest type of attacker is one who listens passively to the
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.
More sophisticated is an attacker who can send his own data traffic
over the network, but who cannot modify or redirect valid traffic.
In SDP's 'advertised' operational mode, this can barely be considered
an attack; media sessions are expected to be initiated from anywhere
on the network. In SDP's offer-answer mode, however, this type of
attack is more serious. An attacker could initiate a connection to
one or both of the endpoints of a session, thus impersonating an
endpoint, or acting as a man in the middle to listen in on their
communications. To thwart these attacks, TLS uses endpoint
certificates. So long as the certificates' private keys have not
been compromised, the endpoints have an external trusted mechanism
(most commonly, a mutually-trusted certificate authority) to validate
certificates, and the endpoints know what certificate identity to
expect, endpoints can be certain that such an attack has not taken
place.
Finally, the most serious type of attacker is one who can modify or
redirect session descriptions: for example, a compromised or
malicious SIP proxy server. Neither TLS itself, nor any mechanisms
which 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 [15] can be used to
secure session descriptions.
3.3 The Need For Self-Signed Certificates
SDP session descriptions are created by any endpoint that needs to
participate in a multimedia session. In many cases, such as SIP
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 certificate authority.
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.
3.4 Example SDP Description For TLS Connection
Figure 1 illustrates an SDP offer which 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 [2], except for the proto parameter and the
fingerprint attribute.) See the subsequent sections for explanations
of the example's TLS-specific attributes.
(Note that the example uses MD5 as its one-way hash function, even
though SHA-1 is preferred. This has been done only because the
longer SHA-1 fingerprint would cause that line of the example to be
wider than the number of characters allowed in an Internet-Draft.)
m=image 54111 TCP/TLS t38
c=IN IP4 10.1.1.2
a=setup:passive
a=connid:1
a=fingerprint:MD5 48:AA:D8:BA:36:7C:6D:70:7F:81:BB:BA:ED:6D:B8:C7
Figure 1: Example SDP Description Offering a TLS Media Stream
4. Protocol Identifiers
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 [1] for a discussion on transport
protocol identifiers.
This specification defines a new protocol identifier, TCP/TLS, which
indicates that the media described will use the Transport Layer
Security protocol [3] over TCP. (Using TLS over other transport
protocols is not discussed by this document.) An m= line that
specifies TCP/TLS MUST further qualify the protocol using a fmt
identifier, to indicate the application being run over TLS.
As TLS sessions are connection-oriented, media sessions described in As TLS sessions are connection-oriented, media sessions described in
this manner are subject to the definitions given in the this manner follow the procedures defined in the connection-oriented
connection-oriented media specification [1]. This includes the media specification [2]. They also use the attributes defined in
"direction" and "reconnect" attributes, and also that specification's that specification, "a=setup" and "a=connid".
rules on session and connection lifetime.
4. Fingerprint Attribute 5. Fingerprint Attribute
In order to associated media streams with connections, and to prevent Parties to a TLS session indicate their identities by presenting
unauthorized barge-in attacks on the media streams, endpoints can authentication certificates as part of the TLS handshake procedure.
optionally provide a certificate fingerprint. If the X.509 Authentication certificates are X.509 [6] certificates, as profiled
certificate presented for the TLS connection matches the fingerprint by RFC 3279 [7] and RFC 3280 [8].
presented in the SDP, the endpoint can be confident that the author
of the SDP is indeed the initiator of the connection.
A certificate fingerprint is a secure hash of the DER (distinguished In order to associate media streams with connections, and to prevent
encoding rules) form of the certificate. (Certificate fingerprints unauthorized barge-in attacks on the media streams, endpoints MAY
are widely supported by tools which manipulate X.509 certificates; provide a certificate fingerprint. If the X.509 certificate
for instance, the command "openssl x509 -fingerprint" causes the presented for the TLS connection matches the fingerprint presented in
openssl package's command-line tool to print a certificate the SDP, the endpoint can be confident that the author of the SDP is
fingerprint, and the certificate managers for Mozilla and Internet indeed the initiator of the connection.
Explorer display them when viewing the details of a certificate.)
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 which 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.)
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
upper-case hexidecimal bytes, separated by colons. The number of upper-case 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 [13], which uses unseparated lower-case hexidecimal authentication [16], which uses unseparated lower-case 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 [8] in Figure 1. This syntax extends the BNF syntax Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax
of SDP [2]. of SDP [1].
attribute =/ fingerprint-attribute attribute =/ fingerprint-attribute
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
hash-func = "sha-1" / "md5" / "md2" / token hash-func = "sha-1" / "md5" / "md2" / token
; New hash functions must be registered ; Additional hash functions can only come
; with IANA. ; from updates to RFC 3279
; TODO: figure out what IANA registry
; this should reference.
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 1: Abstract Backus-Naur Syntax for the Fingerprint Attribute Figure 2: Abstract Backus-Naur Syntax for the Fingerprint Attribute
A certificate fingerprint SHOULD be computed using the same hash
function as is used by the certificate itself. (This guarantees that
the fingerprint will be usable by the other endpoint so long as the
certificate itself is.) Following RFC 3279 [5], therefore, the
defined hash functions are SHA-1 [9][14], MD5 [10], and MD2 [11],
with SHA-1 preferred.
(TODO: figure out what IANA or other registry lists hash functions.) A certificate fingerprint SHOULD be computed using the same one-way
hash function as is used in the certificate's signature algorithm.
(This guarantees that the fingerprint will be usable by the other
endpoint so long as the certificate itself is.) Following RFC 3279
[7], therefore, the defined hash functions are SHA-1 [10][17], MD5
[11], and MD2 [12], with SHA-1 preferred. Additional hash functions
can be defined only by standards-track RFCs which update or obsolete
RFC 3279 [7].
The fingerprint attribute may be either a session-level or a The fingerprint attribute may be either a session-level or a
media-level SDP attribute. If it is a session-level attribute, it media-level SDP attribute. If it is a session-level attribute, it
applies to all TLS sessions for which no media-level fingerprint applies to all TLS sessions for which no media-level fingerprint
attribute is defined. attribute is defined.
5. Endpoint Identification 6. Endpoint Identification
5.1 Certificate Choice 6.1 Certificate Choice
X.509 certificates certify identities. The certificate provided for X.509 certificates certify identities. The certificate provided for
a TLS connection needs to certify an appropriate identity for the a TLS connection needs to certify an appropriate identity for the
connection. Identity matching is performed using the matching rules connection. Identity matching is performed using the matching rules
specified by RFC 3280 [6]. If more than one identity of a given type 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 is present in the certificate (e.g., more than one dNSName name), a
match in any one of the set is considered acceptable. match in any one of the set is considered acceptable.
If an endpoint does not provide a certificate fingerprint in its SDP, If an endpoint does not provide a certificate fingerprint in its SDP,
its certificate MUST correspond to one of the following identities, its certificate MUST correspond to one of the following identities,
and MUST be signed by a well-known certificate authority. If the and MUST be signed by a certificate authority known to the other
endpoint does provide a certificiate fingerprint, the certificate endpoint.
SHOULD indicate one of these identities. In all cases, the
certificate MUST indicate some identity which has a meaningful
relationship to the end point.
o If the connection address for the media description is specified o If the connection address for the media description is specified
as an IP address, the endpoint MAY use a certificate with an as an IP address, the endpoint MAY use a certificate with an
iPAddress subjectAltName which exactly matches the IP in the iPAddress subjectAltName which exactly matches the IP in the
connection address. connection-address in the session description's c= line.
o If the connection address for the media description is specified o If the connection address for the media description is specified
as a fully-qualified domain name, the endpoint MAY use a as a fully-qualified domain name, the endpoint MAY use a
certificate with a dNSName subjectAltName matching the specified certificate with a dNSName subjectAltName matching the specified
connection address. Names may contain the wildcard character * c= line connection-address. Names may contain the wildcard
which is considered to match any single domain name component or character * which is considered to match any single domain name
component fragment. E.g., *.a.com matches foo.a.com but not component or component fragment. E.g., *.a.com matches foo.a.com
bar.foo.a.com. f*.com matches foo.com but not bar.com. but not bar.foo.a.com. f*.com matches foo.com but not bar.com.
o Finally, if the SDP describing the connection was transmitted over (This last pattern is not often meaningful, but is supported by
a secure protocol which uses X.509 certificates to certify the https [18]; thus, it is allowed here as well.)
endpoints of the connection, the endpoint MAY use the same o If the SDP session description describing the session was
certificate to certify the media connection. (For example, an SDP transmitted over an end-to-end secure protocol which uses X.509
description sent over HTTP/TLS [15] or secured by S/MIME [16] MAY certificates, the endpoint MAY use the same certificate to certify
use the same certificate to secure the media connection. Note, the media connection. For example, an SDP description sent over
however, that the sips: protocol (SIP over TLS) [17] provides only HTTP/TLS [18] or secured by S/MIME [15] MAY use the same
hop-by-hop security, so this certificate does not satisfy this certificate to secure the media connection. (Note, however, that
criterion. Such a certificate could satisify one of the previous the sips protocol [14] (SIP over TLS) provides only hop-by-hop
two points, however.) security, so its TLS certificates do not satisfy this criterion.)
In this case, the certificate must be one that is allowed in this
context by the transmitting protocol.
5.2 Certificate Presentation In those cases where an endpoint does provide a certificate
fingerprint, the certificate MAY be self-signed, but MUST indicate
some identity which has a meaningful relationship to the end point.
This identity MAY be one of the identities allowed above for
non-fingerprinted certificates, or MAY correspond to the protocol
over which the SDP was transmitted. For example, protocols which use
URIs could include a certificate with a subjectAltName field of type
uniformResourceIdentifier with a value matching the endpoint's URI.
In all cases, an endpoint acting as the TLS server -- i.e., one 6.2 Certificate Presentation
taking the direction:passive role, in the terminology of
connection-oriented media -- MUST present a certificate during TLS In all cases, an endpoint acting as the TLS server, i.e., one taking
initiation, following the rules presented in Section 5.1. If the the a=setup:passive role, in the terminology of connection-oriented
certificate does not match the original fingerprint, or, if there is media, MUST present a certificate during TLS initiation, following
no fingerprint, the certificate identity is incorrect, the client the rules presented in Section 6.1. If the certificate does not
endpoint MUST either notify the user or terminate the connection with match the original fingerprint, or, if there is no fingerprint, the
certificate identity is incorrect, the client endpoint MUST either
notify the user, if possible, or terminate the media connection with
a bad certificate error. a bad certificate error.
If the SDP offer/answer model [12] is being used, the client (the If the SDP offer/answer model [5] is being used, the client (the
endpoint with the direction:active role) MUST also present a endpoint with the setup:active role) MUST also present a certificate
certificate following the rules of Section 5.1. The server MUST following the rules of Section 6.1. The server MUST request a
request a certificate, and if the client does not provide one, if the certificate, and if the client does not provide one, if the
certificate does not match the provided fingerprint, or, if there was certificate does not match the provided fingerprint, or, if there was
no fingerprint, the certificate identity is incorrect, the server no fingerprint, the certificate identity is incorrect, the server
endpoint MUST either notify the user or terminate the connection with endpoint MUST either notify the user or terminate the media
a bad certificate error. connection with a bad certificate 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 direction:passive or Thus, if the offerer has offered a setup:passive or setup:actpass
direction:both role, it MUST (as specified in the connection-oriented role, it MUST (as specified in the Connection-Oriented Media
media specification [1]) begin listening for an incoming connection specification [2]) begin listening for an incoming connection as soon
as soon as it sends its offer. However, because its peer's media as it sends its offer. However, because its peer's media connection
connection may outrace its answer, it SHOULD NOT definitively accept may outrace its answer, it SHOULD NOT definitively accept or reject
or rejecting the peer's certificate until it has received and the peer's certificate until it has received and processed the SDP
processed the SDP answer. answer.
If offer/answer is not being used (e.g., if the SDP was sent over the If offer/answer is not being used (e.g., if the SDP was sent over the
Session Announcement Protocol [18]), the server typically has no Session Announcement Protocol [13]), the TLS server typically has no
external knowledge of what the client's identity ought to be. In external knowledge of what the TLS client's identity ought to be. In
this case, no client certificate need be presented, and no this case, no client certificate need be presented, and no
certificate validation can be performed, unless the server has certificate validation can be performed, unless the server has
knowledge of valid clients through some external means. knowledge of valid clients through some external means.
6. Example SDP description for TLS connection
Figure 2 illustrates an SDP offer to signal the availability of a
T.38 fax session over TLS. (This example is the same as the one in
[1], except for the transport parameter and the fingerprint
attribute.)
v=0
o=me 2890844526 2890842807 IN IP4 10.1.1.2
s=Call me using TCP
t=3034423619 3042462419
c=IN IP4 10.1.1.2
m=image 54111 TLS t38
a=direction:passive
a=fingerprint:MD5 48:AA:D8:BA:36:7C:6D:70:7F:81:BB:BA:ED:6D:B8:C7
Figure 2: Example SDP description offering a TLS media stream
7. Security Considerations 7. Security Considerations
This entire document concerns itself with security. 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.
Like all SDP messages, SDP messages describing TLS streams are Like all SDP messages, SDP messages describing TLS streams are
conveyed in an encapsulating application protocol (e.g., SIP, MGCP, conveyed in an encapsulating application protocol (e.g., SIP, MGCP,
etc.). It is the responsibility of the encapsulating protocol to etc.). It is the responsibility of the encapsulating protocol to
ensure the protection of the SDP security descriptions. Therefore, ensure the integrity and confidentiality of the SDP security
the application protocol SHOULD either invoke its own security descriptions. Therefore, the application protocol SHOULD either
mechanisms (e.g., secure multiparts) or alternatively utilize a invoke its own security mechanisms (e.g., secure multiparts) or
lower-layer security service (e.g., TLS or IPSec). This security alternatively utilize a lower-layer security service (e.g., TLS or
service SHOULD provide strong message authentication and IPSec). This security service SHOULD provide strong message
packet-payload encryption as well as effective replay protection. authentication and packet-payload encryption as well as effective
replay protection.
TLS is not always the most appropriate choice for secure TLS is not always the most appropriate choice for secure
connection-oriented media; in some cases, a higher-level security connection-oriented media; in some cases, a higher-level security
protocol may be appropriate. For example, RTP and RTCP packets may protocol may be appropriate. For example, RTP and RTCP packets may
be sent over a connection-oriented transport [19]. In this case, it be sent over a connection-oriented transport [19]. In this case, it
is often more appropriate to use the Secure RTP protocol [20] with may be more appropriate to use the Secure RTP protocol [20] with
appropriate SDP descriptions [21]. appropriate SDP descriptions [21].
8. IANA Considerations 8. IANA Considerations
This document registers the "TLS" protocol identifier and the This document defines an SDP proto value: TCP/TLS. Its format is
"fingerprint" attribute for SDP, as specified by Appendix B of the defined in Section 4. This proto value should be registered by IANA
SDP specification [2]. on http://www.iana.org/assignments/sdp-parameters under "proto".
This document defines an SDP session and media level attribute:
fingerprint. Its format is defined in Section 5. This attribute
should be registered by IANA on
http://www.iana.org/assignments/sdp-parameters under "att-field (both
session and media level)".
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Yon, D., "Connection-Oriented Media Transport in SDP", [1] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
draft-ietf-mmusic-sdp-comedia-05 (work in progress), March Description Protocol", draft-ietf-mmusic-sdp-new-18 (work in
2003. progress), June 2004.
[2] Handley, M. and V. Jacobson, "SDP: Session Description [2] Yon, D., "Connection-Oriented Media Transport in the Session
Protocol", RFC 2327, April 1998. Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-07
(work in progress), June 2004.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
[4] International Telecommunications Union, "Information technology [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] International Telecommunications Union, "Information technology
- Open Systems Interconnection - The Directory: Public-key and - Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks", ITU-T Recommendation X.509, attribute certificate frameworks", ITU-T Recommendation X.509,
ISO Standard 9594-8, March 2000. ISO Standard 9594-8, March 2000.
[5] Bassham, L., Polk, W. and R. Housley, "Algorithms and [7] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002. 3279, April 2002.
[6] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 [8] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement [9] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Levels", BCP 14, RFC 2119, March 1997.
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[9] National Institute of Standards and Technology, "Secure Hash [10] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http:// Standard", FIPS PUB 180-1, April 1995,
www.itl.nist.gov/fipspubs/fip180-1.htm>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[11] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, [12] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
April 1992. April 1992.
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
9.2 Informative References 9.2 Informative References
[13] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [13] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Protocol", RFC 2974, October 2000.
Basic and Digest Access Authentication", RFC 2617, June 1999.
[14] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[16] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [15] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999. 2633, June 1999.
[17] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [16] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Session Initiation Protocol", RFC 3261, June 2002. Basic and Digest Access Authentication", RFC 2617, June 1999.
[18] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [17] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
Protocol", RFC 2974, October 2000. RFC 3174, September 2001.
[18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[19] Lazzaro, J., "Framing RTP and RTCP Packets over [19] Lazzaro, J., "Framing RTP and RTCP Packets over
Connection-Oriented Transport", Connection-Oriented Transport",
draft-ietf-avt-rtp-framing-contrans-01 (work in progress), draft-ietf-avt-rtp-framing-contrans-01 (work in progress),
March 2004. March 2004.
[20] Baugher, M., "The Secure Real-time Transport Protocol", [20] Baugher, M., "The Secure Real-time Transport Protocol",
draft-ietf-avt-srtp-09 (work in progress), July 2003. draft-ietf-avt-srtp-09 (work in progress), July 2003.
[21] Andreasen, F., Baugher, M. and D. Wing, "Session Description [21] Andreasen, F., Baugher, M. and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams", Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-03 (work in progress), February draft-ietf-mmusic-sdescriptions-04 (work in progress), May
2004. 2004.
[22] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-15 (work in
progress), October 2003.
Author's Address Author's Address
Jonathan Lennox Jonathan Lennox
Columbia University Department of Computer Science Columbia University Department of Computer Science
450 Computer Science 450 Computer Science
1214 Amsterdam Ave., M.C. 0401 1214 Amsterdam Ave., M.C. 0401
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7018 Phone: +1 212 939 7018
EMail: lennox@cs.columbia.edu EMail: lennox@cs.columbia.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/