Re: [Perc] Question on diet Design?

[Eric Rescorla <[e-mail]>]

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

> Ekr,
>
>
>> 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.
>
>
> Yea, but the key is only used for DTLS exchanges, so independent of
> anything SRTP related (except for the DTLS-SRTP key derivation for HBH that
> you wanted to ignore for now).
>


Well, you're using it to encipher K_g. Right now, I'm primarily concerned
with the key hierarchy
and not which specific protocol is being used.

2. The KD then generates a single shared key K_g which it provides to each
> agent i under
> K_d_i (in DTLS).
>
>
> Correct.
>
>
> 2. Each agent then generates its own transmission key E_i which it
> transmits to everyone
> under K_g.
>
> Do I have this right?
>
>
> Yes, that's correct.
>
>
> 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?
>
>
> Avoiding the one-time pad is a primary concern, but not the only issue.  A
> secondary issue is that in a conferencing environment where each sender is
> transmitting independently, endpoints need to be able to synchronize the
> crypto context of the sender.  The ROC value is conveyed in the EKT
> field, which facilitates this synchronization.  (The ROC for the HBH
> encryption always starts at 0, so no synchronization is required.  But, the
> ROC for any transmitted flow in an existing conferencing might be any
> value.  So, EKT carries the E2E cipher and the ROC for that flow.)
>
>
> [0] If so, I have another way to address this.
>
>
> Assuming we could still convey the ROC in the clear (it's not really
> secret), then I'd like to hear your suggestion.
>

Replace EKT with a fixed block consisting of:

1. A centrally assigned endpoint ID [you need this to avoid two-time pad]
2. The ROC (if needed)

The per-sender key then can be computed as KDF(K_g, ID) [0]. Note that you
don't need to
send this block that frequently, you can use the same algorithm you use for
EKT, though it's
also pretty small, so maybe easier to just send all the time.

I haven't been thinking about this for very long, so I could of course have
something grievously
wrong and insecure, in which people should point and laugh. One potential
concern is
that an attacker can send some incredibly large ROC and thus cause you to
crank the KDF
forward a zillion times. I believe that currently anyone who has K_g can do
this, so requiring
this block to be MACed with K_g should address this problem.

-Ekr

[0] Note, this assumes I am remembering how the ROC works, which, IIRC, is
just that it tells you which generation of SRTP keys to derive from the
master.