Subject: RE: [AVT] RFC 3711 Key Derivation

From: Vavilapalli Srikanth-A19563 <[email-masked]>
Date: Tue, 30 Nov 2004 10:16:01 +0530

Mark

Please correct me if my understanding from the RFC3711 standard is wrong. 

RFC3711 specifies a key derivation mechanism to be run for deriving the
session keys (k_e, k_a, k_s) which are used in encryption and authentication
process and must be executed once before media flow commencement and can be
refreshed depending on the Key derivation rate. This key derivation
mechanism uses the packet index as an input to the PRF algorithm.

First understanding from the above text is if Key derivation rate is "N"
(where N is a non-zero positive integer) means, the SRTP sender should
refresh/regenerate the session keys (k_e, k_s, k_a) for every "N" packets
sent. Am I right here? However, I am not clear on the receiver refreshing
its session keys. Will it also depend on the number of packets received? If
so how are the packet losses accounted in this calculation?

Second, the SRTP sender uses the packet index (ROC || SEQ) of the first
packet to derive the session keys (k_e, k_s, k_a), where ROC will be zero
and SEQ is a random number (not necessarily zero) used as initial sequence
number. This packet index will have impact on the key derivation only when
the derivation rate is non-zero positive integer. In the similar fashion, to
derive the same session keys at the receiving end, the receiver also should
use the same packet index to derive the session keys. With this
understanding I strongly believe that the receiver might get out-of-sync if
the initial packets of the session are lost, because the packet index
estimated at the receiver end might not be the same that is used at the
sender side to derive the session keys. How do we re-sync both parties in
this scenario? 

-Srikanth

-----Original Message-----
From: Mark Baugher [mailto:[email-masked]] 
Sent: Monday, November 29, 2004 11:12 PM
To: Vavilapalli Srikanth-A19563
Cc: Ofer Idan; [email-masked]; Yuval Nissan
Subject: Re: [AVT] RFC 3711 Key Derivation

hi

On Nov 28, 2004, at 10:28 PM, Vavilapalli Srikanth-A19563 wrote:

> Idan
>
> I think the initial sequence number (SEQ) and ROC of the session must  
> be
> communicated to the other participants in the case non-zero key  
> derivation
> rate using some out-of-band signaling.

I hope it's not necessary to communicate the SEQ, which is a
very difficult thing to signal OOB.  Signaling the ROC for ongoing
sessions is bad enough.  The signaling layer typically does not have
access to this sort of state information.
>
> If not (i.e. if SEQ number is not communicated), even the integrity
> protection also can not avoid the out of sync issues. The integrity
> protection helps the receiver to drop the attacker's packet, but also  
> makes
> receiver to drop the actual sender's packets, because receiver uses
> different session key than the sender's.

The value of the SEQ in the validated packet with the ROC are enough  
information
to identify and calculate the correct key (the SEQ is not encrypted so  
the
receiver can determine the key to use).  What am I missing?

Mark
>
>
> Regards
> Srikanth
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of  
> Mark
> Baugher
> Sent: Monday, November 29, 2004 4:08 AM
> To: Ofer Idan
> Cc: Yuval Nissan; [email-masked]
> Subject: Re: [AVT] RFC 3711 Key Derivation
>
> hi
> On Nov 28, 2004, at 12:33 AM, Ofer Idan wrote:
>
>> Hi,
>>
>>  
>>
>> I have a question regarding RFC 3711 Key derivation rate.
>>
>>  
>>
>> In section 3.3 the decrypt process is described:
>>
>>  
>>
>> Bullet (4) says to determine the session keys using the maser key,
>> master salt, key derivation rate.
>>
>> Bullet (5) says to check for anti reply, verify authentication.
>>
>>  
>>
>> I think that there might be a problem here.
>>
>>   
>>
>> Consider a scenario where Key derivation rate is supported (different
>> than zero).
>>
>>  
>>
>> An attacker can send a packet with a higher sequence number that will
>> cause the receiver to change his session keys (according to key
>> derivation rate).
>
> The attacker's packet won't verify upon receipt when the session is
> integrity protected and will be rejected.  (Hence the importance of
> integrity protection).
>
> Mark
>>
>> From this moment on, the two sides will be unsynchronized and the
>> conversation will end.
>>
>>  
>>
>> Therefore I think that before updating the session keys the receiver
>> must first verify the message (and the sequence number) and only if
>> verified he should update all the keys.
>>
>>  
>>
>> Further more;
>>
>> I think that when supporting key derivation rate, authentication must
>> be applied. (otherwise the receiver is vulnerable to such attack)
>>
>>  
>>
>> What do you think ?
>>
>> ------------------
>>
>> Regards,
>>
>> Ofer Idan
>>
>> Audio Codes
>>
>>  
>>
>> ********************************************************************** 
>> *
>> *************************************
>> This email and any files transmitted with it are confidential  
>> material.
>> They are intended solely for the use of the designated individual or
>> entity to whom they are addressed.
>> If the reader of this message is not the intended recipient,
>> you are hereby notified that any dissemination,use,
>> distribution or copying of this communication is strictly prohibited
>> and may be unlawful.
>>
>> If you have received this email in error please notify
>> [email-masked] and permanently delete the e-mail and files.
>>
>>
>> ********************************************************************** 
>> *
>> ************************************
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

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

---

From: Mats Näslund <[email-masked]>
Date: Tue, 30 Nov 2004 10:02:00 +0100

Hi,

I hope Mark excuses me for jumping in, but I can't resist
to give my explanation for why specific synch problem cannot occur
due to the key derivation. Please take a look at the RFC
on page 26. Here, you will see that for a given (just received)
packet, the keys (and salt etc) are given by:

	key = PRF_n(k_master, x),

(where key is k_s, k_a or k_e), and where in turn, x is of the form,

	x = salt XOR (<label> || index DIV key_derivation_rate).

If we "expand" this, you will get (unimportant stuff left out):

key = PRF_n(k_master, ... index DIV key_derivation_rate).

Note that index is determined by SEQ and ROC.  SEQ is carried
along with the packet and does not create problems. The only thing
that can go wrong is if the wrong ROC is used. This can happen
only if packet loss or reordering on the order of 2^15 packets
occurs. However, *if* ROC wrong, notice that ROC is also
part of the IV for the decryption, and it is also part of the
authenticated data, etc. Hence, even if the right keys were used,
decryption and/or authentication will fail anyway. When authentication 
fails, possible ROC update will be discarded. Therefore, the
problem with loosing synch on ROC is general, and the key derivation
does not make it worse, it shows precisely the same problem
as the rest of the protocol does in case of EXTREME loss or
re-order.

You could argue that authentication helps since it will assist
in avoiding false ROC updates. However, as long as we keep
using the wrong ROC on the receiver side, it does not help much
since decryption will just produce garbage anyway, and it is still
not until we somehow re-gain synch on the ROC value that the
protocol starts to work properly again.

Best,

/Mats