Subject: RE: [AVT] SRTP Key Derivation

From: Fries Steffen <[email-masked]>
Date: Tue, 12 Apr 2005 09:13:36 +0200

Hi,

thanks for the answers. I think I got it. I somehow missed the DIV part, but
with that the procedure is clear. Mark, also the remark comming from the
Sdescriptions discussion is good. 

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.

Regards
	Steffen

> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]] 
> Sent: Monday, April 11, 2005 6:30 PM
> To: Sylvain Latulippe
> Cc: Fries Steffen; Karl Norrman (KI/EAB); Avt@Ietf. Org
> Subject: Re: [AVT] SRTP Key Derivation
> Importance: High
> 
> Sylvain
>     Yes, this is a problem for the signaling.  We have 
> discussed it in the context of SDP Security Descriptions 
> signaling for SRTP and offer the following guideline:  Select 
> the initial sequence number between
> 0..2^15-1 rather than 0..2^16-1.  The solution that you 
> mention is fine, but I have heard from many that signaling 
> the RTP ROC or SEQ is an unnatural act - it places 
> constraints on an SRTP implementation to be tightly coupled 
> with signaling and/or key management during a session.
> 
> Mark
> On Apr 11, 2005, at 9:11 AM, Sylvain Latulippe wrote:
> 
> > Hi,
> >
> > There is one condition that may cause the authentication to 
> fail. This 
> > condition may occur when only the initial ROC is given and 
> the initial 
> > SEQ is not.
> >
> > Here is the sequence summary:
> >
> > 1 - The sender and the receiver are given initial ROC = 0, 
> the initial 
> > SEQ is not given
> > 2 - The sender sends first packet with SEQ = 0xFFFF (SRTP 
> computation 
> > is made with ROC = 0, and SEQ = 0xFFFF)
> > 3 - This packet is lost
> > 4 - The sender sends a second packet with SEQ = 0 since it 
> wrapped. So 
> > does the ROC. SRTP computation is made with ROC = 1, and SEQ = 0.
> > 5 - The receiver receives this packet. Since an initial SEQ number 
> > hasn't been provided, it uses the SEQ received in the 
> packet (highest 
> > received RTP SEQ) = 0. When the receiver determines the 
> index with the 
> > SRTP algo in appendix A, it  uses ROC = 0 and SEQ = 0. Since the 
> > sender has used ROC = 1 and SEQ = 0, it won't synchronize and will 
> > cause the authentication to fail.
> >
> > Note that when initial SEQ is given to the receiver, this 
> problem does 
> > not exist unless more than 32K packets are lost.
> >
> >
> > Sylvain
> >
> >
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > Fries Steffen
> > Sent: 11 avril, 2005 11:14
> > To: Karl Norrman (KI/EAB)
> > Cc: Avt@Ietf. Org; Mark Baugher
> > Subject: RE: [AVT] SRTP Key Derivation
> >
> > Hi Karl,
> >
> > I was refering to the session keys. As far as I know the IV is 
> > constructed on a per packet base, but the keys?
> >
> > Regards
> > 	Steffen
> >
> >
> >> -----Original Message-----
> >> From: Karl Norrman (KI/EAB) [mailto:[email-masked]]
> >> Sent: Monday, April 11, 2005 5:07 PM
> >> To: Fries Steffen
> >> Cc: Avt@Ietf. Org; Mark Baugher
> >> Subject: RE: [AVT] SRTP Key Derivation
> >>
> >> Hello!
> >>
> >> Please note that the key derivation is conceptually performed on a 
> >> per
> >
> >> packet basis.  This means that it does not matter if a packet is 
> >> lost;
> >
> >> synchronization is regained when the next packet arrives.
> >>
> >> Regards,
> >> Karl
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] [mailto:[email-masked]]On
> >> Behalf Of
> >>> Fries Steffen
> >>> Sent: den 11 april 2005 16:49
> >>> To: Mark Baugher
> >>> Cc: Avt@Ietf. Org
> >>> Subject: [AVT] SRTP Key Derivation
> >>>
> >>>
> >>> Hi Mark,
> >>>
> >>> I've got a short question regarding the key derivation in SRTP.
> >>> The packet index is one item that goes into the derivation
> >> function.
> >>> The packet index itself is build through the ROC and the
> >> RTP sequence
> >>> number in the packet. What happens if the first packet gets lost?
> >>> Is there any way of synchronization?
> >>>
> >>> Regards
> >>> 	Steffen
> >>>
> >>>
> >>> --------------------------------------------
> >>>  Steffen Fries,     Siemens AG, CT IC 3	
> >>>  Otto-Hahn-Ring 6,  D-81730 Munich, Germany
> >>>  Phone:  (+49) 89 / 636-53403,
> >>>  Fax  :  (+49) 89 / 636-48000
> >>>  email:  [email-masked]
> >>> --------------------------------------------
> >>>
> >>> _______________________________________________
> >>> 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, 12 Apr 2005 11:16:00 +0200

Hi Steffen,

> 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