Subject: Re: [AVT] Question regarding RFC 3711

From: Tom Taylor <[email-masked]>
Date: Wed, 08 Jul 2009 11:22:17 -0400

I'm forwarding this message to the list. It seems to have been sent to 
[email-masked] (which route to us list administrators) rather than to 
[email-masked].

Tom T

Subject:
RE: Question regarding RFC 3711
From:
Ilan Doron <[email-masked]>
Date:
Wed, 8 Jul 2009 11:08:46 +0300
To:
"[email-masked]" <[email-masked]>, "Wyss, Felix" <[email-masked]>

Hi
In our case the new keys are received from a re invite session done by the SIP 
(or any control protocol).
No multiple keys so I believe MKI is not relevant.
It seems state is ambiguous:
If considered as re-keying ROC should be kept. Otherwise ROC should be zeroed.

Am I getting this right?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wyss, Felix
Sent: Monday, July 06, 2009 8:28 PM
To: Ilan Doron; [email-masked]'
Subject: Re: [AVT] Question regarding RFC 3711

[inline]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ilan Doron
Sent: Monday, July 06, 2009 10:23
To: [email-masked]'
Subject: [AVT] Question regarding RFC 3711

I have a few questions regarding rfc 3711:

 >From the RFC, section 3.3.1:
After a re-keying occurs (changing to a new master key), the rollover
    counter always maintains its sequence of values, i.e., it MUST NOT be
    reset to zero.

1.       Does re-keying include reinvite session where new keys are allocated?
[Wyss, Felix] Not necessarily.  If multiple master keys were supplied as part of 
the key distribution, the sender can switch between them arbitrarily and 
indicate which one is used for that packet by means of the MKI.

2.       If ROC is maintained, can I assume full SRTP session is maintained, 
i.e. RTP sequence + replay lists + SSRC?
[Wyss, Felix] As SRTP is just a bump in the stack, changes of the SSRC are not 
under the SRTP sender's control.  For a particular SSRC, the SRTP sender needs 
to maintain the appropriate state for a cryptographic context, including the 
ROC.  How many contexts the SRTP sender maintains depends on the application 
(e.g. how many concurrent streams may have to be processed).

Regarding SSRC change during SRTP session:

1.       If a new SSRC arrives should the packet be authenticated with a zero 
ROC or with the current ROC value?
[Wyss, Felix] Each context starts at a ROC of zero.  If you might be joining 
streams late, you can of course try authenticating a couple of ROCs for added 
robustness (but potentially increased denial of service risk).

2.       Assuming authentication succeeds, SRTP session will be reset to zero 
(Sequence, replay lists ROC etc.)?
[Wyss, Felix] A new SSRC gets a new crypto context.  You will want to maintain 
at least as many contexts as there may be concurrent streams being processed 
plus a couple of spares to deal with periods of overlapping streams when you 
switch between devices.

Ilan Doron
Media application Team Leader
Tel:         +972-3-9764354
Fax:        +972-3-9764223
Mobile:   +972-54-6262-775
Email:     [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>Web: 
www.audiocodes.com<http://www.audiocodes.com/>

<http://www.audiocodes.com/solutions/hdvoip>
Click to Sign Up for our email 
updates<http://www.mymarketing.co.il/Subscribe.htm?_u=f3j2a8>

________________________________
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 immediately notify the sender 
and delete or destroy any copy of this message

________________________________
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 immediately notify the sender 
and delete or destroy any copy of this message