<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3711 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc4568 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4568.xml">
<!ENTITY rfc5764 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml">
<!ENTITY rfc6188 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6188.xml">
<!ENTITY rfc7714 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7714.xml">

]>
<rfc category="info" docName="draft-lennox-avtcore-dtls-srtp-bigaes-01" ipr="trust200902">
  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes" ?>

  <!-- alphabetize the references -->

  <?rfc comments="no"?>

  <!-- show comments -->

  <?rfc inline="yes" ?>

  <!-- comments are inline -->

  <?rfc toc="yes" ?>

  <!-- generate table of contents -->

  <front>
    <title abbrev="DTLS/SRTP AES-258">DTLS/SRTP Protection Profiles for 256-bit AES-CTR Encryption</title>

    <author fullname="Jonathan Lennox" initials="J." surname="Lennox">
      <organization abbrev="Vidyo">Vidyo, Inc.</organization>

      <address>
        <postal>
          <street>433 Hackensack Avenue</street>

          <street>Seventh Floor</street>

          <city>Hackensack</city>

          <region>NJ</region>

          <code>07601</code>

          <country>US</country>
        </postal>

        <email>jonathan@vidyo.com</email>
      </address>
    </author>

    <date/>

    <area>RAI</area>

    <workgroup>AVTCore Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>RTP</keyword>

    <keyword>SRTP</keyword>

    <keyword>DTLS</keyword>

    <keyword>AES</keyword>

    <keyword>AES-256</keyword>

    <abstract>
      <t>This memo defines Datagram Transport Layer Security (DTLS)
      Secure Real-time Transport Protocol (SRTP) Protection Profiles
      for 256-bit Advanced Encryption Standard (AES) Counter Mode.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>This memo defines Datagram Transport Layer Security (DTLS)
      Secure Real-time Transport Protocol (SRTP) Protection Profiles
      for 256-bit Advanced Encryption Standard (AES) Counter Mode.</t>

	  <t>DTLS-based key establishment for SRTP is defined in
		<xref target="RFC5764"/>.  The use of AES-256 counter mode
		with SRTP is defined in <xref target="RFC6188"/>.</t>

		<t>The draft document that became <xref target="RFC5764"/>
		initially defined protection profiles for AES-256; they were
		removed because the document that became <xref target="RFC6188"
		/> was not yet ready.  However, the definitions of the
		protection profiles were not transfered to the
		<xref target="RFC6188" /> drafts, apparently as an oversight.
		This document restores those codepoints, with their original
		values.</t>

    <section anchor="motivation" title="Motivation">
      <t>The question might arise as to why this is necessary.
      <xref target="RFC7714" /> defines the use of AES-256 with Galois
      Counter Mode, and current thought is that Galois Counter Mode is
      preferable to Counter Mode plus HMAC-based authentication.</t>

	  <t>The reason is to minimize the difficulty of moving
		implementations away from <xref target="RFC4568">Security
		Descriptions-based keying</xref>.  Use of Security
		Descriptions is strongly discouraged, as its security
		properties are much weaker than those of DTLS/SRTP.
		However, as <xref target="RFC6188"/> defines Security Descriptions
		signaling elements for AES-256-CTR, existing implementations
		use them to negotiate the use of these crypto suites, and
		many of the these implementations do not have
		Galois Counter Mode cryptography implemented (or certified).
		Thus, defining AES-256-CTR codepoints for DTLS/SRTP allows
		these implementations to continue using their existing SRTP
		cryptography while moving to a more secure keying protocol.</t>
    </section>

    </section>


    <section anchor="conventions"
             title="Conventions, Definitions and Acronyms">
      <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"/>.</t>
    </section>

	<section anchor="protectionProfiles" title="SRTP Protection
      Profiles">

	  <t>A DTLS-SRTP SRTP Protection Profile defines the parameters
		and options that are in effect for the SRTP processing.  This
		document defines the following SRTP protection profiles.</t>

	  <t>
		<figure>
		  <artwork>
      SRTPProtectionProfile SRTP_AES256_CM_SHA1_80 = {0x00, 0x03};
      SRTPProtectionProfile SRTP_AES256_CM_SHA1_32 = {0x00, 0x04};
</artwork>
		</figure>
	  </t>

	  <t>
		The following list indicates the SRTP transform parameters for
		each protection profile.  The parameters cipher_key_length,
		cipher_salt_length, auth_key_length, and auth_tag_length
		express the number of bits in the values to which they refer.
		The maximum_lifetime parameter indicates the maximum number of
		packets that can be protected with each single set of keys when the
		parameter profile is in use.  All of these parameters apply to both RTP and
		RTCP, unless the RTCP parameters are separately specified.</t>

	  <t>All of the crypto algorithms in these profiles are from
		<xref target="RFC6188"/>.</t>

	  <t>
		<figure>
		  <artwork>
   SRTP_AES256_CM_HMAC_SHA1_80
         cipher:  AES_256_CM
         cipher_key_length:  256
         cipher_salt_length:  112
         maximum_lifetime:  2^31
         auth_function:  HMAC-SHA1
         auth_key_length:  160
         auth_tag_length:  80
   SRTP_AES256_CM_HMAC_SHA1_32
         cipher:  AES_256_CM
         cipher_key_length:  256
         cipher_salt_length:  112
         maximum_lifetime:  2^31
         auth_function:  HMAC-SHA1
         auth_key_length:  160
         auth_tag_length:  32
         RTCP auth_tag_length:  80
</artwork>
		</figure>
	  </t>

	  
	  <t>With both of these SRTP Parameter profiles, the following SRTP options
		are in effect:</t>

	  <t><list style="symbols">
		  <t>The TLS Key Derivation Function (KDF) is used to generate keys to
			feed into the SRTP KDF.</t>
		  <t>The Key Derivation Rate (KDR) is equal to zero.  Thus, keys are
			not re-derived based on the SRTP sequence number.</t>
		  <t>The key derivation procedures from Section 3 of AES_256_CM_KDF
			<xref target="RFC6188"/> are used.</t>
		  <t>For all other parameters, (in particular, SRTP replay window
			size and FEC order) the default values are used.</t>
		</list></t>

	  <t>If values other than the defaults for these parameters are
		required, they can be enabled by writing a separate specification specifying
		SDP syntax to signal them.</t>
	</section>

    <section anchor="securityConsiderations" title="Security Considerations">
	  <t>This document defines security mechanisms.  No additional
	  security issues beyond those of <xref target="RFC5764"/> and
	  <xref target="RFC6188"/> apply.</t> 
	  
    </section>

    <section anchor="IANAConsiderations" title="IANA Considerations">
	  <t>IANA is requested to add the SRTP Protection Profiles
	  defined in <xref target='protectionProfiles'/> to the DTLS
	  SRTPProtectionProfile registry.</t>
	</section>
  </middle>

  <back>
    <references title='Normative References'>

      &rfc2119;

	  &rfc3711;

      &rfc5764;

      &rfc6188;

    </references>

    <references title='Informative References'>

      &rfc4568;
	  
	  &rfc7714;

	</references>
  </back>
</rfc>
