draft-ietf-mmusic-comedia-tls-05.txt   draft-ietf-mmusic-comedia-tls-06.txt 
Multiparty Multimedia Session J. Lennox Multiparty Multimedia Session J. Lennox
Control Columbia U. Control Columbia U.
Expires: January 2, 2006 Expires: September 4, 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-05 draft-ietf-mmusic-comedia-tls-06
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 2, 2006. This Internet-Draft will expire on September 4, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies how to establish secure connection-oriented This document specifies how to establish secure connection-oriented
media transport sessions over the Transport Layer Security (TLS) media transport sessions over the Transport Layer Security (TLS)
protocol using the Session Description Protocol (SDP). It defines a protocol using the Session Description Protocol (SDP). It defines a
new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax
and semantics for an SDP 'fingerprint' attribute that identifies the and semantics for an SDP 'fingerprint' attribute that identifies the
certificate 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.
This revision of the document reflects comments made during IESG
review.
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 . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Changes From Earlier Versions . . . . . . . . . . . 12 Appendix A. Changes From Earlier Versions . . . . . . . . . . . 13
Appendix A.1. Changes From Draft -04 . . . . . . . . . . . . . . . 12 Appendix A.1. Changes From Draft -05 . . . . . . . . . . . . . . . 13
Appendix A.2. Changes From Draft -03 . . . . . . . . . . . . . . . 12 Appendix A.2. Changes From Draft -04 . . . . . . . . . . . . . . . 14
Appendix A.3. Changes From Draft -02 . . . . . . . . . . . . . . . 12 Appendix A.3. Changes From Draft -03 . . . . . . . . . . . . . . . 14
Appendix A.4. Changes From Draft -01 . . . . . . . . . . . . . . . 13 Appendix A.4. Changes From Draft -02 . . . . . . . . . . . . . . . 15
Appendix A.5. Changes From Draft -00 . . . . . . . . . . . . . . . 13 Appendix A.5. Changes From Draft -01 . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A.6. Changes From Draft -00 . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
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. RFC 4145, Connection-Oriented Media Transport in
in the Session Description Protocol (SDP) [2] specifies a general 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
streams; however, the only transport protocol it directly supports is streams; however, the only transport protocol it directly supports is
TCP. In many cases, session participants wish to provide TCP. In many cases, session participants wish to provide
confidentiality, data integrity, and authentication for their media confidentiality, data integrity, and authentication for their media
sessions. This document therefore extends the Connection-Oriented sessions. This document therefore extends the Connection-Oriented
Media specification to allow session descriptions to describe media Media specification to allow session descriptions to describe media
sessions that use the Transport Layer Security (TLS) protocol [3]. sessions that use the Transport Layer Security (TLS) protocol [3].
The TLS protocol allows applications to communicate over a channel The TLS protocol allows applications to communicate over a channel
which provides privacy and data integrity. The TLS specification, which provides confidentiality and data integrity. The TLS
however, does not specify how specific protocols establish and use specification, however, does not specify how specific protocols
this secure channel; particularly, TLS leaves the question of how to establish and use this secure channel; particularly, TLS leaves the
interpret and validate authentication certificates as an issue for question of how to interpret and validate authentication certificates
the protocols which run over TLS. This document specifies such usage as an issue for the protocols which run over TLS. This document
for the case of connection-oriented media transport. specifies such usage for the case of connection-oriented media
transport.
Complicating this issue, endpoints exchanging media will often be Complicating this issue, endpoints exchanging media will often be
unable to obtain authentication certificates signed by a well-known unable to obtain authentication certificates signed by a well-known
root certificate authority (CA). Most certificate authorities charge root certification authority (CA). Most certificate authorities
for signed certificates, particularly host-based certificates; charge 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 certification 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. Furthermore, in many cases endpoints' IP addresses correct party. Furthermore, in many cases endpoints' IP addresses
and host names are dynamic: they may be obtained from DHCP, for and host names are dynamic: they may be obtained from DHCP, for
example. It is impractical to obtain a CA-signed certificate valid example. It is impractical to obtain a CA-signed certificate valid
for the duration of a DHCP lease. For such hosts, self-signed for the duration of a DHCP lease. For such hosts, self-signed
certificates are usually the only option. This specification defines certificates are usually the only option. This specification defines
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
skipping to change at page 5, line 31 skipping to change at page 5, line 31
over the network, but who cannot modify or redirect valid traffic. over the network, but who cannot modify or redirect valid traffic.
In SDP's 'advertised' operational mode, this can barely be considered In SDP's 'advertised' operational mode, this can barely be considered
an attack; media sessions are expected to be initiated from anywhere an attack; media sessions are expected to be initiated from anywhere
on the network. In SDP's offer-answer mode, however, this type of on the network. In SDP's offer-answer mode, however, this type of
attack is more serious. An attacker could initiate a connection to attack is more serious. An attacker could initiate a connection to
one or both of the endpoints of a session, thus impersonating an 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 endpoint, or acting as a man in the middle to listen in on their
communications. To thwart these attacks, TLS uses endpoint communications. To thwart these attacks, TLS uses endpoint
certificates. So long as the certificates' private keys have not certificates. So long as the certificates' private keys have not
been compromised, the endpoints have an external trusted mechanism been compromised, the endpoints have an external trusted mechanism
(most commonly, a mutually-trusted certificate authority) to validate (most commonly, a mutually-trusted certification authority) to
certificates, and the endpoints know what certificate identity to validate certificates, and the endpoints know what certificate
expect, endpoints can be certain that such an attack has not taken identity to expect, endpoints can be certain that such an attack has
place. not taken place.
Finally, the most serious type of attacker is one who can modify or Finally, the most serious type of attacker is one who can modify or
redirect session descriptions: for example, a compromised or redirect session descriptions: for example, a compromised or
malicious SIP proxy server. Neither TLS itself, nor any mechanisms malicious SIP proxy server. Neither TLS itself, nor any mechanisms
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 certification 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 RFC 4145 [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
across lines whose content would exceed 72 characters. A backslash across lines whose content would exceed 72 characters. A backslash
character marks where this line folding has taken place. This character marks where this line folding has taken place. This
backslash and its trailing CRLF and whitespace would not appear in backslash and its trailing CRLF and whitespace would not appear in
actual SDP content.) actual SDP content.)
m=image 54111 TCP/TLS t38 m=image 54111 TCP/TLS t38
skipping to change at page 7, line 9 skipping to change at page 7, line 9
This specification defines a new protocol identifier, 'TCP/TLS', This specification defines a new protocol identifier, 'TCP/TLS',
which indicates that the media described will use the Transport Layer which 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.) The 'TCP/TLS' protocol protocols is not discussed by this document.) The 'TCP/TLS' protocol
identifier describes only the transport protocol, not the upper-layer identifier describes only the transport protocol, not the upper-layer
protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify protocol. An 'm' line that specifies 'TCP/TLS' MUST further qualify
the protocol using a fmt identifier, to indicate the application the protocol using a fmt identifier, to indicate the application
being run over TLS. being run over TLS.
Media sessions described with this identifier follow the procedures Media sessions described with this identifier follow the procedures
defined in the connection-oriented media specification [2]. They defined in RFC 4145 [2]. They also use the SDP attributes defined in
also use the SDP attributes defined in that specification, 'setup' that specification, 'setup' and 'connection'.
and '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], RFC 3280 [8] and RFC 4055 [9]. by RFC 3279 [7], RFC 3280 [8] and RFC 4055 [9].
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 MUST unauthorized barge-in attacks on the media streams, endpoints MUST
skipping to change at page 8, line 25 skipping to change at page 8, line 25
fingerprint = 2UHEX *(":" 2UHEX) fingerprint = 2UHEX *(":" 2UHEX)
; Each byte in upper-case hex, separated ; Each byte in upper-case hex, separated
; by colons. ; by colons.
UHEX = DIGIT / %x41-46 ; A-F uppercase UHEX = DIGIT / %x41-46 ; A-F uppercase
Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
A certificate fingerprint MUST be computed using the same one-way A certificate fingerprint MUST 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 ensures that the security properties required for the
endpoint, so long as the certificate itself is.) Following RFC 3279 certificate are also apply for the fingerprint. It also guarantees
[7] as updated by RFC 4055 [9], therefore, the defined hash functions that the fingerprint will be usable by the other endpoint, so long as
are 'SHA-1' [11] [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' the certificate itself is.) Following RFC 3279 [7] as updated by RFC
[11], 'SHA-512' [11], 'MD5' [12], and 'MD2' [13], with 'SHA-1' 4055 [9], therefore, the defined hash functions are 'SHA-1' [11]
preferred. Additional hash functions can be defined only by [19], 'SHA-224' [11], 'SHA-256' [11], 'SHA-384' [11], 'SHA-512' [11],
standards-track RFCs which update or obsolete RFC 3279 [7]. Self- 'MD5' [12], and 'MD2' [13], with 'SHA-1' preferred. A new IANA
signed certificates (for which legacy certificates are not a registry of Hash Function Textual Names, specified in Section 8,
allows for addition of future tokens, but they may only be added if
they are included in RFCs which update or obsolete RFC 3279 [7].
Self-signed certificates (for which legacy certificates are not a
consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA- consideration) MUST use one of the FIPS 180 algorithms (SHA-1, SHA-
224, SHA-256, SHA-384, or SHA-512) as their signature algorithm, and 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 An X.509 certificate binds an identity and a public key. If SDP
a TLS connection needs to certify an appropriate identity for the describing a TLS session is transmitted over a mechanism which
connection. Identity matching is performed using the matching rules provides integrity protection, a certificate asserting any
specified by RFC 3280 [8]. If more than one identity of a given type syntactically valid identity MAY be used. For example, an SDP
is present in the certificate (e.g., more than one dNSName name), a description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY
match in any one of the set is considered acceptable. assert any identity in the certificate securing the media connection.
The certificate presented by an endpoint MUST correspond to one of Security protocols which provide only hop-by-hop integrity
the following identities: protection, e.g., the sips protocol [16] (SIP over TLS), are
considered sufficiently secure to allow the mode in which any valid
identity is accepted. However, see Section 7 for a discussion of
some security implications of this fact.
In situations where the SDP is not integrity-protected, however, the
certificate provided for a TLS connection MUST certify an appropriate
identity for the connection. In these scenarios, the certificate
presented by an endpoint MUST certify either the SDP connection
address, or the identity of the creator of the SDP message, as
follows:
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 Similarly, if the connection address for the media description is
as a fully-qualified domain name, the endpoint MAY use a specified as a pfully-qualified domain name, the endpoint MAY use
certificate with a dNSName subjectAltName matching the specified a certificate with a dNSName subjectAltName matching the specified
'c' line connection-address exactly. (Wildcard patterns MUST NOT 'c' line connection-address exactly. (Wildcard patterns MUST NOT
be used.) be used.)
o If the SDP session description describing the session was o Alternately, if the SDP session description describing the session
transmitted over a protocol (such as SIP [16]) for which the was transmitted over a protocol (such as SIP [16]) for which the
identities of session participants are defined by uniform resource identities of session participants are defined by uniform resource
identifiers (URIs), the endpoint MAY use a certificate with a identifiers (URIs), the endpoint MAY use a certificate with a
uniformResourceIdentifier subjectAltName. The details of what uniformResourceIdentifier subjectAltName corresponding to the
URIs are appropriate are dependent on the transmitting protocol. identity of the endpoint which generated the SDP. The details of
(For more details on this, see Section 7.) what URIs are valid are dependent on the transmitting protocol.
(For more details on the validity of URIs, see Section 7.)
If the SDP session description describing the session was transmitted Identity matching is performed using the matching rules specified by
over an end-to-end secure protocol which uses X.509 certificates, and RFC 3280 [8]. If more than one identity of a given type is present
the certificates sent fulfill the requirements above (as they in the certificate (e.g., more than one dNSName name), a match in any
normally would be expected to), the endpoint MAY use the same one of the set is considered acceptable. To support the use of
certificate to certify the media connection. For example, an SDP certificate caches, as described in Section 7, endpoints SHOULD
description sent over HTTP/TLS [20] or secured by S/MIME [17] MAY use consistently provide the same certificate for each identity they
the same certificate to secure the media connection. (Note, however, support.
that the sips protocol [16] (SIP over TLS) provides only hop-by-hop
security, so its TLS certificates do not satisfy this criterion.) To
support the use of certificate caches, as described in Section 7,
endpoints SHOULD consistently provide the same certificate for each
identity they support.
6.2. Certificate Presentation 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, the client endpoint MUST terminate
certificate identity is incorrect, the client endpoint MUST either the media connection with a bad_certificate error.
notify the user, if possible, or terminate the media connection with
a bad certificate error.
If the SDP offer/answer model [5] is being used, the client (the If the SDP offer/answer model [5] is being used, the client (the
endpoint with the 'setup:active' role) MUST also present a endpoint with the 'setup:active' role) MUST also present a
certificate following the rules of Section 6.1. The server MUST certificate following the rules of Section 6.1. The server MUST
request a certificate, and if the client does not provide one, if the request a certificate, and if the client does not provide one, or if
certificate does not match the provided fingerprint, or, if there was the certificate does not match the provided fingerprint, the server
no fingerprint, the certificate identity is incorrect, the server endpoint MUST terminate the media connection with a bad_certificate
endpoint MUST either notify the user or terminate the media 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 '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 RFC 4145 [2]) begin listening for an
specification [2]) begin listening for an incoming connection as soon incoming connection as soon as it sends its offer. However, it MUST
as it sends its offer. However, because its peer's media connection NOT assume the data transmitted over the TLS connection is valid
may outrace its answer, it MUST NOT definitively accept the peer's until it has received a matching fingerprint in an SDP answer. If
certificate until it has received and processed the SDP answer. the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
If offer/answer is not being used (e.g., if the SDP was sent over the If offer/answer is not being used (e.g., if the SDP was sent over the
Session Announcement Protocol [15]), the TLS server typically has no Session Announcement Protocol [15]), there is no secure channel
external knowledge of what the TLS client's identity ought to be. In available for clients to communicate certificate fingerprints to
this case, no client certificate need be presented, and no servers. In this case, servers MAY request client certificates,
certificate validation can be performed, unless the server has which SHOULD be signed by a well-known certification authority, or
knowledge of valid clients through some external means. MAY allow clients to connect without a certificate.
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. See the SDP specification [1] for security presented in Section 3. See the SDP specification [1] for security
considerations applicable to SDP in general. considerations applicable to SDP in general.
Offering an TCP/TLS connection in SDP (or agreeing to one in SDP
offer/answer mode) does not create an obligation for an endpoint to
accept any TLS connection with the given fingerprint. Instead, the
endpoint must engage in the standard TLS negotiation procedure to
ensure that the TLS stream cypher and MAC algorithm chosen meet the
security needs of the higher-level application. (For example, an
offered stream cypher of TLS_NULL_WITH_NULL_NULL SHOULD be rejected
in almost every application scenario.)
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 of the SDP security descriptions. Therefore,
descriptions. Therefore, the application protocol SHOULD either the application protocol SHOULD either invoke its own security
invoke its own security mechanisms (e.g., secure multiparts) or mechanisms (e.g., secure multiparts) or alternatively utilize a
alternatively utilize a lower-layer security service (e.g., TLS or lower-layer security service (e.g., TLS or IPsec). This security
IPSec). This security service SHOULD provide strong message service SHOULD provide strong message authentication as well as
authentication and packet-payload encryption as well as effective effective replay protection.
replay protection.
However, such integrity protection is not always possible. For these However, such integrity protection is not always possible. For these
cases, end systems SHOULD maintain a cache of certificates which cases, end systems SHOULD maintain a cache of certificates which
other parties have previously presented using this mechanism. If other parties have previously presented using this mechanism. If
possible, users SHOULD be notified when an unsecured certificate possible, users SHOULD be notified when an unsecured certificate
associated with a previously unknown end system is presented, and associated with a previously unknown end system is presented, and
SHOULD be strongly warned if a different and unauthenticated SHOULD be strongly warned if a different unsecured certificate is
certificate is presented by a party with which they have communicated presented by a party with which they have communicated in the past.
in the past. In this way, even in the absence of integrity In this way, even in the absence of integrity protection for SDP, the
protection for SDP, the security of this document's mechanism is security of this document's mechanism is equivalent to that of the
equivalent to that of the Secure Shell (ssh) protocol [21], which is Secure Shell (ssh) protocol [21], which is vulnerable to man-in-the-
vulnerable to man-in-the-middle attacks when two parties first middle attacks when two parties first communicate, but can detect
communicate, but can detect ones that occur subsequently. (Note that ones that occur subsequently. (Note that a precise definition of the
a precise definition of the "other party" depends on the application "other party" depends on the application protocol carrying the SDP
protocol carrying the SDP message.) message.) Users SHOULD NOT, however, in any circumstances be
notified about certificates described in SDP descriptions sent over
an integrity-protected channel.
Depending on how SDP messages are transmitted, it is not always To aid interoperability and deployment, security protocols which
possible to determine whether a uniformResourceIdentifier provide only hop-by-hop integrity protection, e.g., the sips protocol
subjectAltName presented in a remote certificate is expected or not [16] (SIP over TLS), are considered sufficiently secure to allow the
for the remote party. In particular, given call forwarding, third- mode in which any syntactially valid identity is accepted in a
party call control, or session descriptions generated by endpoints certificate. This decision was made because sips is currently the
controlled by the Gateway Control Protocol [22], it is not always integrity mechanism most likely to be used in deployed networks in
possible in SIP to determine what entity ought to have generated a the short to medium-term. However, in this mode, SDP integrity is
remote SDP response. In some cases this determination may need to be vulnerable to attacks by compromised or malicious middleboxes, e.g.
made by a human, as automated logic may not be able to determine SIP proxy servers. End systems MAY warn users about SDP sessions
correctness. (For example, "You placed this call to that are secured in only a hop-by-hop manner, and definitions of
sip:alice@example.com, but the remote certificate presented belongs media formats running over TCP/TLS MAY specify that only end-to-end
to sip:bob@example.com. Continue?") This issue is not one specific integrity mechanisms are to be used.
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- Depending on how SDP messages are transmitted, it is not always
oriented media; in some cases, a higher- or lower-level security possible to determine whether a subjectAltName presented in a remote
protocol may be appropriate. certificate is expected or not for the remote party. In particular,
given call forwarding, third-party call control, or session
descriptions generated by endpoints controlled by the Gateway Control
Protocol [22], it is not always possible in SIP to determine what
entity ought to have generated a remote SDP response. In general,
when not using authenticity and integrity protection of SDP
descriptions, a certificate transmitted over SIP SHOULD assert the
endpoint's SIP Address of Record as a uniformResourceIndicator
subjectAltName. When an endpoint receives a certificate over SIP
asserting an identity (including an iPAddress or dNSName identity)
other than the one to which it placed or received the call, it SHOULD
alert the user and ask for confirmation. This applies whether
certificates are self-signed, or signed by certification authorities;
a certificate for sip:bob@example.com may be legitimately signed by a
certification authority, but may still not be acceptable for a call
to sip:alice@example.com. (This issue is not one specific to this
specification; the same consideration applies for S/MIME-signed SDP
carried over SIP.)
This document does not define any mechanism for securely transporting 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 [23] over a connection-oriented transport send Secure RTP packets [23] over a connection-oriented transport
[24], 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.
TLS is not always the most appropriate choice for secure connection-
oriented media; in some cases, a higher- or lower-level security
protocol may be appropriate.
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".
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 under "Session Description Protocol should be registered by IANA under "Session Description Protocol
(SDP) Parameters" under "att-field (both session and media level)". (SDP) Parameters" under "att-field (both session and media level)".
The SDP specification, RFC2327, states that specifications defining The SDP specification [1] states that specifications defining new
new proto values, like the 'TCP/TLS' proto value defined in this one, proto values, like the 'TCP/TLS' proto value defined in this one,
must define the rules by which their media format (fmt) namespace is must define the rules by which their media format (fmt) namespace is
managed. For the TCP/TLS protocol, new formats SHOULD have an managed. For the TCP/TLS protocol, new formats SHOULD have an
associated MIME registration. Use of an existing MIME subtype for associated MIME registration. Use of an existing MIME subtype for
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.
This specification creates a new IANA registry named "Hash Function
Textual Names". It will not be part of the SDP Parameters.
The names of hash functions used for certificate fingerprints are
registered by the IANA. Hash functions MUST be defined by standards-
track RFCs which update or obsolete RFC 3279 [7].
When registering a new hash function textual name, the following
information MUST be provided.
o The textual name of the hash function.
o The Object Identifier (OID) of the hash function as used in X.509
certificates.
o A reference to the standards-track RFC, updating or obsoleting RFC
3279 [7], defining the use of the hash function in X.509
certificates.
Figure 3 contains the initial values of this registry.
Hash Function Name OID Reference
------------------ --- ---------
"md2" 1.2.840.113549.2.2 RFC 3279
"md5" 1.2.840.113549.2.5 RFC 3279
"sha-1" 1.3.14.3.2.26 RFC 3279
"sha-224" 2.16.840.1.101.3.4.2.4 RFC 4055
"sha-256" 2.16.840.1.101.3.4.2.1 RFC 4055
"sha-384" 2.16.840.1.101.3.4.2.2 RFC 4055
"sha-512" 2.16.840.1.101.3.4.2.3 RFC 4055
Figure 3: IANA Hash Function Textual Name Registry
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 -04 Appendix A.1. Changes From Draft -05
The section discussing the difficulty of knowing what URI identities o Specified that hop-by-hop integrity protection counts as valid
are appropriate for SDP was expanded, adding a reference to the integrity protection (though specific media formats can define
Gateway Control Protocol. otherwise if they choose.)
o Allowed SDP descriptions which are integrity-protected to
advertise any subjectAltName in their certificates.
o Made session teardown a MUST following a bad certificate
fingerprint -- user notification is no longer an option in this
scenario.
An un-cited informative reference was removed. o Established and populated a new IANA registry for Hash Function
Textual Names.
o Allowed announcement-mode (SAP-like) uses of TLS to request client
certificates, even though there is no way for clients to provide
certificate fingerprints in this case.
o Confidentiality is not required for secure transmission of SDP
descriptions, only integrity protection; removed this requirement.
o Established that user notification about bad certificate
identities only applies to certificates not sent over a protected
channel.
o Clarified the language on what identity must be asserted, for
certificates which must include specific identities.
o Clarified the scenarios in which users must be consulted on
whether certificates are acceptable.
o Clarified that TLS connections MUST NOT act upon data transmitted
over a TLS connection before they have verified the fingerprint.
o Clarified that the use of the same hash function for fingerprints
as for their corresponding certificates ensures that the
certificates' security properties are preserved for their
fingerprints.
o Standardized some terminology to properly reflect standard
security usage. Notably, "confidentiality" and "certification
authority" replaced "privacy" and "certificate authority"
respectively.
o Updated the references for Connection-Oriented Media in SDP (now
RFC 4145 [2]), ABNF (now RFC 4234 [10]), Media Type Registration
Procedures (now RFC 4288 [14]), and the SSH Protocol Architecture
(now RFC 4251 [21]).
Appendix A.2. Changes From Draft -03 Appendix A.2. Changes From Draft -04
The number of options in the protocol were significantly reduced: a o The section discussing the difficulty of knowing what URI
number of SHOULD requirements were elevated to MUST. Notably, the identities are appropriate for SDP was expanded, adding a
use of the 'fingerprint' attribute, strict certificate identity reference to the Gateway Control Protocol.
choices, and the use of the same digest algorithm for fingerprints as o An un-cited informative reference was removed.
for certificates were all made mandatory.
Support for the digest algorithms from FIPS 180-2 [11] / RFC 4055 [9] Appendix A.3. Changes From Draft -03
('SHA-224', 'SHA-256', 'SHA-384', and 'SHA-512') was added.
Discussion was added about the difficulty of automatically o The number of options in the protocol were significantly reduced:
a number of SHOULD requirements were elevated to MUST. Notably,
the use of the 'fingerprint' attribute, strict certificate
identity choices, and the use of the same digest algorithm for
fingerprints as for certificates were all made mandatory.
o Support for the digest algorithms from FIPS 180-2 [11] / RFC 4055
[9] ('SHA-224', 'SHA-256', 'SHA-384', and 'SHA-512') was added.
o 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-
call control. party call control.
o 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
draft-ietf-mmusic-comedia [2]. This consisted mostly of wording and and formatting changes.
formatting changes.
Appendix A.3. Changes From Draft -02 Appendix A.4. 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.4. Changes From Draft -01 Appendix A.5. 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.5. Changes From Draft -00 Appendix A.6. 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-25 (work in progress), July 2005. draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006.
[2] Yon, D., "Connection-Oriented Media Transport in the Session [2] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10 Session Description Protocol (SDP)", RFC 4145, September 2005.
(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.
[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 14, line 22 skipping to change at page 16, line 30
[8] 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.
[9] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms [9] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005. Revocation List (CRL) Profile", RFC 4055, June 2005.
[10] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 4234, October 2005.
[11] National Institute of Standards and Technology, "Secure Hash [11] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/ Standard", FIPS PUB 180-2, August 2002, <http://csrc.nist.gov/
publications/fips/fips180-2/fips180-2.pdf>. publications/fips/fips180-2/fips180-2.pdf>.
[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. and J. Klensin, "Media Type Specifications and
Mail Extensions (MIME) Part Four: Registration Procedures", Registration Procedures", BCP 13, RFC 4288, December 2005.
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.
[18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [18] 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.
[19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [19] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
skipping to change at page 15, line 12 skipping to change at page 17, line 19
[18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [18] 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.
[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, "The Secure Shell (SSH) Protocol
draft-ietf-secsh-architecture-22 (work in progress), Architecture", RFC 4251, January 2006.
March 2005.
[22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway [22] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
Control Protocol Version 1", RFC 3525, June 2003. Control Protocol Version 1", RFC 3525, June 2003.
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [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.
[24] 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-06 Oriented Transport", draft-ietf-avt-rtp-framing-contrans-06
skipping to change at page 16, line 14 skipping to change at page 18, line 14
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
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
skipping to change at page 17, line 41 skipping to change at page 19, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 52 change blocks. 
163 lines changed or deleted 267 lines changed or added

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