Re: [Perc] Question on diet Design?

[Eric Rescorla <[e-mail]>]

On Tue, Mar 21, 2017 at 4:48 PM, Paul E. Jones <[e-mail]>
wrote:

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

Let's ignore salts for now. I'd also like to ignore all the hop-by-hop
keys, because I'm
primarily concerned with the e2e keys.


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

I'm going to stop here, because I think this is the relevant point, that I
had misunderstood
and I want to summarize looking just at the E2E portion.

1. You start out with every agent i having a pairwise key K_d_i (the DTLS
traffic key) with the
KD.

2. The KD then generates a single shared key K_g which it provides to each
agent i under
K_d_i (in DTLS).

2. Each agent then generates its own transmission key E_i which it
transmits to everyone
under K_g.

Do I have this right?

If so, my question is. Why? In particular, why can't we use K_g directly to
encrypt SRTP
packets (i.e., as one ginormous SRTP session). I am assuming your answer
here is going
to be that then if you have SSRC collisions then we get two-time pad [0]?
If not, then
is there some other reason I am missing?

-Ekr



[0] If so, I have another way to address this.














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