Re: [Perc] Question on diet Design?

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

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


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

I'll note that there was an alternative some time ago 
(draft-mcgrew-srtp-aero), but that work did not progress.  Since I 
wasn't involved, I do not know why.  Perhaps because it moved away from 
SRTP and defining an SRTP replacement would have been a pretty high 
barrier?

Paul