One document matched: draft-jennings-perc-double-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-jennings-perc-double-00" category="std">

<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="Double SRTP">SRTP Double Encryption Procedures</title>

    <author initials="C." surname="Jennings" fullname="Cullen Jennings">
      <organization>Cisco</organization>
      <address>
        
        
        <email>fluffy@iii.ca</email>
        
      </address>
    </author>
    <author initials="P.E." surname="Jones" fullname="Paul E. Jones">
      <organization>Cisco</organization>
      <address>
        
        
        <email>paulej@packetizer.com</email>
        
      </address>
    </author>
    <author initials="A.B." surname="Roach" fullname="Adam Roach">
      <organization>Mozilla</organization>
      <address>
        
        
        <email>adam@nostrum.com</email>
        
      </address>
    </author>

    <date year="2015" month="October" day="18"/>

    <area>Art</area>
    <workgroup>mmusic</workgroup>
    <keyword>perc</keyword>

    <abstract>


<t>In some conferencing scenarios, it is desirable for an intermediary to be able
to manipulate some RTP parameters, while still providing strong end-to-end
security guarantees.  This document defines a SRTP procedures
that uses two separate but related cryptographic contexts to provide “hop by
hop” and “end to end” security guarantees.
Both the end-to-end and hop-by-hop cryptographic transforms can utilizes an
authenticated encryption with associated data scheme or take advantage of future
SRTP transforms with different properties. SRTCP is encrypted hop-by-hop using
an already-defined SRTCP cryptographic transform.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Cloud conferencing systems that are based on switched conferencing have a
central media distribution device (MDD) that receives media from clients and
distributes it to other clients, but does not need to interpret or change the
media content. For these systems, it is desirable to have one security
association from the sending client to the receiving client that can encrypt and
authenticated the media end-to-end while still allowing certain RTP header
information to be changed by the MDD. At the same time, a separate security
association provides integrity and optional confidentiality for the RTP and
media flowing between the MDD and the clients.
More information about the requirements can be
found in <xref target="I-D.jones-perc-private-media-reqts"/>.</t>

<t>This specification RECOMMENDS the SRTP AES-GCM transform
<xref target="I-D.ietf-avtcore-srtp-aes-gcm"/> to encrypt an RTP packet to form the end-to-end
security association. The output of this is treated as an RTP packet and (optionally) again
encrypted with an SRTP transform to form the hop-by-hop security
association between the client and the MDD. The MDD decrypts and checks
integrity of the hop-by-hop security. At this point the MDD may change some of
the RTP header information that would impact the end-to-end integrity. For any
values that are changed, the original values before changing are included in a
new RTP header extension called the Original Header Block. The new RTP
packet is encrypted with the hop-by-hop security association for the destination
client before being sent.
The receiving client decrypts and checks integrity for the hop-by-hop
association from the MDD then replaces any parameters the MDD changes
using the information in the Original Header Block before decrypting and
checking the end-to-end integrity.</t>

</section>
<section anchor="terminology" 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"/>.</t>

<t>Terms:</t>

<t><list style='symbols'>
  <t>MDD: media distribution device that routes media from one client to other
clients</t>
  <t>E2E: end-to-end meaning the link from one client through the MDD to the client
at the other end.</t>
  <t>HBH: hop-by-hop meaning the link from the client to or from the MDD.</t>
  <t>OHB: Original Header Block containing a TLVs for each value that the MDD
Changed in the RTP header.</t>
</list></t>

</section>
<section anchor="cryptographic-contexts" title="Cryptographic Contexts">

<t>This specification uses two cryptographic contexts: An “end-to-end” context that
is used by endpoints that originate and consume media, and a “hop-by-hop”
context” that is used by an MDD that wishes to make modifications to some RTP
header fields.  The RECOMMENDED cipher for the hop-by-hop and end-to-end context
is AES-GCM but as new SRTP ciphers are defined, new combination of the double
encryption version of them can be added to the IANA registry.</t>

<t>The keys and salt for these contexts are generated with the following steps:</t>

<t><list style='symbols'>
  <t>Generate key and salt values of twice the length required by the E2E and HBH transforms</t>
  <t>Assign the first part of each value to be the key and salt, respectively, for
the inner transform.</t>
  <t>Assign the second part of each value to be the key and salt, respectively, for
the outer transform.</t>
</list></t>

<t>Obviously, if the MDD is to be able to modify header fields but not decrypt
the payload, then it must have cryptographic context for the outer transform,
but not the inner transform.  This document does not define how the MDD should
be provisioned with this information.</t>

</section>
<section anchor="original-header-block" title="Original Header Block">

<t>Any SRTP packet processed following these procedures MAY contain an Original Header
Block (OHB) extension.  </t>

<t>This RTP header extension contains the original values
of any modified header fields, in the following form:</t>

