Re: [Perc] Question on diet Design?

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

Ekr,

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

I think what you propose would work, but each stream from a given 
endpoint would need to have a unique key since we do not want the any 
two media flows using the same key. Thus, I think we'd need:
   KDF(K_g, ID || stream_id)

The ID, steam_id, and ROC values would need to be conveyed in the RTP 
packet (or RTCP packet -- though I'd prefer to try to avoid putting such 
info into RTCP) to ensure that the receiver gets the information it 
needs to decrypt the flow.  So, it's not clear that there is an 
advantage to this approach.  The size of the EKT field might be smaller, 
but we could make it smaller now if we wanted (removing extensibility 
and length fields).

Perhaps I'm missing an important advantage?

Paul