Subject: [AVT] Question regarding RFC 3711

From: Ilan Doron <[email-masked]>
Date: Mon, 6 Jul 2009 17:22:41 +0300

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?

2.       If ROC is maintained, can I assume full SRTP session is maintained, i.e. RTP sequence + replay lists + SSRC?

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?

2.       Assuming authentication succeeds, SRTP session will be reset to zero (Sequence, replay lists ROC etc.)?

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

---

From: Mats Näslund <[email-masked]>
Date: Tue, 7 Jul 2009 09:26:06 +0200

Hi Ilan,
 
My recollection from writing the spec is as follows.
 
One reason that ROC is kept when a new key is taken into use is due to the
fact that SRTP has an option to associate key usage with a range of SRTP-indexes, <From, To>,
where the ROC forms the most significant bits of these indexes.
 
Suppose that you pre-distribute 3 keys with validity <0, a>, <a+1, b>, <b+1, c>. Suppose now
that after some time you reach index a+1. You will now take the 2nd key into use. *If* you were 
to reset ROC at the same time, the index would "jump back" to a value smaller than a+1 and the
key you just changed to would no longer be valid, you would be supposed to revert back to the first
key again (with possible associated security problems).
 
If you use the MKI mechanism to signal use of a new key, you would not have this problem but
as I recall, it occurred to us that it was easier to always use an index handling that was 
independent of the re-key mechanism. Hence, replay lists also are unaffected though notice that
close to time when the key changes, the replay window may cover packets processed both with
the old and the new key so if there is packet reorder you may need to be prepared to revert to
the old key on occasion. 

Handling of ROC and other parameters when someone joins a session is described in Sections
3.3.1, 8 and 11.3 of RFC3711.
 
/Mats

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Ilan Doron
	Sent: den 6 juli 2009 16:23
	To: [email-masked]'
	Subject: [AVT] Question regarding RFC 3711

	   reset to zero.

	Ilan Doron

	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/> 

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

---

From: "Wyss, Felix" <[email-masked]>
Date: Mon, 6 Jul 2009 13:28:20 -0400

[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

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).

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

---

From: "Wyss, Felix" <[email-masked]>
Date: Wed, 8 Jul 2009 12:24:36 -0400

Based on 3.2.3 of RFC#3711, the cryptographic context is identified by the triple <SSRC, source address, destination address>.  Thus, if your re-invite does not change any of these, it applies to the same context and the ROC must not be reset (as per 3.3.1).

In practice, consider changing the SSRC on a re-keying re-invite to force a new cryptographic context and re-synchronize the receiving device. That way, it will just work if the other device handles the re-invite differently (e.g. by discarding all its crypto contexts) instead of difficult to diagnose bug reports of "one-way-audio" from the field.

--Felix

From: Ilan Doron [mailto:[email-masked]]
Sent: Wednesday, July 08, 2009 04:09
To: [email-masked]; Wyss, Felix
Subject: RE: Question regarding RFC 3711

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]

Ilan Doron

---

From: Ilan Doron <[email-masked]>
Date: Mon, 13 Jul 2009 11:55:24 +0300

Thank u very much for your help.
We are clear with our issues now.

The suggestion of changing SSRC upon re keying is helpful.
But previously we had problems with some applications that couldn't handle SSRC changes during a session (if I recall it was some version of Quick time player) so I am not sure if we can apply this change.

Anyway thanx again.

Ilan Doron

From: Wyss, Felix [mailto:[email-masked]]
Sent: Wednesday, July 08, 2009 19:25
To: Ilan Doron; IETF AVT WG
Subject: RE: Question regarding RFC 3711

--Felix

Hi

Am I getting this right?

[inline]

Ilan Doron