draft-ietf-mmusic-comedia-tls-04.txt   draft-ietf-mmusic-comedia-tls-05.txt 
Multiparty Multimedia Session J. Lennox Multiparty Multimedia Session J. Lennox
Control Columbia U. Control Columbia U.
Expires: January 7, 2006 Expires: January 2, 2006
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-04 draft-ietf-mmusic-comedia-tls-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 7, 2006. This Internet-Draft will expire on January 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
A. Changes From Earlier Versions . . . . . . . . . . . . . . . . 12 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 12
A.1 Changes From Draft -03 . . . . . . . . . . . . . . . . . . 12 Appendix A.1. Changes From Draft -04 . . . . . . . . . . . . . . . 12
A.2 Changes From Draft -02 . . . . . . . . . . . . . . . . . . 12 Appendix A.2. Changes From Draft -03 . . . . . . . . . . . . . . . 12
A.3 Changes From Draft -01 . . . . . . . . . . . . . . . . . . 12 Appendix A.3. Changes From Draft -02 . . . . . . . . . . . . . . . 12
A.4 Changes From Draft -00 . . . . . . . . . . . . . . . . . . 13 Appendix A.4. Changes From Draft -01 . . . . . . . . . . . . . . . 13
Appendix A.5. Changes From Draft -00 . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2 Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
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 connection- part of a multimedia session, a media stream which uses a connection-
oriented transport. The document Connection-Oriented Media Transport oriented transport. The document Connection-Oriented Media Transport
in the Session Description Protocol (SDP) [2] specifies a general in the Session Description Protocol (SDP) [2] specifies a general
mechanism for describing and establishing such connection-oriented mechanism for describing and establishing such connection-oriented
skipping to change at page 4, line 22 skipping to change at page 4, line 22
"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
This section discusses the threat model which motivates TLS transport This section discusses the threat model which motivates TLS transport
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 Announcement Protocol (SAP) [15], in which SDP session Session Announcement Protocol (SAP) [15], 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. (Connection- conferences, but unicast sessions are also possible. (Connection-
skipping to change at page 4, line 48 skipping to change at page 5, line 5
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)
[16]. [16].
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
traffic associated with a multimedia session. This attacker might, traffic associated with a multimedia session. This attacker might,
for example, be on the same local-area or wireless network as one of for example, be on the same local-area or wireless network as one of
skipping to change at page 5, line 39 skipping to change at page 5, line 44
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 [17] can be used to mechanism; SIP, for example, defines how S/MIME [17] 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.
If two endpoints have no prior relationship, self-signed certificates If two endpoints have no prior relationship, self-signed certificates
cannot generally be trusted, as there is no guarantee that an cannot generally be trusted, as there is no guarantee that an
attacker is not launching a man-in-the-middle attack. Fortunately, attacker is not launching a man-in-the-middle attack. Fortunately,
however, if the integrity of SDP session descriptions can be assured, however, if the integrity of SDP session descriptions can be assured,
it is possible to consider those SDP descriptions themselves as a it is possible to consider those SDP descriptions themselves as a
prior relationship: certificates can be securely described in the prior relationship: certificates can be securely described in the
session description itself. This is done by providing a secure hash session description itself. This is done by providing a secure hash
of a certificate, or "certificate fingerprint", as an SDP attribute; of a certificate, or "certificate fingerprint", as an SDP attribute;
this mechanism is described in Section 5. this mechanism is described in Section 5.
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: due to RFC formatting conventions, this draft splits SDP (Note: due to RFC formatting conventions, this draft splits SDP
skipping to change at page 8, line 44 skipping to change at page 8, line 44
224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and 224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and
thus also MUST use it to calculate certificate fingerprints. thus also MUST use it to calculate certificate fingerprints.
The fingerprint attribute may be either a session-level or a media- The fingerprint attribute may be either a session-level or a media-
level SDP attribute. If it is a session-level attribute, it applies level SDP attribute. If it is a session-level attribute, it applies
to all TLS sessions for which no media-level fingerprint attribute is to all TLS sessions for which no media-level fingerprint attribute is
defined. defined.
6. Endpoint Identification 6. Endpoint Identification
6.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 [8]. 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.
The certificate presented by an endpoint MUST correspond to one of The certificate presented by an endpoint MUST correspond to one of
the following identities: the following identities:
skipping to change at page 9, line 38 skipping to change at page 9, line 38
normally would be expected to), the endpoint MAY use the same normally would be expected to), the endpoint MAY use the same
certificate to certify the media connection. For example, an SDP certificate to certify the media connection. For example, an SDP
description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY use description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY use
the same certificate to secure the media connection. (Note, however, the same certificate to secure the media connection. (Note, however,
that the sips protocol [16] (SIP over TLS) provides only hop-by-hop that the sips protocol [16] (SIP over TLS) provides only hop-by-hop
security, so its TLS certificates do not satisfy this criterion.) To security, so its TLS certificates do not satisfy this criterion.) To
support the use of certificate caches, as described in Section 7, support the use of certificate caches, as described in Section 7,
endpoints SHOULD consistently provide the same certificate for each endpoints SHOULD consistently provide the same certificate for each
identity they support. identity they support.
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 'setup:passive' role, in the terminology of connection-oriented the 'setup:passive' role, in the terminology of connection-oriented
media, MUST present a certificate during TLS initiation, following media, MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, 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
a bad certificate error. a bad certificate error.
skipping to change at page 11, line 13 skipping to change at page 11, line 14
protection for SDP, the security of this document's mechanism is protection for SDP, the security of this document's mechanism is
equivalent to that of the Secure Shell (ssh) protocol [21], which is equivalent to that of the Secure Shell (ssh) protocol [21], which is
vulnerable to man-in-the-middle attacks when two parties first vulnerable to man-in-the-middle attacks when two parties first
communicate, but can detect ones that occur subsequently. (Note that communicate, but can detect ones that occur subsequently. (Note that
a precise definition of the "other party" depends on the application a precise definition of the "other party" depends on the application
protocol carrying the SDP message.) protocol carrying the SDP message.)
Depending on how SDP messages are transmitted, it is not always Depending on how SDP messages are transmitted, it is not always
possible to determine whether a uniformResourceIdentifier possible to determine whether a uniformResourceIdentifier
subjectAltName presented in a remote certificate is expected or not subjectAltName presented in a remote certificate is expected or not
for the remote party. In particular, given call forwarding and for the remote party. In particular, given call forwarding, third-
third-party call control, it is not always possible in SIP to party call control, or session descriptions generated by endpoints
determine what entity ought to have generated a remote SDP response. controlled by the Gateway Control Protocol [22], it is not always
In some cases this determination may need to be made by a human, as possible in SIP to determine what entity ought to have generated a
automated logic may not be able to determine correctness. (For remote SDP response. In some cases this determination may need to be
example, "You placed this call to sip:alice@example.com, but the made by a human, as automated logic may not be able to determine
remote certificate presented belongs to sip:bob@example.com. correctness. (For example, "You placed this call to
Continue?") This issue is not one specific to this specification; sip:alice@example.com, but the remote certificate presented belongs
the same consideration applies for S/MIME-signed SDP carried over to sip:bob@example.com. Continue?") This issue is not one specific
SIP. to this specification; the same consideration applies for S/MIME-
signed SDP carried over SIP.
TLS is not always the most appropriate choice for secure connection- TLS is not always the most appropriate choice for secure connection-
oriented media; in some cases, a higher- or lower-level security oriented media; in some cases, a higher- or lower-level security
protocol may be appropriate. protocol may be appropriate.
This document does not define any mechanism for securely transporting This document does not define any mechanism for securely transporting
RTP and RTCP packets over a connection-oriented channel. There was 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 no consensus in the working group as to whether it would be better to
send Secure RTP packets [22] over a connection-oriented transport send Secure RTP packets [23] over a connection-oriented transport
[23], or whether it would be better to send standard unsecured RTP [24], or whether it would be better to send standard unsecured RTP
packets over TLS using the mechanisms described in this document. packets over TLS using the mechanisms described in this document.
The group consensus was to wait until a use-case requiring secure The group consensus was to wait until a use-case requiring secure
connection-oriented RTP was presented. 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 under "Session Description Protocol (SDP) Parameters" under on under "Session Description Protocol (SDP) Parameters" under
"proto". "proto".
skipping to change at page 12, line 16 skipping to change at page 12, line 20
the format is encouraged. If no MIME subtype exists, it is the format is encouraged. If no MIME subtype exists, it is
RECOMMENDED that a suitable one be registered through the IETF RECOMMENDED that a suitable one be registered through the IETF
process [14] by production of, or reference to, a standards-track RFC process [14] by production of, or reference to, a standards-track RFC
that defines the transport protocol for the format. that defines the transport protocol for the format.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
Appendix A.1 Changes From Draft -03 Appendix A.1. Changes From Draft -04
The section discussing the difficulty of knowing what URI identities
are appropriate for SDP was expanded, adding a reference to the
Gateway Control Protocol.
An un-cited informative reference was removed.
Appendix A.2. Changes From Draft -03
The number of options in the protocol were significantly reduced: a The number of options in the protocol were significantly reduced: a
number of SHOULD requirements were elevated to MUST. Notably, the number of SHOULD requirements were elevated to MUST. Notably, the
use of the 'fingerprint' attribute, strict certificate identity use of the 'fingerprint' attribute, strict certificate identity
choices, and the use of the same digest algorithm for fingerprints as choices, and the use of the same digest algorithm for fingerprints as
for certificates were all made mandatory. for certificates were all made mandatory.
Support for the digest algorithms from FIPS 180-2 [11] / RFC 4055 [9] Support for the digest algorithms from FIPS 180-2 [11] / RFC 4055 [9]
('SHA-224', 'SHA-256', 'SHA-384', and 'SHA-512') was added. ('SHA-224', 'SHA-256', 'SHA-384', and 'SHA-512') was added.
Discussion was added about the difficulty of automatically Discussion was added about the difficulty of automatically
determining the URI a remote endpoint's certificate should assert, determining the URI a remote endpoint's certificate should assert,
especially in SIP in the presence of call forwarding or third-party especially in SIP in the presence of call forwarding or third-party
call control. call control.
The document was aligned with version -10 of The document was aligned with version -10 of
draft-ietf-mmusic-comedia [2]. This consisted mostly of wording and draft-ietf-mmusic-comedia [2]. This consisted mostly of wording and
formatting changes. formatting changes.
Appendix A.2 Changes From Draft -02 Appendix A.3. Changes From Draft -02
None, other than IPR boilerplate and reference updates. Draft -03 None, other than IPR boilerplate and reference updates. Draft -03
was a resubmission to refresh the draft's presence in the Internet- was a resubmission to refresh the draft's presence in the Internet-
Drafts repository. Drafts repository.
Appendix A.3 Changes From Draft -01 Appendix A.4. Changes From Draft -01
o Made the use of SHA-1 fingerprints mandatory in self-signed o Made the use of SHA-1 fingerprints mandatory in self-signed
certificates. certificates.
o Aligned with version -09 of draft-ietf-mmusic-comedia [2], also o Aligned with version -09 of draft-ietf-mmusic-comedia [2], also
drawing some wording changes from that document. drawing some wording changes from that document.
o Forbid the use of wildcards for the dNS subjectAltName. o Forbid the use of wildcards for the dNS subjectAltName.
o Eliminated requirements on identities provided with self-signed o Eliminated requirements on identities provided with self-signed
certificates. certificates.
o Recommended the use of a certificate cache when SDP integrity o Recommended the use of a certificate cache when SDP integrity
protection cannot be assured. protection cannot be assured.
o Explained that there is no currently supported mechanism for o Explained that there is no currently supported mechanism for
securely sending RTP over connection-oriented media. securely sending RTP over connection-oriented media.
o Described the procedure for establishing media formats for TCP/ o Described the procedure for establishing media formats for TCP/
TLS. TLS.
Appendix A.4 Changes From Draft -00 Appendix A.5. Changes From Draft -00
o Significantly expanded introduction and motivation sections. o Significantly expanded introduction and motivation sections.
o Significant clarifications to other sections. o Significant clarifications to other sections.
o Aligned with version -07 of draft-ietf-mmusic-comedia [2]. o Aligned with version -07 of draft-ietf-mmusic-comedia [2].
Protocol identifier changed from TLS to TCP/TLS at that document's Protocol identifier changed from TLS to TCP/TLS at that document's
recommendation. recommendation.
9. References 9. References
9.1 Normative References 9.1. Normative References
[1] Handley, M., "SDP: Session Description Protocol", [1] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. draft-ietf-mmusic-sdp-new-25 (work in progress), July 2005.
[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-10 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10
(work in progress), November 2004. (work in progress), November 2004.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 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.
skipping to change at page 14, line 27 skipping to change at page 14, line 39
[12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [12] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, [13] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
April 1992. April 1992.
[14] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet [14] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", Mail Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 2048, November 1996. BCP 13, RFC 2048, November 1996.
9.2 Informative References 9.2. Informative References
[15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [15] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [16] 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.
[17] Ramsdell, B., "S/MIME Version 3 Message Specification", [17] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
skipping to change at page 14, line 52 skipping to change at page 15, line 16
[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001. RFC 3174, September 2001.
[20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [20] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[21] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", [21] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-22 (work in progress), draft-ietf-secsh-architecture-22 (work in progress),
March 2005. March 2005.
[22] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003.
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[23] Lazzaro, J., "Framing RTP and RTCP Packets over Connection- [24] Lazzaro, J., "Framing RTP and RTCP Packets over Connection-
Oriented Transport", draft-ietf-avt-rtp-framing-contrans-05 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06
(work in progress), January 2005. (work in progress), September 2005.
[24] Andreasen, F., "Session Description Protocol Security
Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-11 (work in progress),
June 2005.
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. 26 change blocks. 
53 lines changed or deleted 59 lines changed or added

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