draft-ietf-mmusic-comedia-tls-02.txt   draft-ietf-mmusic-comedia-tls-03.txt 
Multiparty Multimedia Session J. Lennox Multiparty Multimedia Session J. Lennox
Control Columbia U. Control Columbia U.
Expires: April 4, 2005 Expires: December 18, 2005
Connection-Oriented Media Transport over the Transport Layer Security Connection-Oriented Media Transport over the Transport Layer Security
(TLS) Protocol in the Session Description Protocol (SDP) (TLS) Protocol in the Session Description Protocol (SDP)
draft-ietf-mmusic-comedia-tls-02 draft-ietf-mmusic-comedia-tls-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 4, 2005. This Internet-Draft will expire on December 18, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). 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
new protocol identifier, TCP/TLS. It also defines the syntax and new protocol identifier, TCP/TLS. It also defines the syntax and
semantics for an SDP "fingerprint" attribute that identifies the semantics for an SDP "fingerprint" attribute that identifies the
certificate which will be presented for the TLS session. This certificate which will be presented for the TLS session. This
mechanism allows media transport over TLS connections to be mechanism allows media transport over TLS connections to be
established securely, so long as the integrity of session established securely, so long as the integrity of session
descriptions is assured. descriptions is assured.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 SDP Operational Modes . . . . . . . . . . . . . . . . . . 4 3.1 SDP Operational Modes . . . . . . . . . . . . . . . . . . 4
3.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 11 A. Changes From Earlier Versions . . . . . . . . . . . . . . . . 11
A.1 Changes From Draft -01 . . . . . . . . . . . . . . . . . . 11 A.1 Changes From Draft -02 . . . . . . . . . . . . . . . . . . 11
A.2 Changes From Draft -00 . . . . . . . . . . . . . . . . . . 12 A.2 Changes From Draft -01 . . . . . . . . . . . . . . . . . . 11
A.3 Changes From Draft -00 . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 9.1 Normative References . . . . . . . . . . . . . . . . . . . 12
9.2 Informative References . . . . . . . . . . . . . . . . . . . 13 9.2 Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 15
1. Introduction 1. Introduction
The Session Description Protocol (SDP) [1] provides a general purpose The Session Description Protocol (SDP) [1] provides a general purpose
format for describing multimedia sessions in announcements or format for describing multimedia sessions in announcements or
invitations. For many applications, it is desirable to establish, as invitations. For many applications, it is desirable to establish, as
part of a multimedia session, a media stream which uses a part of a multimedia session, a media stream which uses a connection-
connection-oriented transport. The document Connection-Oriented oriented transport. The document Connection-Oriented Media Transport
Media Transport in the Session Description Protocol (SDP) [2] in the Session Description Protocol (SDP) [2] specifies a general
specifies a general mechanism for describing and establishing such mechanism for describing and establishing such connection-oriented
connection-oriented streams; however, the only transport protocol it streams; however, the only transport protocol it directly supports is
directly supports is TCP. In many cases, session participants wish TCP. In many cases, session participants wish to provide
to provide confidentiality, data integrity, and authentication for confidentiality, data integrity, and authentication for their media
their media sessions. This document therefore extends the sessions. This document therefore extends the Connection-Oriented
Connection-Oriented Media specification to allow session descriptions Media specification to allow session descriptions to describe media
to describe media sessions that use the Transport Layer Security sessions that use the Transport Layer Security (TLS) protocol [3].
(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 privacy and data integrity. The TLS specification,
however, does not specify how specific protocols establish and use however, does not specify how specific protocols establish and use
this secure channel; particularly, TLS leaves the question of how to this secure channel; particularly, TLS leaves the question of how to
interpret and validate authentication certificates as an issue for interpret and validate authentication certificates as an issue for
the protocols which run over TLS. This document specifies such usage the protocols which run over TLS. This document specifies such usage
for the case of connection-oriented media transport. 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
skipping to change at page 4, line 33 skipping to change at page 4, line 32
3.1 SDP Operational Modes 3.1 SDP Operational Modes
There are two principal operational modes for multimedia sessions: There are two principal operational modes for multimedia sessions:
advertised and offer-answer. Advertised sessions are the simpler advertised and offer-answer. Advertised sessions are the simpler
mode. In this mode, a server publishes, in some manner, an SDP mode. In this mode, a server publishes, in some manner, an SDP
session description describing a multimedia session it is making session description describing a multimedia session it is making
available. The classic example of this mode of operation is the available. The classic example of this mode of operation is the
Session Announcment Protocol (SAP) [14], in which SDP session Session Announcment Protocol (SAP) [14], in which SDP session
descriptions are periodically transmitted to a well-known multicast descriptions are periodically transmitted to a well-known multicast
group. Traditionally, these descriptions involve multicast group. Traditionally, these descriptions involve multicast
conferences, but unicast sessions are also possible. conferences, but unicast sessions are also possible. (Connection-
(Connection-oriented media, obviously, cannot use multicast.) oriented media, obviously, cannot use multicast.) Recipients of a
Recipients of a session description connect to the addresses session description connect to the addresses published in the session
published in the session description. These recipients may not description. These recipients may not previously have been known to
previously have been known to the advertiser of the session the advertiser of the session description.
description.
Alternatively, SDP conferences can operate in offer-answer mode [5]. Alternatively, SDP conferences can operate in offer-answer mode [5].
This mode allows two participants in a multimedia session to This mode allows two participants in a multimedia session to
negotiate the multimedia session between them. In this model, one negotiate the multimedia session between them. In this model, one
participant offers the other a description of the desired session participant offers the other a description of the desired session
from its perspective, and the other participant answers with the from its perspective, and the other participant answers with the
desired session from its own perspective. In this mode, each of the desired session from its own perspective. In this mode, each of the
participants in the session has knowledge of the other one. This is participants in the session has knowledge of the other one. This is
the mode of operation used by the Session Initiation Protocol (SIP) the mode of operation used by the Session Initiation Protocol (SIP)
[15]. [15].
skipping to change at page 8, line 19 skipping to change at page 8, line 19
hash-func = "sha-1" / "md5" / "md2" / token hash-func = "sha-1" / "md5" / "md2" / token
; Additional hash functions can only come ; Additional hash functions can only come
; from updates to RFC 3279 ; from updates to RFC 3279
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: Abstract Backus-Naur Syntax for the Fingerprint Attribute Figure 2: Augmented Backus-Naur Syntax for the Fingerprint Attribute
A certificate fingerprint SHOULD be computed using the same one-way A certificate fingerprint SHOULD be computed using the same one-way
hash function as is used in the certificate's signature algorithm. hash function as is used in the certificate's signature algorithm.
(This guarantees that the fingerprint will be usable by the other (This guarantees that the fingerprint will be usable by the other
endpoint, so long as the certificate itself is.) Following RFC 3279 endpoint, so long as the certificate itself is.) Following RFC 3279
[7], therefore, the defined hash functions are SHA-1 [10][18], MD5 [7], therefore, the defined hash functions are SHA-1 [10][18], MD5
[11], and MD2 [12], with SHA-1 preferred. Additional hash functions [11], and MD2 [12], with SHA-1 preferred. Additional hash functions
can be defined only by standards-track RFCs which update or obsolete can be defined only by standards-track RFCs which update or obsolete
RFC 3279 [7]. Self-signed certificates (for which legacy RFC 3279 [7]. Self-signed certificates (for which legacy
certificates are not a consideration) MUST use SHA-1 in their certificates are not a consideration) MUST use SHA-1 in their
signature algorithm, and thus also MUST use it to calculate signature algorithm, and thus also MUST use it to calculate
certificate fingerprints. certificate fingerprints.
The fingerprint attribute may be either a session-level or a The fingerprint attribute may be either a session-level or a media-
media-level SDP attribute. If it is a session-level attribute, it level SDP attribute. If it is a session-level attribute, it applies
applies to all TLS sessions for which no media-level fingerprint to all TLS sessions for which no media-level fingerprint attribute is
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
skipping to change at page 9, line 26 skipping to change at page 9, line 26
certificates, the endpoint MAY use the same certificate to certify certificates, the endpoint MAY use the same certificate to certify
the media connection. For example, an SDP description sent over the media connection. For example, an SDP description sent over
HTTP/TLS [19] or secured by S/MIME [16] MAY use the same HTTP/TLS [19] or secured by S/MIME [16] MAY use the same
certificate to secure the media connection. (Note, however, that certificate to secure the media connection. (Note, however, that
the sips protocol [15] (SIP over TLS) provides only hop-by-hop the sips protocol [15] (SIP over TLS) provides only hop-by-hop
security, so its TLS certificates do not satisfy this criterion.) security, so its TLS certificates do not satisfy this criterion.)
In this case, the certificate must be one that is allowed in this In this case, the certificate must be one that is allowed in this
context by the transmitting protocol. context by the transmitting protocol.
In those cases where an endpoint provides a certificate fingerprint, In those cases where an endpoint provides a certificate fingerprint,
the certificate MAY be self-signed. The certificate MUST be the certificate MAY be self-signed. The certificate MUST be well-
well-formed (and thus MUST include a syntactically valid formed (and thus MUST include a syntactically valid SubjectAltName),
SubjectAltName), but no further requirements are imposed upon this but no further requirements are imposed upon this field's contents.
field's contents. To support the use of certificate caches, however, To support the use of certificate caches, however, as described in
as described in Section 7, endpoints SHOULD consistently provide the Section 7, endpoints SHOULD consistently provide the same certificate
same certificate for each identity they support. 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 a=setup:passive role, in the terminology of connection-oriented the a=setup:passive role, in the terminology of connection-oriented
media, MUST present a certificate during TLS initiation, following media, MUST present a certificate during TLS initiation, following
the rules presented in Section 6.1. If the certificate does not the rules presented in Section 6.1. If the certificate does not
match the original fingerprint, or, if there is no fingerprint, the match the original fingerprint, or, if there is no fingerprint, the
certificate identity is incorrect, the client endpoint MUST either certificate identity is incorrect, the client endpoint MUST either
notify the user, if possible, or terminate the media connection with notify the user, if possible, or terminate the media connection with
skipping to change at page 11, line 6 skipping to change at page 11, line 6
SHOULD be strongly warned if a different and unauthenticated SHOULD be strongly warned if a different and unauthenticated
certificate is presented by a party with which they have communicated certificate is presented by a party with which they have communicated
in the past. In this way, even in the absence of integrity in the past. In this way, even in the absence of integrity
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 [20], which is equivalent to that of the Secure Shell (ssh) protocol [20], 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.)
TLS is not always the most appropriate choice for secure TLS is not always the most appropriate choice for secure connection-
connection-oriented media; in some cases, a higher- or lower-level oriented media; in some cases, a higher- or lower-level security
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 [21] over a connection-oriented transport send Secure RTP packets [21] over a connection-oriented transport
[22], or whether it would be better to send standard unsecured RTP [22], 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.
skipping to change at page 11, line 42 skipping to change at page 11, line 42
the rules by which their media format (fmt) namespace is managed. the rules by which their media format (fmt) namespace is managed.
For the TCP/TLS protocol, new formats SHOULD have an associated MIME For the TCP/TLS protocol, new formats SHOULD have an associated MIME
registration. Use of an existing MIME subtype for the format is registration. Use of an existing MIME subtype for the format is
encouraged. If no MIME subtype exists, it is RECOMMENDED that a encouraged. If no MIME subtype exists, it is RECOMMENDED that a
suitable one be registered through the IETF process [13] by suitable one be registered through the IETF process [13] by
production of, or reference to, a standards-track RFC that defines production of, or reference to, a standards-track RFC that defines
the transport protocol for the format. the transport protocol for the format.
Appendix A. Changes From Earlier Versions Appendix A. Changes From Earlier Versions
Appendix A.1 Changes From Draft -01 Appendix A.1 Changes From Draft -02
None, other than IPR boilerplate and reference updates. Draft -03
was a resubmission to refresh the draft's presence in the Internet-
Drafts repository.
Appendix A.2 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.2 Changes From Draft -00 Appendix A.3 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., Jacobson, V. and C. Perkins, "SDP: Session [1] Handley, M., "SDP: Session Description Protocol",
Description Protocol", draft-ietf-mmusic-sdp-new-20 (work in draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005.
progress), September 2004.
[2] Yon, D., "Connection-Oriented Media Transport in the Session [2] Yon, D., "Connection-Oriented Media Transport in the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-09 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-10
(work in progress), September 2004. (work in progress), November 2004.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
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.
[6] International Telecommunications Union, "Information technology [6] International Telecommunications Union, "Information technology
- Open Systems Interconnection - The Directory: Public-key and - Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks", ITU-T Recommendation X.509, attribute certificate frameworks", ITU-T Recommendation X.509,
ISO Standard 9594-8, March 2000. ISO Standard 9594-8, March 2000.
[7] Bassham, L., Polk, W. and R. Housley, "Algorithms and [7] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC Certificate and Certificate Revocation List (CRL) Profile",
3279, April 2002. RFC 3279, April 2002.
[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] Crocker, D. and P. Overell, "Augmented BNF for Syntax [9] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[10] National Institute of Standards and Technology, "Secure Hash [10] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1992. April 1992.
[12] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, [12] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
April 1992. April 1992.
[13] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet [13] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP Mail Extensions (MIME) Part Four: Registration Procedures",
13, RFC 2048, November 1996. BCP 13, RFC 2048, November 1996.
9.2 Informative References 9.2 Informative References
[14] Handley, M., Perkins, C. and E. Whelan, "Session Announcement [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[16] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [16] Ramsdell, B., "S/MIME Version 3 Message Specification",
2633, June 1999. RFC 2633, June 1999.
[17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[18] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", [18] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001. RFC 3174, September 2001.
[19] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [19] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[20] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", [20] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-16 (work in progress), June 2004. draft-ietf-secsh-architecture-22 (work in progress),
March 2005.
[21] Baugher, M., "The Secure Real-time Transport Protocol", [21] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
draft-ietf-avt-srtp-09 (work in progress), July 2003. Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[22] Lazzaro, J., "Framing RTP and RTCP Packets over [22] Lazzaro, J., "Framing RTP and RTCP Packets over Connection-
Connection-Oriented Transport", Oriented Transport", draft-ietf-avt-rtp-framing-contrans-05
draft-ietf-avt-rtp-framing-contrans-03 (work in progress), July (work in progress), January 2005.
2004.
[23] Andreasen, F., Baugher, M. and D. Wing, "Session Description [23] Andreasen, F., "Session Description Protocol Security
Protocol Security Descriptions for Media Streams", Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-07 (work in progress), July draft-ietf-mmusic-sdescriptions-11 (work in progress),
2004. 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
Phone: +1 212 939 7018 Phone: +1 212 939 7018
EMail: lennox@cs.columbia.edu Email: lennox@cs.columbia.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 15, line 41 skipping to change at page 15, 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 (2004). This document is subject Copyright (C) The Internet Society (2005). 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. 

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