A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing
draft-ietf-perc-private-media-framework-07

quot; the size that is needed.
   Per the Double specification, the E2E part is the first half of the
   key, so the endpoint will just discard that information in PERC.  It
   is not used.  The second half of the key material is for HBH
   operations, so that half of the key (corresponding to the least
   significant bits) is assigned internally as the HBH key.

   The media distributor doesn't perform DTLS-SRTP, but it is at this
   point that the key distributor will inform the media distributor of
   the HBH key value via the tunnel protocol
   ([I-D.ietf-perc-dtls-tunnel]).  The key distributor will send the
   least significant bits corresponding to the half of the keying
   material determined through DTLS-SRTP with the endpoint to the media
   distributor via the tunnel protocol.  There is a salt generated along
   with the HBH key.  The salt is also longer than needed for HBH
   operations, thus only the least significant bits of the required
   length (i.e., half of the generated salt material) are sent to the
   media distributor via the tunnel protocol.

   No two endpoints will have the same HBH key, thus the media
   distributor must keep track each distinct HBH key (and the
   corresponding salt) and use it only for the specified hop.

   This key is also used for HBH encryption of RTCP.  RTCP is not end-
   to-end encrypted in PERC.

A.2.  The Key Distributor Transmits the KEK (EKT Key)

   Via the aforementioned DTLS-SRTP association, the key distributor
   will send the endpoint the KEK (i.e., EKT Key per
   [I-D.ietf-perc-srtp-ekt-diet]).  This key is known only to the key
   distributor and endpoints.  This key is the most important to protect
   since having knowledge of this key (and the SRTP master salt
   transmitted as a part of the same message) will allow an entity to
   decrypt any media packet in the conference.

   Note that the key distributor can send any number of EKT Keys to
   endpoints.  This can be used to re-key the entire conference.  Each
   key is identified by a "Security Parameter Index" (SPI) value.
   Endpoints should expect that a conference might be re-keyed when a
   new participant joins a conference or when a participant leaves a
   conference in order to protect the confidentiality of the
   conversation before and after such events.

Jones, et al.             Expires March 8, 2019                [Page 20]
Internet-Draft           Private Media Framework          September 2018

   The SRTP master salt to be used by the endpoint is transmitted along
   with the EKT Key.  All endpoints in the conference utilize the same
   SRTP master salt that corresponds with a given EKT Key.

   The EKT Field in media packets is encrypted using a cipher specified
   via the EKTKey message (e.g., AES Key Wrap with a 128-bit key).  This
   cipher is different than the cipher used to protect media and is only
   used to encrypt the endpoint's SRTP master key (and other EKT Field
   data as per [I-D.ietf-perc-srtp-ekt-diet]).

   The media distributor is not given the KEK (i.e., EKT Key).

A.3.  Endpoints fabricate an SRTP Master Key

   As stated earlier, the E2E key determined via DTLS-SRTP MAY be
   discarded in favor of a locally-generated SRTP master key.  While the
   DTLS-SRTP-derived key could be used, the fact that an endpoint might
   need to change the SRTP master key periodically or is forced to
   change the SRTP master key as a result of the EKT key changing means
   using it has only limited utility.  To reduce complexity, PERC
   *RECOMMENDS* that endpoints create random SRTP master keys locally to
   be used for E2E encryption.

   This locally-generated SRTP master key is used along with the master
   salt transmitted to the endpoint from the key distributor via the
   EKTKey message to encrypt media end-to-end.

   Since the media distributor is not involved in E2E functions, it will
   not create this key nor have access to any endpoint's E2E key.  Note,
   too, that even the key distributor is unaware of the locally-
   generated E2E keys used by each endpoint.

   The endpoint will transmit its E2E key to other endpoints in the
   conference by periodically including it in SRTP packets in a Full EKT
   Field.  When placed in the Full EKT Field, it is encrypted using the
   EKT Key provided by the key distributor.  The master salt is not
   transmitted, though, since all endpoints will have received the same
   master salt via the EKTKey message.  The recommended frequency with
   which an endpoint transmits its SRTP master key is specified in
   [I-D.ietf-perc-srtp-ekt-diet].

A.4.  Who has What Key

   All endpoints have knowledge of the KEK.

   Every HBH key is distinct for a given endpoint, thus Endpoint A and
   endpoint B do not have knowledge of the other's HBH key.

Jones, et al.             Expires March 8, 2019                [Page 21]
Internet-Draft           Private Media Framework          September 2018

   Each endpoint generates its own E2E Key (SRTP master key), thus the
   key distinct per endpoint.  This key is transmitted (encrypted) via
   the EKT Field to other endpoints.  Endpoints that receive media from
   a given transmitting endpoint will therefore have knowledge of the
   transmitter's E2E key.

   To summarize the various keys and which entity is in possession of a
   given key, refer to Figure 5.

    +----------------------+------------+-------+-------+------------+
    | Key     /    Entity  | Endpoint A |  MD X |  MD Y | Endpoint B |
    +----------------------+------------+-------+-------+------------+
    | KEK                  |    Yes     |  No   |  No   |     Yes    |
    +----------------------+------------+-------+-------+------------+
    | E2E Key (A and B)    |    Yes     |  No   |  No   |     Yes    |
    +----------------------+------------+-------+-------+------------+
    | HBH Key (A<=>MD X)   |    Yes     |  Yes  |  No   |     No     |
    +----------------------+------------+-------+-------+------------+
    | HBH Key (B<=>MD Y)   |    No      |  No   |  Yes  |     Yes    |
    +----------------------+------------+---------------+------------+
    | HBH Key (MD X<=>MD Y)|    No      |  Yes  |  Yes  |     No     |
    +----------------------+------------+---------------+------------+

                         Figure 5: Keys per Entity

Appendix B.  PERC Packet Format

   Figure 6 presents a complete picture of what a PERC packet looks like
   when transmitted over the wire.

Jones, et al.             Expires March 8, 2019                [Page 22]
Internet-Draft           Private Media Framework          September 2018

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    A |V=2|P|X|  CC   |M|     PT      |       sequence number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    A |                           timestamp                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    A |           synchronization source (SSRC) identifier            |
      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
    A |            contributing source (CSRC) identifiers             |
    A |                               ....                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    A |                    RTP extension (OPTIONAL)                   |
    A |                      (including the OHB)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    C :                                                               :
    C :                       Ciphertext Payload                      :
    C :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    R :                                                               :
    R :                        EKT Field                              :
    R :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 C = Ciphertext (encrypted and authenticated)
                 A = Associated Data (authenticated only)
                 R = neither encrypted nor authenticated, added
                     after Authenticated Encryption completed

                       Figure 6: PERC Packet Format

Authors' Addresses

   Paul E. Jones
   Cisco
   7025 Kit Creek Rd.
   Research Triangle Park, North Carolina  27709
   USA

   Phone: +1 919 476 2048
   Email: paulej@packetizer.com

   David Benham
   Independent

   Email: dabenham@gmail.com

Jones, et al.             Expires March 8, 2019                [Page 23]
Internet-Draft           Private Media Framework          September 2018

   Christian Groves
   Independent
   Melbourne
   Australia

   Email: Christian.Groves@nteczone.com

Jones, et al.             Expires March 8, 2019                [Page 24]