<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2327 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2327.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY RFC4145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4145.xml">
<!ENTITY RFC4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
<!ENTITY RFC4571 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4571.xml">
<!ENTITY I-D.ietf-dccp-spec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dccp-spec.xml">
<!ENTITY RFC4572 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY I-D.ietf-mmusic-sdp-capability-negotiation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-capability-negotiation.xml">
<!ENTITY I-D.ietf-mmusic-sdp-capability-negotiation-reqts SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-capability-negotiation-reqts.xml">
<!ENTITY I-D.ietf-avt-dtls-srtp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-dtls-srtp.xml">
<!ENTITY I-D.ietf-sip-dtls-srtp-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-dtls-srtp-framework.xml">
]>
<!--<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>-->
<!-- $Id: dtls-sdp.xml,v 1.19 2006/02/26 04:04:17 cullen Exp $ -->
<?rfc comments="yes"?>
<?rfc compact="yes" ?>
<?rfc inline="yes"?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes"?>
<?rfc symrefs="no"?>
<?rfc toc="yes"?>
<rfc category="std" docName="draft-ietf-mmusic-sdp-dtls-00.txt" ipr="full3978">
    <front>
        <title abbrev="SDP for DTLS">Session Description Protocol (SDP) Indicators for Datagram
            Transport Layer Security (DTLS)</title>
        <author fullname="Jason Fischl" initials="J." surname="Fischl">
            <organization>CounterPath Solutions, Inc.</organization>
            <address>
                <postal>
                    <street>Suite 300, One Bentall Centre, 505 Burrard Street</street>
                    <city>Vancouver</city>
                    <region>BC</region>
                    <code>V7X 1M3</code>
                    <country>Canada</country>
                </postal>
                <phone>+1 604 320-3340</phone>
                <email>jason@counterpath.com</email>
            </address>
        </author>
        <author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
            <organization>Nokia Siemens Networks</organization>
            <address>
                <postal>
                    <street>Linnoitustie 6</street>
                    <city>Espoo</city>
                    <code>02600</code>
                    <country>Finland</country>
                </postal>
                <phone>+358 (50) 4871445</phone>
                <email>Hannes.Tschofenig@nsn.com</email>
                <uri>http://www.tschofenig.com</uri>
            </address>
        </author>
        <date year="2008"/>
        <abstract>
            <t>This specification defines how to use the Session Description Protocol (SDP) to
                signal that media will be transported over Datagram Transport Layer Security (DTLS)
                or where the SRTP security context is established using DTLS and. It reuses the
                syntax and semantics for an SDP 'fingerprint' attribute that identifies the
                certificate which will be presented during the DTLS handshake.</t>
        </abstract>
    </front>
    <middle>
        <section title="Introduction">
            <t> Session Description Protocol (SDP) <xref target="RFC2327">RFC 2327</xref> has been
                used to set up the transport of various types of media with RTP <xref
                    target="RFC3550"/> over UDP <xref target="RFC3551"/>, TCP <xref target="RFC4571"
                />, and TLS <xref target="RFC4572"/>. DTLS <xref target="RFC4347"/> is a protocol
                for applying TLS security to datagram protocols such as UDP and DCCP <xref
                    target="I-D.ietf-dccp-spec"/>. This specification defines new SDP protocol
                syntax that allow SDP to indicate that DTLS should be used to transport the media
                when TLS is used.</t>
            <t> The handling of TLS sessions in SDP is defined in <xref target="RFC4572"/> that
                discusses only TLS over TCP. This document extends that specification to also deal
                with TLS over datagram protocols such as UDP and DCCP and when (D)TLS is used to
                establish keys for SRTP as in <xref target="I-D.ietf-avt-dtls-srtp"/></t>
            <!--	    <t>
	    [[NOTE: This document has a major dependency on work currently
	    going on in the MMUSIC WG to 
      mechanisms for SDP capability
      negotiation which will enable this sort of best-effort encryption.
      When that work is finished, this draft will be harmonized with it.]]</t>
