Subject: RE: [AVT] RFC 3711 Key Derivation

From: Vavilapalli Srikanth-A19563 <[email-masked]>
Date: Tue, 30 Nov 2004 14:50:06 +0530

Thanks a lot Mats.

Effectively you are saying that the RTP senders and receivers have to derive
the session keys (k_e, k_s, k_a) for "every packet" sent or received
respectively, not just once before session start. Am I right?

If that is the case, then I agree there will not be any out-of-sync issues
at-least in the session key derivation because of initial loss of packets. 

NOTE: However, no where in the RFC (at-least from my understanding) says to
derive the session keys for every packet sent and received. It was saying to
derive the session once before session commencement and refresh the keys
whenever (index mod 2^key-derivation-rate) is zero. Isn't my understanding
right here?

Regards
Srikanth

-----Original Message-----
From: Mats Näslund [mailto:[email-masked]] 
Sent: Tuesday, November 30, 2004 2:32 PM
To: Vavilapalli Srikanth-A19563
Cc: Mark Baugher; Yuval Nissan; [email-masked]
Subject: Re: [AVT] RFC 3711 Key Derivation

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

Vavilapalli Srikanth-A19563 wrote:

> 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

_______________________________________________
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:40:55 +0100

Hi Srikanth,

> respectively, not just once before session start. Am I right?

Yes. At least you will need to *consider* the need to perform derivation
on every packet. Just because you updated the key on the previous
packet, you can never be sure that you won't need to go back to the
"previous" key again due to re-order. I would compare the "logic" needed
with that you need to keep ROC updated (sect 3.3.1) where you MAY need
to consider any ROC in the set { ROC-1, ROC, ROC+1 }. It's the same with
the keys.

In almost all practical cases (unless you have derivation_rate close
to "1") you will NOT need to derive a new key for the next packet,
and this can be determined by straight-forward "sequence number logic"
without actually applying the derivation function.

As Mark said, if this still worries you, just set the rate to zero.

> at-least in the session key derivation because of initial loss of packets.

Good.

> whenever (index mod 2^key-derivation-rate) is zero. Isn't my understanding

One can always ask if the spec. if clear enough on every single issue.
We certainly tried to be. If you look at the "formula" on p 26,
as I wrote before, the keys are computed like

	key = PRF( ... , ... index ...),

so since index can vary both up and down, I hope it is clear that the
order in which the keys are to be used may not always be "monotonic".

Best,

/Mats

---

From: Mark Baugher <[email-masked]>
Date: Tue, 30 Nov 2004 07:05:47 -0800

Thanks for the explanations Mats.  Over the past year or so, several 
people have misread how the key derivation algorithm works in about the 
same way: People expect to perform key derivation after 2^Nth packet 
has been sent rather than when the extended sequence number reaches 
2^N.  We might want to update the specification or even put the 
clarification in the form of an errata write-up on the RFC page.

Mark