Re: [AVT] SRTP first packet key with k_d_r > 0

[Mats Näslund <mats.naslund at ericsson.com>]

Hi,

johkul-9 at student.ltu.se wrote:

> Hi,
>
> I have a question regarding the generation of session keys for the first 
> received packet using a key_derivation_rate higher than 0 in SRTP.
>
> Consider a scenario where redundant T140 encoded text is sent over srtp from a 
> sender S to a receiver R. The sequence number used to derive session keys for 
> S is randomly set to 12499 and the key_derivation_rate for the session is 
> decided to be 1000.
>
> If the first packet sent by S is lost R will try to generate keys with the 
> index of the received packet. Now S sends the packet with index 12500 and R 
> generates keys with this index. What should R do in this scenario? The packet

R should derive a key according to spec. I.e.

k_e = PRF(k_m, ..... ((ROC*2^16 + 12500) DIV key_derivation_rate ...),

i.e. using index = ROC*2^16 + 12500.

All he needs from the packet is the SEQ (plus the locally maintained
ROC).


> will not get authenticated (as R's keys are generated using an index of 12500)
> and waiting for 500 more packets (containing text data) for synchronization to 
> occur is not an option.
>
> Considering a network where not many consecutive packets will be lost one 
> could, for the first packet received, generate a set of keys for every earlier 
> index (at most until index mod k_d_r == 0 in which case synchronization is 
> obtained or the packet must be a fake) check for authenticity and, if the 
> packet is finally authenticated, assume this was the index with which the 
> original keys were generated. If it is known huge ammounts of consecutive 

This is a sub-optimal (and not needed) method, since it lowers the 
effective strength of integrity: more than one tag value may be
accepted.

> packets are not going to be lost this should not be too computationaly 
> expensive as there will be only as many generations as there are initial lost 
> packets.
>
> However, the above approach opens up opportunities for exploitation by an 
> attacker. An attacker A might, in our scenario, send a faked packet before the 

Yes.

> first genuine S-packet is received by R (since text is only sent on user input 
> this time window will be much bigger than say with an audio or video stream). 
> In a worst case scenario this would cause R to generate k_d_r - 1 number of 
> keys and for each key check the packet for authenticity. An attacker might 
> also have a greater chance of getting a faked packet authenticated as a lot of 
> keystream is used against that one packet.
>
> If the above algorithm is limited to generating keys for only say 10 previous 
> sequence numbers this attack might not be terribly effective, but then again 
> this would mean that if the 11 first packets are lost one might have to wait 
> for k_d_r - 12 packets to be sent before synchronization occurs (when a new 
> key is generated).
>
> Now, with an application such as the one mentioned one would probably use a 
> k_d_r of much less than 1000, but I'd still like to know what you propose I do 
> to ensure synchronization from the first packet received without exposing 
> myself to the multiple authentication key concern and DoS attack above.
>
> I'd be thankful for any advice you might give me.

The RFC is robust in this sense. I suspect the problem you (think you)
see is due to an assumption to implement the derivation in a "statefull" 
way. Rather, each packet carries (self contained) the info needed to 
derive the right key, and you cannot rely on having performed any
previous derivations. There is no "history".

It may be illustrative to compare to the "IV" used in the decryption.
That too is formed on per-packet basis, taking info from each RTP
header, without dependece on earlier packets.

Hope this helps.

/Mats


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt