[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 draft-ietf-perc-double

mmusic                                                       C. Jennings
Internet-Draft                                                  P. Jones
Intended status: Standards Track                                   Cisco
Expires: April 20, 2016                                         A. Roach
                                                                 Mozilla
                                                        October 18, 2015


                   SRTP Double Encryption Procedures
                     draft-jennings-perc-double-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 20, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Jennings, et al.         Expires April 20, 2016                 [Page 1]


Internet-Draft                 Double SRTP                  October 2015


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   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
   [I-D.jones-perc-private-media-reqts].

   This specification RECOMMENDS the SRTP AES-GCM transform
   [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.

2.  Terminology

   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 [RFC2119].

   Terms:




Jennings, et al.         Expires April 20, 2016                 [Page 2]


Internet-Draft                 Double SRTP                  October 2015


   o  MDD: media distribution device that routes media from one client
      to other clients

   o  E2E: end-to-end meaning the link from one client through the MDD
      to the client at the other end.

   o  HBH: hop-by-hop meaning the link from the client to or from the
      MDD.

   o  OHB: Original Header Block containing a TLVs for each value that
      the MDD Changed in the RTP header.

3.  Cryptographic Contexts

   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.

   The keys and salt for these contexts are generated with the following
   steps:

   o  Generate key and salt values of twice the length required by the
      E2E and HBH transforms

   o  Assign the first part of each value to be the key and salt,
      respectively, for the inner transform.

   o  Assign the second part of each value to be the key and salt,
      respectively, for the outer transform.

   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.

4.  Original Header Block

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

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

   (type  || value) || (type || value) || ...



Jennings, et al.         Expires April 20, 2016                 [Page 3]


Internet-Draft                 Double SRTP                  October 2015


   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

                    +-----------+------+--------------+
                    | Field     | Type | Value length |
                    +-----------+------+--------------+
                    | X         | 1    | 1            |
                    |           |      |              |
                    | CC        | 2    | 1            |
                    |           |      |              |
                    | M         | 3    | 1            |
                    |           |      |              |
                    | PT        | 4    | 1            |
                    |           |      |              |
                    | Seq Num   | 5    | 2            |
                    |           |      |              |
                    | Timestamp | 6    | 4            |
                    |           |      |              |
                    | SSRC      | 7    | 4            |
                    |           |      |              |
                    | Ext Len   | 8    | 2            |
                    +-----------+------+--------------+

   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.

5.  Operations

5.1.  Encrypting a Packet

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

   o  Form an RTP packet.  If there are any header extensions, they MUST
      use [RFC5285].

   o  Apply the transform to the RTP packet

   o  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?





Jennings, et al.         Expires April 20, 2016                 [Page 4]


Internet-Draft                 Double SRTP                  October 2015


   o  Apply the SRTP cryptographic transform with the outer parameters
      (outer transform)

5.2.  Modifying a Packet

   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.

   o  Apply the (outer) decryption transform to the packet

   o  Separate the OHB from the (encrypted) original payload

   o  Change any required parameters

   o  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.

   o  If the MDD resets a parameter to its original value, it MAY drop
      it from the OHB.

   o  The MDD MUST NOT delete any header extensions, but MAY add them.

      *  If the MDD adds any header extensions, it must append them and
         it must maintain the order of the original headers in the
         [RFC5285] block.

      *  If the MDD appends headers, then it MUST add the value of the
         original [RFC5285] length field to the OHB, or update it if it
         is already there.  The original [RFC5285] length is counted in
         words and stored in the Ext Len field of the OHB.

   o  Recombine the new OHB and the (encrypted) original payload

   o  Apply the (outer) encryption transform to the packet

5.3.  Decrypting a Packet

   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.

   o  Apply the (outer) decryption transform to the packet

   o  Separate the OHB from the (encrypted) original payload

   o  Form a new SRTP packet with:



Jennings, et al.         Expires April 20, 2016                 [Page 5]


Internet-Draft                 Double SRTP                  October 2015


      *  Header = Received header, with header fields replaced with
         values from OHB

      *  Header extensions truncated to the [RFC5285] length in OHB

      *  Payload = (encrypted) original payload

   o  Apply the (inner) decryption transform to this synthetic SRTP
      packet

5.4.  Recommended Inner and Outer Cryptographic Transforms

   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.

   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.

6.  Security Considerations

   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.

   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.

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

7.  IANA Considerations

7.1.  RTP Header Extension

   TODO - Define RTP header extension for the OBP block.





Jennings, et al.         Expires April 20, 2016                 [Page 6]


Internet-Draft                 Double SRTP                  October 2015


7.2.  DTLS-SRTP

   We request IANA to add the following values to defines a DTLS-SRTP
   "SRTP Protection Profile" defined in [RFC5764].

            DOUBLE_SRTP_AEAD_AES_128_GCM    = {TBD, TBD }
            DOUBLE_SRTP_AEAD_AES_256_GCM    = {TBD, TBD }

   The SRTP transform parameters for each of these protection are:

      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

   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.

8.  Acknowledgements

   Many thanks to review from GET YOUR NAME HERE.  Send comments.

9.  References

9.1.  Normative References

   [I-D.ietf-avtcore-srtp-aes-gcm]
              McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
              in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-aes-gcm-17
              (work in progress), June 2015.




Jennings, et al.         Expires April 20, 2016                 [Page 7]


Internet-Draft                 Double SRTP                  October 2015


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
              2008, <http://www.rfc-editor.org/info/rfc5285>.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, DOI
              10.17487/RFC5764, May 2010,
              <http://www.rfc-editor.org/info/rfc5764>.

9.2.  Informative References

   [I-D.jones-perc-private-media-reqts]
              Jones, P., Ismail, N., Benham, D., Buckles, N., Mattsson,
              J., and R. Barnes, "Private Media Requirements in Privacy
              Enhanced RTP Conferencing", draft-jones-perc-private-
              media-reqts-00 (work in progress), July 2015.

Authors' Addresses

   Cullen Jennings
   Cisco

   Email: fluffy@iii.ca


   Paul E. Jones
   Cisco

   Email: paulej@packetizer.com


   Adam Roach
   Mozilla

   Email: adam@nostrum.com










Jennings, et al.         Expires April 20, 2016                 [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/