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

From: [email-masked]
Date: Tue, 1 Feb 2005 13:10:14 +0100

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

Regards,
Johan

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Mats Näslund <[email-masked]>
Date: Tue, 01 Feb 2005 13:39:54 +0100

Hi,

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

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

> attacker. An attacker A might, in our scenario, send a faked packet before the 

Yes.

> 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