Re: [Perc] Question on diet Design?

["Paul E. Jones" <[e-mail]>]

Ekr,

For each endpoint, a HBH key is established using DTLS-SRTP (RFC 5764) 
procedures via an association established between the endpoint and key 
distributor.  Those procedures are (mostly) unaltered from the 
endpoint's perspective and independent of EKT.   The only aspect that is 
"alternated" is that, since we're using a "double" cipher, half of the 
bits generated for the HBH key are discarded (as they're not used).  In 
the framework document, this is referred to as Key(j).  For simplicity 
in keeping your notation below, let's call this K_h.  This is the SRTP 
master key. There is also an SRTP master salt S_h created via the 
DTLS-SRTP procedures.

Over that DTLS association, the key distributor will send an "EKTKey" 
message containing the conference key (what you called the group key, 
K_g).  The same conference key is given to each endpoint in the 
conference.  In the same message, an SRTP master salt S_g is provided by 
the key distributor.

As the "EKTKey" message is transmitted to the endpoint, the values {K_h, 
S_h} are delivered to the media distributor via the tunnel protocol.

At this point, the endpoint has {K_h, S_h, K_g, S_g} and the media 
distributor has {K_h, S_h}.  For every endpoint i, the K_h and S_h 
values differ.

Each endpoint then manufacturers a random SRTP master key E_i used for 
E2E encryption.  The endpoint then generates the various keys for RTP 
encryption, RTP authentication, RTCP encryption, and RTCP authentication 
using the KDF defined in RFC 3711 from the pair {E_i, S_g}.  This 
produces k_e, k_a, k_s (Section 4.3.1 of RFC 3711).  Since we will have 
these for both E2E and HBH, let's suffix whese with _e (for E2E).  So, 
we'll have K_e_e.

The endpoint then generates the various keys for RTP encryption, RTP 
authentication, RTCP encryption, and RTCP authentication using the KDF 
defined in RFC 3711 from the pair {K_h, S_h}.  As above, we'll have k_e, 
k_a, k_s, which let's suffix as k_e_h (for HBH).

The endpoint then performs these steps:
   1) encrypts the RTP packet using the keys derived via the KDF for E2E, 
K_e_e and salt k_s_e.
   2) encrypts the RTP packet using the keys derives via the KDF for HBH, 
namely K_e_h and k_s_h.

The EKT field is then added to the end of the packet.  If it's the 
"short EKT field", it has no keying material inside. It would just be a 
single 0 octet.

The long EKT field is used periodically to allow the endpoint to 
transmit E_i to other endpoints.  The plaintext of this field is 
constructed and then encrypted using AESKeyWrap(K_g, ekt_field).  The 
ciphertext is then appended to the packet, along with a few plaintext 
fields indicating the field type and length.

As the media distributor receives the packet, it removes the EKT field, 
then decrypts the packet using the keys derived from {K_h,S_h}.  It then 
re-encrypts the packet using {K_h',S_h'} (where ' denotes the HBH keys 
shared with the endpoint to which the media distributor intends to 
forward the packet) and then attached the EKT field to the end 
untouched.

Upon receipt of the packet, the receiving endpoint first processes the 
EKT field.  It decrypts the field using K_g.  It extracts the SRTP 
master key E_i.  It already has S_g via the EKTKey message from its own 
exchange with the key distributor.   So, using its own HBH keying 
material {K_h',S_h'} and the E2E keying material {E_i,S_g}, it can 
perform HBH and E2E decryption of the packet.

I hope that helps.  As you can see, EKT plays a very limited role in the 
overall architecture.  We're still very much relying on DTLS-SRTP 
procedures and on standard SRTP procedures.  Juggling all these keys is 
certainly confusing, though.  I guess a pretty picture showing all the 
pieces would be useful.

Paul

------ Original Message ------
From: "Eric Rescorla" <[e-mail]>
To: [e-mail]
Sent: 3/21/2017 5:48:17 PM
Subject: [Perc] Question on diet Design?

>I've read this document and I'm finding it hard to understand the
>basic design. Ignoring all the details, we have a node i which
>connects to the Key Distributor (KD), and we want to establish a
>shared key for each node i = 0, 1, ... n (this is just to establish
>E2E keys. I'm ignoring HBH keys for now). So, as I read it, the system
>works like this.
>
>- Node i connects to KD and establishes a DTLS connection which 
>establishes
>   a pairwise key K_d_i.
>- The KD then generates a fresh EKT key K_e_i and sends it to i 
>encrypted
>   under K_d_i.
>- The KD then generates a shared group key K_g and sends it 
>individually
>   to all i in SRTP/EKT encrypted under K_e_i.
>
>Is that correct so far?
>
>If so, my question is why you need K_e_i? You have already established
>a shared secret via the DTLS connection and you can make as many fresh
>pairwise encryption keys as you want from that, so why do you need
>to make a new encryption key K_e_i and send it from KD to i?
>
>-Ekr
>