<figure><artwork><![CDATA[
(type  || value) || (type || value) || ...
]]></artwork></figure>

<t>In each type/value pair, the “type” field indicates the type of parameter that
was changed, and the “value” field carries the original value of the parameter.
The mapping from RTP header parameters to type values, and the length of the
value field is as follows</t>

<texttable>
      <ttcol align='left'>Field</ttcol>
      <ttcol align='left'>Type</ttcol>
      <ttcol align='left'>Value length</ttcol>
      <c>X</c>
      <c>1</c>
      <c>1</c>
      <c>CC</c>
      <c>2</c>
      <c>1</c>
      <c>M</c>
      <c>3</c>
      <c>1</c>
      <c>PT</c>
      <c>4</c>
      <c>1</c>
      <c>Seq Num</c>
      <c>5</c>
      <c>2</c>
      <c>Timestamp</c>
      <c>6</c>
      <c>4</c>
      <c>SSRC</c>
      <c>7</c>
      <c>4</c>
      <c>Ext Len</c>
      <c>8</c>
      <c>2</c>
</texttable>

<t>Open Issue: We could make a efficient coding by packing the above values as bits
in bit field and perhaps packing some of the single values into the same byte.</t>

</section>
<section anchor="operations" title="Operations">

<section anchor="encrypting-a-packet" title="Encrypting a Packet">

<t>To encrypt a packet, the endpoint encrypts the packet with
the inner transform, may add an OHB, then applies the outer transform.</t>

<t><list style='symbols'>
  <t>Form an RTP packet.  If there are any header extensions, they MUST use
<xref target="RFC5285"/>.</t>
  <t>Apply the transform to the RTP packet</t>
  <t>Optionally add an OHB header extension.  The endpoint MAY include any
header fields that are signaled to be modified by the MDD, to reduce processing
burden on the MDD. Open Issue: do we want the sending client to be able to add an OHB? </t>
  <t>Apply the SRTP cryptographic transform with the outer parameters (outer transform)</t>
</list></t>

</section>
<section anchor="modifying-a-packet" title="Modifying a Packet">

<t>In order to modify a packet, the MDD undoes the outer transform, modifies the
packet, updates the OHB with any new modifications, and re-applies the outer
tranform.</t>

<t><list style='symbols'>
  <t>Apply the (outer) decryption transform to the packet</t>
  <t>Separate the OHB from the (encrypted) original payload</t>
  <t>Change any required parameters</t>
  <t>If a changed parameter is not already in the OHB, add it with its original
value to the OHB. Note that in the case of cascaded MDDs, the first MDD may
have already added an OHB.</t>
  <t>If the MDD resets a parameter to its original value, it MAY drop it from the
OHB.</t>
  <t>The MDD MUST NOT delete any header extensions, but MAY add them.  <list style='symbols'>
      <t>If the MDD adds any header extensions, it must append them and it must
maintain the order of the original headers in the <xref target="RFC5285"/> block.</t>
      <t>If the MDD appends headers, then it MUST add the value of the original
<xref target="RFC5285"/> length field to the OHB, or update it if it is already there. The
original <xref target="RFC5285"/> length is counted in words and stored in the Ext Len field
of the OHB.</t>
    </list></t>
  <t>Recombine the new OHB and the (encrypted) original payload</t>
  <t>Apply the (outer) encryption transform to the packet</t>
</list></t>

</section>
<section anchor="decrypting-a-packet" title="Decrypting a Packet">

<t>To decrypt a packet, the endpoint first decrypts and verifies using the outer
transform, then uses the OHB to reconstruct the original packet, which it
decrypts and verifies with the inner transform.</t>

<t><list style='symbols'>
  <t>Apply the (outer) decryption transform to the packet</t>
  <t>Separate the OHB from the (encrypted) original payload</t>
  <t>Form a new SRTP packet with:  <list style='symbols'>
      <t>Header = Received header, with header fields replaced with values from OHB</t>
      <t>Header extensions truncated to the <xref target="RFC5285"/> length in OHB</t>
      <t>Payload = (encrypted) original payload</t>
    </list></t>
  <t>Apply the (inner) decryption transform to this synthetic SRTP packet</t>
</list></t>

</section>
<section anchor="recommended-inner-and-outer-cryptographic-transforms" title="Recommended Inner and Outer Cryptographic Transforms">

<t>This specification recommends and defines values for AES-GCM as both the inner
and outer cryptographic transforms (DOUBLE_SRTP_AEAD_AES_128_GCM and
DOUBLE_SRTP_AEAD_AES_256_GCM).  This transform provides for authenticated
encryption and will consume additional processing time double-encrypting for
HBH.  However, the approach is secure and simple, and is thus viewed as an
acceptable tradeoff in processing efficiency.</t>

