One document matched: draft-ietf-mmusic-sdp-dtls-00.xml
<?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:
-->
| PAFTECH AB 2003-2026 | 2026-04-23 09:35:05 |