draft-ietf-mmusic-comedia-tls-01.txt   draft-ietf-mmusic-comedia-tls-02.txt 
Multiparty Multimedia Session J. Lennox Multiparty Multimedia Session J. Lennox
Control Columbia U. Control Columbia U.
Expires: January 14, 2005 Expires: April 4, 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-01 draft-ietf-mmusic-comedia-tls-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at
http://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 January 14, 2005. This Internet-Draft will expire on April 4, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This document specifies how to establish secure connection-oriented This document specifies how to establish secure connection-oriented
media transport sessions over the Transport Layer Security (TLS) media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines a protocol using the Session Description Protocol (SDP). It defines a
new protocol identifier, TCP/TLS. It also defines the syntax and new protocol identifier, TCP/TLS. It also defines the syntax and
semantics for an SDP "fingerprint" attribute that identifies the semantics for an SDP "fingerprint" attribute that identifies the
certificate which will be presented for the TLS session. This certificate which will be presented for the TLS session. This
mechanism allows media transport over TLS connections to be mechanism allows media transport over TLS connections to be
established securely, so long as the integrity of session established securely, so long as the integrity of session
descriptions is assured. descriptions is assured.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 SDP Operational Modes . . . . . . . . . . . . . . . . . . 4 3.1 SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
3.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 The Need For Self-Signed Certificates . . . . . . . . . . 5 3.3 The Need For Self-Signed Certificates . . . . . . . . . . 5
3.4 Example SDP Description For TLS Connection . . . . . . . . 6 3.4 Example SDP Description For TLS Connection . . . . . . . . 6
4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . . 6
5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7 5. Fingerprint Attribute . . . . . . . . . . . . . . . . . . . . 7
6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 8 6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 8
6.1 Certificate Choice . . . . . . . . . . . . . . . . . . . . 8 6.1 Certificate Choice . . . . . . . . . . . . . . . . . . . . 8
6.2 Certificate Presentation . . . . . . . . . . . . . . . . . 9 6.2 Certificate Presentation . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A. Changes From Earlier Versions . . . . . . . . . . . . . . . . 11
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 A.1 Changes From Draft -01 . . . . . . . . . . . . . . . . . . 11
9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 A.2 Changes From Draft -00 . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
9.2 Informative References . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [1] provides a general purpose The Session Description Protocol (SDP) [1] provides a general purpose
format for describing multimedia sessions in announcements or format for describing multimedia sessions in announcements or
invitations. For many applications, it is desirable to establish, as invitations. For many applications, it is desirable to establish, as
part of a multimedia session, a media stream which uses a part of a multimedia session, a media stream which uses a
connection-oriented transport. The document Connection-Oriented connection-oriented transport. The document Connection-Oriented
Media Transport in the Session Description Protocol (SDP) [2] Media Transport in the Session Description Protocol (SDP) [2]
specifies a general mechanism for describing and establishing such specifies a general mechanism for describing and establishing such
skipping to change at page 3, line 52 skipping to change at page 3, line 52
a mechanism which allows self-signed certificates can be used a mechanism which allows self-signed certificates can be used
securely, provided that the integrity of the SDP description is securely, provided that the integrity of the SDP description is
assured. It provides for endpoints to include a secure hash of their assured. It provides for endpoints to include a secure hash of their
certificate, known as the "certificate fingerprint", within the certificate, known as the "certificate fingerprint", within the
session description. Provided the fingerprint of the offered session description. Provided the fingerprint of the offered
certificate matches the one in the session description, end hosts can certificate matches the one in the session description, end hosts can
trust even self-signed certificates. trust even self-signed certificates.
The rest of this document is laid out as follows. An overview of the The rest of this document is laid out as follows. An overview of the
problem and threat model is given in Section 3. Section 4 gives the problem and threat model is given in Section 3. Section 4 gives the
basic use of SDP. Section 5 describes the SDP fingerprint attribute, basic mechanism for establishing TLS-based connected-oriented media
which, assuming the integrity of SDP content is assured, allows the in SDP. Section 5 describes the SDP fingerprint attribute, which,
secure use of self-signed certificates. Section 6 describes which assuming the integrity of SDP content is assured, allows the secure
X.509 certificates are presented, and how they are used in TLS. use of self-signed certificates. Section 6 describes which X.509
Section 7 discusses additional security considerations. 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 [4] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Overview 3. Overview
skipping to change at page 4, line 29 skipping to change at page 4, line 30
for connection-oriented media streams. It also discusses in more for connection-oriented media streams. It also discusses in more
detail the need for end systems to use self-signed certificates. detail the need for end systems to use self-signed certificates.
3.1 SDP Operational Modes 3.1 SDP Operational Modes
There are two principal operational modes for multimedia sessions: There are two principal operational modes for multimedia sessions:
advertised and offer-answer. Advertised sessions are the simpler advertised and offer-answer. Advertised sessions are the simpler
mode. In this mode, a server publishes, in some manner, an SDP mode. In this mode, a server publishes, in some manner, an SDP
session description describing a multimedia session it is making session description describing a multimedia session it is making
available. The classic example of this mode of operation is the available. The classic example of this mode of operation is the
Session Announcment Protocol (SAP) [13], in which SDP session Session Announcment Protocol (SAP) [14], in which SDP session
descriptions are periodically transmitted to a well-known multicast descriptions are periodically transmitted to a well-known multicast
group. Traditionally, these descriptions involve multicast group. Traditionally, these descriptions involve multicast
conferences, but unicast sessions are also possible. conferences, but unicast sessions are also possible.
(Connection-oriented media, obviously, cannot use multicast.) (Connection-oriented media, obviously, cannot use multicast.)
Recipients of a session description connect to the addresses Recipients of a session description connect to the addresses
published in the session description. These recipients may not published in the session description. These recipients may not
previously have been known to the advertiser of the session previously have been known to the advertiser of the session
description. description.
Alternatively, SDP conferences can operate in offer-answer mode [5]. Alternatively, SDP conferences can operate in offer-answer mode [5].
This mode allows two participants in a multimedia session to This mode allows two participants in a multimedia session to
negotiate the multimedia session between them. In this model, one negotiate the multimedia session between them. In this model, one
participant offers the other a description of the desired session participant offers the other a description of the desired session
from its perspective, and the other participant answers with the from its perspective, and the other participant answers with the
desired session from its own perspective. In this mode, each of 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 participants in the session has knowledge of the other one. This is
the mode of operation used by the Session Initiation Protocol (SIP) the mode of operation used by the Session Initiation Protocol (SIP)
[14]. [15].
3.2 Threat Model 3.2 Threat Model
Participants in multimedia conferences often wish to guarantee Participants in multimedia conferences often wish to guarantee
confidentiality, data integrity, and authentication for their media confidentiality, data integrity, and authentication for their media
sessions. This section describes various types of attackers and the sessions. This section describes various types of attackers and the
ways they attempt to violate these guarantees. It then describes how ways they attempt to violate these guarantees. It then describes how
the TLS protocol can be used to thwart the attackers. the TLS protocol can be used to thwart the attackers.
The simplest type of attacker is one who listens passively to the The simplest type of attacker is one who listens passively to the
skipping to change at page 5, line 37 skipping to change at page 5, line 41
(most commonly, a mutually-trusted certificate authority) to validate (most commonly, a mutually-trusted certificate authority) to validate
certificates, and the endpoints know what certificate identity to certificates, and the endpoints know what certificate identity to
expect, endpoints can be certain that such an attack has not taken expect, endpoints can be certain that such an attack has not taken
place. place.
Finally, the most serious type of attacker is one who can modify or Finally, the most serious type of attacker is one who can modify or
redirect session descriptions: for example, a compromised or redirect session descriptions: for example, a compromised or
malicious SIP proxy server. Neither TLS itself, nor any mechanisms malicious SIP proxy server. Neither TLS itself, nor any mechanisms
which use it, can protect an SDP session against such an attacker. which use it, can protect an SDP session against such an attacker.
Instead, the SDP description itself must be secured through some Instead, the SDP description itself must be secured through some
mechanism; SIP, for example, defines how S/MIME [15] can be used to mechanism; SIP, for example, defines how S/MIME [16] can be used to
secure session descriptions. secure session descriptions.
3.3 The Need For Self-Signed Certificates 3.3 The Need For Self-Signed Certificates
SDP session descriptions are created by any endpoint that needs to SDP session descriptions are created by any endpoint that needs to
participate in a multimedia session. In many cases, such as SIP participate in a multimedia session. In many cases, such as SIP
phones, such endpoints have dynamically-configured IP addresses and phones, such endpoints have dynamically-configured IP addresses and
host names, and must be deployed with nearly zero configuration. For host names, and must be deployed with nearly zero configuration. For
such an endpoint, it is for practical purposes impossible to obtain a such an endpoint, it is for practical purposes impossible to obtain a
certificate signed by a well-known certificate authority. certificate signed by a well-known certificate authority.
skipping to change at page 6, line 21 skipping to change at page 6, line 25
3.4 Example SDP Description For TLS Connection 3.4 Example SDP Description For TLS Connection
Figure 1 illustrates an SDP offer which signals the availability of a 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 T.38 fax session over TLS. For the purpose of brevity, the main
portion of the session description is omitted in the example, showing portion of the session description is omitted in the example, showing
only the m= line and its attributes. (This example is the same as 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 the first one in [2], except for the proto parameter and the
fingerprint attribute.) See the subsequent sections for explanations fingerprint attribute.) See the subsequent sections for explanations
of the example's TLS-specific attributes. of the example's TLS-specific attributes.
(Note that the example uses MD5 as its one-way hash function, even (Note: due to RFC formatting conventions, this draft splits SDP
though SHA-1 is preferred. This has been done only because the across lines whose content would exceed 72 characters. A backslash
longer SHA-1 fingerprint would cause that line of the example to be character marks where this line folding has taken place. This
wider than the number of characters allowed in an Internet-Draft.) backslash and its trailing CRLF and whitespace would not appear in
actual SDP content.)
m=image 54111 TCP/TLS t38 m=image 54111 TCP/TLS t38
c=IN IP4 10.1.1.2 c=IN IP4 192.0.2.2
a=setup:passive a=setup:passive
a=connid:1 a=connection:new
a=fingerprint:MD5 48:AA:D8:BA:36:7C:6D:70:7F:81:BB:BA:ED:6D:B8:C7 a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 1: Example SDP Description Offering a TLS Media Stream Figure 1: Example SDP Description Offering a TLS Media Stream
4. Protocol Identifiers 4. Protocol Identifiers
The m= line in SDP specifies, among other items, the transport The m= line in SDP specifies, among other items, the transport
protocol to be used for the media in the session. See the "Media protocol to be used for the media in the session. See the "Media
Descriptions" section of SDP [1] for a discussion on transport Descriptions" section of SDP [1] for a discussion on transport
protocol identifiers. protocol identifiers.
This specification defines a new protocol identifier, TCP/TLS, which This specification defines a new protocol identifier, TCP/TLS, which
indicates that the media described will use the Transport Layer indicates that the media described will use the Transport Layer
Security protocol [3] over TCP. (Using TLS over other transport Security protocol [3] over TCP. (Using TLS over other transport
protocols is not discussed by this document.) An m= line that protocols is not discussed by this document.) The TCP/TLS protocol
specifies TCP/TLS MUST further qualify the protocol using a fmt identifier describes only the transport protocol, not the upper-layer
identifier, to indicate the application being run over TLS. 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.
As TLS sessions are connection-oriented, media sessions described in As TLS sessions are connection-oriented, media sessions described in
this manner follow the procedures defined in the connection-oriented this manner follow the procedures defined in the connection-oriented
media specification [2]. They also use the attributes defined in media specification [2]. They also use the attributes defined in
that specification, "a=setup" and "a=connid". that specification, "a=setup" and "a=connection".
5. Fingerprint Attribute 5. Fingerprint Attribute
Parties to a TLS session indicate their identities by presenting Parties to a TLS session indicate their identities by presenting
authentication certificates as part of the TLS handshake procedure. authentication certificates as part of the TLS handshake procedure.
Authentication certificates are X.509 [6] certificates, as profiled Authentication certificates are X.509 [6] certificates, as profiled
by RFC 3279 [7] and RFC 3280 [8]. by RFC 3279 [7] and RFC 3280 [8].
In order to associate media streams with connections, and to prevent In order to associate media streams with connections, and to prevent
unauthorized barge-in attacks on the media streams, endpoints MAY unauthorized barge-in attacks on the media streams, endpoints MAY
skipping to change at page 7, line 36 skipping to change at page 7, line 43
Internet Explorer display them when viewing the details of a Internet Explorer display them when viewing the details of a
certificate.) certificate.)
A fingerprint is represented in SDP as an attribute (an "a=" line). A fingerprint is represented in SDP as an attribute (an "a=" line).
It consists of the name of the hash function used, followed by the It consists of the name of the hash function used, followed by the
hash value itself. The hash value is represented as a sequence of hash value itself. The hash value is represented as a sequence of
upper-case hexadecimal 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 [16], which uses unseparated lower-case hexadecimal authentication [17], 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 [9] in Figure 2. This syntax extends the BNF syntax Backus-Naur Form [9] in Figure 2. This syntax extends the BNF syntax
of SDP [1]. of SDP [1].
attribute =/ fingerprint-attribute attribute =/ fingerprint-attribute
fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint
skipping to change at page 8, line 24 skipping to change at page 8, line 24
; Each byte in upper-case hex, separated ; Each byte in upper-case hex, separated
; by colons. ; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercase UHEX = DIGIT / %x41-46 ; A-F uppercase
Figure 2: 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 one-way A certificate fingerprint SHOULD be computed using the same one-way
hash function as is used in the certificate's signature algorithm. hash function as is used in the certificate's signature algorithm.
(This guarantees that the fingerprint will be usable by the other (This guarantees that the fingerprint will be usable by the other
endpoint so long as the certificate itself is.) Following RFC 3279 endpoint, so long as the certificate itself is.) Following RFC 3279
[7], therefore, the defined hash functions are SHA-1 [10][17], MD5 [7], therefore, the defined hash functions are SHA-1 [10][18], MD5
[11], and MD2 [12], with SHA-1 preferred. Additional hash functions [11], and MD2 [12], with SHA-1 preferred. Additional hash functions
can be defined only by standards-track RFCs which update or obsolete can be defined only by standards-track RFCs which update or obsolete
RFC 3279 [7]. RFC 3279 [7]. Self-signed certificates (for which legacy
certificates are not a consideration) MUST use SHA-1 in their
signature algorithm, and thus also MUST use it to calculate
certificate fingerprints.
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.
6. Endpoint Identification 6. Endpoint Identification
6.1 Certificate Choice 6.1 Certificate Choice
skipping to change at page 9, line 9 skipping to change at page 9, line 12
and MUST be signed by a certificate authority known to the other and MUST be signed by a certificate authority known to the other
endpoint. endpoint.
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 in the session description's c= line. 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
c= line connection-address. Names may contain the wildcard c= line connection-address exactly. (Wildcard patterns MUST NOT
character * which is considered to match any single domain name be used.)
component or component fragment. E.g., *.a.com matches foo.a.com
but not bar.foo.a.com. f*.com matches foo.com but not bar.com.
(This last pattern is not often meaningful, but is supported by
https [18]; thus, it is allowed here as well.)
o If the SDP session description describing the session was o If the SDP session description describing the session was
transmitted over an end-to-end secure protocol which uses X.509 transmitted over an end-to-end secure protocol which uses X.509
certificates, the endpoint MAY use the same certificate to certify certificates, the endpoint MAY use the same certificate to certify
the media connection. For example, an SDP description sent over the media connection. For example, an SDP description sent over
HTTP/TLS [18] or secured by S/MIME [15] MAY use the same HTTP/TLS [19] or secured by S/MIME [16] MAY use the same
certificate to secure the media connection. (Note, however, that certificate to secure the media connection. (Note, however, that
the sips protocol [14] (SIP over TLS) provides only hop-by-hop the sips protocol [15] (SIP over TLS) provides only hop-by-hop
security, so its TLS certificates do not satisfy this criterion.) security, so its TLS certificates do not satisfy this criterion.)
In this case, the certificate must be one that is allowed in this In this case, the certificate must be one that is allowed in this
context by the transmitting protocol. context by the transmitting protocol.
In those cases where an endpoint does provide a certificate In those cases where an endpoint provides a certificate fingerprint,
fingerprint, the certificate MAY be self-signed, but MUST indicate the certificate MAY be self-signed. The certificate MUST be
some identity which has a meaningful relationship to the end point. well-formed (and thus MUST include a syntactically valid
This identity MAY be one of the identities allowed above for SubjectAltName), but no further requirements are imposed upon this
non-fingerprinted certificates, or MAY correspond to the protocol field's contents. To support the use of certificate caches, however,
over which the SDP was transmitted. For example, protocols which use as described in Section 7, endpoints SHOULD consistently provide the
URIs could include a certificate with a subjectAltName field of type same certificate for each identity they support.
uniformResourceIdentifier with a value matching the endpoint's URI.
6.2 Certificate Presentation 6.2 Certificate Presentation
In all cases, an endpoint acting as the TLS server, i.e., one taking In all cases, an endpoint acting as the TLS server, i.e., one taking
the a=setup:passive role, in the terminology of connection-oriented the a=setup:passive role, in the terminology of connection-oriented
media, MUST present a certificate during TLS initiation, following media, MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, or, if there is no fingerprint, the match the original fingerprint, or, if there is no fingerprint, the
certificate identity is incorrect, the client endpoint MUST either certificate identity is incorrect, the client endpoint MUST either
notify the user, if possible, or terminate the media connection with notify the user, if possible, or terminate the media connection with
skipping to change at page 10, line 18 skipping to change at page 10, line 16
for a media connection to outrace the answer back to the offerer. for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a setup:passive or setup:actpass Thus, if the offerer has offered a setup:passive or setup:actpass
role, it MUST (as specified in the Connection-Oriented Media role, it MUST (as specified in the Connection-Oriented Media
specification [2]) begin listening for an incoming connection as soon specification [2]) begin listening for an incoming connection as soon
as it sends its offer. However, because its peer's media connection as it sends its offer. However, because its peer's media connection
may outrace its answer, it SHOULD NOT definitively accept or reject may outrace its answer, it SHOULD NOT definitively accept or reject
the peer's certificate until it has received and processed the SDP the peer's certificate until it has received and 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 [13]), the TLS server typically has no Session Announcement Protocol [14]), the TLS server typically has no
external knowledge of what the TLS 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.
7. Security Considerations 7. Security Considerations
This entire document concerns itself with security. The problem to This entire document concerns itself with security. The problem to
be solved is addressed in Section 1, and a high-level overview is be solved is addressed in Section 1, and a high-level overview is
presented in Section 3. presented in Section 3. See the SDP specification [1] for security
considerations applicable to SDP in general.
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 integrity and confidentiality of the SDP security ensure the integrity and confidentiality of the SDP security
descriptions. Therefore, the application protocol SHOULD either descriptions. Therefore, the application protocol SHOULD either
invoke its own security mechanisms (e.g., secure multiparts) or invoke its own security mechanisms (e.g., secure multiparts) or
alternatively utilize a lower-layer security service (e.g., TLS or alternatively utilize a lower-layer security service (e.g., TLS or
IPSec). This security service SHOULD provide strong message IPSec). This security service SHOULD provide strong message
authentication and packet-payload encryption as well as effective authentication and packet-payload encryption as well as effective
replay protection. replay protection.
However, such integrity protection is not always possible. For these
cases, end systems SHOULD maintain a cache of certificates which
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 and unauthenticated
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 [20], 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.)
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- or lower-level
protocol may be appropriate. For example, RTP and RTCP packets may security protocol may be appropriate.
be sent over a connection-oriented transport [19]. In this case, it
may be more appropriate to use the Secure RTP protocol [20] with This document does not define any mechanism for securely transporting
appropriate SDP descriptions [21]. RTP and 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
[22], 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.
8. IANA Considerations 8. IANA Considerations
This document defines an SDP proto value: TCP/TLS. Its format is This document defines an SDP proto value: TCP/TLS. Its format is
defined in Section 4. This proto value should be registered by IANA defined in Section 4. This proto value should be registered by IANA
on http://www.iana.org/assignments/sdp-parameters under "proto". on http://www.iana.org/assignments/sdp-parameters under "proto".
This document defines an SDP session and media level attribute: This document defines an SDP session and media level attribute:
fingerprint. Its format is defined in Section 5. This attribute fingerprint. Its format is defined in Section 5. This attribute
should be registered by IANA on should be registered by IANA on
http://www.iana.org/assignments/sdp-parameters under "att-field (both http://www.iana.org/assignments/sdp-parameters under "att-field (both
session and media level)". session and media level)".
Specifications defining new proto values, like 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 [13] by
production of, or reference to, a standards-track RFC that defines
the transport protocol for the format.
Appendix A. Changes From Earlier Versions
Appendix A.1 Changes From Draft -01
o Made the use of SHA-1 fingerprints mandatory in self-signed
certificates.
o Aligned with version -09 of draft-ietf-mmusic-comedia [2], also
drawing some wording changes from that document.
o Forbid the use of wildcards for the dNS subjectAltName.
o Eliminated requirements on identities provided with self-signed
certificates.
o Recommended the use of a certificate cache when SDP integrity
protection cannot be assured.
o Explained that there is no currently supported mechanism for
securely sending RTP over connection-oriented media.
o Described the procedure for establishing media formats for TCP/
TLS.
Appendix A.2 Changes From Draft -00
o Significantly expanded introduction and motivation sections.
o Significant clarifications to other sections.
o Aligned with version -07 of draft-ietf-mmusic-comedia [2].
Protocol identifier changed from TLS to TCP/TLS at that document's
recommendation.
9. References 9. References
9.1 Normative References 9.1 Normative References
[1] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session [1] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-18 (work in Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in
progress), June 2004. progress), September 2004.
[2] Yon, D., "Connection-Oriented Media Transport in the Session [2] Yon, D., "Connection-Oriented Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-07 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-09
(work in progress), June 2004. (work in progress), September 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
skipping to change at page 12, line 12 skipping to change at page 13, line 19
[10] National Institute of Standards and Technology, "Secure Hash [10] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992. 1992.
[12] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, [12] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
April 1992. April 1992.
[13] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
9.2 Informative References 9.2 Informative References
[13] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [14] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[15] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [16] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999. 2633, June 1999.
[16] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[17] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [18] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001. RFC 3174, September 2001.
[18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [19] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[19] Lazzaro, J., "Framing RTP and RTCP Packets over [20] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
Connection-Oriented Transport", draft-ietf-secsh-architecture-16 (work in progress), June 2004.
draft-ietf-avt-rtp-framing-contrans-01 (work in progress),
March 2004.
[20] Baugher, M., "The Secure Real-time Transport Protocol", [21] 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 [22] Lazzaro, J., "Framing RTP and RTCP Packets over
Connection-Oriented Transport",
draft-ietf-avt-rtp-framing-contrans-03 (work in progress), July
2004.
[23] 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-04 (work in progress), May draft-ietf-mmusic-sdescriptions-07 (work in progress), July
2004. 2004.
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
 End of changes. 

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