-->
        </section>
        <section title="Terminology">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
                NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
                described in <xref target="RFC2119">RFC 2119</xref>.</t>
        </section>
        <section title="DTLS Certificates">
            <t> The two endpoints in the exchange present their identities as part of the DTLS
                handshake procedure using certificates. This document uses certificates in the same
                style as described in Comedia over TLS in SDP <xref target="RFC4572"/>.</t>
            <t> If self-signed certificates are used, the content of the subjectAltName attribute
                inside the certificate MAY use the uniform resource identifier (URI) of the user.
                This is useful for debugging purposes only and is not required to bind the
                certificate to one of the communication endpoints. The integrity of the certificate
                is ensured through the fingerprint attribute in the SDP. The subjectAltName is not
                an important component of the certificate verification.</t>
            <t> If the endpoint is also able to make anonymous sessions, a distinct, unique,
                self-signed certificate SHOULD be provided for this purpose.</t>
            <t> The generation of public/private key pairs is relatively expensive. Endpoints are
                not required to generate certificates for each session.</t>
            <t> The endpoints MAY cache their certificates and reuse them across multiple sessions.</t>
            <t>[Editor's Note: Certificate lifetime issues will be discussed in a future draft
                version.]</t>
        </section>
        <section anchor="section.sdp" title="SDP">
            <t> In addition to the usual contents of an SDP <xref target="RFC4566"/> message, each
                'm' line will also contain several attributes as specified in <xref target="RFC4145"
                    >RFC 4145</xref> and <xref target="RFC4572"/>.</t>
            <t> The endpoint MUST use the setup and connection attributes defined in "TCP-Based
                Media Transport in the SDP" <xref target="RFC4145"/>.
                <!-- The setup attribute is used in the 'm' line of an SDP message. --> For the
                purposes of this specification, a setup:active endpoint will act as a DTLS client
                and a setup:passive endpoint will act as a DTLS server. The connection attribute
                indicates whether or not to reuse an existing DTLS association.</t>
            <t>A certificate fingerprint is the output of a one-way hash function computed over the
                distinguished encoding rules (DER) form of the certificate. The endpoint MUST use
                the certificate fingerprint attribute as specified in <xref target="RFC4572"/>.</t>
            <t> TODO: The MMUSIC working group is currently studying the problem of signalling in
                SDP the ability/desire to initiate a secure channel rather than an insecure one
                    <xref target="I-D.ietf-mmusic-sdp-capability-negotiation"/><xref
                    target="I-D.ietf-mmusic-sdp-capability-negotiation-reqts"/>. We need to use
                those techniques when they are finalized.</t>
        </section>
        <section title="Session Description for RTP/SAVP over DTLS">
            <t> This specification defines new tokens to describe the protocol used in SDP "m="
                lines. The new values defined for the proto field are: </t>
            <t>
                <list style="symbols">
                    <t> When a RTP/SAVP stream is transported over DTLS with DCCP, then the token
                        SHALL be DCCP/TLS/RTP/SAVP.</t>

                    <t> When a RTP/SAVP stream is transported over DTLS with UDP, the token SHALL be
                        UDP/TLS/RTP/SAVP.</t>

                    <t> When a RTP/SAVP stream is transported over TLS with TCP, the token SHALL be
                        TCP/TLS/RTP/SAVP.</t>

                    <t> When media is transported over DTLS with UDP, the token SHALL be UDP/TLS.</t>

                    <t> When media is transported over DTLS with DCCP, the token SHALL be
                    DCCP/TLS.</t>
                </list>
            </t>

            <t> For RTP profiles other than AVP, a new token should be defined in the form of
                DCCP/TLS/RTP/xyz, UDP/TLS/RTP/xyz and TCP/TLS/RTP/xyz where xyz is replaced with an
                appropriate token for that profile.</t>
        </section>
        <section title="IANA Considerations">
            <t>This specification updates the "Session Description Protocol (SDP) Parameters"
                registry as defined in Appendix B of <xref target="RFC2327">RFC 2327</xref>.
                Specifically it adds the following values to the table for the "proto" field. </t>
            <figure>
                <artwork><![CDATA[
Type            SDP Name                     Reference
----            ------------------           ---------
proto           TCP/TLS/RTP/SAVP              [RFC-XXXX]
                UDP/TLS/RTP/SAVP              [RFC-XXXX]
                DCCP/TLS/RTP/SAVP             [RFC-XXXX]
                UDP/TLS                      [RFC-XXXX]
                DCCP/TLS                     [RFC-XXXX]
]]></artwork>
            </figure>
            <t> Note to RFC Editor: Please replace RFC-XXXX with the RFC number of this
                specification.</t>
        </section>
        <section title="Security Considerations">
            <t> When using self signed certificates, the signalling protocol used to transport the
                SDP MUST ensure the integrity of the SDP so that the fingerprint attribute can not
                be altered. Failure to do this would allow a attacker to insert themselves in the
                media channel as a man-in-the-middle. A method of ensuring the integrity of the SDP
                when transporting over the SIP <xref target="RFC3261">RFC 3261</xref> signalling
                protocol is described in <xref target="I-D.ietf-sip-dtls-srtp-framework"/>
            </t>
        </section>
        <section title="Acknowledgments">
            <t> Cullen Jennings contributed substantial text and comments to this document. This
                document benefitted from discussions with Francois Audet, Nagendra Modadugu, Eric
                Rescorla, and Dan Wing. Thanks also for useful comments by Flemming Andreasen, Rohan
                Mahy, David McGrew, and David Oran.</t>
        </section>
    </middle>
    <back>
        <references title="Normative References"> &I-D.ietf-dccp-spec; &RFC4572;
            &I-D.ietf-mmusic-sdp-capability-negotiation;
            &I-D.ietf-mmusic-sdp-capability-negotiation-reqts; &I-D.ietf-avt-dtls-srtp;
            &RFC2119; &RFC2327; &RFC3261; &RFC3550; &RFC3551; &RFC4145;
            &RFC4347; </references>

        <references title="Informational References"> &RFC4566; &RFC4571;
            &I-D.ietf-sip-dtls-srtp-framework; </references>
    </back>
</rfc>
<!-- Keep this comment at the end of the file
Local variables:
sgml-omittag:nil
sgml-shorttag:nil
sgml-namecase-general:nil
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:nil
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
