Subject: RE: [AVT] SRTP Key Derivation

From: Fries Steffen <[email-masked]>
Date: Tue, 12 Apr 2005 12:26:48 +0200

Hi Maets, 

no, what I meant is the following
 Sender                                      Rec.
 ------                                      ----
 
 Initial packet 
 SEQ1 = N*keyDerivationRate-1
 k1 = KDF(SEQ1)
 
                --------> packet lost
 
 SEQ2 = SEQ1+1
 k1 is still used, as the key derivation rate is not reached.
 
                --------------------------> packet containing
                                            SEQ = N*keyDerivationRate
                                            arrives
 
                                            k = KDF(SEQ) (== k2) 

The sender pics the first sequence number randomly and increments this by 1
for each new packet. If the initial sequence number is accedently
KeyDerivationRate-1, and the packet gets lost, then sender and receiver will
derive different keys. The sender is still using the first derived key,
while the receiver only sees the second packet, for which the result of SEQ#
DIV KeyDerivationRate is different than for the sender.

Regards
	Steffen

> -----Original Message-----
> From: Mats Näslund [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2005 11:16 AM
> To: Fries Steffen
> Cc: Mark Baugher; Sylvain Latulippe; Karl Norrman (KI/EAB); 
> Avt@Ietf. Org
> Subject: Re: [AVT] SRTP Key Derivation
> 
> Hi Steffen,
> 
> Fries Steffen wrote:
> 
> > Based on the remarks from Sylvain, I think one could even 
> generalize 
> > the guideline to the case when the initial SEQ# is 0xFFFF. 
> The SEQ# is 
> > randomly chosen, but if the SEQ# of the first packet is 
> > (N*keyDerivationRate-1 ) and the packet gets lost, than the DIV 
> > operation on both sides will produce different results. I'm 
> not quite 
> > sure about the probability of this happen, but maybe we 
> could extend the guideline to cover that case too.
> 
> We don't see why this would create problems. The first 
> succesfully arriving packet will contain the SEQ# which the 
> sender used to derive keys for that very packet, so the 
> receiver will use the same SEQ# as input to the KDF on his 
> side. That is:
> 
> Sender                                      Rec.
> ------                                      ----
> 
> SEQ1 = N*keyDerivationRate-1
> k1 = KDF(SEQ1)
> 
>                --------> packet lost
> 
> SEQ2 = N*keyDerivationRate
> k2 = KDF(SEQ2)
> 
>                --------------------------> packet containing
>                                            SEQ = N*keyDerivationRate
>                                            arrives
> 
>                                            k = KDF(SEQ) (== k2)
> 
> etc.
> 
> 
> 
> Cheers
> 
> /Mats
> 
> 

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

---

From: Mats Näslund <[email-masked]>
Date: Tue, 12 Apr 2005 14:01:14 +0200

Hi Steffen,

We still don't see the problem.

First, let us assume there is no ROC synch-issue. (We agree there
are issues with this as Mark discussed before, but this is a
general problem, not related to KDF as such.)

Let us take a "helicopter view" of the key derivation.

We are assuming sender/receiver use the same ROC. Given that,
the KDF can (simplified) be descibed as a function

   key_for_packet_with_SEQ = KDF(...., SEQ DIV RATE, ....),

where we only highlight the synch-dependent parameters (the other
inputs are static for our purpose). Now, "RATE" is a constant and "SEQ"
is carried *in the packet*. So, how can sender/receiver get different
values, for the same function, applied to the same input(s)?

More explicit comments below:

> no, what I meant is the following

Note: "SEQ1 DIV keyDerivationRate" will here be N-1.

>  k1 = KDF(SEQ1)

To be exact, the input to KDF is "SEQ1 DIV keyDerivationRate",
i.e. N-1.

>  k1 is still used, as the key derivation rate is not reached.

Why?

Note: "SEQ2 DIV keyDerivationRate" will here be N.

These are not the same, so if the sender uses the same k1, he
is not complying with the spec.

/Mats