Multiparty Multimedia Session J. Lennox Control Columbia U. Expires:
October 25, 2004January 14, 2005 Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) draft-ietf-mmusic-comedia-tls-00draft-ietf-mmusic-comedia-tls-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 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 http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 25, 2004.January 14, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describesspecifies how to expressestablish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol.Protocol (SDP). It defines a new protocol identifier, TLS.TCP/TLS. It also defines the syntax and semantics for an SDP "fingerprint" attribute that identifies the certificate which will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol IdentifiersOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Fingerprint Attribute3.1 SDP Operational Modes . . . . . . . . . . . . . . . . . . 4 3.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 The Need For Self-Signed Certificates . . . . . . . . . . 5 3.4 Example SDP Description For TLS Connection . . . . . . . . 6 4. Protocol Identifiers . . . . . . . . . . . . . . . . . . . . . 6 5. Endpoint IdentificationFingerprint Attribute . . . . . . . . . . . . . . . . . . . 5 5.1 Certificate Choice. 7 6. Endpoint Identification . . . . . . . . . . . . . . . . . . . 5 5.28 6.1 Certificate PresentationChoice . . . . . . . . . . . . . . . . . 6 6. Example SDP description for TLS connection. . . 8 6.2 Certificate Presentation . . . . . . . 7. . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 710 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 810 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 811 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 811 9.2 Informative References . . . . . . . . . . . . . . . . . . . 912 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 1013 Intellectual Property and Copyright Statements . . . . . . . . 1114 1. Introduction The document Connection-Oriented Media Transport in SDP  describes how to express media transport over connection-oriented protocols using theSession Description Protocol . SDP is(SDP)  provides a general-purposegeneral purpose format for describing multimedia sessions in announcements or invitations. The Connection-Oriented Media document defines how SDP can be used for connection-oriented media, suchFor many applications, it is desirable to establish, as TCP,part of a multimedia session, a media stream which must be explicitly connected before being used. Theuses a connection-oriented media draft definestransport. The document Connection-Oriented Media Transport in the connection setup procedureSession Description Protocol (SDP)  specifies a general mechanism for such connections,describing and defines how SDP descriptions can advertise whether they wish to initiate and/or receiveestablishing such connection-oriented streams; however, the media connections.only transport protocol it directly supports is TCP. In many cases, session participants wish to provide confidentiality, data integrity, and authentication for their media sessions. For connection-oriented media,This document therefore extends the Connection-Oriented Media specification to allow session descriptions to describe media sessions that use the Transport Layer Security (TLS) protocol  is an obvious and widely-implemented choice which can provide an encrypted data channel and authenticated client and server identities. However,. The TLS cannot be used blindly; it is necessary to specify the appropriate certificates which each end party to a connection should present, so their counterparties can verify that they are indeed who they claim to be. Partiesprotocol allows applications to communicate over a channel which provides privacy and data integrity. The TLS session indicate their identities by presenting authentication certificates as part of the TLS handshake procedure. Authentication certificates are X.509  certificates, as profiled by RFC 3279 specification, however, does not specify how specific protocols establish and RFC 3280 .use this secure channel; particularly, TLS leaves the issuequestion of how to interpret theseand validate authentication certificates as an issue for the protocols which run atopover TLS. Certificate interpretation is a critical issue, however; it does an endpoint no good to know only that its peer has a valid certificate, without also having some way of judging whether the identity that it certifies is indeed a correct oneThis document specifies such usage for its counterparty. Further complicatingthe case of connection-oriented media transport. Complicating this issue, endpoints exchanging media will often be unable to afford toobtain authentication certificates signed by a well-known root certificate authority.authority (CA). Most certificate authorities charge for signed certificates, particularly host-based certificates; additionally, there is a substantial administrative overhead to obtaining signed certificates, as certificate authorities must be able to confirm that they are issuing the signed certificates to the correct party. This specification, therefore, defines how to signal TLS-based media sessionsFurthermore, in SDP.many cases endpoints' IP addresses and host names are dynamic: they may be obtained from DHCP, for example. It describes what identities endpoints should present in certificates, and, assumingis impractical to obtain a CA-signed certificate valid for the duration of a DHCP lease. For such hosts, self-signed certificates are usually the only option. This specification defines a mechanism which allows self-signed certificates can be used securely, provided that the integrity of the SDP contentdescription is assured, allows theassured. It provides for endpoints to include a secure usehash of self-signed certificates. 2. Terminology In this document,their certificate, known as the key words "MUST", "MUST NOT","certificate fingerprint", within the session description. Provided the fingerprint of the offered certificate matches the one in the session description, end hosts can trust even self-signed certificates. The rest of this document is laid out as follows. An overview of the problem and threat model is given in Section 3. Section 4 gives the basic use of SDP. Section 5 describes the SDP fingerprint attribute, which, assuming the integrity of SDP content is assured, allows the secure use of self-signed certificates. Section 6 describes which X.509 certificates are presented, and how they are used in TLS. Section 7 discusses additional security considerations. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as describedinterpreted as described in RFC 2119  and indicate requirement levels for compliant implementations. 3. Overview This section discusses the threat model which motivates TLS transport for connection-oriented media streams. It also discusses in more detail the need for end systems to use self-signed certificates. 3.1 SDP Operational Modes There are two principal operational modes for multimedia sessions: advertised and offer-answer. Advertised sessions are the simpler mode. In this mode, a server publishes, in some manner, an SDP session description describing a multimedia session it is making available. The classic example of this mode of operation is the Session Announcment Protocol (SAP) , in which SDP session descriptions are periodically transmitted to a well-known multicast group. Traditionally, these descriptions involve multicast conferences, but unicast sessions are also possible. (Connection-oriented media, obviously, cannot use multicast.) Recipients of a session description connect to the addresses published in the session description. These recipients may not previously have been known to the advertiser of the session description. Alternatively, SDP conferences can operate in offer-answer mode . This mode allows two participants in a multimedia session to negotiate the multimedia session between them. In this model, one participant offers the other a description of the desired session from its perspective, and the other participant answers with the desired session from its own perspective. In this mode, each of the participants in the session has knowledge of the other one. This is the mode of operation used by the Session Initiation Protocol (SIP) . 3.2 Threat Model Participants in multimedia conferences often wish to guarantee confidentiality, data integrity, and authentication for their media sessions. This section describes various types of attackers and the ways they attempt to violate these guarantees. It then describes how the TLS protocol can be used to thwart the attackers. The simplest type of attacker is one who listens passively to the traffic associated with a multimedia session. This attacker might, for example, be on the same local-area or wireless network as one of the participants in a conference. This sort of attacker does not threaten a connection's data integrity or authentication, and almost any operational mode of TLS can provide media stream confidentiality. More sophisticated is an attacker who can send his own data traffic over the network, but who cannot modify or redirect valid traffic. In SDP's 'advertised' operational mode, this can barely be considered an attack; media sessions are expected to be initiated from anywhere on the network. In SDP's offer-answer mode, however, this type of attack is more serious. An attacker could initiate a connection to one or both of the endpoints of a session, thus impersonating an endpoint, or acting as a man in the middle to listen in on their communications. To thwart these attacks, TLS uses endpoint certificates. So long as the certificates' private keys have not been compromised, the endpoints have an external trusted mechanism (most commonly, a mutually-trusted certificate authority) to validate certificates, and the endpoints know what certificate identity to expect, endpoints can be certain that such an attack has not taken place. Finally, the most serious type of attacker is one who can modify or redirect session descriptions: for example, a compromised or malicious SIP proxy server. Neither TLS itself, nor any mechanisms which use it, can protect an SDP session against such an attacker. Instead, the SDP description itself must be secured through some mechanism; SIP, for example, defines how S/MIME  can be used to secure session descriptions. 3.3 The Need For Self-Signed Certificates SDP session descriptions are created by any endpoint that needs to participate in a multimedia session. In many cases, such as SIP phones, such endpoints have dynamically-configured IP addresses and host names, and must be deployed with nearly zero configuration. For such an endpoint, it is for practical purposes impossible to obtain a certificate signed by a well-known certificate authority. If two endpoints have no prior relationship, self-signed certificates cannot generally be trusted, as there is no guarantee that an attacker is not launching a man-in-the-middle attack. Fortunately, however, if the integrity of SDP session descriptions can be assured, it is possible to consider those SDP descriptions themselves as a prior relationship: certificates can be securely described in the session description itself. This is done by providing a secure hash of a certificate, or "certificate fingerprint", as an SDP attribute; this mechanism is described in Section 5. 3.4 Example SDP Description For TLS Connection Figure 1 illustrates an SDP offer which signals the availability of a T.38 fax session over TLS. For the purpose of brevity, the main portion of the session description is omitted in the example, showing only the m= line and its attributes. (This example is the same as the first one in , except for the proto parameter and the fingerprint attribute.) See the subsequent sections for explanations of the example's TLS-specific attributes. (Note that the example uses MD5 as its one-way hash function, even though SHA-1 is preferred. This has been done only because the longer SHA-1 fingerprint would cause that line of the example to be wider than the number of characters allowed in RFC 2119  and indicate requirement levels for compliant implementations. 3.an Internet-Draft.) m=image 54111 TCP/TLS t38 c=IN IP4 10.1.1.2 a=setup:passive a=connid:1 a=fingerprint:MD5 48:AA:D8:BA:36:7C:6D:70:7F:81:BB:BA:ED:6D:B8:C7 Figure 1: Example SDP Description Offering a TLS Media Stream 4. Protocol Identifiers The m= line in SDP is where an endpoint specifiesspecifies, among other items, the transport protocol to be used for the media in the session. See the "Media Announcements"Descriptions" section of SDP  for a discussion on transport protocol identifiers. The protocol identifier "TLS" inThis specification defines a media description specifiesnew protocol identifier, TCP/TLS, which indicates that the media beingdescribed will use the Transport Layer Security protocol  with an implied transport protocol ofover TCP. (Using TLS over other transport protocols is not discussed by this document.) An m= line that specifies TLSTCP/TLS MUST further qualify the protocol using a fmt identifier.identifier, to indicate the application being run over TLS. As TLS sessions are connection-oriented, media sessions described in this manner are subject tofollow the definitions givenprocedures defined in the connection-oriented media specification . This includes the "direction" and "reconnect" attributes, and. They also use the attributes defined in that specification's rules on sessionspecification, "a=setup" and connection lifetime. 4."a=connid". 5. Fingerprint Attribute Parties to a TLS session indicate their identities by presenting authentication certificates as part of the TLS handshake procedure. Authentication certificates are X.509  certificates, as profiled by RFC 3279  and RFC 3280 . In order to associatedassociate media streams with connections, and to prevent unauthorized barge-in attacks on the media streams, endpoints can optionallyMAY provide a certificate fingerprint. If the X.509 certificate presented for the TLS connection matches the fingerprint presented in the SDP, the endpoint can be confident that the author of the SDP is indeed the initiator of the connection. A certificate fingerprint is a secure one-way hash of the DER (distinguished encoding rules) form of the certificate. (Certificate fingerprints are widely supported by tools which manipulate X.509 certificates; for instance, the command "openssl x509 -fingerprint" causes the openssl package'scommand-line tool of the openssl package to print a certificate fingerprint, and the certificate managers for Mozilla and Internet Explorer display them when viewing the details of a certificate.) A fingerprint is represented in SDP as an attribute (an "a=" line). It consists of the name of the hash function used, followed by the hash value itself. The hash value is represented as a sequence of upper-case hexidecimalhexadecimal bytes, separated by colons. The number of bytes is defined by the hash function. (This is the syntax used by openssl and by the browsers' certificate managers. It is different from the syntax used to represent hash values in, e.g., HTTP digest authentication ,, which uses unseparated lower-case hexidecimalhexadecimal bytes. It was felt that consistency with other applications of fingerprints was more important.) The formal syntax of the fingerprint attribute is given in Augmented Backus-Naur Form  in Figure 1.2. This syntax extends the BNF syntax of SDP .. attribute =/ fingerprint-attribute fingerprint-attribute = "fingerprint" ":" hash-func SP fingerprint hash-func = "sha-1" / "md5" / "md2" / token ; NewAdditional hash functions must be registered ; with IANA. ; TODO: figure out what IANA registrycan only come ; this should reference.from updates to RFC 3279 fingerprint = 2UHEX *(":" 2UHEX) ; Each byte in upper-case hex, separated ; by colons. UHEX = DIGIT / %x41-46 ; A-F uppercase Figure 1:2: Abstract Backus-Naur Syntax for the Fingerprint Attribute A certificate fingerprint SHOULD be computed using the same one-way hash function as is used byin the certificate itself.certificate's signature algorithm. (This guarantees that the fingerprint will be usable by the other endpoint so long as the certificate itself is.) Following RFC 3279 ,, therefore, the defined hash functions are SHA-1 ,, MD5 ,, and MD2 ,, with SHA-1 preferred. (TODO: figure out what IANA or other registry listsAdditional hash functions.)functions can be defined only by standards-track RFCs which update or obsolete RFC 3279 . The fingerprint attribute may be either a session-level or a media-level SDP attribute. If it is a session-level attribute, it applies to all TLS sessions for which no media-level fingerprint attribute is defined. 5.6. Endpoint Identification 5.16.1 Certificate Choice X.509 certificates certify identities. The certificate provided for a TLS connection needs to certify an appropriate identity for the connection. Identity matching is performed using the matching rules specified by RFC 3280 .. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name), a match in any one of the set is considered acceptable. If an endpoint does not provide a certificate fingerprint in its SDP, its certificate MUST correspond to one of the following identities, and MUST be signed by a well-known certificate authority. If the endpoint does provide a certificiate fingerprint, the certificate SHOULD indicate one of these identities. In all cases, thecertificate MUST indicate some identity which has a meaningful relationshipauthority known to the end point.other endpoint. o If the connection address for the media description is specified as an IP address, the endpoint MAY use a certificate with an iPAddress subjectAltName which exactly matches the IP in the connection address.connection-address in the session description's c= line. o If the connection address for the media description is specified as a fully-qualified domain name, the endpoint MAY use a certificate with a dNSName subjectAltName matching the specified connection address.c= line connection-address. Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. (This last pattern is not often meaningful, but is supported by https ; thus, it is allowed here as well.) o Finally, ifIf the SDP session description describing the connectionsession was transmitted over aan end-to-end secure protocol which uses X.509 certificates to certify the endpoints of the connection,certificates, the endpoint MAY use the same certificate to certify the media connection. (ForFor example, an SDP description sent over HTTP/TLS  or secured by S/MIME  MAY use the same certificate to secure the media connection. Note,(Note, however, that the sips:sips protocol  (SIP over TLS) provides only hop-by-hop security, so this certificate doesits TLS certificates do not satisfy this criterion. Suchcriterion.) In this case, the certificate must be one that is allowed in this context by the transmitting protocol. In those cases where an endpoint does provide a certificate could satisifyfingerprint, the certificate MAY be self-signed, but MUST indicate some identity which has a meaningful relationship to the end point. This identity MAY be one of the previous two points, however.) 5.2identities allowed above for non-fingerprinted certificates, or MAY correspond to the protocol over which the SDP was transmitted. For example, protocols which use URIs could include a certificate with a subjectAltName field of type uniformResourceIdentifier with a value matching the endpoint's URI. 6.2 Certificate Presentation In all cases, an endpoint acting as the TLS server --server, i.e., one taking the direction:passivea=setup:passive role, in the terminology of connection-oriented media --media, MUST present a certificate during TLS initiation, following the rules presented in Section 184.108.40.206. If the certificate does not match the original fingerprint, or, if there is no fingerprint, the certificate identity is incorrect, the client endpoint MUST either notify the useruser, if possible, or terminate the media connection with a bad certificate error. If the SDP offer/answer model  is being used, the client (the endpoint with the direction:activesetup:active role) MUST also present a certificate following the rules of Section 220.127.116.11. The server MUST request a certificate, and if the client does not provide one, if the certificate does not match the provided fingerprint, or, if there was no fingerprint, the certificate identity is incorrect, the server endpoint MUST either notify the user or terminate the media connection with a bad certificate error. 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. Thus, if the offerer has offered a direction:passivesetup:passive or direction:bothsetup:actpass role, it MUST (as specified in the connection-oriented mediaConnection-Oriented Media specification )) begin listening for an incoming connection as soon as it sends its offer. However, because its peer's media connection may outrace its answer, it SHOULD NOT definitively accept or rejectingreject the peer's certificate until it has received and processed the SDP answer. If offer/answer is not being used (e.g., if the SDP was sent over the Session Announcement Protocol ),), the TLS server typically has no external knowledge of what the TLS client's identity ought to be. In this case, no client certificate need be presented, and no certificate validation can be performed, unless the server has knowledge of valid clients through some external means. 6. Example SDP description for TLS connection Figure 2 illustrates an SDP offer to signal the availability of a T.38 fax session over TLS. (This example is the same as the one in , except for the transport parameter and the fingerprint attribute.) v=0 o=me 2890844526 2890842807 IN IP4 10.1.1.2 s=Call me using TCP t=3034423619 3042462419 c=IN IP4 10.1.1.2 m=image 54111 TLS t38 a=direction:passive a=fingerprint:MD5 48:AA:D8:BA:36:7C:6D:70:7F:81:BB:BA:ED:6D:B8:C7 Figure 2: Example SDP description offering a TLS media stream7. Security Considerations This entire document concerns itself with security. The problem to be solved is addressed in Section 1, and a high-level overview is presented in Section 3. Like all SDP messages, SDP messages describing TLS streams are conveyed in an encapsulating application protocol (e.g., SIP, MGCP, etc.). It is the responsibility of the encapsulating protocol to ensure the protectionintegrity and confidentiality of the SDP security descriptions. Therefore, the application protocol SHOULD either invoke its own security mechanisms (e.g., secure multiparts) or alternatively utilize a lower-layer security service (e.g., TLS or IPSec). This security service SHOULD provide strong message authentication and packet-payload encryption as well as effective replay protection. TLS is not always the most appropriate choice for secure connection-oriented media; in some cases, a higher-level security protocol may be appropriate. For example, RTP and RTCP packets may be sent over a connection-oriented transport . In this case, it is oftenmay be more appropriate to use the Secure RTP protocol  with appropriate SDP descriptions . 8. IANA Considerations This document registers the "TLS" protocol identifierdefines an SDP proto value: TCP/TLS. Its format is defined in Section 4. This proto value should be registered by IANA on http://www.iana.org/assignments/sdp-parameters under "proto". This document defines an SDP session and the "fingerprint"media level attribute: fingerprint. Its format is defined in Section 5. This attribute for SDP, as specifiedshould be registered by Appendix B of the SDP specification .IANA on http://www.iana.org/assignments/sdp-parameters under "att-field (both session and media level)". 9. References 9.1 Normative References  Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-18 (work in progress), June 2004.  Yon, D., "Connection-Oriented Media Transport in SDP", draft-ietf-mmusic-sdp-comedia-05the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-07 (work in progress), March 2003.  Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.June 2004.  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.  International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000.  Bassham, L., Polk, W. and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.  National Institute of Standards and Technology, "Secure Hash 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>.  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.  Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.  Rosenberg, J.9.2 Informative References  Handley, M., Perkins, C. and H.E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.  Rosenberg, J., Schulzrinne, "An Offer/Answer Model withH., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Description Protocol (SDP)",Initiation Protocol", RFC 3264,3261, June 2002. 9.2 Informative References  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. Lazzaro, J., "Framing RTP and RTCP Packets over Connection-Oriented Transport", draft-ietf-avt-rtp-framing-contrans-01 (work in progress), March 2004.  Baugher, M., "The Secure Real-time Transport Protocol", draft-ietf-avt-srtp-09 (work in progress), July 2003.  Andreasen, F., Baugher, M. and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-03draft-ietf-mmusic-sdescriptions-04 (work in progress), FebruaryMay 2004.  Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-15 (work in progress), October 2003.Author's Address Jonathan Lennox Columbia University Department of Computer Science 450 Computer Science 1214 Amsterdam Ave., M.C. 0401 New York, NY 10027 US Phone: +1 212 939 7018 EMail: email@example.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the IETF'sprocedures with respect to rights in IETF DocumentsRFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.