Subject: [AVT] RE: RFC3711: SRTP session keys derivation with non-zero key deriv ation rate

From: Vavilapalli Srikanth-A19563 <[email-masked]>
Date: Mon, 22 Nov 2004 20:34:39 +0530

Karl

Thanks for your reply. I am still not fully clarified with this answer.

Lets take an example of an RTP session with two participants X and Y. Assume
X & Y have communicated their ROC of zero using some out-of-band signaling.
I don't think you are suggesting us to exchange the initial sequence numbers
of this session also here, are you? (Though RFC states that "Sending the RTP
sequence number in the key management MAY be useful e.g., when the initial
sequence number is close to wrapping (to avoid synchronization problems),
and to communicate the current sequence number to a joining endpoint (to
properly initialize its replay list).")

Assumption1: Initial sequence number is not communicated using key mgmt
protocol. Only ROC is exchanged.

"X" started the RTP TX traffic with initial sequence number say 150 and ROC
obviously zero. So PACKET_INDEX at Tx side is = ROC || SEQ = 150. Using this
index value including with some other parameters, "X" derives his session
keys (k_e, k_a, k_s) using AEC-CM PRF function. This key derivation happens
once at the initial time before transmitting first packet and after that
whenever (index mod KDR) equals zero. Now "X" encrypts the first packet
using k_e and transmits to "Y". Similarly "X" transmits packet index 151
after encrypting it with the same session key k_e derived earlier.
Tx Packet traffic = 150, 151, 152...

Assumption2: The packet with index 150 is lost in the transit.

"Y" receives his first packet and estimates the value "v" from set {ROC-1,
ROC, ROC+1} and calculates the PACKET_INDEX = v || SEQ = 151. As this is the
first packet, "Y" derives his session keys using packet index 151 and some
other params and gets a different set of session keys (k_e1, k_a1, k_s1),
which he uses to decrypt the packet. However this packet was encrypted with
a key-stream which was generated using the session key (k_e) at "X". Hence
decryption fails for all the consecutive packets. How to tackle this
scenario or synchronization issue?

Hope my question is clear.

Regards
Srikanth  

-----Original Message-----
From: Karl Norrman \(KI/EAB\) [mailto:[email-masked]] 
Sent: Monday, November 22, 2004 7:27 PM
To: Vavilapalli Srikanth-A19563
Cc: milo diurn; Elisabetta Carrara \(KI/EAB\); [email-masked]; David A.
McGrew; [email-masked]
Subject: RE: RFC3711: SRTP session keys derivation with non-zero key
derivatio n rate

Hello!

First, please refer to our previous answer (in another thread)
where we explained that "parameters" in general need to be communicated
out-of-band by key management.

Specifically, in this case, the current ROC is communicated
to the receiver as he joins the session. Alternatively, the
session just starts and the ROC is zero. On consecutive packets,
an "estimation" of the index is done at the receiver (as also
explained in the RFC). 

To be more specific, the packet index is the
concatenation of the roll-over counter and the sequence number. 
The roll-over counter can be estimated from the sequence number 
carried with each SRTP packet using, e.g., the algorithm in appendix A.
Hence, the sender and receiver would be synchronized when the next
packet arrives.

You are absolutely right that there *are* (extreme) cases when
the receiver *can* get out of synch.

Regards,
Karl & Co

> -----Original Message-----
> From: Vavilapalli Srikanth-A19563 [mailto:[email-masked]]
> Sent: den 22 november 2004 13:46
> To: David A. McGrew; Karl Norrman (KI/EAB); [email-masked]
> Cc: milo diurn; Elisabetta Carrara (KI/EAB); [email-masked]
> Subject: RFC3711: SRTP session keys derivation with non-zero key
> derivatio n rate
> 
> 
> David, Karl and SRTP Community
> 
> RFC: 3711
> Section: 4.3.1 (Key Derivation Algorithm)
> Scenario: Unicast Bidirectional single stream RTP session
> 
> RFC States: that the sender and receiver of a SRTP session 
> derive all the
> SRTP/SRTCP session keys from master key using Master key, Master salt,
> Packet Index and Key Derivation Rate (KDR).
> Mathematically k_e = PRF_n_e (k_master, ((0x00 || (index DIV KDR)) XOR
> master_salt)
> And also it mentions that the derivation should happen before 
> the first
> packet sent or first packet is received. 
> 
> Description: In this scenario how can the sender of SRTP 
> packets make sure
> that the receiver uses the same packet index to derive the 
> same session keys
> at receiver's place that are used at sender side? I mean what 
> if the packet
> with packet index (which is used for key derivation at the 
> sender side) is
> not reached to the receiver's and the KDR used for this 
> session is non-zero.
> Then I guess the sender and receivers will be out of sync in terms of
> session keys. Am I right in stating that?
> 
> OR
> 
> Are the applications using a non-zero value of KDR out of 
> scope of this
> document? 
> 
> There will not be any issues in this approach if the KDR is 
> zero because
> "(index DIV zero)" produces zero every where. Even in the 
> examples, the
> session keys are derived with KDR as zero.
>  
> 
> Could you please clarify this point?
> 
> 
> Thanks & Regards
> Srikanth Vavilapalli
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David
> A. McGrew
> Sent: Friday, November 19, 2004 9:34 PM
> To: milo diurn
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [AVT] RFC3711: Srtp key_id ?
> 
> Milo,
> 
> On Nov 19, 2004, at 7:12 AM, milo diurn wrote:
> 
> > Karl, and Srtp community,
> >
> > In RFC3711,
> > how is key_id defined and by which part (external/internal) ?
> 
> it is defined externally.  From Section 3.1:
> 
>     MKI (Master Key Identifier): configurable length, OPTIONAL.  The
>                MKI is defined, signaled, and used by key management.
> 
> 
> >
> > If key_id belongs to the Srtp parameters, why do not 
> referring to it in
> > the parameters list (chap 8.2) ?
> 
> It is there, but you might have missed it because it is only referred 
> to by the acronym "MKI"
> 
> Hope this helps!
> 
> David
> 
> >
> > Could you, please, clarify this point ?
> >
> > Thanks
> >
> > Regards
> >
> > _________________________________________________________________
> > FREE pop-up blocking with the new MSN Toolbar - get it now! 
> > http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
> >
> 
> 
> _______________________________________________
> 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