<t>If a new SRTP transform was defined that encrypted some of all of the RTP
header, it would be reasonable for systems to have the option of using that for
the outer transform. Similarly if a new transform was defined that provided only
integrity, that would also be reasonable to use for the HBH as the payload data
is already encrypted by the E2E.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>It is obviously critical that the intermediary have only the outer transform
parameters, and not the inner.  We rely on an external key management protocol
to assure this property.</t>

<t>Modifications by the intermediary result in the recipient getting two values for
changed parameters (original and modified).  The recipient will have to choose
which to use; there is risk in using either that depends on the session setup.</t>

<t>The security properties for both the inner and outer key holders are the same as
the security properties of classic SRTP</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<section anchor="rtp-header-extension" title="RTP Header Extension">

<t>TODO - Define RTP header extension for the OBP block. </t>

</section>
<section anchor="dtls-srtp" title="DTLS-SRTP">

<t>We request IANA to add the following values to defines a DTLS-SRTP “SRTP
 Protection Profile” defined in <xref target="RFC5764"/>.</t>

<figure><artwork><![CDATA[
         DOUBLE_SRTP_AEAD_AES_128_GCM    = {TBD, TBD }
         DOUBLE_SRTP_AEAD_AES_256_GCM    = {TBD, TBD }
]]></artwork></figure>

<t>The  SRTP  transform parameters for each of these protection are:</t>

<figure><artwork><![CDATA[
   DOUBLE_SRTP_AEAD_AES_128_GCM
        cipher:                 AES_128_GCM
        cipher_key_length:      256 bits
        cipher_salt_length:     192 bits
        aead_auth_tag_length:   32 octets
        auth_function:          NULL
        auth_key_length:        N/A
        auth_tag_length:        N/A
        maximum lifetime:       at most 2^31 SRTCP packets and
                                            at most 2^48 SRTP packets

   DOUBLE_SRTP_AEAD_AES_256_GCM
        cipher:                 AES_256_GCM
        cipher_key_length:      512 bits
        cipher_salt_length:     192 bits
        aead_auth_tag_length:   32 octets
        auth_function:          NULL
        auth_key_length:        N/A
        auth_tag_length:        N/A
        maximum lifetime:       at most 2^31 SRTCP packets and
                                            at most 2^48 SRTP packets
]]></artwork></figure>

<t>The first half of the key and salt is used for the inner (E2E) transform and the
second half is used for the outer (HBH) transform.</t>

</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Many thanks to review from GET YOUR NAME HERE. Send comments.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC5285' target='http://www.rfc-editor.org/info/rfc5285'>
<front>
<title>A General Mechanism for RTP Header Extensions</title>
<author initials='D.' surname='Singer' fullname='D. Singer'><organization /></author>
<author initials='H.' surname='Desineni' fullname='H. Desineni'><organization /></author>
<date year='2008' month='July' />
<abstract><t>This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol).  It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized.  The actual extensions in use in a session are signaled in the setup information for that session.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5285'/>
<seriesInfo name='DOI' value='10.17487/RFC5285'/>
</reference>



<reference anchor='I-D.ietf-avtcore-srtp-aes-gcm'>
<front>
<title>AES-GCM Authenticated Encryption in Secure RTP (SRTP)</title>

<author initials='D' surname='McGrew' fullname='David McGrew'>
    <organization />
</author>

<author initials='K' surname='Igoe' fullname='Kevin Igoe'>
    <organization />
</author>

<date month='June' day='30' year='2015' />

<abstract><t>This document defines how the AES-GCM Authenticated Encryption with Associated Data family of algorithms can be used to provide confidentiality and data authentication in the SRTP protocol.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-avtcore-srtp-aes-gcm-17' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-aes-gcm-17.txt' />
</reference>



<reference  anchor='RFC5764' target='http://www.rfc-editor.org/info/rfc5764'>
<front>
<title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='May' />
<abstract><t>This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows.  DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5764'/>
<seriesInfo name='DOI' value='10.17487/RFC5764'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='I-D.jones-perc-private-media-reqts'>
<front>
<title>Private Media Requirements in Privacy Enhanced RTP Conferencing</title>

<author initials='P' surname='Jones' fullname='Paul Jones'>
    <organization />
</author>

<author initials='N' surname='Ismail' fullname='Nermeen Ismail'>
    <organization />
</author>

<author initials='D' surname='Benham' fullname='David Benham'>
    <organization />
</author>

<author initials='N' surname='Buckles' fullname='Nathan Buckles'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='R' surname='Barnes' fullname='Richard Barnes'>
    <organization />
</author>

<date month='July' day='6' year='2015' />

<abstract><t>This document specifies the requirements for ensuring the privacy and integrity of real-time transport protocol (RTP) media flows between two or more endpoints communicating through one or more centrally located media distribution devices (MDDs).</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-jones-perc-private-media-reqts-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-jones-perc-private-media-reqts-00.txt' />
</reference>




    </references>



  </back>
</rfc>